rfc1582.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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]

RFC 1582                       Demand RIP                  February 1994


          7.1. Database Timer ................................... 24
          7.2. Retransmission Timer ............................. 25
          7.3. Reassembly Timer ................................. 26
      8. Implementation Considerations ...........................27
      9. Security Considerations ................................ 27
     10. References ............................................. 28
     11. Author's Address ....................................... 29

1. Introduction

   Routers are used on connection oriented networks, such as X.25 packet
   switched networks and ISDN networks, to allow potential connectivity
   to a large number of remote destinations.  Circuits on the Wide Area
   Network (WAN) are established on demand and are relinquished when the
   traffic subsides.  Depending on the application, the connection
   between any two sites for user data might actually be short and
   relatively infrequent.

   Practical experience of routing shows that periodic 'broadcasting' of
   routing updates on the WAN is unsatisfactory on several counts:

   o  Running a routing protocol like RIP is expensive if the standard
      form of transmitting routing information to every next hop router
      every 30 seconds is adhered to.  The more routers there are
      wishing to exchange information the worse the problem.  If there
      are N routers on the WAN, N * (N - 1) routing updates are sent over
      N * (N - 1)/2 connections every broadcast period.

      The expense arises because a circuit has to be kept open to each
      destination to which routing information is to be sent.  Routing
      updates are sufficiently frequent that little benefit is obtainable
      on most networks by attempting to set up a call purely for
      the duration of the routing update. (There are often minimum call
      charges, or there is a charge to set up a call irrespective of
      what data is sent.)

      The option of reducing the 'broadcast' frequency, while reducing
      the cost, would make the system less responsive.

   o  The number of networks to be connected (N) on the WAN can easily
      exceed the number of simultaneous calls (M) which the interface
      can support.  If this happens the routing 'broadcast' will only
      reach M next hop routers, and (N - M) next hop routers will not
      receive the routing update.

      A basic rate ISDN interface can support 2 simultaneous calls, and
      even the number of logical channels most users subscribe to on an
      X.25 network is not large.  There is no fundamental reason why



Meyer                                                           [Page 3]

RFC 1582                       Demand RIP                  February 1994


      routing protocols should restrict the user to routing between so
      few sites.

   o  Since there is no broadcast facility on the WAN, 'broadcasting' of
      routing information actually consists of sending the updates
      separately to all known locations.  This means that N routing
      updates are queued for transmission on the WAN link (in addition
      to any data which might be queued).

      Routers take a pragmatic view on queuing datagrams for the WAN.
      If the queue length gets too long, so that datagrams at the end of
      the queue would take too long be transmitted in a reasonable time
      (say 1 to 2 seconds) the router may start discarding them.  On an
      X.25 network, with slow line speeds (perhaps 9600 baud), it may
      not take too many routing updates to fulfill this condition if the
      link is also actively being used to carry user data.

   This memo addresses all the above problems.

   The approach taken is to modify the routing protocols so as to send
   information on the WAN only when there has been an update to the
   routing database OR a change in the reachability of a next hop router
   is indicated by the task which manages connections on the WAN.

   Because datagrams are not guaranteed to get through on all WAN media,
   an acknowledgement and retransmission system is required to provide
   reliability.

   This memo describes the modifications required for Bellman-Ford (or
   distance vector) algorithm information broadcasting protocols, such
   as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN.  The protocols
   run unmodified on Local Area Networks (LANs) or fixed point-to-point
   links, and so interoperate transparently with implementations
   adhering to the original specifications.

2. Running Routing Protocols on the WAN

2.1 Overview

   Multiprotocol routers are used on connection oriented Wide Area
   Networks (WANs), such as X.25 packet switched networks and ISDN
   networks, to interconnect LANs.  By using the multiplexing properties
   of the underlying WAN technology, several LANs can be interconnected
   simultaneously through a single physical interface on the router.

   A circuit manager provides an interface between the connectionless
   network layers (IP, IPX, CLNP etc) and the connection oriented WAN
   (X.25 or ISDN).  Figure 1 shows a schematic representative stack



Meyer                                                           [Page 4]

RFC 1582                       Demand RIP                  February 1994


   showing the relationship between routing protocols, the network
   layers, the circuit manager and the connection oriented WAN.

             --------------           ---------  ---------
             |    RIP     |           |  RIP  |  |  SAP  |
             --------------           ---------  ---------
                   |                      |          |
             --------------               |          |
             |    UDP     |               |          |
             --------------               |          |
                   |                      |          |
             --------------             ----------------
             |    IP      |             |     IPX      |
             --------------             ----------------
                   |                           |
             -------------------------------------------
             |             Circuit Manager             |
             -------------------------------------------
                              ||||||||||
                              ||||||||||
                      ---------------------------
                      |   Connection Oriented   |
                      |        WAN stack        |
                      ---------------------------

     A WAN circuit manager will support a variety of network layer
     protocols, on its upper interface.  On its lower interface, it
     may support one or more subnetworks.  A subnetwork may support a
     number of Virtual Circuits.


            Figure 1.   Representative Multiprotocol Router stack

   The router has a translation table which relates the network layer
   address of the next hop router to the physical address used to
   establish a Virtual Circuit (VC) to it.  Datagrams may be
   encapsulated in a header to distinguish the network layer protocol
   [5].

   The circuit manager takes datagrams from the connectionless network
   layer protocols and (if one is not currently available) opens a VC to
   the next hop router.  A VC can carry all traffic between two end-
   point routers for a given network layer protocol (or with appropriate
   encapsulation all network layer protocols).  An idle timer is used to
   close the VC when the datagrams stop arriving at the circuit manager.

   Running routing protocols on the WAN has traditionally consisted of
   making small modifications to the methods used on LANs.  Where



Meyer                                                           [Page 5]

RFC 1582                       Demand RIP                  February 1994


   routing information would be broadcast periodically on a LAN
   interface, it is converted to a series of periodic updates sent to a
   list of addresses on the WAN.

   This memo targets two areas:

   o  Eliminating the overkill inherent in periodic transmission of
      routing updates.

   o  Overcoming the bandwidth limitations on the WAN: the number of
      simultaneous VCs to next hop routers and restricted data
      throughput which the WAN link can support.

   The first of these is overcome by transmitting routing updates
   (called routing responses) only when required:

   o  Firstly, when a specific request for a routing update has been
      received.

   o  Secondly, when the routing database is modified by new
      information from another interface.

      Update information received in this way is not normally
      propagated on other interfaces immediately, but is delayed for a
      few seconds to allow information from several updates to be
      grouped.

   o  Thirdly, when the circuit manager indicates that a destination
      has changed from an unreachable (circuit down) to a reachable
      (circuit up) state.

   Because of the inherent unreliability of a datagram based system,
   both routing requests and routing responses require acknowledgement,
   and retransmission in the event of NOT receiving an acknowledgement.

   To overcome the bandwidth limitations the routing application can
   perform a form of self-imposed flow control, to spread routing
   updates out over a period of time.

2.2 Presumption of Reachability