rfc2210.txt

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

   The length field allows the ADSPEC information for a service to be
   skipped over by a network elements which does not recognize or
   implement the service.  When an element does this, it sets the break
   bit, indicating that the service's ADSPEC data was not updated at at
   least one hop. Note that a service's break bit can be set without
   otherwise supporting the service in any way.  In all cases, a network
   element encountering a per-service data header it does not understand
   simply sets bit 23 to report that the service is not supported, then
   skips over the rest of the fragment.

   Data fragments must always appear in an ADSPEC in service_number
   order. In particular, the default general parameters fragment
   (service_number 1) always comes first.

   Within a data fragment, the service-specific data must alway come
   first, followed by any non-default general parameters which may be
   present, ordered by parameter_number. The size and structure of the
   service-specific data is fixed by the service definition, and does
   not require run-time parsing. The remainder of the fragment, which
   carries non-default general parameters, varies in size and structure
   depending on which, if any, of these parameters are present. This
   part of the fragment must be parsed by examining the per-parameter
   headers.



Wroclawski                  Standards Track                    [Page 16]

RFC 2210                   RSVP with INTSERV              September 1997


   Since the overall size of each data fragment is variable, it is
   always necessary to examine the length field to find the end of the
   fragment, rather than assuming a fixed-size structure.

   3.3.1. RSVP ADSPEC format

   The basic ADSPEC format is shown below. The message header and the
   default general parameters fragment are always present. The fragments
   for Guaranteed or Controlled-Load service may be omitted if the
   service is not to be used by the RSVP session. Additional data
   fragments will be added if new services are defined.

       31           24 23            16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0 (a) |      reserved         |  Msg length - 1 (b)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Default General Parameters fragment (Service 1)  (c)       |
       |    (Always Present)                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Guaranteed Service Fragment (Service 2)    (d)             |
       |    (Present if application might use Guaranteed Service)      |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Controlled-Load Service Fragment (Service 5)  (e)          |
       |    (Present if application might use Controlled-Load Service) |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall message length not including header word
     (c, d, e) - Data fragments

3.3.2. Default General Characterization Parameters ADSPEC data fragment

   All RSVP ADSPECs carry the general characterization parameters
   defined in [RFC 2215].  Values for global or default general
   parameters (values which apply to the all services or the path
   itself) are carried in the per-service data fragment for service
   number 1, as shown in the picture above.  This fragment is always
   present, and always first in the message.







Wroclawski                  Standards Track                    [Page 17]

RFC 2210                   RSVP with INTSERV              September 1997


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |    1  (c)     |x| reserved    |           8 (d)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    4 (e)      |    (f)        |           1 (g)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |        IS hop cnt (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |    6 (h)      |    (i)        |           1 (j)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Path b/w estimate  (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |     8 (k)     |    (l)        |           1 (m)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |        Minimum path latency (32-bit integer)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |     10 (n)    |      (o)      |           1 (p)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |      Composed MTU (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (c) - Per-Service header, service number 1 (Default General
           Parameters)
     (d) - Global Break bit ([RFC 2215], Parameter 2) (marked x) and
           length of General Parameters data block.
     (e) - Parameter ID, parameter 4 (Number-of-IS-hops param from
           [RFC 2215])
     (f) - Parameter 4 flag byte
     (g) - Parameter 4 length, 1 word not including header
     (h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
     (i) - Parameter 6 flag byte
     (j) - Parameter 6 length, 1 word not including header
     (k) - Parameter ID, parameter 8 (minimum path latency from [RFC
           2215])
     (l) - Parameter 8 flag byte
     (m) - Parameter 8 length, 1 word not including header
     (n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
     (o) - Parameter 10 flag byte
     (p) - Parameter 10 length, 1 word not including header


   Rules for composing general parameters appear in [RFC 2215].

   In the above fragment, the global break bit (bit 23 of word 1, marked
   with (x) in the picture) is used to indicate the existence of a
   network element not supporting QoS control services somewhere in the
   data path.  This bit is cleared when the ADSPEC is created, and set
   to one if a network element which does not support RSVP or integrated



Wroclawski                  Standards Track                    [Page 18]

RFC 2210                   RSVP with INTSERV              September 1997


   services is encountered.  An ADSPEC arriving at a receiver with this
   bit set indicates that all other parameters in the ADSPEC may be
   invalid, since not all network elements along the path support
   updating of the ADSPEC.

   The general parameters are updated at every network node which
   supports RSVP:

      - When a PATH message ADSPEC encounters a network element
      implementing integrated services, the portion of the ADSPEC
      associated with service number 1 is passed to the module
      implementing general parameters. This module updates the global
      general parameters.

      - When a PATH message ADSPEC encounters a network element that
      does *not* support RSVP or implement integrated services, the
      break bit in the general parameters service header must be set. In
      practice, this bit will usually be set by another network element
      which supports RSVP, but has been made aware of the gap in
      integrated services coverage.

      - In either case, the ADSPEC is passed back to RSVP for delivery
      to the next hop along the path.

3.3.3. Guaranteed Service ADSPEC data fragment

   The Guaranteed service uses the RSVP ADSPEC to carry data needed to
   compute the C and D terms passed from the network to the application.
   The minimum size of a non-empty guaranteed service data fragment is 8
   32-bit words.  The ADSPEC fragment for Guaranteed service has the
   following format:




















Wroclawski                  Standards Track                    [Page 19]

RFC 2210                   RSVP with INTSERV              September 1997


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     2 (a)     |x|  reserved   |             N-1 (b)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    133 (c)    |     0 (d)     |             1 (e)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   End-to-end composed value for C [Ctot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |     134 (f)   |       (g)     |             1 (h)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |   End-to-end composed value for D [Dtot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |     135 (i)   |       (j)     |             1 (k)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   | Since-last-reshaping point composed C [Csum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |     136 (l)   |       (m)     |             1 (n)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  | Service-specific general parameter headers/values, if present |
    .  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .
   N   |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 2 (Guaranteed)
     (b) - Break bit and Length of per-service data in 32-bit
           words not including header word.
     (c) - Parameter ID, parameter 133 (Composed Ctot)
     (d) - Parameter 133 flag byte
     (e) - Parameter 133 length, 1 word not including header
     (f) - Parameter ID, parameter 134 (Composed Dtot)
     (g) - Parameter 134 flag byte
     (h) - Parameter 134 length, 1 word not including header
     (i) - Parameter ID, parameter 135 (Composed Csum).
     (j) - Parameter 135 flag byte
     (k) - Parameter 135 length, 1 word not including header
     (l) - Parameter ID, parameter 136 (Composed Dsum).
     (m) - Parameter 136 flag byte
     (n) - Parameter 136 length, 1 word not including header

   When a node which actually implements guaranteed service creates the
   guaranteed service adspec fragment, the parameter values are set to
   the local values for each parameter. When an application or network






Wroclawski                  Standards Track                    [Page 20]

RFC 2210                   RSVP with INTSERV              September 1997


   element which does not itself implement guaranteed service creates a
   guaranteed service adspec fragment, it should set the values of each
   parameter to zero, and set the break bit to indicate that the service
   is not actually implemented at the node.

   An application or host RSVP which is creating a guaranteed service
   adspec fragment but does not itself implement the guaranteed service
   may create a truncated "empty" guaranteed adspec fragment consisting
   of only a header word:


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     2 (a)     |1|    (b)      |         0 (c)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 2 (Guaranteed)
     (b) - Break bit (set, service not implemented)
     (c) - Length of per-service data in 32-bit words not
           including header word.


   This might occur if the sending application or host does not do
   resource reservation iself, but still wants the network to do so.
   Note that in this case the break bit will always be set, since the
   creator of the adspec fragment does not itself implement guaranteed
   service.

   When a PATH message ADSPEC containing a per-service header for
   Guaranteed service encounters a network element implementing
   Guaranteed service, the guaranteed service data fragment is updated:

      - If the data block in the ADSPEC is an empty (header-only) block
      the header-only fragment must first be expanded into the complete