From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2092.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc2092.txt (limited to 'doc/rfc/rfc2092.txt') diff --git a/doc/rfc/rfc2092.txt b/doc/rfc/rfc2092.txt new file mode 100644 index 0000000..eadee35 --- /dev/null +++ b/doc/rfc/rfc2092.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group S. Sherry +Request for Comments: 2092 Xyplex +Category: Informational G. Meyer + Shiva + January 1997 + + + Protocol Analysis for Triggered RIP + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +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. + +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. + + + +Sherry & Meyer Informational [Page 1] + +RFC 2092 Triggered RIP Protocol Analysis January 1997 + + + 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 + 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; 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 + 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. + + + + + + + + +Sherry & Meyer Informational [Page 2] + +RFC 2092 Triggered RIP Protocol Analysis January 1997 + + +3.3 Technology Restrictions + + There is a small but nontrivial possiblility of an incorrectly + configured or poorly operating link causing severe data loss, + resulting in a 'black hole' in routing. This is often unidirectional + - the link that route updates cross works properly, but not the + return path. + + Triggered RIP will NOT fuction properly (and should NOT be used) if a + routing information will be retained/advertised for an arbitrarily + long period of time (until an update in the opposite direction fails + to obtain a response). + + To detect black holes in technologies which use PPP encapsulation, + either Echo Request/Response or Link Quality Monitoring should be + used. When a black hole is detected a circuit down indication must + be sent to the routing application. + + Current (and future) technologies which do not use PPP, need to use + an equivalent 'are-you-there' mechanism - or should NOT be used with + Triggered RIP. + +3.4 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.5 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. + + + + + +Sherry & Meyer Informational [Page 3] + +RFC 2092 Triggered RIP Protocol Analysis January 1997 + + +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. + + + + + + + +Sherry & Meyer Informational [Page 4] + +RFC 2092 Triggered RIP Protocol Analysis January 1997 + + + 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 + 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. + + + + + + + + + + + + + + + + + + +Sherry & Meyer Informational [Page 5] + +RFC 2092 Triggered RIP Protocol Analysis January 1997 + + +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", RFC 2091, Shiva and Xyplex, 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. + + [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 561 4223 + Fax: (UK) 131 561 4083 + Email: gerry@europe.shiva.com + + + + + + + + + + + + + +Sherry & Meyer Informational [Page 6] + -- cgit v1.2.3