rfc2210.txt

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

      is a non-RSVP hop, the application's traffic will receive
      reservationless best-effort service at at least one point on the
      path.

      - Whether or not a specific QoS control service is implemented at
      every hop along the path. For example, a receiver might learn that
      at least one integrated-services aware hop along the path supports
      the Controlled-Load service but not the Guaranteed service.

      - Default or global values for the general characterization
      parameters described in [RFC 2215]. These values describe
      properties of the path itself, irrespective of the selected QoS
      control service. A value reported in this section of the ADSPEC
      applies to all services unless a different, service-specific value
      is also present in the ADSPEC.

      - A service-specific value for one or more general
      characterization parameters, if the service-specific value differs
      from the default value.

      - Values of the per-service characterization parameters defined by
      each supported service.

   Data in the ADSPEC is divided into blocks or fragments, each of which
   is associated with a specific service.  This allows the adspec to
   carry information about multiple services, allows new services to be
   deployed in the future without immediately updating existing code,
   and allows an application which will never use a particular service
   to omit the ADSPEC data for that service.  The structure of the
   ADSPEC is described in detail in Section 3.3.

   A sender may indicate that a specific QoS control service should
   *not* be used by the receivers within an RSVP session.  This is done
   by omitting all mention of that service from the ADSPEC, as described
   in Section 3.3.  Upon arrival at a receiver, the complete absence of
   an ADSPEC fragment for a specific service indicates to receivers that
   the service should not be used.

      NOTE: In RSVP Version 1, all receivers within a session are
      required to choose the same QoS control service.  This restriction
      is imposed by the difficulty of merging reservations requesting
      different QoS control services, and the current lack of a general
      service replacement mechanism.  The restriction may be eliminated
      in the future.



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


      Considering this restriction, it may be useful to coordinate the
      receivers' selection of a QoS control service by having the
      sender(s) offer only one choice, using the ADSPEC mechanism
      mentioned above.  All receivers must then select the same service.
      Alternatively, the coordination might be accomplished by using a
      higher-level session announcement and setup mechanism to inform
      the receivers of the QoS control service in use, by manual
      configuration of the receivers, or by an agreement protocol
      running among the session receivers themselves.

      As with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object formats
      described in Section 3 are capable of carrying TSpecs and RSpecs
      for more than one QoS control service in separate data fragments.
      Currently, use of a FLOWSPEC or SENDER_TSPEC containing fragments
      for more than one QoS control service is not supported.  In the
      future, this capability may be used to implement a more flexible
      service request and replacement scheme, allowing applications to
      obtain useful end-to-end QoS control when not all intermediate
      nodes support the same set of QoS services.  RSVP-application APIs
      should be designed to support passing SENDER_TSPEC, FLOWSPEC, and
      ADSPEC objects of variable size and containing information about
      multiple QoS control services between RSVP and its clients.

2.3. Use of ADSPEC Information

   This section gives some details about setting reservation parameters
   and the use of information conveyed by the RSVP ADSPEC object.

2.3.1. Determining the availability of a QoS control service

   The RSVP ADSPEC carries flag bits telling the application receivers
   whether or not a completely reservation-capable path exists between
   each sender and the receiver. These bits are called "break bits",
   because they indicate breaks in the QoS control along a network path.
   Break bits are carried within the header which begins each per-
   service data fragment of an RSVP ADSPEC.

   Service number 1 is used within the ADSPEC to identify a fragment
   carrying information about global parameter values that apply to all
   services (see [RFC 2215] for more details). The break bit in service
   1's per-service header is used to tell the receiver(s) whether all of
   the network elements along the path from sender to receiver support
   RSVP and integrated services.  If a receiver finds this bit set, at
   least one network element along the data transmission path between
   the ADSPEC's sender and the receiver can not provide QoS control
   services at all.  This bit corresponds to the global NON_IS_HOP
   characterization parameter defined in [RFC 2215].




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


      NOTE: If this bit is set, the values of all other parameters in
      the ADSPEC are unreliable. The bit being set indicates that at
      least one node along the sender-receiver path did not fully
      process the ADSPEC.

   Service-specific break bits tell the receiver(s) whether all of the
   network elements along the path from sender to receiver support a
   particular QoS control service.  The break bit for each service is
   carried within the ADSPEC's per-service header for that service.  If
   a bit is set at the receiver, at least one network element along the
   data transmission path supports RSVP but does not support the QoS
   control service corresponding to the per-service header.  These bits
   correspond to the service-specific NON_IS_HOP characterization
   parameters defined in [RFC 2215].

   Section 3 gives more information about break bits.

2.3.2. Determining Path MTU

   Both Guaranteed and Controlled-Load QoS control services place an
   upper bound on packet size, and require that the application limit
   the maximum size of packets subject to resource reservation. For both
   services, the desired maximum packet size is a parameter of the
   reservation request, and the service will reject (with an admission
   control error) reservation requests specifying a packet size larger
   than that supported by the service.

   Since RSVP reservation requests are made by receivers, this implies
   that the *receivers* in an RSVP session, as well as the senders, need
   to know the MTU supported by the QoS control services along a data
   path.  Further, in some unusual cases the MTU supported by a QoS
   control service may differ from that supported by the same router
   when providing best effort service.

   A scalable form of MTU negotiation is used to address these problems.
   MTU negotiation in an RSVP system works as follows:

      - Each sending application joining an RSVP session fills in the M
      (maximum packet size) parameter in its generated Sender_TSpec
      (carried from senders to receivers in a SENDER_TSPEC object) with
      the maximum packet size it wishes to send covered by resource
      reservation.

      - Each RSVP PATH message from a sending application also carries
      an ADSPEC object containing at least one PATH_MTU characterization
      parameter. When it arrives at the receiver, this parameter gives
      the minimum MTU at any point along the path from sender to
      receiver.  Generally, only the "global" PATH_MTU parameter



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


      (service 1, parameter 9) will be present, in which case its value
      is a legal MTU for all reservation requests. If a service specific
      PATH_MTU parameter is present, its value will be smaller than that
      of the global parameter, and should be used for reservation
      requests for that service.

      - Each receiver takes the minimum of all the PATH_MTU values (for
      the desired QoS control service) arriving in ADSPEC messages from
      different senders and uses that value as the MTU in its
      reservation requests.  This value is used to fill in the M
      parameter of the TSpec created at the receiver.  In the case of a
      FF style reservation, a receiver may also choose to use the MTU
      derived from each sender's ADSPEC in the FLOWSPEC generated for
      that sender, if the receiver is concerned about obtaining the
      maximum MTU on each data path. To accomodate changes in the data
      path, the receiver may continue to watch the arriving ADSPECS, and
      modify the reservation if a newly arriving ADSPEC indicates a
      smaller MTU than is currently in use.

      - As reservation requests (RESV messages) move from receivers to
      senders, reservation parameters are merged at intermediate nodes.
      As part of this merging, the smaller of two M parameters arriving
      at a merge point will be forwarded in the upstream RESV message.

      - As reservation requests arrive at intermediate RSVPs, the
      minimum of the receivers' requested TSpec and the sum of the
      sender TSpecs is taken, and a reservation for the resulting TSpec
      is made. The reservation will use the smaller of the actual path
      MTU value computed by the receivers and the largest maximum packet
      size declared by any of the sender(s). (The TSpec sum() function
      result's M parameter is the max of the summed TSpec M parameters).

      - When the completely merged RESV message arrives at each sender,
      the MTU value (M parameter) in the merged FLOWSPEC object will
      have been set to the smallest acceptable MTU of the data paths
      from that sender to any session receiver. This MTU should be used
      by the sending application to size its packets. Any packets larger
      than this MTU may be delivered as best-effort rather than being
      covered by the session's resource reservation.

      Note that senders do *not* adjust the value of their
      Sender_TSpec's M field to match the actual packet size selected in
      this step. The value of M represents the largest packet the sender
      could send, not the largest packet the sender is currently
      sending.






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


   Note that the scheme above will allow each sender in a session to use
   the largest MTU appropriate for that sender, in cases where different
   data paths or receivers have different acceptable MTU's.

3. RSVP Object Formats

   This section specifies the detailed contents and wire format of RSVP
   SENDER_TSPEC, ADSPEC, and FLOWSPEC objects for use with the
   Guaranteed and Controlled-Load QoS control services. The object
   formats specified here are based on the general message construction
   rules given in Appendix 1.

3.1. RSVP SENDER_TSPEC Object

   The RSVP SENDER_TSPEC object carries information about a data
   source's generated traffic. The required RSVP SENDER_TSPEC object
   contains a global Token_Bucket_TSpec parameter (service_number 1,
   parameter 127, as defined in [RFC 2215]). This TSpec carries traffic
   information usable by either the Guaranteed or Controlled-Load QoS
   control services.































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


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |             7 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    1  (c)     |0| reserved    |             6 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+