Movatterモバイル変換

Network Working Group                                     S. SherryRequest for Comments: 2092                                   XyplexCategory: Informational                                    G. Meyer                                                              Shiva                                                       January 1997Protocol Analysis for Triggered RIPStatus 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 19973.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 19974. 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 1997References   [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.comSherry & Meyer               Informational                      [Page 6]