rfc2961.txt

RFC 的详细文档！

           See Section 2.

         0x02-0x08: Reserved

      Msg type: 8 bits

         12 = Bundle

      RSVP checksum: 16 bits

         The one's complement of the one's complement sum of the entire
         message, with the checksum field replaced by zero for the
         purpose of computing the checksum.  An all-zero value means
         that no checksum was transmitted.  Because individual sub-
         messages may carry their own checksum as well as the INTEGRITY
         object for authentication, this field MAY be set to zero.  Note
         that when the checksum is not computed, the header of the
         bundle message will not be covered by any checksum.  If the
         checksum is computed, individual sub-messages MAY set their own
         checksum to zero.

      Send_TTL: 8 bits

         The IP TTL value with which the message was sent.  This is used
         by RSVP to detect a non-RSVP hop by comparing the Send_TTL with
         the IP TTL in a received message.

      RSVP length: 16 bits

         The total length of this RSVP Bundle message in bytes,
         including the bundle header and the sub-messages that follow.

3.2. Message Formats

   An RSVP Bundle message must contain at least one sub-message.  A
   sub-message MAY be any message type except for another Bundle
   message.










Berger, et al.              Standards Track                     [Page 6]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


       0                   1                   2                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  | Flags |      12       |         RSVP checksum         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Send_TTL    |  (Reserved)   |         RSVP length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                   First sub-message                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                   More sub-messages..                       //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3. Sending RSVP Bundle Messages

   Support for RSVP Bundle messages is optional.  While message bundling
   helps in scaling RSVP, by reducing processing overhead and bandwidth
   consumption, a node is not required to transmit every standard RSVP
   message in a Bundle message.  A node MUST always be ready to receive
   standard RSVP messages.

   RSVP Bundle messages can only be sent to RSVP neighbors that support
   bundling.  Methods for discovering such information include: (1)
   manual configuration and (2) observing the Refresh-Reduction-Capable
   bit (see Section 2) in the received RSVP messages.  RSVP Bundle
   messages MUST NOT be used if the RSVP neighbor does not support RSVP
   Bundle messages.

   RSVP Bundle messages are sent hop by hop between RSVP-capable nodes
   as "raw" IP datagrams with protocol number 46.  The IP source address
   is an address local to the system that originated the Bundle message.
   The IP destination address is the RSVP neighbor for which the sub-
   messages are intended.

   RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP
   option in their IP headers.  This is because Bundle messages are
   addressed directly to RSVP neighbors.

   Each RSVP Bundle message MUST occupy exactly one IP datagram, which
   is approximately 64K bytes.  If it exceeds the MTU, the datagram is
   fragmented by IP and reassembled at the recipient node.
   Implementations may choose to limit each RSVP Bundle message to the
   MTU size of the outgoing link, e.g., 1500 bytes.  Implementations
   SHOULD also limit the amount of time that a message is delayed in
   order to be bundled.  Different limits may be used for trigger and



Berger, et al.              Standards Track                     [Page 7]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


   standard refresh messages.  Trigger messages SHOULD be delayed a
   minimal amount of time.  Refresh messages may be delayed up to their
   refresh interval.  Note that messages related to the same Resv or
   Path state should not be delayed at different intervals in order to
   preserve ordering.

   If the RSVP neighbor is not known or changes in next hops cannot be
   identified via routing, Bundle messages MUST NOT be used.  Note that
   when the routing next hop is not RSVP capable it will typically not
   be possible to identify changes in next hop.

   Any message that will be handled by the RSVP neighbor indicated in a
   Bundle Message's destination address may be included in the same
   message.  This includes all RSVP messages that would be sent out a
   point-to-point link.  It includes any message, such as a Resv,
   addressed to the same destination address.  It also includes Path and
   PathTear messages when the next hop is known to be the destination
   and changes in next hops can be detected.  Path and PathTear messages
   for multicast sessions MUST NOT be sent in Bundle messages when the
   outgoing link is not a point-to-point link or when the next hop does
   not support the refresh overhead reduction extensions.

3.4. Receiving RSVP Bundle Messages

   If the local system does not recognize or does not wish to accept a
   Bundle message, the received messages shall be discarded without
   further analysis.

   The receiver next compares the Send_TTL with which a Bundle message
   is sent to the IP TTL with which it is received.  If a non-RSVP hop
   is detected, the number of non-RSVP hops is recorded.  It is used
   later in processing of sub-messages.

   Next, the receiver verifies the version number and checksum of the
   RSVP Bundle message and discards the message if any mismatch is
   found.

   The receiver then starts decapsulating individual sub-messages.  Each
   sub-message has its own complete message length and authentication
   information.  With the exception of using the Send_TTL from the
   header of the Bundle message, each sub-message is processed as if it
   was received individually.

4. MESSAGE_ID Extension

   Three new objects are defined as part of the MESSAGE_ID extension.
   The objects are the MESSAGE_ID object, the MESSAGE_ID_ACK object, and
   the MESSAGE_ID_NACK objects.  The first two objects are used to



Berger, et al.              Standards Track                     [Page 8]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


   support acknowledgments and reliable RSVP message delivery.  The last
   object is used to support the summary refresh extension described in
   Section 5.  The MESSAGE_ID object can also be used to simply provide
   a shorthand indication of when the message carrying the object is a
   refresh message.  Such information can be used by the receiving node
   to reduce refresh processing requirements.

   Message identification and acknowledgment is done on a per hop basis.
   All types of MESSAGE_ID objects contain a message identifier.  The
   identifier MUST be unique on a per object generator's IP address
   basis.  No more than one MESSAGE_ID object may be included in an RSVP
   message.  Each message containing a MESSAGE_ID object may be
   acknowledged via a MESSAGE_ID_ACK object, when so indicated.
   MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggy-backed
   in unrelated RSVP messages or in RSVP Ack messages.  RSVP messages
   carrying any of the three object types may be included in a bundle
   message.  When included, each object is treated as if it were
   contained in a standard, non-bundled, RSVP message.

4.1. Modification of Standard Message Formats

   The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be
   included in the standard RSVP messages, as defined in [RFC2205].
   When included, one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects
   MUST immediately follow the INTEGRITY object.  When no INTEGRITY
   object is present, the MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST
   immediately follow the message or sub-message header.  Only one
   MESSAGE_ID object MAY be included in a message or sub-message and it
   MUST follow any present MESSAGE_ID_ACK or MESSAGE_ID_NACK objects.
   When no MESSAGE_ID_ACK or MESSAGE_ID_NACK objects are present, the
   MESSAGE_ID object MUST immediately follow the INTEGRITY object.  When
   no INTEGRITY object is present, the MESSAGE_ID object MUST
   immediately follow the message or sub-message header.

   The ordering of the ACK objects for all standard RSVP messages is:
   <Common Header>  [ <INTEGRITY> ]
                    [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                    [ <MESSAGE_ID> ]













Berger, et al.              Standards Track                     [Page 9]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


4.2. MESSAGE_ID Objects

   MESSAGE_ID Class = 23

   MESSAGE_ID object

      Class = MESSAGE_ID Class, C_Type = 1

       0                   1                   2                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |                      Epoch                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message_Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Flags: 8 bits

         0x01 = ACK_Desired flag

           Indicates that the sender requests the receiver to send an
           acknowledgment for the message.

      Epoch: 24 bits

         A value that indicates when the Message_Identifier sequence has
         reset.  SHOULD be randomly generated each time a node reboots
         or the RSVP agent is restarted.  The value SHOULD NOT be the
         same as was used when the node was last operational.  This
         value MUST NOT be changed during normal operation.

      Message_Identifier: 32 bits

         When combined with the message generator's IP address, the
         Message_Identifier field uniquely identifies a message.  The
         values placed in this field change incrementally and only
         decrease when the Epoch changes or when the value wraps.














Berger, et al.              Standards Track                    [Page 10]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


4.3. MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects


   MESSAGE_ID_ACK Class = 24

   MESSAGE_ID_ACK object

      Class = MESSAGE_ID_ACK Class, C_Type = 1

       0                   1                   2                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |                      Epoch                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+