RFC 1581 (rfc1581) - Page 3 of 4

Protocol Analysis for Extensions to RIP to Support Demand Circuits

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.

4. Implementations

   At this stage there is only believed to be one completed
   implementation.

   The Spider Systems' implementation supports all the features outlined
   for IP RIP-1, IPX RIP and IPX SAP.  RIP-2 is not currently supported.
   It has been tested against itself on X.25 and ISDN WANs.  It has also
   been tested in operation with various router and host RIP-1, IPX RIP
   and IPX SAP implementations on Ethernet LANs.

   Two other Novell-only implementations are known to be under
   development.

5. 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.





Meyer