rfc2210.txt

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

   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     (a) - Message format version number (0)
     (b) - Overall length (7 words not including header)
     (c) - Service header, service number 1 (default/global information)
     (d) - Length of service 1 data, 6 words not including header
     (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including header


   In this TSpec, the parameters [r] and [b] are set to reflect the
   sender's view of its generated traffic. The peak rate parameter [p]
   may be set to the sender's peak traffic generation rate (if known and
   controlled), the physical interface line rate (if known), or positive
   infinity (if no better value is available).  Positive infinity is
   represented as an IEEE single-precision floating-point number with an
   exponent of all ones (255) and a sign and mantissa of all zeros.  The
   format of IEEE floating-point numbers is further summarized in [RFC
   1832].

   The minimum policed unit parameter [m] should generally be set equal
   to the size of the smallest packet generated by the application. This
   packet size includes the application data and all protocol headers at
   or above the IP level (IP, TCP, UDP, RTP, etc.). The size given does
   not include any link-level headers, because these headers will change
   as the packet crosses different portions of the internetwork.






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


   The [m] parameter is used by nodes within the network to compute the
   maximum bandwidth overhead needed to carry a flow's packets over the
   particular link-level technology, based on the ratio of [m] to the
   link-level header size. This allows the correct amount of bandwidth
   to be allocated to the flow at each point in the net.  Note that
   smaller values of this parameter lead to increased overhead
   estimates, and thus increased likelyhood of a reservation request
   being rejected by the node. In some cases, an application
   transmitting a low percentage of very small packets may therefore
   choose to set the value of [m] larger than the actual minimum
   transmitted packet size. This will increase the likelyhood of the
   reservation succeeding, at the expense of policing packets of size
   less than [m] as if they were of size [m].

   Note that the an [m] value of zero is illegal. A value of zero would
   indicate that no data or IP headers are present, and would give an
   infinite amount of link-level overhead.

   The maximum packet size parameter [M] should be set to the size of
   the largest packet the application might wish to generate, as
   described in Section 2.3.2. This value must, by definition, be equal
   to or larger than the value of [m].

3.2. RSVP FLOWSPEC Object

   The RSVP FLOWSPEC object carries information necessary to make
   reservation requests from the receiver(s) into the network. This
   includes an indication of which QoS control service is being
   requested, and the parameters needed for that service.

   The QoS control service requested is indicated by the service_number
   in the FLOWSPEC's per-service header.

3.2.1 FLOWSPEC object when requesting Controlled-Load service

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting Controlled-Load service is shown below. Each of the TSpec
   fields is represented using the preferred concrete representation
   specified in the 'Invocation Information' section of [RFC 2211]. The
   value of 5 in the per-service header (field (c), below) indicates
   that Controlled-Load service is being requested.










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


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |             7 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    5  (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)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall length (7 words not including header)
     (c) - Service header, service number 5 (Controlled-Load)
     (d) - Length of controlled-load data, 6 words not including
           per-service header
     (e) - Parameter ID, parameter 127 (Token Bucket TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including per-service
           header


   In this object, the TSpec parameters [r], [b], and [p] are set to
   reflect the traffic parameters of the receiver's desired reservation
   (the Reservation TSpec). The meaning of these fields is discussed
   fully in [RFC 2211]. Note that it is unlikely to make sense for the
   [p] term to be smaller than the [r] term.

   The maximum packet size parameter [M] should be set to the value of
   the smallest path MTU, which the receiver learns from information in
   arriving RSVP ADSPEC objects.  Alternatively, if the receiving
   application has built-in knowledge of the maximum packet size in use
   within the RSVP session, and this value is smaller than the smallest
   path MTU, [M] may be set to this value.  Note that requesting a value
   of [M] larger than the service modules along the data path can
   support will cause the reservation to fail. See section 2.3.2 for
   further discussion of the MTU value.






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


   The value of [m] can be chosen in several ways. Recall that when a
   resource reservation is installed at each intermediate node, the
   value used for [m] is the smaller of the receiver's request and the
   values in each sender's SENDER_TSPEC.

   If the application has a fixed, known minimum packet size, than that
   value should be used for [m]. This is the most desirable case.

   For a shared reservation style, the receiver may choose between two
   options, or pick some intermediate point between them.

      - if the receiver chooses a large value for [m], then the
      reservation will allocate less overhead for link-level headers.
      However, if a new sender with a smaller SENDER_TSPEC [m] joins the
      session later, an already-installed reservation may fail at that
      time.

      - if the receiver chooses a value of [m] equal to the smallest
      value which might be used by any sender, then the reservation will
      be forced to allocate more overhead for link-level headers.
      However it will not fail later if a new sender with a smaller
      SENDER_TSPEC [m] joins the session.

   For a FF reservation style, if no application-specific value is known
   the receiver should simply use the value of [m] arriving in each
   sender's SENDER_TSPEC for its reservation request to that sender.

3.2.2. FLOWSPEC Object when Requesting Guaranteed Service

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting Guaranteed service is shown below. The flowspec object
   used to request guaranteed service carries a TSpec and RSpec
   specifying the traffic parameters of the flow desired by the
   receiver.

   Each of the TSpec and RSpec fields is represented using the preferred
   concrete representation specified in the 'Invocation Information'
   section of [RFC 2212]. The value of 2 for the service header
   identifier (field (c) in the picture below) indicates that Guaranteed
   service is being requested.











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


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    Unused             |            10 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    2  (c)     |0| reserved    |             9 (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)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |     130 (h)   |    0 (i)      |            2 (j)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  |  Rate [R]  (32-bit IEEE floating point number)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11  |  Slack Term [S]  (32-bit integer)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall length (9 words not including header)
     (c) - Service header, service number 2 (Guaranteed)
     (d) - Length of per-service data, 9 words not including per-service
           header
     (e) - Parameter ID, parameter 127 (Token Bucket TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including parameter header
     (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec)
     (i) - Parameter 130 flags (none set)
     (j) - Parameter 130 length, 2 words not including parameter header


   In this object, the TSpec parameters [r], [b], and [p] are set to
   reflect the traffic parameters of the receiver's desired reservation
   (the Reservation TSpec). The meaning of these fields is discussed
   fully in [RFC 2212]. Note that it is unlikely to make sense for the
   [p] term to be smaller than the [r] term.

   The RSpec terms [R] and [S] are selected to obtain the desired
   bandwidth and delay guarantees. This selection is described in [RFC
   2212].




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


   The [m] and [M] parameters are set identically to those for the
   Controlled-Load service FLOWSPEC, described in the previous section.

3.3. RSVP ADSPEC Object

   An RSVP ADSPEC object is constructed from data fragments contributed
   by each service which might be used by the application.  The ADSPEC
   begins with an overall message header, followed by a fragment for the
   default general parameters, followed by fragments for every QoS
   control service which may be selected by application receivers. The
   size of the ADSPEC varies depending on the number and size of per-
   service data fragments present and the presence of non-default
   general parameters (described in Section 3.3.5).

   The complete absence of a data fragment for a particular service
   means that the application sender does not know or care about that
   service, and is a signal to intermediate nodes not to add or update
   information about that service to the ADSPEC. It is also a signal to
   application receivers that they should not select that service when
   making reservations.

   Each fragment present is identified by a per-service data header.
   Each header contains a field identifying the service, a break bit,
   and a length field.