Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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.


 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.


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

4. Implementations

 At this stage there is only believed to be one completed
 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

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 for any routes advertised on the WAN.

Meyer [Page 3] RFC 1581 Demand RIP February 1994

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

7. 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., "Extensions to RIP to Support Demand Circuits", RFC
     1582, Spider Systems, February 1994.
 [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
     Rutgers University, June 1988.
 [4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
     RFC 1388, Xylogics, January 1993.
 [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC
     1389, Xylogics, ACC, January 1993.

Author's Address

     Gerry Meyer
     Spider Systems
     Stanwell Street
     Edinburgh EH6 5NG
     Scotland, UK
     Phone: (UK) 31 554 9424
     Fax:   (UK) 31 554 0649

Meyer [Page 4]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1581.txt · Last modified: 1994/02/17 00:35 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki