rfc1582.txt

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

   If a routing update is received from a next hop router on the WAN,
   entries in the update are thereafter always considered to be
   reachable, unless proven otherwise:

   o  If in the normal course of routing datagrams, the circuit manager
      fails to establish a connection to the next hop router, it
      notifies the routing application that the next hop router is not



Meyer                                                           [Page 6]

RFC 1582                       Demand RIP                  February 1994


      reachable through an internal circuit down message.

      The routing application then goes through a process of timing out
      database entries to make them unreachable in the routing sense.

   o  If the circuit manager is subsequently able to establish a
      connec tion to the next hop router, it will notify the routing
      applica tion that the next hop router is reachable through an
      internal circuit up message.

      The routing application will then exchange messages with the next
      hop router so as to re-prime their respective routing databases
      with up-to-date information.

   Handling of circuit up and circuit down messages requires that the
   circuit manager takes responsibility for establishing (or
   reestablishing) the connection in the event of a next hop router
   becoming unreachable.  A description of the processes the circuit
   manager adopts to perform this task is outside the scope of this
   memo.

2.3 WAN Router list

   The routing task MAY be provided with a list of routers to send
   routing updates to on the WAN.  It will comprise of the logical
   addresses of next hop routers for which the router has a logical to
   physical address mapping.  Entries in the list SHOULD be categorized
   (on a per-peer basis) as follows:

   o  Running the standard routing protocol, namely transmitting
      updates periodically with the packet formats used in LAN
      broadcasts.

      This option is supported to allow interoperability with existing
      routing implementations, and might also be appropriate if some
      of the destinations are using Permanent Virtual Circuits (PVCs)
      rather than SVCs.

   o  Running the triggered update routing protocol proposed in this
      memo.

   Omitting an address from both of these categories is equivalent to
   not running the routing protocols.

   If routing packets arrive from a destination not supporting the
   appropriate variant they MUST be discarded.





Meyer                                                           [Page 7]

RFC 1582                       Demand RIP                  February 1994


2.4 Triggered Updates and Unreliable Delivery

   If triggered update information is sent to next hop routers on the
   WAN only once it can fail to arrive for one of the following reasons:

   o  A free VC resource might not be available, because of a
      restricted number of X.25 logical channels or ISDN B-channels.

   o  The transmit queue might be full - requiring the datagram to be
      discarded.

   o  The VC might be pre-empted (in favour of establishing a VC to
      another next hop router) while the datagram is in a queue,
      resulting in the queue being flushed and the datagram
      discarded.

   o  In cases where the method of transport is not guaranteed, for
      example with PPP where there is no acknowledgement and
      retransmission of HDLC frames, a corrupted frame will result in
      the loss of the datagram.

2.5 Guaranteeing delivery of Routing Updates

   To guarantee delivery of routing updates on the WAN an
   acknowledgement and retransmission scheme MUST be used:

   o  Send a routing update to a next hop router on the WAN.

   o  The other router responds with an acknowledgement packet.

      The original router receives the acknowledgement.

   o  Otherwise the original router retransmits the update until an
      acknowledgement is received.

      Retransmission timer values are covered in section 7.

      In cases where the routing database is modified before an
      acknowledgement is received a new routing update with an
      updated sequence number is sent out.  If an acknowledgement for
      the old routing update is received it is ignored.

   o  A router only updates its routing database when it receives a
      complete update, which may consist of several fragments.  Each
      fragment is individually acknowledged.

   The above mechanism caters for cases where the datagram is lost
   because of a frame error or is discarded because of an over-full



Meyer                                                           [Page 8]

RFC 1582                       Demand RIP                  February 1994


   queue.  The routing update and acknowledgement will eventually both
   get through.

   In cases where the circuit manager cannot establish a connection, a
   mechanism is provided to allow the circuit manager to inform the
   routing task of the failure to make a connection so that it can
   suppress retransmissions until a circuit becomes available.

2.6 The Routing Database

   A requirement of using triggered updates for propagating routing
   information is that NO routing information ever gets LOST or
   DISCARDED.

   The routing database MUST adopt one of the following strategies:

   o  It must keep ALL alternative routing information it learns from
      any routing updates from the LAN and the WAN, so that if the
      best route disappears an alternative route (if available) can
      replace it as the new best route.

   o  If the amount of memory this consumes is problematic the routing
      application must keep SOME alternative routing information - say
      a best route and two alternatives.

      If the router ever has to discard routing information about a
      route it should note the fact.  If the routes that have been
      kept disappear because they have become unreachable, the router
      MUST issue a request on all interfaces to try and obtain
      discarded alternatives.

      It is recommended that the request is issued BEFORE all routes
      to a destination have been lost.

   Entries in the routing database can either be permanent or temporary.
   Entries learned from broadcasts on LANs are temporary. They will
   expire if not periodically refreshed by further broadcasts.

   Entries learned from a triggered response on the WAN are 'permanent'.
   They MUST not time out in the normal course of events.  The entries
   state MUST be changed to 'temporary' by the following events:

   o  The arrival of a routing update containing the entry set to
      unreachable.

      The normal hold down timer MUST be started, after which the
      entry disappears from the routing database.




Meyer                                                           [Page 9]

RFC 1582                       Demand RIP                  February 1994


   o  The arrival of a routing update with the entry absent.

      If the hold down timer is not already running, the entry MUST be
      set to unreachable and the hold down timer started.

   o  A message sent from the circuit manager, to indicate that it
      failed to make a connection in normal running.

      The routing table MUST be scanned for all routes via that next
      hop router.  Aging of these routing entries MUST commence.  If
      the aging timer expires the entry MUST be set to unreachable and
      the hold down timer started.  If the hold down timer expires the
      entry disappears from the routing database.

   o  If the interface goes down, the circuit manager should indicate
      that all circuits on that interface have gone down.

   Database timer values are covered in section 7.

2.7 New Packet Types

   To support triggered updates, three new packet types MUST be
   supported:

   TRIGGERED REQUEST

             A request to the responding system to send all
             appropriate elements in its routing database.

             A triggered request is retransmitted at periodic
             intervals until a triggered response is received.

             Routing requests are transmitted in the following
             circumstances:

             o  Firstly when the router is powered on.

             o  Secondly when the circuit manager indicates a
                destination has been in an unreachable (circuit down)
                state for an extended period and changes to a
                reachable (circuit up) state.

             o  Thirdly in the event of all routing update fragments
                failing to arrive within a set period.

             o  It may also send triggered requests at other times to
                compensate for discarding non-optimal routing
                information.



Meyer                                                          [Page 10]

RFC 1582                       Demand RIP                  February 1994


   TRIGGERED RESPONSE

             A message containing all appropriate elements of the
             routing database.  An appropriate element is an entry
             NOT learned from the interface to which the routing
             information is being sent out.  This is known as "split
             horizon".

             Stability is improved by adding "poisoned reverse" on
             routes learned from a destination.  This consists of also
             including some routes learned from a destination in
             routing updates sent back to that destination, but
             setting the routes as unreachable.  A route is only
             poisoned if it is the best route (rather than an inferior
             alternative route) in the database.

             A triggered response message may be sent in response to a
             triggered request, or it may be an update message issued
             because of a change in the routing database.

             A triggered response message MUST be sent in response to
             a triggered request message even if there are no routes
             to propagate.  This would be the case for a host which
             had a WAN interface only, but which wished to run the
             triggered update protocol.

             A triggered response is retransmitted at periodic
             intervals until a triggered acknowledgement is received.

   TRIGGERED ACKNOWLEDGEMENT

             A message sent in response to every triggered response
             packet received.

   Triggered response and triggered acknowledgement packets MUST contain
   additional fields for a sequence number, fragment number and number
   of fragments.

   If a triggered request or response is not acknowledged after 10
   retransmissions, routes to the destination should be marked as
   unreachable for the duration of a hold down timer before being
   deleted.

   The destination should then be polled at a lower frequency using
   triggered request packets.  When a triggered response is received,
   the router should prime the next hop router my sending its routing
   database through triggered response packets.




Meyer                                                          [Page 11]

RFC 1582                       Demand RIP                  February 1994


   Strictly speaking polling should occur indefinitely to guarantee
   database integrity.  However the administrator MAY wish the router to
   cease polling after a few attempts believing that the lack of
   response is due to a mis-configuration of the next hop router.  The
   destination should be marked as NOT supporting the mechanism and no
   further routing messages should be sent to that destination.

   Before marking the destination as not supporting the mechanism, at
   least 5 triggered request polls (without acknowledgement) should be
   sent.

   If a destination marked as not supporting the mechanism, subsequently
   sends a valid 'triggered' message, the destination should be marked
   as supporting the mechanism once more (to allow for the next hop
   router's configuration being changed).  It should be sent a triggered
   request and a triggered response to obtain and propagate up-to-date
   routing information.

2.8 Fragmentation

   If a routing update is sufficiently large, the information MUST be
   fragmented over several triggered response packets:

   o  Each fragment MUST be individually acknowledged with a triggered
      acknowledgement packet.

      The sender of the routing update MUST periodically retransmit
      fragments which have not been acknowledged (or until the
      destination is marked as not supporting the mechanism).