"Extensions to RIP to Support Demand Circuits"  suggests an enhancement to the "Routing Internet Protocol" (RIP)  and "RIP-2"  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 .
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.
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.
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.
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.
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.
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  where appropriate.