rfc2745.txt

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

   are 16 byte IPv6 addresses.

   The fields are as follows:

   Max-RSVP-hops

      An octet specifying the maximum number of RSVP hops over which
      information will be collected.  If an error condition in the
      middle of the path prevents the DREQ packet from reaching the
      specified ending node, the Max-RSVP-hops field may be used to
      perform an expanding-length search to reach the point just before



Terzis, et al.              Standards Track                     [Page 6]

RFC 2745                RSVP Diagnostic Messages            January 2000


      the problem.  If this value is 1, the starting node and the ending
      node of the query will be the same.  If it is zero, there is no
      hop limit.

   RSVP-hop-count

      Records the number of RSVP hops that have been traversed so far.
      If the starting and ending nodes are the same, this value will be
      1 in the resulting DREP message.

   Fragment Offset

      Indicates where this DREP fragment belongs in the complete DREP
      message, measured in octets.  The first fragment has offset zero.
      Fragment Offset is used also to determine if a DREQ message
      containing zero DIAG_RESPONSE objects should be processed at an
      RSVP capable node.

   MF flag

      Flag means "more fragments".  It must be set to zero (0) in all
      DREQ messages.  It must be set to one (1) in all DREP packets that
      carry partial results and are returned by intermediate nodes due
      to the MTU limit.  When the DREQ message is converted to a DREP
      message in the ending node, the MF flag must remain zero.

   Request ID

      Identifies an individual DREQ message and the corresponding DREP
      message (or all the fragments of the reply message).

      One possible way to define the Request ID would use 16 bits to
      specify the ID of the process making the query and 16 bits to
      distinguish different queries from this process.

   Path MTU

      Specifies a default MTU size in octets for DREP and DREQ messages.
      This value should not be smaller than the size of the "base" DREQ
      packet. A "base" DREQ packet is one that contains a Common Header,
      a Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object,
      an empty ROUTE object and a single default DIAG_RESPONSE (see
      below).  The assumption made here is that a diagnostic packet of
      this size can always be forwarded without IP fragmentation.







Terzis, et al.              Standards Track                     [Page 7]

RFC 2745                RSVP Diagnostic Messages            January 2000


   LAST-HOP Address

      The IP address of the LAST-HOP node.  The DREQ message starts
      collecting information at this node and proceeds toward the
      sender.

   SENDER_TEMPLATE object

      This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and
      the port of a sender for the session being diagnosed.  The DREQ
      packet is forwarded hop-by-hop towards this address.

   Requester FILTER_SPEC Object

      This IPv4/IPv6 FILTER_SPEC object contains the IP address and the
      port from which the request originated and to which the DREP
      message(s) should be sent.

3.4.  DIAG_SELECT Object

   o DIAG_SELECT Class = 33, C-Type = 1.

   A Diagnostic message may optionally contain a DIAG_SELECT object to
   specify which specific RSVP objects should be reported in a
   DIAG_RESPONSE object.  In the absence of a DIAG_SELECT object, the
   DIAG_RESPONSE object added by the node will contain a default set of
   object types (see DIAG_RESPONSE object below).

   The DIAG_SELECT object contains a list of [Class, C-type] pairs, in
   the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    class      |     C-Type    |    class      |     C-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                                                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    class      |     C-Type    |    class      |     C-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When a DIAG_SELECT object is included in a DREQ message, each RSVP
   node along the path will add a DIAG_RESPONSE object containing
   response objects (see below) whose classes and C-Types match entries
   in the DIAG_SELECT list (and are from matching path and reservation
   state). A C-type octet of zero is a 'wildcard', matching any C-Type
   associated with the associated class.






Terzis, et al.              Standards Track                     [Page 8]

RFC 2745                RSVP Diagnostic Messages            January 2000


   Depending on the type of objects requested, a node can find the
   associated information in the path or reservation state stored for
   the session described in the SESSION object. Specifically,
   information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC
   objects can be extracted from the node's path state, while
   information for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and SCOPE
   objects can be found in the node's reservation state (if existent).

   If the number of [Class, C-Type] pairs is odd, the last two octets of
   the DIAG_SELECT object must be  zero. A maximum DIAG_SELECT object is
   one that contains the [Class, C-type] pairs for all the RSVP objects
   that can be requested in a Diagnostic query.

3.5.  ROUTE Object

   A diagnostic message may contain a ROUTE object, which is used to
   record the route of the DREQ message and as a source route for
   returning the DREP message(s) hop-by-hop.

   o IPv4 ROUTE object: Class = 31, C-Type = 1.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             reserved                          |    R-pointer  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     RSVP Node List                            |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This message signifies how the reply should be returned.  If it does
   not exist in the DREQ packet then DREP packets should be sent to the
   requester directly. If it does exist, DREP packets must be returned
   hop-by-hop along the reverse path to the LAST-HOP node and thence to
   the requester node.

   An empty ROUTE object is one that has an empty RSVP Node list and R-
   pointer is equal to zero.

   RSVP Node List

      A list of RSVP node IPv4 addresses.  The number of addresses in
      this list can be computed from the object size.

   R-pointer

      Used in DREP messages only (see Section 4.2 for details), but it
      is incremented as each hop adds its incoming interface address in
      the ROUTE object.



Terzis, et al.              Standards Track                     [Page 9]

RFC 2745                RSVP Diagnostic Messages            January 2000


   o IPv6 ROUTE object: Class = 31, C-Type = 2

   The same, except RSVP Node List contains IPv6 addresses.

   In a DREQ message, RSVP Node List specifies all RSVP hops between the
   LAST-HOP address specified in the DIAGNOSTIC object, and the last
   RSVP node the DREQ message has visited.  In a DREP message, RSVP Node
   List specifies all RSVP hops between the LAST-HOP and the node that
   returns this DREP message.

3.6.  DIAG_RESPONSE Object

   Each RSVP node attaches a DIAG_RESPONSE object to each DREQ message
   it receives, before forwarding the message.  The DIAG_RESPONSE object
   contains the state to be reported for this node.  It has a fixed-
   format header and then a variable list of RSVP state objects, or
   "response objects".

   o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       DREQ Arrival Time                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Incoming Interface Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Outgoing Interface Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Previous-RSVP-Hop Router Address              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   D-TTL       |M|R-err|  K    |      Timer value              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                  (optional) TUNNEL object                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                       Response objects                      //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.

   This object has the same format, except that all explicit and
   embedded IP addresses are IPv6 addresses.

   The fields are as follows:




Terzis, et al.              Standards Track                    [Page 10]

RFC 2745                RSVP Diagnostic Messages            January 2000


   DREQ Arrival Time

      A 32-bit NTP timestamp specifying the time the DREQ message
      arrived at this node.  The 32-bit form of an NTP timestamp
      consists of the middle 32 bits of the full 64-bit form, that is,
      the low 16 bits of the integer part and the high 16 bits of the
      fractional part.

   Incoming Interface Address

      Specifies the IP address of the interface on which messages from
      the sender are expected to arrive, or 0 if unknown.

   Outgoing Interface Address

      Specifies the IP address of the interface through which the DREQ
      message arrived and to which messages from the given sender and
      for the specified session address flow, or 0 if unknown.

   Previous-RSVP-Hop Router Address

      Specifies the IP address from which this node receives RSVP PATH
      messages for this source, or 0 if unknown.  This is also the
      interface to which the DREQ will be forwarded.

   D-TTL

      The number of IP hops this DREQ message traveled from the down-
      stream RSVP node to the current node.

   M flag

      A single-bit flag which indicates whether the reservation
      described by the response objects is merged with reservations from
      other down-stream interfaces when being forwarded upstream.

   R-error

      A 3-bit field that indicates error conditions at a node. Currently
      defined values are:

           0x00: no error
           0x01: No PATH state
           0x02: packet too big
           0x04: ROUTE object too big






Terzis, et al.              Standards Track                    [Page 11]

RFC 2745                RSVP Diagnostic Messages            January 2000


   K

      The refresh timer multiple (defined in [RSVP]).

   Timer value

      The local refresh timer value in seconds.

   The set of response objects to be included at the end of the
   DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is
   present.  If no DIAG_SELECT object is present, the response objects
   belong to the default list of classes:

      SENDER_TSPEC object      FILTER_SPEC object      FLOWSPEC object
      STYLE object

   Any C-Type present in the local RSVP state will be used.  These
   response objects may be in any order but they must all be at the end
   of the DIAG_RESPONSE object.

   A default DIAG_RESPONSE object is one containing the default list of
   classes described above.

3.7.  TUNNEL Object