RFC 1581 (rfc1581) - Page 3 of 4
Protocol Analysis for Extensions to RIP to Support Demand Circuits
Alternative Format: Original Text Document
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