Network Working Group G.M. Meyer Internet Draft Spider Systems Expires Dec 25, 1993 Jun 1993 Routing over Demand Circuits - RIP Protocol Analysis Status of this Memo This memo is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Distribution of this memo 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. Meyer [Page 1] Internet Draft Routing over Demand Circuits - Analysis Jun 1993 1. Protocol Documents "Routing over Demand Circuits on Wide Area Networks - RIP" [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). 2. 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. 2.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. 2.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. Meyer [Page 2] Internet Draft Routing over Demand Circuits - Analysis Jun 1993 2.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. 2.4 Routing Information Flow Control If the circuit manager reports a circuit as down, the routing appli- cation 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. 3. Implementations At this stage there is only believed to be one 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. 4. Security Considerations Security is provided through authentication of the logical and physi- cal address of the sender of the routing update. Incoming call requests are matched by the circuit manager against a list of physi- cal addresses (used to make outgoing calls). The routing application makes a further check against the logical address of an incoming update. Meyer [Page 3] Internet Draft Routing over Demand Circuits - Analysis Jun 1993 Additional security can be provided by RIP-2 authentication [2] where appropriate. 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.M., "Routing over Demand Circuits on Wide Area Networks - RIP", Internet Draft "draft-meyer-demandrouting-01.txt", Spider Systems, May 1991. [3] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988. [4] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1388 Draft, Xylogics, 1992. 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 Meyer [Page 4]