Extensions to RIP to Support Demand Circuits (RFC1582)
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]
Network Working Group G. Meyer Request for Comments: 1582 Spider Systems Category: Standards Track February 1994
Extensions to RIP to Support Demand Circuits
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Running routing protocols on connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data.
Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide Area Network (WAN).
This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above.
The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links.
Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface. When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received.
Meyer [Page 1]
RFC 1582 Demand RIP February 1994
The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.
I would like to thank colleagues at Spider, in particular Richard Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM), Martha Steenstrup (BBN), and members of the RIP-2 working group of the IETF for stimulating discussions and comments which helped to clarify this memo.
The following language conventions are used in the items of specification in this document:
o MUST -- the item is an absolute requirement of the specification. MUST is only used where it is actually required for interoperation, not to try to impose a particular method on implementors where not required for interoperability.
o SHOULD -- the item should be followed for all but exceptional cir- cumstances.
o MAY or optional -- the item is truly o...