1 files changed, 339 insertions, 0 deletions
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]
+