rfc2961.txt

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

   IPv6/MESSAGE_ID MCAST_LIST object

      Class = MESSAGE_ID_LIST Class, C_Type = 5

       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                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                                                               |
      |                           IPv6 Multicast_                     |
      |                        Message_Identifier_                    |
      |                               Tuple                           |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                 :                             |
      //                                :                            //
      |                                 :                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                                                               |
      |                           IPv6 Multicast_                     |
      |                        Message_Identifier_                    |
      |                               Tuple                           |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


















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


   Where a IPv6 Multicast_Message_Identifier_Tuple consists of:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Message_Identifier                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      IPv6 Source_IP_Address                   |
      |                            (16 Bytes)                         |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                     IPv6 Destination_IP_Address               |
      |                            (16 Bytes)                         |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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 from the MESSAGE_ID object corresponding to the
         trigger message that advertised the state being refreshed.

      Message_Identifier: 32 bits

         The Message_Identifier field from the MESSAGE_ID object
         corresponding to the trigger message that advertised the Path
         state being refreshed.  One or more Message_Identifiers may be
         included.  Each Message_Identifier MUST be followed by the
         source IP address corresponding to the sender of the Path state
         being refreshed, and the destination IP address of the session.

      Source_IP_Address

         The IP address corresponding to the sender of the Path state
         being refreshed.

      Destination_IP_Address

         The destination IP address corresponding to the session of the
         Path state being refreshed.







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


5.2. Srefresh Message Format

   Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
   SRC_LIST, and MESSAGE_ID MCAST_LIST objects.  MESSAGE_ID LIST and
   MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh
   message.  MESSAGE_ID SRC_LIST can not be combined in Srefresh
   messages with the other objects.  A single Srefresh message MAY
   refresh both Path and Resv state.

   Srefresh messages carrying Message_Identifier fields corresponding to
   Path state are normally sent with a destination IP address equal to
   the address carried in the corresponding SESSION objects.  The
   destination IP address MAY be set to the RSVP next hop when the next
   hop is known to be RSVP capable and either (a) the session is unicast
   or (b) the outgoing interface is a point-to-point link.  Srefresh
   messages carrying Message_Identifier fields corresponding to Resv
   state MUST be sent with a destination IP address set to the Resv
   state's previous hop.

   Srefresh messages sent to a multicast session's destination IP
   address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT
   include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects.
   Srefresh messages sent to the RSVP next hop MAY contain either or
   both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT
   include any MESSAGE_ID SRC_LIST objects.

   The source IP address of an Srefresh message is an address of the
   node that generates the message.  The source IP address MUST match
   the address associate with the MESSAGE_ID objects when they were
   included in a standard RSVP message.  As previously mentioned, the
   source address associated with a MESSAGE_ID object is represented in
   a per RSVP message type specific fashion.  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 message, the
   associated IP address is the source address in the IP header.

   Srefresh messages that are addressed to a session's destination IP
   address MUST be sent with the Router Alert IP option in their IP
   headers.  Srefresh messages addressed directly to RSVP neighbors
   SHOULD NOT be sent with the Router Alert IP option in their IP
   headers.

   Each Srefresh message MUST occupy exactly one IP datagram.  If it
   exceeds the MTU, the datagram is fragmented by IP and reassembled at
   the recipient node.  Srefresh messages MAY be sent within an RSVP
   Bundle messages.  Although this is not expected since Srefresh





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


   messages can carry a list of Message_Identifier fields within a
   single object.  Implementations may choose to limit each Srefresh
   message to the MTU size of the outgoing link, e.g., 1500 bytes.

   The Srefresh message format is:

   <Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <srefresh list> | <source srefresh list>

   <srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
                         [ <srefresh list> ]

   <source srefresh list> ::= <MESSAGE_ID SRC_LIST>
                                [ <source srefresh list> ]

   For Srefresh messages, the Msg Type field of the Common Header MUST
   be set to 15.

5.3. Srefresh Message Usage

   An Srefresh message may be generated to refresh Resv and Path state.
   If an Srefresh message is used to refresh some particular state, then
   the generation of a standard refresh message for that particular
   state SHOULD be suppressed.  A state's refresh interval is not
   affected by the use of Srefresh message based refreshes.

   When generating an Srefresh message, a node SHOULD refresh as much
   Path and Resv state as is possible by including the information from
   as many MESSAGE_ID objects in the same Srefresh message.  Only the
   information from MESSAGE_ID objects that meet the source and
   destination IP address restrictions, as described in Sections 5.2,
   may be included in the same Srefresh message.  Identifying Resv state
   that can be refreshed using the same Srefresh message is fairly
   straightforward.  Identifying which Path state may be included is a
   little more complex.

   Only state that was previously advertised in Path and Resv messages
   containing MESSAGE_ID objects can be refreshed via an Srefresh
   message.  Srefresh message based refreshes must preserve the state
   synchronization properties of Path or Resv message based refreshes.
   Specifically, the use of Srefresh messages MUST NOT result in state
   being timed-out at the RSVP next hop.  The period at which state is
   refreshed when using Srefresh messages MAY be shorter than the period
   that would be used when using Path or Resv message based refreshes,
   but it MUST NOT be longer.




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


   The particular approach used to trigger Srefresh message based
   refreshes is implementation specific.  Some possibilities are
   triggering Srefresh message generation based on each state's refresh
   period or, on a per interface basis, periodically generating Srefresh
   messages to refresh all state that has not been refreshed within the
   state's refresh interval.  Other approaches are also possible.  A
   default Srefresh message generation interval of 30 seconds is
   suggested for nodes that do not dynamically calculate a generation
   interval.

   When generating an Srefresh message, there are two methods for
   identifying which Path state may be refreshed in a specific message.
   In both cases, the previously mentioned refresh interval and source
   IP address restrictions must be followed.  The primary method is to
   include only those sessions that share the same destination IP
   address in the same Srefresh message.

   The secondary method for identifying which Path state may be
   refreshed within a single Srefresh message is an optimization.  This
   method MAY be used when the next hop is known to support RSVP and
   when either (a) the session is unicast or (b) the outgoing interface
   is a point-to-point link.  This method MUST NOT be used when the next
   hop is not known to support RSVP or when the outgoing interface is to
   a multi-access network and the session is to a multicast address.
   The use of this method MAY be administratively configured.  When
   using this method, the destination address in the IP header of the
   Srefresh message is usually the next hop's address.  When the use of
   this method is administratively configured, the destination address
   should be the well known group address 224.0.0.14.  When the outgoing
   interface is a point-to-point link, all Path state associated with
   sessions advertised out the interface SHOULD be included in the same
   Srefresh message.  When the outgoing interface is not a point-to-
   point link, all unicast session Path state SHOULD be included in the
   same Srefresh message.

   Identifying which Resv state may be refreshed within a single
   Srefresh message is based simply on the source and destination IP
   addresses.  Any state that was previously advertised in Resv messages
   with the same IP addresses as an Srefresh message MAY be included.

   After identifying the Path and Resv state that can be included in a
   particular Srefresh message, the message generator adds to the
   message MESSAGE_ID information matching each identified state's
   previously used object.  For all Resv state and for Path state of
   unicast sessions, the information is added to the message in a
   MESSAGE_ID LIST object that has a matching Epoch value.  (Note only
   one Epoch value will be in use during normal operation.)  If no
   matching object exists, then a new MESSAGE_ID LIST object is created.



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


   Path state of multicast sessions may be added to the same message
   when the destination address of the Srefresh message is the RSVP next
   hop and the outgoing interface is a point-to-point link.  In this
   case the information is added to the message in a MESSAGE_ID
   MCAST_LIST object that has a matching Epoch value.  If no matching
   object exists, then a new MESSAGE_ID MCAST_LIST object is created.
   When the destination address of the message is a multicast address,
   then identified information is added to the message in a MESSAGE_ID
   SRC_LIST object that has a matching Epoch value.  If no matching
   object exists, then a new MESSAGE_ID SRC_LIST object is created.
   Once the Srefresh message is composed, the message generator
   transmit