rfc2091.txt

RFC 的详细文档！

   database is in flux the packet MUST be re-created from the database
   to contain only the subset of routes which currently apply.  And if
   none of the routes still apply, nothing will be 'retransmitted'.

   For simplicity of implementation we would advise having only one
   packet in flight.  However if the 'round trip' for a response and
   acknowledgement is quite long this could significantly delay large
   updates.  See Appendix A for an understanding of the additional
   complexity of managing several packets in flight.

4. New Packet Types

   To support triggered updates, three new packet types MUST be
   supported.  For IP RIP Version 1 [1] and IP RIP Version 2 [2] these
   are identified by the Command Field values shown:

      o  9 - Update Request

      o  10 - Update Response

      o  11 - Update Acknowledge

   For Netware RIP and SAP [3] the equivalent Field to distinguish
   between packet types is called Operation and these take the same
   values.

   These Command and Operation types require the addition of a 4 octet
   Update header.  All three packet types contain a Version, which MUST
   be 1.  Update Response and Update Acknowledge also have a Sequence
   Number and a Flush Flag.







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


4.1 Update Request

   The Update Request has the Command/Operation value 9.

   It is a request to the peer system to send ALL appropriate elements
   in its routing database.  It is retransmitted at periodic intervals
   (every 5 seconds) until an Update Response message is received with
   the Flush flag set.

   An Update Request is 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 and changes to a reachable
      (circuit up) state.

   An Update Request may also be sent at other times to compensate for
   discarding non-optimal routing information or if an Update Response
   continues to be unacknowledged (see section 6.3).

4.2 Update Response

   The Update Response has the Command/Operation value 10.

   It is a message containing zero or more routes in an update.  It is
   retransmitted at periodic intervals until an Update Acknowledge is
   received.

   An Update Response message MUST be sent:

   o  In response to an Update Request.  The Update Response MUST have
      the Flush flag set.  Other Update Responses should NOT be sent
      until an Update Acknowledge has been received acknowledging the
      Flush flag.

      The remainder of the database MUST then be sent as a series of
      Update Responses with the Flush flag NOT set.

   o  An Update Response with the Flush flag set MUST also be sent at
      power on to flush the peer's routing table learned from a previous
      incarnation.  This Update Response SHOULD NOT contain any routes.
      This avoids any possibility of an acknowledgement being received
      to a response sent BEFORE the unit was restarted causing confusion
      about which routes are being acknowledged.

   Update Response messages continue to be sent any time there is fresh
   routing information to be propagated.



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


   Each new Update Response is given a different Sequence Number.  The
   Sequence Number only has 'meaning' to the sender of the Update
   Response.  The same Update Response sent to different peers MAY have
   a different Sequence Number.

   An Update Response packet with the Flush flag set MUST be sent to a
   peer:

      o  At power on.

      o  In response to an Update Request packet.

      o  After transitioning from a circuit down to a circuit up state.

   After sending an Update Flush, the full database MUST be sent
   subsequently.

4.3 Update Acknowledge

   The Update Acknowledge has the Command/Operation value 11.

   It is a message sent in response to every Update Response packet
   received.  If the Update Response packet has the flush flag set then
   so should the Update Acknowledge packet.

5. Packet Formats

5.1 Update Header

   To support the mechanism outlined in this proposal the packet format
   for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3]
   are modified to include an additional small header when using
   Commands Update Request (9), Update Response (10) and Update
   Acknowledge (11).  Commands are called Operations in Netware.

   Update Request (9):

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version (1)  |               must be zero (3)                |
     +-------------------------------+-------------------------------+









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


     Update Response (10) and Update Acknowledge (11):

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version (1)  |   Flush (1)   |     Sequence Number (2)       |
     +-------------------------------+-------------------------------+


     Four octet Update headers, with each  tick  mark  representing  one
     bit.  All fields are coded in network byte order (big-endian).


                         Figure 2.   Update Headers.

   Version MUST be 1 in all headers.  Any packets received for a
   different Version MUST be silently discarded.

   The Sequence Number MUST be incremented every time a new Update
   Response packet is sent on the WAN.  The Sequence Number is unchanged
   for retransmissions.  The Sequence Number wraps round at 65535.

   Flush is set to 1 in an Update Response if the peer is required to
   start timing out its entries - otherwise it is set to zero.  Any
   other values MUST be silently discarded.

   The peer returns an Update Acknowledge containing the same Sequence
   Number and Flush.

5.2 IP Routing Information Protocol Version 1

   IP RIP [1] is a UDP-based protocol which generally sends and receives
   datagrams on UDP port number 520.

   To support the mechanism outlined in this proposal the packet format
   for RIP Version 1 [1] is modified when using Commands Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 3.

5.3 IP Routing Information Protocol Version 2

   IP RIP Version 2 [2] is an enhancement to IP RIP Version 1 which
   allows RIP updates to include subnetting information.

   To support the mechanism outlined in this proposal the packet format
   for RIP Version 2 [2] is modified when using Commands Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 4.





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


5.4 Netware Routing Information Protocol

   Netware [3] supports a mechanism that allows routers on an
   internetwork to exchange routing information using the Routing
   Information Protocol (RIP) which runs over the Internetwork Packet
   Exchange (IPX) protocol using socket number 453h.

   To support the mechanism outlined in this proposal the packet format
   for Novell RIP [3] is modified when using Operations Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 5.

5.5 Netware Service Advertising Protocol

   Netware [3] also supports a mechanism that allows servers on an
   internetwork to advertise their services by name and type using the
   Service Advertising Protocol (SAP) which runs over the Internetwork
   Packet Exchange (IPX) protocol using socket number 452h.  SAP
   operates on similar principals to running RIP.  Routers act as SAP
   agents, collecting service information from different networks and
   relay it to interested parties.

   To support the mechanism outlined in this proposal the packet format
   for Novell SAP [3] is modified when using Operations Update Request
   (9), Update Response (10) and Update Acknowledge (11).  See Figure 6.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Command (1)   | RIP Version (1)|     must be zero (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)                         |
     +-------------------------------+-------------------------------+















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


     Update Response then has up to 25 routing entries (each 20 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address Family Identifier (2) |      must be zero (2)         |
     +-------------------------------+-------------------------------+
     |                         IP address (4)                        |
     +---------------------------------------------------------------+
     |                         must be zero (4)                      |
     +---------------------------------------------------------------+
     |                         must be zero (4)                      |
     +---------------------------------------------------------------+
     |                         Metric (4)                            |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of an IP RIP 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
     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)
     packets.  They are not present in packet types in the original  RIP
     Version 1 specification.

                  Figure 3.   IP RIP Version 1 packet format























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


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Command (1)   |RIP Version (1)|      must be zero (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 25 routing entries (each 20 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address Family Identifier (2) |        Route Tag (2)          |
     +-------------------------------+-------------------------------+
     |                         IP address (4)                        |
     +---------------------------------------------------------------+
     |                         Subnet Mask (4)                       |
     +---------------------------------------------------------------+
     |                         Next Hop (4) - must be zero           |
     +---------------------------------------------------------------+
     |                         Metric (4)                            |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of an IP RIP Version 2 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
     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)
     Packets.  They are not present in packet types in the original  RIP
     Version 2 specification.

     Next Hop MUST be zero, since Triggered RIP can NOT advertise routes
     on behalf of other WAN routers.

     If authentication is used it immediately follows the Update header.

                  Figure 4.   IP RIP Version 2 packet format






Meyer & Sherry              Standards Track                    [Page 14]

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 50 routing entries (each 8 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Network Number (4)                      |
     +---------------------------------------------------------------+
     |       Number of Hops (2)      |      Number of Ticks (2)      |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of a Netware RIP 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 RIP specification.

                    Figure 5.   Netware RIP packet format