Protocol Analysis for Extensions to RIP to Support Demand Circuits
Using RIP on dial-up networks without constant polling
Meyer, G., "Protocol Analysis for Extensions to RIP to Support Demand Circuits", RFC 1581, DOI 10.17487/RFC1581, February 1994, <https://www.rfc-editor.org/info/rfc1581>.
@misc{rfc1581,
series = {Request for Comments},
number = 1581,
howpublished = {RFC 1581},
publisher = {RFC Editor},
doi = {10.17487/RFC1581},
url = {https://www.rfc-editor.org/info/rfc1581},
author = {G. Meyer},
title = {{Protocol Analysis for Extensions to RIP to Support Demand Circuits}},
pagetotal = 4,
year = 1994,
month = feb,
} RFC text
Contents
Network Working Group G. Meyer Request for Comments: 1581 Spider Systems Category: Informational February 1994 Protocol Analysis for Extensions to RIP to Support Demand Circuits Status of this Memo This document provides information for the Internet community. This document does not specify an Internet standard of any kind. Distribution of this document is unlimited. Abstract As required by Routing Protocol Criteria [1], this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP [2] and the current implementation experience. Acknowledgements I would like to thank colleagues at Spider, in particular Richard Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP and SAP implementations. 1. Protocol Documents "Extensions to RIP to Support Demand Circuits" [2] suggests an enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" [4] to allow them to run more cost-effectively on Wide Area Networks (WANs). Network management extensions for Demand RIP are described in RIP Version 2 MIB Extensions [5]. 2. Applicability Demand RIP requires that there is an underlying mechanism for determining unreachability in a finite predictable period. The demand extensions to RIP are particularly appropriate for WANs where the cost - either financial or packet overhead - would make periodic transmission of routing (or service advertising) updates unacceptable: o Connection oriented Public Data Networks - for example X.25 packet switched networks or ISDN. o Point-to-point links supporting PPP link quality monitoring or echo request to determine link failure. A demand RIP implementation runs standard RIP on Local Area Networks (LANs) allowing them to interoperate transparently with implementations adhering to the original specifications. 3. Key Features The proposal shares the same basic algorithms as RIP or RIP-2 when running on LANs or fixed point-to-point links; Packet formats, broadcast frequency, triggered update operation and database timeouts are all unmodified. The new features operate on WANs which use switched circuits on demand to achieve intermittent connectivity. Instead of using periodic 'broadcasts', information is only sent as triggered updates. The proposal makes use of features of the underlying connection oriented service to provide feedback on connectivity. 3.1 Triggered Updates Updates are only sent on the WAN when an event changes the routing database. Each update is retransmitted until acknowledged. Information received in an update is not timed out. The packet format of a RIP response is modified (with a different unique command field) to include sequence and fragment number information. An acknowledgement packet is also defined. 3.2 Circuit Manager The circuit manager running below the IP network layer is responsible for establishing a circuit to the next hop router whenever there is data (or a routing update) to transfer. After a period of inactivity the circuit will be closed by the circuit manager. If the circuit manager fails to make a connection a circuit down indication is sent to the routing application. The circuit manager will then attempt at (increasing) intervals to establish a connection. When successful a circuit up indication is sent to the routing application. 3.3 Presumption of Reachability In a stable network there is no requirement to propagate routing information on a circuit, so if no routing information is (being) received on a circuit it is assumed that: o The most recently received information is accurate. o The intervening path is operational (although there may be no current connection). If the circuit manager determines that the intervening path is NOT operational routing information previously received on that circuit is timed out. It is worth stressing that it can be ANY routed datagram which triggers the event. When the circuit manager re-establishes a connection, the application exchanges full routing information with its peer. 3.4 Routing Information Flow Control If the circuit manager reports a circuit as down, the routing application is flow controlled from sending further information on the circuit. To prevent transmit queue overflow and also to avoid 'predictable' circuit down messages, the routing application can also optionally limit the rate of sending routing messages to an interface. 4. Implementations At this stage there is only believed to be one completed implementation. The Spider Systems' implementation supports all the features outlined for IP RIP-1, IPX RIP and IPX SAP. RIP-2 is not currently supported. It has been tested against itself on X.25 and ISDN WANs. It has also been tested in operation with various router and host RIP-1, IPX RIP and IPX SAP implementations on Ethernet LANs. Two other Novell-only implementations are known to be under development. 5. Restrictions Demand RIP relies on the ability to place a call in either direction. Some dialup services - for example DTR dialing - allow calls to be made in one direction only. Demand RIP can not operate with third-party advertisement of routes on the WAN. The next hop IP address in RIP-2 should always be 0.0.0.0 for any routes advertised on the WAN. 6. Security Considerations Security is provided through authentication of the logical and physical address of the sender of the routing update. Incoming call requests are matched by the circuit manager against a list of physical addresses (used to make outgoing calls). The routing application makes a further check against the logical address of an incoming update. Additional security can be provided by RIP-2 authentication [2] where appropriate. 7. References [1] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, Bolt Beranek and Newman, Inc, October 1991. [2] Meyer. G., "Extensions to RIP to Support Demand Circuits", RFC 1582, Spider Systems, February 1994. [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988. [4] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1388, Xylogics, January 1993. [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC 1389, Xylogics, ACC, January 1993. Author's Address Gerry Meyer Spider Systems Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 31 554 9424 Fax: (UK) 31 554 0649 EMail: gerry@spider.co.uk
AI ELI5
On this page
§1RIP and the Demand Circuit Problem
Standard RIP (Routing Information Protocol) sends periodic routing updates at fixed intervals. This works fine on local area networks where the link is always available and bandwidth is plentiful, but on wide-area networks using switched circuits like X.25 packet networks or ISDN, every connection costs money. A router that sends routing updates every 30 seconds across a switched line will incur continuous costs even when the network is stable and no changes need to be communicated.
This RFC documents how extensions to RIP can make it practical for dial-up and switched WAN links. Instead of periodic broadcasting, Demand RIP sends updates only when the routing database changes.
A postcard says the same thing every minute whether anything changed or not. A smarter system waits until it has real news to share.
§2How Demand RIP Works
Demand RIP introduces four key mechanisms. Triggered updates replace periodic broadcasts: updates are sent only when something in the routing database changes, and they are retransmitted until acknowledged. The packet format includes sequence and fragment numbers to track delivery.
A circuit manager runs below the network layer and controls when connections are made. When a router has data or a routing update to send, the circuit manager establishes a connection to the peer. After inactivity, the circuit closes automatically. If the circuit manager detects the line is down, it signals this to the routing application.
Presumption of reachability means that in a stable network, if no updates are being received on a circuit, the router assumes the most recent information is still valid and the path is still working. This avoids the need to poll. When the circuit manager detects the path is truly down, only then does the routing information time out.
Finally, flow control prevents the router from sending updates when the circuit is down, and optionally rate-limits update transmission to avoid overwhelming the circuit.
The circuit manager is like a receptionist who only opens the office door when there is business to do, and closes it when things are quiet. Routes are assumed still good unless we hear they are broken.
§3Implementation and Limits
At the time this RFC was written, Spider Systems had completed an implementation supporting RIP-1 and IPX RIP on X.25 and ISDN networks, and it interoperated with standard RIP implementations on Ethernet LANs. Two other Novell-only implementations were in development.
Demand RIP does have restrictions. It requires the ability to place calls in both directions; some dial-up services allow calls in only one direction. It also cannot work with third-party advertisement of routes on the WAN—the next-hop address in RIP-2 advertisements must be 0.0.0.0 on a demand circuit.
The system works when both sides can call each other, and when routes are announced from the actual router sending the update.
§4Security on Demand Links
The circuit manager matches incoming call requests against a list of approved physical addresses. The routing application checks the logical address of incoming updates. This two-layer authentication prevents unauthorized routers from sending updates across the WAN. RIP-2 authentication can provide an additional layer of security where needed.
The phone number and the sender's address must both match a trusted list before the router listens to an update.