rfc2961.txt

RFC 的详细文档！

      |                       Message_Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Flags: 8 bits

         No flags are currently defined.  This field MUST be zero on
         transmission and ignored on receipt.

      Epoch: 24 bits

         The Epoch field copied from the message being acknowledged.

      Message_Identifier: 32 bits

         The Message_Identifier field copied from the message being
         acknowledged.

   MESSAGE_ID_NACK object

      Class = MESSAGE_ID_ACK Class, C_Type = 2

         Definition is the same as the MESSAGE_ID_ACK object.

4.4. Ack Message Format

   Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK
   objects.  They MUST NOT contain any MESSAGE_ID objects.  Ack messages
   are sent between neighboring RSVP nodes.  The IP destination address
   of an Ack message is the unicast address of the node that generated
   the message(s) being acknowledged.  For messages with RSVP_HOP
   objects, such as Path and Resv messages, the address is found in the
   RSVP_HOP object.  For other messages, such as ResvConf, the
   associated IP address is the source address in the IP header.  The IP
   source address is an address of the node that sends the Ack message.



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


   The Ack message format is as follows:

     <ACK Message> ::= <Common Header> [ <INTEGRITY> ]
                       <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
                       [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

     For Ack messages, the Msg Type field of the Common Header MUST be
     set to 13.

     Section 4.6 provides guidance on when an Ack message should be used
     and when MESSAGE_ID objects should be sent piggy-backed in other
     RSVP messages.

4.5. MESSAGE_ID Object Usage

   The MESSAGE_ID object may be included in any RSVP message other than
   the Ack and Bundle messages.  The MESSAGE_ID object is always
   generated and processed over a single hop between RSVP neighbors.
   The IP address of the object generator, i.e., the node that creates
   the object, is represented in a per RSVP message type specific
   fashion.  For messages with RSVP_HOP objects, such as Path and Resv
   messages, the generator's IP address is found in the RSVP_HOP object.
   For other messages, such as ResvConf message, the generator's IP
   address is the source address in the IP header.  Note that MESSAGE_ID
   objects can only be used in a Bundle sub-messages, but not in a
   Bundle message.  As is always the case with the Bundle message, each
   sub-message is processed as if it was received individually.  This
   includes processing of MESSAGE_ID objects.

   The Epoch field contains a generator selected value.  The value is
   used to indicate when the sender resets the values used in the
   Message_Identifier field.  On startup, a node SHOULD randomly select
   a value to be used in the Epoch field.  The node SHOULD ensure that
   the selected value is not the same as was used when the node was last
   operational.  The value MUST NOT be changed unless the node or the
   RSVP agent is restarted.

   The Message_Identifier field contains a generator selected value.
   This value, when combined with the generator's IP address, identifies
   a particular RSVP message and the specific state information it
   represents.  The combination of Message_Identifier and Epoch can also
   be used to detect out of order messages.  When a node is sending a
   refresh message with a MESSAGE_ID object, it SHOULD use the same
   Message_Identifier value that was used in the RSVP message that first
   advertised the state being refreshed.  When a node is sending a
   trigger message, the Message_Identifier value MUST have a value that
   is greater than any other value previously used with the same Epoch
   field value.  A value is considered to have been used when it has



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


   been sent in any message using the associated IP address with the
   same Epoch field value.

   The ACK_Desired flag is set when the MESSAGE_ID object generator
   wants a MESSAGE_ID_ACK object sent in response to the message.  Such
   information can be used to ensure reliable delivery of RSVP messages
   in the face of network loss.  Nodes setting the ACK_Desired flag
   SHOULD retransmit unacknowledged messages at a more rapid interval
   than the standard refresh period until the message is acknowledged or
   until a "rapid" retry limit is reached.  Rapid retransmission rate
   MUST be based on the exponential exponential back-off procedures
   defined in section 6.  The ACK_Desired flag will typically be set
   only in trigger messages.  The ACK_Desired flag MAY be set in refresh
   messages.  Issues relate to multicast sessions are covered in a later
   section.

   Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a
   newly received message is out of order and can be ignored.  Out of
   order messages SHOULD be ignored, i.e., silently dropped.  Out of
   order messages can be identified by examining the values in the Epoch
   and Message_Identifier fields.  To determine ordering, the received
   Epoch value must match the value previously received from the message
   sender.  If the values differ then the receiver MUST NOT treat the
   message as out of order.  When the Epoch values match and the
   Message_Identifier value is less than the largest value previously
   received from the sender, then the receiver SHOULD check the value
   previously received for the state associated with the message.  This
   check should be performed for any message that installs or changes
   state.  (Includes at least: Path, Resv, PathTear, ResvTear, PathErr
   and ResvErr.)  If no local state information can be associated with
   the message, the receiver MUST NOT treat the message as out of order.
   If local state can be associated with the message and the received
   Message_Identifier value is less than the most recently received
   value associated with the state, the message SHOULD be treated as
   being out of order.

   Note that the 32-bit Message_Identifier value MAY wrap.  To cover the
   wrap case, the following expression may be used to test if a newly
   received Message_Identifier value is less than a previously received
   value:

       if ((int) old_id - (int) new_id > 0) {
          new value is less than old value;
       }

   MESSAGE_ID objects of messages that are not out of order SHOULD be
   used to aid in determining if the message represents new state or a
   state refresh.  Note that state is only refreshed in Path and Resv



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


   messages.  If the received Epoch values differs from the value
   previously received from the message sender, the message is a trigger
   message and the receiver MUST fully process the message.  If a Path
   or Resv message contains the same Message_Identifier value that was
   used in the most recently received message for the same session and,
   for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the
   message as a state refresh.  If the Message_Identifier value is
   greater than the most recently received value, the receiver MUST
   fully processes the message.  When fully processing a Path or Resv
   message, the receiver MUST store the received Message_Identifier
   value as part of the local Path or Resv state for future reference.

   Nodes receiving a non-out of order message containing a MESSAGE_ID
   object with the ACK_Desired flag set, SHOULD respond with a
   MESSAGE_ID_ACK object.  Note that MESSAGE_ID objects received in
   messages containing errors, i.e., are not syntactically valid,  MUST
   NOT be acknowledged.  PathErr and ResvErr messages SHOULD be treated
   as implicit acknowledgments.

4.6. MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage

   The MESSAGE_ID_ACK object is used to acknowledge receipt of messages
   containing MESSAGE_ID objects that were sent with the ACK_Desired
   flag set.  A MESSAGE_ID_ACK object MUST NOT be generated in response
   to a received MESSAGE_ID object when the ACK_Desired flag is not set.

   The MESSAGE_ID_NACK object is used as part of the summary refresh
   extension.  The generation and processing of MESSAGE_ID_NACK objects
   is described in further detail in Section 5.4.

   MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any RSVP
   message that has an IP destination address matching the generator of
   the associated MESSAGE_ID object.  This means that the objects will
   not typically be included in the non hop-by-hop Path, PathTear and
   ResvConf messages.  When no appropriate message is available, one or
   more objects SHOULD be sent in an Ack message.  Implementations
   SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in standard
   RSVP messages when possible.

   Implementations SHOULD limit the amount of time that an object is
   delayed in order to be piggy-backed or sent in an Ack message.
   Different limits may be used for MESSAGE_ID_ACK and MESSAGE_ID_NACK
   objects.  MESSAGE_ID_ACK objects are used to detect link transmission
   losses.  If an ACK object is delayed too long, the corresponding
   message will be retransmitted.  To avoid such retransmission, ACK
   objects SHOULD be delayed a minimal amount of time.  A delay time
   equal to the link transit time MAY be used.  MESSAGE_ID_NACK objects
   may be delayed an independent and longer time, although additional



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


   delay increases the amount of time a desired reservation is not
   installed.

4.7. Multicast Considerations

   Path and PathTear messages may be sent to IP multicast destination
   addresses.  When the destination is a multicast address, it is
   possible that a single message containing a single MESSAGE_ID object
   will be received by multiple RSVP next hops.  When the ACK_Desired
   flag is set in this case, acknowledgment processing is more complex.

   There are a number of issues to be addressed including ACK implosion,
   number of acknowledgments to be expected and handling of new
   receivers.

   ACK implosion occurs when each receiver responds to the MESSAGE_ID
   object at approximately the same time.  This can lead to a
   potentially large number of MESSAGE_ID_ACK objects being
   simultaneously delivered to the message generator.  To address this
   case, the receiver MUST wait a random interval prior to acknowledging
   a MESSAGE_ID object received in a message destined to a multicast
   address.  The random interval SHOULD be between zero (0) and a
   configured maximum time.  The configured maximum SHOULD be set in
   proportion to the refresh and "rapid" retransmission interval, i.e,
   such that the maximum time before sending an acknowledgment does not
   result in retransmission.  It should be noted that ACK implosion is
   being addressed by spreading acknowledgments out in time, not by ACK
   suppression.

   A more fundamental issue is the number of acknowledgments that the
   upstream node, i.e., the message generator, should expect.  The
   number of acknowledgments that should be expected is the same as the
   number of RSVP next hops.  In the router-to-router case, the number
   of next hops can often be obtained from routing.  When hosts are
   either the upstream node or the next hops, the number of next hops
   will typically not be readily available.  Another case where the
   number of RSVP next hops will typically not be known is when there
   are non-RSVP routers between the message generator and the RSVP next
   hops.

   When the number of next hops is not known, the message generator
   SHOULD only expect a single response.  The result of this behavior
   will be special retransmission handling until the message is
   delivered to at least one next hop, then followed by standard RSVP
   refreshes.  Refresh messages will synchronize state with any next
   hops that don't receive the original message.





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


4.7.1. Reference RSVP/Routing Interface

   When using the MESSAGE_ID extension with multicast sessions it is
   preferable for RSVP to obtain the number of next hops from routing
   and to be notified when that number changes.  The interface between
   routing and RSVP is purely an implementation issue.  Since RSVP
   [RFC2205] describes a reference routing interface, a version of the
   RSVP/routing interface updated to provide number of next hop
   information is presented.  See [RFC2205] for previously defined
   parameters and function description.

      o    Route Query
           Mcast_Route_Query( [ SrcAddress, ] DestAddress,
                              Notify_flag )
                              -> [ IncInterface, ] OutInterface_list,
                              NHops_list

      o    Route Change Notification
           Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
                             [ IncInterface, ] OutInterface_list,
                             NHops_list

      NHops_list provides the number of multicast group members
      reachable via each OutInterface_list entry.