Protocol Analysis for Triggered RIP
draft-ietf-rip-trigger-analysis-01
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2092.
|
|
---|---|---|---|
Authors | Dr. Gerry Meyer , Steven Sherry | ||
Last updated | 2020-01-21 (Latest revision 1996-07-10) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 2092 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-rip-trigger-analysis-01
Network Working Group S. Sherry Internet Draft Xyplex Expires 10 Jan, 1997 G.M. Meyer Shiva Ltd Protocol Analysis for Triggered RIP draft-ietf-rip-trigger-analysis-01.txt Status of this Memo This document is a submission to the RIP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-rip@xylogics.com mailing list. Distribution of this memo is unlimited. 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, and 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted. Acknowledgements The authors wish to thank Johanna Kruger and Jim Pearl of Xyplex for many comments and suggestions which improved this effort. Meyer [Page 1] Internet Draft Triggered RIP Protocol Analysis July 1996 1. Protocol Documents "Triggered 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). 2. Applicability Triggered RIP requires that there is an underlying mechanism for determining unreachability in a finite predictable period. The triggered 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 triggered RIP implementation runs standard RIP on Local Area Net- works (LANs) allowing them to interoperate transparently with imple- mentations adhering to the original specifications. 3. Key Features The proposal shares the same basic algorithms as RIP or RIP-2 when running on LANs; 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; Or on permanent WAN connections where there is a desire to keep routing packet overhead to a minimum. 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 Meyer [Page 2] Internet Draft Triggered RIP Protocol Analysis July 1996 unique command field) to include sequence 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. Meyer [Page 3] Internet Draft Triggered RIP Protocol Analysis July 1996 4. Relationship to Demand RIP The Triggered RIP proposal [2] has a number of efficiency advantages over the Demand RIP proposal [5]: o When routing information changes Demand RIP sends the full database to its partner. Once a router has exchanged all routing information with its partner, Triggered RIP sends only the changed information to the partner. This can dramatically decrease the quantity of information requiring propagation when a route change occurs. o Demand RIP requires a full routing update to be stored by the receiver, before applying changes to the routing database. A Triggered RIP receiver is able to apply all changes immediately upon receiving each packet from its partner. Systems therefore need to use less memory than Demand RIP. o Demand RIP has an upper limit of 255 fragments in an update. This sets an upper limit on the sizes of routing and service advertising databases which can be propagated. This restriction is lifted in Triggered RIP (which does not use fragmentation). In all other respects Demand RIP and Triggered RIP perform the same function. 5. Obsoleting Demand RIP While it is possible that systems could be able to support Demand RIP and Triggered RIP, the internal maintenance of structures is likely to differ significantly. The method of propagating the information also differs significantly. In practice it is unlikely that systems would support Demand RIP and Triggered RIP. As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted. 6. Implementations At this stage there are believed to be two completed implementation. The Xyplex implementation supports all the features outlined for IP RIP-1, IP RIP-2, IPX RIP, and IPX SAP. However, it only supports one outstanding acknowledgement per partner. The implementation has been Meyer [Page 4] Internet Draft Triggered RIP Protocol Analysis July 1996 tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs, and asynchronous modems. It has also been tested in operation with various router and host implementations on Ethernet LANs. The DEC implementation supports IP RIP-1 over ISDN, Frame Relay, leased lines and V.25bis. The Xyplex and DEC IP RIP-1 implementations have been checked for interoperability over ISDN without problems. 7. 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. 8. 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. 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. and Sherry, S., "Triggered Extensions to RIP to Support Demand Circuits", Internet Draft "draft-ietf-rip- trigger-rip-00.txt", Spider Systems, Aug 1995. [3] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988. [4] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1723, Xylogics, November 1994. Meyer [Page 5] Internet Draft Triggered RIP Protocol Analysis July 1996 [5] Meyer. G., "Extensions to RIP to Support Demand Circuits", Spider Systems, February 1994. Authors' Address: Steve Sherry Xyplex 295 Foster St. Littleton, MA 01460 Phone: (US) 508 952 4745 Fax: (US) 508 952 4887 Email: shs@xyplex.com Gerry Meyer Shiva Europe Ltd Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 131 554 9424 Fax: (UK) 131 554 0649 Email: gerry@europe.shiva.com Meyer [Page 6]