rfc2091.txt

RFC 的详细文档！

Meyer & Sherry              Standards Track                    [Page 15]

RFC 2091                      Trigger RIP                   January 1997


     0                   1         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Operation (2)           |
     +---------------+---------------+

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Update Header (4)                         |
     +-------------------------------+-------------------------------+

     Update Response then has up to 8 service entries (each 64 octets):

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Type (2)       |                               |
     +-------------------------------+                               |
     |                       Service Name (48)                       |
     |                            .                                  |
                                  .
                                  .  +-------------------------------+
     |                            .  | Network Address (4)           |
     +-------------------------------+-------------------------------+
     |  Network Address (cont)       |                               |
     +-------------------------------+                               |
     |                        Node Address (6)                       |
     +-------------------------------+-------------------------------+
     |      Socket Address (2)       |       Hops to Server (2)      |
     +-------------------------------+-------------------------------+
                                     .
                                     .

     The format of a Netware SAP datagram in octets, with each tick mark
     representing  one  bit.  All fields are coded in network byte order
     (big-endian).

     The four octets of the Update header are included in Update Request
     (Operation  9),  Update  Response  (10) and Update Acknowledge (11)
     packets.  They are not present in  packet  types  in  the  original
     Novell SAP specification.


                    Figure 6.   Netware SAP packet format






Meyer & Sherry              Standards Track                    [Page 16]

RFC 2091                      Trigger RIP                   January 1997


6. Timers

   Three timers are supported to handle the triggered update mechanism:

   o  Database timer.

   o  Hold down timer.

   o  Retransmission timer.

   An optional over-subscription timer MAY also be supported.

6.1 Database Timer

   Routes learned by an Update Response are normally considered to be
   permanent.

   When an Update Response with the Flush flag set is received, 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).

   Namely each route exists while the database entry timer (usually 180
   seconds) 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.

6.2 Hold down Timer

   A hold down timer of 120 seconds is started on a route:

   o  When the database timer for the route expires.

   o  When a formerly reachable route changes to unreachable in an
      incoming response.

   o  When a circuit down is received from the circuit manager.

   While the hold down timer is running routes are advertised as
   unreachable on other interfaces.

   When the hold down timer expires the route MAY be deleted from the
   database PROVIDING its unreachability has been successfully
   propagated to all WAN destinations, or the remaining WAN destinations
   are in a circuit down state.  If a route can not be deleted when the
   hold-down timer expires, it MAY subsequently be deleted when each and
   every peer is either up-to-date or is in a circuit down state.




Meyer & Sherry              Standards Track                    [Page 17]

RFC 2091                      Trigger RIP                   January 1997


   If the hold down timer is already running it is NOT reset by any
   events which would start the hold down timer.

6.3 Retransmission Timer

   The routing task runs a retransmission timer:

   o  An Update Request packet is retransmitted periodically until an
      Update Flush packet is received.  An Update Flush packet is an
      Update Response packet with the Flush field set.  It need not
      contain routes.

   o  An Update Response packet is retransmitted periodically until an
      Update Acknowledge packet is received containing the same Sequence
      Number.

   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.

   To prevent against failures in the circuit manager a limit SHOULD be
   placed on the number of retransmissions. If no response has been
   received after a configurable length of time (say 180 seconds) routes
   via the next hop router are marked as unreachable, the hold down
   timer is started and the entry is advertised as unreachable on other
   interfaces.

   The next hop router may then be polled with Update Requests at a
   reduced frequency.  A suitable poll interval would be of the order of
   minutes rather than seconds.  Alternatively an Update Request could
   be initiated by administrative action.  When a response is received
   the routers should perform a complete exchange of routing
   information.

6.4 Over-subscription Timer

   Over-subscription is where there are more next hop routers to send
   updates to on the WAN than there are channels.  For example 3 next
   hop routers accessed by an ISDN Basic Rate Interface (BRI) which can
   only support 2 calls simultaneously.

   To avoid route oscillation routes may NOT be marked unreachable
   immediately on receiving a circuit down message from the circuit
   manager.  A timeout MAY be used to delay marking the routes
   unreachable for sufficiently long to allow the calls to 'time
   division multiplex' over the available channels.  A timeout as long
   as the regular 180 second RIP route timeout MAY be suitable.  In
   general the greater the over-subscription, the longer the time out
   should be.



Meyer & Sherry              Standards Track                    [Page 18]

RFC 2091                      Trigger RIP                   January 1997


   Implementations wishing to support over-subscription may implement
   the delay within the circuit manager or within the routing
   application.

   If the delay is implemented within the routing application the
   routing entries MUST NOT start timing out during  the delay.  This
   allows the circuit up message to be ignored if the timeout after
   receiving the circuit down has still to expire.  This avoids any
   confusion if the peer had previously issued a Route Flush command and
   was part way through an update.

7. Security Considerations

   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.  The circuit manager SHOULD only allow incoming calls to be
   accepted from the same well defined list of routers.

   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.

   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.

   RIP Version 2 also allows further authentication of Triggered RIP
   packets.




















Meyer & Sherry              Standards Track                    [Page 19]

RFC 2091                      Trigger RIP                   January 1997


Appendix A - Implementation Suggestion

   This section suggests how the database might be structured to handle
   Triggered RIP.

   Each entry in the database is given a unique route number.  Every
   time a best route to a network changes, a global route number is
   incremented and the changed route is given the new route number.
   Note that this route number is completely internal to the router and
   has no bearing on the Sequence Number sent in Update Responses sent
   to the peer.

   The route number size should be large enough so as not to wrap round
   - or the routes can be renumbered before it becomes a problem.  Re-
   numbering requires that the database environment is stable (No Update
   Responses are queued awaiting Acknowledgement)

   Is is probably easier to manage the routes if they are also chained
   together using a pointer to a later (and possibly also a pointer to
   an earlier) entry which reflect the route number/age.

   Performing a complete update then consists of running though the
   routes from the oldest to the latest and sending them out in Update
   Responses.  Subsequent changes to the database are treated as sending
   out only the changed entries (from the previous latest to the new
   latest).

   When allowing for several packets in flight care must be taken with
   retransmissions.  An Update Response 'retransmission' MAY be
   different from the original.  When transmitting a sequence of Update
   Responses each Response packet contains a number of routes which is a
represented by a series of routes with consecutive route numbers.
   Consider sending three Update Responses with Sequence numbers 10,11
   and 12 each containing 10 routes:

   Sequence Number    Routes represented by Route Numbers

         10           101, 102, 103, 104, 105, 106, 107, 108, 109, 110

         11           111, 112, 113, 114, 115, 116, 117, 118, 119, 120

         12           121, 122, 123, 124, 125, 126, 127, 128, 129, 130









Meyer & Sherry              Standards Track                    [Page 20]

RFC 2091                      Trigger RIP                   January 1997


   If these Update Responses are NOT acknowledged, but in the meantime
   the routing database has changed and the routes represented by route
   numbers 104, 112 - 116 and 127 have changed and been assigned new
   route numbers 131 - 137, the retransmission will look like:

           Sequence Number    Routes represented by Route Numbers

            10           101, 102, 103, 105, 106, 107, 108, 109, 110

            11           111, 117, 118, 119, 120

            12           121, 122, 123, 124, 125, 126, 128, 129, 130

            13           131, 132, 133, 134, 135, 136, 137

      To perform a retransmission it is VERY IMPORTANT that the
      retransmission contains only the SUB-SET of route numbers which
      currently apply.  If there are NO suitable routes to send, it is not
      necessary to send an empty retransmission.

   An alternative 'retransmission' strategy is to always use different
   sequence numbers when resending updates.  Consider transmitting
   packets with sequence numbers 10 through 20 - and responses are
   received from all packets except those with sequence numbers 14 and
   17.  In this case only the data in packets 10 through 13 can be
   considered to be acknowledged.  The data from packet 14 onwards MUST
   be re-sent and given new sequence numbers starting at 21.

References

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

   [2]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
        RFC 1723, Xylogics, November 1994.

   [3]  Novell Incorporated., "IPX Router Specification", Version 1.20,
        October 1993.

   [4]  Meyer. G., "Extensions to RIP to Support Demand Circuits",
        Spider Systems, February 1994.










Meyer & Sherry              Standards Track                    [Page 21]

RFC 2091                      Trigger RIP                   January 1997


Authors'  Address:

   Gerry Meyer
   Shiva
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

   Phone: (UK) 131 554 9424
   Fax:   (UK) 131 467 7749
   Email: [e-mail]

   Steve Sherry
   Xyplex
   295 Foster St.
   Littleton, MA 01460

   Phone: (US) 508 952 4745
   Fax:   (US) 508 952 4887
   Email: [e-mail]































Meyer & Sherry              Standards Track                    [Page 22]