Extensions to RIP to Support Demand Circuits
RFC 1582

 
Document Type RFC - Proposed Standard (February 1994; No errata)
Was draft-meyer-demandrouting (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1582 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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.

Abstract

   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.

Acknowledgements

   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.

Conventions

   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 optional and may be followed
         or ignored according to the needs of the implementor.

   The words "should" and "may" are also used, in lower case, in their
   more ordinary senses.

Table of Contents

      1. Introduction ...........................................  3
      2. Running a routing Protocol on the WAN ..................  4
          2.1. Overview .........................................  4
          2.2. Presumption of Reachability ......................  6
          2.3. WAN Router list ..................................  7
          2.4. Triggered Updates and Unreliable Delivery ........  8
          2.5. Guaranteeing delivery of Routing Updates .........  8
          2.6. The Routing Database .............................  9
          2.7. New Packet Types ................................. 10
          2.8. Fragmentation .................................... 12
          2.9. Preventing Queue Overload ........................ 13
      3. IP Routing Information Protocol Version 1 .............. 13
      4. IP Routing Information Protocol Version 2 .............. 16
      5. Netware Routing Information Protocol ................... 17
      6. Netware Service Advertising Protocol ................... 20
      7. Timers ................................................. 24

Meyer                                                           [Page 2]
Show full document text