Protocol Analysis for Extensions to RIP to Support Demand Circuits
RFC 1581

Document Type RFC - Informational (February 1994; No errata)
Was draft-meyer-rip-analysis (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1581 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           G. Meyer
Request for Comments: 1581                                Spider Systems
Category: Informational                                    February 1994

   Protocol Analysis for Extensions to RIP to Support Demand Circuits

Status of this Memo

   This document provides information for the Internet community.  This
   document does not specify an Internet standard of any kind.
   Distribution of this document is unlimited.

Abstract

   As required by Routing Protocol Criteria [1], this report documents
   the key features of Routing over Demand Circuits on Wide Area
   Networks - RIP [2] and the current implementation experience.

Acknowledgements

   I would like to thank colleagues at Spider, in particular Richard
   Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP
   and SAP implementations.

1. Protocol Documents

   "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).  Network management extensions for Demand RIP are described
   in RIP Version 2 MIB Extensions [5].

2. Applicability

   Demand RIP requires that there is an underlying mechanism for
   determining unreachability in a finite predictable period.

   The demand 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.

Meyer                                                           [Page 1]
RFC 1581                       Demand RIP                  February 1994

   A demand 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 or fixed point-to-point links; 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.  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 and fragment 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:

Meyer                                                           [Page 2]
RFC 1581                       Demand RIP                  February 1994

   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.

   To prevent transmit queue overflow and also to avoid 'predictable'
   circuit down messages, the routing application can also optionally
   limit the rate of sending routing messages to an interface.
Show full document text