rfc1582.txt

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

   further 30 octets).

7. Timers

   A number of timers are supported to handle the triggered update
   mechanism:

   o  Database timers.

   o  Retransmission timer.

   o  Reassembly timer.

   In this section appropriate timer values for IP RIP are suggested.

   For other routing protocols, only the database timer should need to
   take different values.  The database timer values are chosen to match
   equivalent timer operation for using the protocol on a LAN.  The
   behaviour of a routing entry when a timer is running becomes
   indistinguishable from a routing entry learned from a broadcast
   update.

   Implementations MAY make timer values configurable - and hence
   different from the values suggested here - but interoperability
   requires that all timers on a sub-network should be the same in all
   routers.

7.1 Database Timers

   Routes learned by a triggered response command (7) are normally
   considered to be permanent - that is they do NOT time out unless
   activated by one of the following events:

   o  If the circuit manager indicates that a next hop router cannot be
      contacted, all routes learned from that next hop router should
      start timing out as if they had (just) been learned from a
      conventional response command (2).




Meyer                                                          [Page 24]

RFC 1582                       Demand RIP                  February 1994


      Namely each route exists while the database entry timer is
      running and is advertised on other interfaces as if still
      present.  The route is then advertised as unreachable while a
      further hold down timer is allowed to expire, at which point the
      entry is deleted.

      If the circuit manager indicates that the next hop router can be
      contacted while the database entry timer is running, the routes
      are reinstated as permanent entries.

      If the database entry timer has expired and the circuit manager
      indicates that the next hop router is reachable, the routing
      application MUST issue a triggered request.  The routes will be
      reinstated on the basis of any triggered response packet(s)
      received.

   o  If a triggered response packet is received in which a route is
      marked unreachable, the hold down timer MUST be started and the
      entry is advertised as unreachable on other interfaces.  On
      expiry of the hold down timer the entry is deleted.

      If a triggered response packet is received in which an existing
      route is ABSENT, the hold down timer MUST also be started and
      the entry is advertised as unreachable on other interfaces.  On
      expiry of the hold down timer the entry is deleted.

   For IP RIP the hold down timer should always run for 120 seconds, to
   be consistent with RIP usage on broadcast networks.  The database
   entry timer should by default run for 180 seconds.  The network can
   be made more responsive by reducing the database entry timer value.
   However, making this timer too short can lead to network
   instabilities.  The duration of the database entry timer allows a
   period of grace in which contention for network resources can be
   resolved by the circuit manager.

7.2 Retransmission Timer

   The routing task runs a retransmission timer:

   o  When a triggered request is sent it will be retransmitted
      periodically while a triggered response packet is not received.

   o  When a triggered response is sent a note of the sequence number
      and fragment number(s) of the routing update is kept.

      Fragments will be retransmitted at periodic intervals while a
      triggered acknowledgement packet is not received for the
      appropriate fragment.



Meyer                                                          [Page 25]

RFC 1582                       Demand RIP                  February 1994


   With call set up time on the WAN being of the order of a second, a
   value of 5 seconds for the retransmission timer is appropriate.

   If no response is received after 10 retransmissions, routes via the
   next hop router are marked as unreachable, the hold down timer MUST
   be started and the entry is advertised as unreachable on other
   interfaces.  On expiry of the hold down timer the entry is deleted.

   The next hop router is then polled using a triggered request packet
   at 60 second intervals.  If a response is received the routers should
   exchange routing information using triggered response packets.

   It may not be desirable to poll indefinitely, since a lack of
   response (when a circuit is up) is most likely caused by incorrect
   configuration of the next hop router.  An administrator definable
   number of polls (5 or greater) should be provided.

   If the circuit manager indicates that the next hop router is
   unreachable, the retransmission is suppressed until the circuit
   manager indicates that the next hop router is reachable once more.
   Counting of the number of retransmissions continues from where it
   left off prior to the circuit down indication.

7.3 Reassembly Timer

   When a router receives a triggered response update it MUST
   acknowledge each fragment.  If the routing update is fragmented over
   more than one packet, the receiving router MUST store the fragments
   until ALL fragments are received.

   On receiving the first fragment a timer should be started.  If all
   fragments of the routing update are not received within that period
   they are discarded - and a triggered request is sent back to the
   originator (with retransmissions if necessary).  The originator MUST
   then resend ALL triggered response fragments.

   The reassembly timer should be set to four times the value of the
   retransmission timer.  With a suggested retransmission timer value of
   5 seconds, the suggested reassembly timer value SHOULD be 20 seconds.

   Implementations MAY allow the reassembly timer and retransmission
   timer to be configurable (in the 1:4 ratio), but interoperability
   will be compromised on WANs where all participating routers DO NOT
   support the same values for these timers.

   Fragments MUST also be discarded if a new fragment with a different
   sequence number is received.  A triggered request MUST not be sent in
   this instance.



Meyer                                                          [Page 26]

RFC 1582                       Demand RIP                  February 1994


8. Implementation Considerations

   In the implementation described in this memo, it is assumed that
   there is a close binding between the circuit manager and the routing
   applications - that they are in some way the same 'program'.  This is
   not necessarily true of all products which are routers.

   In particular there are UNIX host implementations in which the
   routing application is distinct from the kernel, where the circuit
   manager is likely to be installed.  In such systems it is possible to
   stop (or crash) the routing applications independently of what is
   happening in the kernel.

   Other implementations might have the circuit manager on a separate
   card which again may give the circuit manager a life of its own.

   In implementations where the applications and circuit manager have
   independent lives, a keep-alive mechanism MUST be provided between
   the applications and the circuit manager, so that if the application
   or network layer dies and is subsequently re-started they can
   resynchronize their state tables.

   Ideally, when an application dies, the circuit manager should close
   all existing VCs appropriate to the application and make no further
   outgoing calls and reject incoming calls until the application is
   running again.

   If the circuit manager is using some form of encapsulation, several
   applications may be sharing the same VC.  If this is the case the
   circuit manager may wish to filter out datagrams for the appropriate
   network layer if only one of the applications is affected.  But this
   is not an ideal solution.

   Conversely if the application believes the circuit manager has died,
   it should mark all routes via the circuit manager as unreachable and
   advertise them on other interfaces for the duration of the hold down
   timer before deleting them.

9. Security Considerations

   Security is provided my a number of aspects:

   o  The circuit manager is required to be provided with a list of
      physical addresses to enable it to establish a call to the next
      hop router on an X.25 SVC or ISDN B-channel.

      The circuit manager SHOULD only allow incoming calls to be
      accepted from the same well defined list of routers.



Meyer                                                          [Page 27]

RFC 1582                       Demand RIP                  February 1994


      Elsewhere in the system there will be a set of logical address
      and physical address tuples to enable the network protocols to
      run over the correct circuit.  This may be a lookup table, or in
      some instances there may be an algorithmic conversion between
      the two addresses.

   o  The routing (or service advertising) task MUST be provided with a
      list of logical addresses to which triggered updates are to be
      sent on the WAN.  The list MAY be a subset of the list of next
      hop routers maintained by the circuit manager.

      There MAY also be a separate list of next hop routers to which
      traditional broadcasts of routing (or service advertising)
      updates should be sent.  Next hop routers omitted from either
      list are assumed to be not participating in routing (or service
      advertising) updates.

      The list (or lists) doubles as a list of routers from which
      routing updates are allowed to be received from the WAN.  Any
      routing information received from a router not in the
      appropriate list MUST be discarded.

10. References

   [1] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
       Rutgers University, June 1988.

   [2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
       RFC 1388, Xylogics, January 1993.

   [3] Novell Incorporated., "IPX Router Specification", Version 1.10,
       October 1992.

   [4] Xerox Corporation., "Internet Transport Protocols", Xerox System
       Integration Standard XSIS 028112, December 1981.

   [5] Malis. A., Robinson. D., and R. Ullmann, "Multiprotocol
       Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN
       Communications, Computervision Systems Integration, Process
       Software Corporation, August 1992.











Meyer                                                          [Page 28]

RFC 1582                       Demand RIP                  February 1994


11. Author's Address

       Gerry Meyer
       Spider Systems
       Stanwell Street
       Edinburgh EH6 5NG
       Scotland, UK

       Phone: (UK) 31 554 9424
       Fax:   (UK) 31 554 0649
       EMail: [e-mail]








































Meyer                                                          [Page 29]