rfc2210.txt

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

      data fragment described above, with initial values of Ctot, Dtot,
      Csum, and Dsum set to zero. An empty fragment can be recognized
      quickly by checking for a size field of zero.  The value of the
      break bit in the header is preserved when the additional
      Guaranteed service data is added. The overall message length and
      the guaranteed-service data fragment size (field (b) in the
      pictures above) are changed to reflect the increased message
      length.

      The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data
      fragment are then composed with the local values exported by the
      network element according to the composition functions defined in
      [RFC 2212].




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


      - When a PATH message ADSPEC with a Guaranteed service header
      encounters a network element that supports RSVP but does *not*
      implement Guaranteed service, the network element sets the break
      bit in the Guaranteed service header.

      - The new values are placed in the correct fields of the ADSPEC,
      and the ADSPEC is passed back to RSVP for delivery to the next hop
      along the path.

   When a PATH message ADSPEC containing a Guaranteed service data
   fragment encounters a network element that supports RSVP but does
   *not* implement Guaranteed service, the network element sets the
   break bit in the Guaranteed service header.

   When a PATH message ADSPEC *without* a Guaranteed service header
   encounters a network element implementing Guaranteed service, the
   Guaranteed service module of the network element leaves the ADSPEC
   unchanged. The absence of a Guaranteed service per-service header in
   the ADSPEC indicates that the application does not care about
   Guaranteed service.


3.3.4. Controlled-Load Service ADSPEC data fragment

   Unlike the Guaranteed service, the Controlled-Load service does not
   require extra ADSPEC data to function correctly. The only ADSPEC data
   specific to the Controlled-Load service is the Controlled-Load break
   bit.  Therefore the usual Controlled-Load service data block contains
   no extra information. The minimum size of the controlled-load service
   data fragment is 1 32-bit word.



       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     5 (a)     |x|  (b)        |            N-1 (c)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   | Service-specific general parameter headers/values, if present |
    .  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .
   N   |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (a) - Per-Service header, service number 5 (Controlled-Load)
     (b) - Break bit
     (c) - Length of per-service data in 32 bit words not including
           header word.





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


   The Controlled-Load portion of the ADSPEC is processed according to
   the following rules:

      - When a PATH message ADSPEC with a Controlled-Load service header
      encounters a network element implementing Controlled-Load service,
      the network element makes no changes to the service header.

      - When a PATH message ADSPEC with a Controlled-Load service header
      encounters a network element that supports RSVP but does *not*
      implement Controlled-Load service, the network element sets the
      break bit in the Controlled-Load service header.

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

3.3.5. Overriding Global ADSPEC Data with Service-Specific Information

   In some cases, the default values for the general parameters are not
   correct for a particular service. For example, an implementation of
   Guaranteed service may accept only packets with a smaller maximum
   size than the link MTU, or the percentage of outgoing link bandwidth
   made available to the Controlled-Load service at a network element
   may be administratively limited to less than the overall bandwidth.

   In these cases, a service-specific value, as well as the default
   value, is reported to the receiver receiving the ADSPEC.  Service-
   specific information which overrides general information is carried
   by a parameter with the same name as the general parameter, placed
   within the data fragment of the QoS control service to which it
   applies. These service-specific values are referred to as override or
   service-specific general parameters.

   For example, the following Controlled-Load ADSPEC fragment carries
   information overriding the global path bandwidth estimate with a
   different value:
















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


       31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     5 (a)     |x| (b)         |             2 (c)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |     6 (d)     |      0 (d)    |             1 (e)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |  Path b/w estimate for C-L service (32b IEEE FP number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 5 (Controlled-Load)
     (b) - Break bit
     (c) - Length of per-service data, two words not including header
     (c) - Parameter ID, parameter 6
           (AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215])
     (d) - Parameter 6 flags (none set)
     (e) - Parameter 6 length, one word not including header


   The presence of override parameters in a data fragment can be quickly
   detected by examining the fragment's length field, which will be
   larger than the "standard" length for the fragment.  Specific
   override parameters can be easily identified by examining the
   parameter headers, because they have parameter_number's from the
   general parameter portion of the number space (1-127), but are found
   in service-specific data blocks (those with service_numbers between 2
   and 254 in the per_service header field).

   The presence of override parameters in a data fragment is optional. A
   parameter header/value pair is added only when a particular
   application or QoS control service wishes to override the global
   value of a general parameter with a service-specific value.

   As with IP options, it is only the use of these override parameters
   that is optional. All implementations must be prepared to receive and
   process override parameters.

   The basic principle for handling override parameters is to use the
   override value (local or adspec) if it exists, and to use the default
   value otherwise. If a local node exports an override value for a
   general parameter, but there is no override value in the arriving
   adspec, the local node adds it. The following pseudo-code fragment
   gives more detail:









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


   /* Adspec parameter processing rules *

   <get arriving ADSPEC from RSVP>

   for ( <each service number N with a fragment in the ADSPEC> ) {
     if ( <the local node does not support the service> ) {
       <set the break bit in the service header>
     } else {
       for ( <each parameter in the data fragment for service N> ) {
         if ( < the local service N supplies a value for the parameter> ) {
            <compose the arriving and values and update the adspec>
         } else {
            /* Must be a general parameter, or service N would have
             * supplied a value..
             */
            <compose the arriving value with the local default value
             and update the adspec>
         }
       }
       for ( <any parameters supplied by the local service N
             implementation but not found in the adspec> ) {
            /*
             * Must be an override value for a general parameter,
             * or the adspec would have contained a value..
             */
            <compose the local override value with the arriving default
             value (from the service 1 data fragment) and add the parameter
             to the adspec's service N fragment in parameter_number order>
       }
     }
   }

   <pass updated ADSPEC back to RSVP>

   In practice, the two 'for' loops can be combined. Since override
   parameters within a service's fragment are transmitted in numerical
   order, it is possible to determine whether a parameter is present
   without scanning the entire fragment. Also, because the data
   fragments are ordered by service_number, the default values for
   general parameters will always be read before they might be needed to
   update local override values in the second for loop.

3.3.6. Example

   The picture below shows the complete adspec for an application which
   can use either controlled-load or guaranteed service. In the example,





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


   data fragments are present for general parameters, guaranteed, and
   controlled-load services. All fragments are of standard size, and
   there are no override parameters present.


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    Unused             |          19 (b)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    1  (c)     |x| reserved (d)|           8 (e)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |    4 (f)      |    (g)        |           1 (h)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  zero extension of ..           IS hop cnt (16-bit unsigned)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |    6 (i)      |    (j)        |           1 (k)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Path b/w estimate  (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |     8 (l)     |    (m)        |           1 (n)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |        Minimum path latency (32-bit integer)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |     10 (o)    |      (p)      |           1 (q)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  |  zero extension of ..        composed MTU (16-bit unsigned)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11  |     2 (r)     |x| reserved (s)|             8 (t)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   12  |    133 (u)    |       (v)     |             1 (w)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   13  |   End-to-end composed value for C [Ctot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   14  |     134 (x)   |       (y)     |             1 (z)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   15  |   End-to-end composed value for D [Dtot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   16  |     135 (aa   |       (bb     |             1 (cc)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   17  | Since-last-reshaping point composed C [Csum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   18  |     136 (dd