Protocol Analysis for Triggered RIP
RFC 2092

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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