rfc2381.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,315 行 · 第 1/5 页

2.5.1 Translating Traffic Descriptors for Guaranteed Service

   For Guaranteed Service the source TSpec contains peak rate, rate and
   and bucket depth parameters, p_s, r_s, b_s.  The receiver TSpec
   contains corresponding parameters p_r, r_r, b_r.  The (receiver)
   RSpec also has a rate, R.  The two different TSpec rates are intended
   to support receiver heterogeneity, in the sense that receivers can
   accept different rates representing different subsets of the sender's
   traffic.  Whenever rates from different receivers differ, the values
   MUST always be merged appropriately before being mapping into ATM
   parameters.

   Note that when the sender and receiver TSpec rates r_s, r_r differ,
   there is no mechanism specified (in either rsvp or the int-serv
   specs) for indicating which subset of the traffic is to be
   transported.  Implementation of this feature is therefore completely
   network specific.  The policing and scheduling mechanisms may simply
   be parameterized with the (lower) receiver rate, resulting in the
   random loss of traffic sufficient to make up the difference in rates.

   The receiver TSpec rate describes the traffic for which resources are
   to be reserved, and may be used for policing, while the RSpec rate
   (which cannot be smaller) is used (perhaps in an implementation
   specific way) to modify the allocated service bandwidth in order to
   reduce the delay.

   When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic
   descriptor parameters (PCR, SCR, MBS) can be set cannonically as:

        PCR = p_r
        SCR = R
        MBS = b_r.

   There are a number of conditions that may lead to different choices.
   The following discussion is not intended to set hard requirements,
   but to provide some interpretation and guidance on the bounds of
   possible parameter mappings.  The ingress edge device generally
   includes a buffer preceding the ATM network interface.  This buffer
   can be used to absorb bursts that fall within the IP-level TSpec, but
   not within the ATM traffic descriptor.  The minimal REQUIREMENT for
   guaranteed service is that the delay in this buffer MUST NOT exceed
   b/R, and the delays within the ATM network MUST be accurately
   accounted for in the values of Adspec parameters C and D advertised
   by the ingress router (see Section 3.3 below).

   If either an edge device buffer of size b_r exists or the ATM maximum
   burst size (MBS) parameter is at least b_r, then the various rate
   parameters will generally exhibit the following relationship:



Garrett & Borden            Standards Track                    [Page 15]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


        r_r <= SCR <= R <= PCR <= APB <= line rate

        r_r <=       p_r       <= APB

   APB refers to the General Characterization Parameter,
   AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion
   of the PATH message.  APB reflects the narrowest bottleneck rate
   along the path, and so is always no larger than the local line rate.
   The receiver SHOULD choose a peak rate no greater than APB for the
   reservation to be accepted, although the source peak rate, p_s, could
   be higher, as the source does not know the value of APB.  There is no
   advantage to allocating any rate above APB of course, so it is an
   upper bound for all the other parameters.

   We might normally expect to find R <= p_r, as would be necessary for
   the simple mapping of PCR = p_r, SCR = R given above.  However, a
   receiver is free to choose R > p_r to lower the GS delay [8].  In
   this case, PCR cannot be set below R, because a burst of size b
   arriving into the buffer MUST be cleared at rate R to keep the first
   component of GS delay down to b/R.  So here we will have PCR = R.  It
   may seem that PCR = p_r would be sufficient to avoid buffer overflow,
   since data is generated at the source at a rate bounded by p_r.
   However, setting PCR < R, can result in the delay bound advertised by
   C and D not being met.  Also, traffic is always subject to jitter in
   the network, and the arrival rate at a network element can exceed p_r
   for short periods of time.

   In the case R <= p_r, we may still choose PCR such that R <= PCR <
   p_r.  The edge device buffer is then necessary (and sufficient) to
   absorb the bursts (limited to size b_r + C_sum + R D_sum) which
   arrive faster than they depart.  For example, it may be the case that
   the cost of the ATM VC depends on PCR, while the cost of the Internet
   service reservation is not strongly dependent on the IP-level peak
   rate.  The user may then have an incentive to set p_r to APB, while
   the operator of the IP/ATM edge router has an incentive to reduce PCR
   as much as possible.  This may be a realistic concern, since the
   charging models of IP and ATM are historically different as far as
   usage sensitivity, and the value of p_r, if set close to APB, could
   be many times the nominal GS allocated rate of R.  Thus, we can set
   PCR to R, with a buffer of size b_r + C_sum + R D_sum, with no loss
   of traffic, and no violation of the GS delay bound.

   A more subtle, and perhaps controversial case is where we set SCR to
   a value below R.  The major feature of the GS service is to allow a
   receiver to specify the allocated rate R to be larger than the rate
   r_r sufficient to transport the traffic, in order to lower the
   queueing delay (roughly) from b/r + C_TOT/r + D_TOT to b/R + C_TOT/R
   + D_TOT.  To effectively allocate bandwidth R to the flow, we set SCR



Garrett & Borden            Standards Track                    [Page 16]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


   to match R.  (Note it is unnecessary in any case to set SCR above R,
   so the relation, SCR <= R, is still true.)  It is possible to set SCR
   to a value as low as r_r, without violating the delay bounds or
   overflowing the edge device buffer.  With PCR = R, a burst of size b
   will be buffered and sent into the ATM network at rate R, so the last
   byte suffers delay only b/R.  Any further traffic will be limited to
   rate r_r, which is SCR, so with the arriving and departing rates
   matched, its delay will also be no more than b/R.

   While this scenario meets the GS service requirements, the penalty
   for allocating SCR = r_r rather than R is that the delay in the ATM
   network will have a component of MBS/SCR, which will be b/r rather
   than b/R, contained in the D term advertised for the ATM sub-network
   (see further discussion in Section 3.3 below).  It is also true that
   allocating r instead of R in a portion of the path is rather against
   the spirit of GS.  As mentioned above, this mapping may however be
   useful in practice in the case where pricing in the ATM network leads
   to different incentives in the tradeoff between delay and bandwidth
   than those of the user who buys IP integrated services.

   Another point of view on parameter mapping suggests that SCR may
   merely reflect the traffic description, hence SCR = r_r, while the
   service requirement is expressed in the QoS parameter as CDV = b/R.
   Thus the ATM network may internally allocate bandwidth R, but it is
   free to use other methods as well to achieve the delay constraint.
   Mechanisms such as statistical flow/connection aggregation may be
   implemented in the ATM network and hidden from the user (or parameter
   mapping module in the edge router) which sees only the interface
   implemented in the signalled parameters.

   Note that this discussion considers an edge device buffer size of
   b_r.  In practice, it may be necessary for the AAL/segmentation
   module to buffer M bytes in converting packets to cells.  Also an
   additional amount of buffer equal to C_sum + R D_sum is generally
   necessary to absorb jitter imposed by the upstream network [8].

   With ATM, it is possible to have little or no buffer in the edge
   router, because the ATM VC can be set to accept bursts at peak rate.
   This may be unusual, since the edge router normally has enough buffer
   to absorb bursts according to the TSpec token bucket parameters.  We
   consider two cases.  First, if PCR >= p_r, then MBS can be set to b_r
   and no buffering is necessary to absorb non-excessive bursts.  The
   extra buffering needed to absorb jitter can also be transferred to
   MBS.  This effectively moves the buffering across the UNI into the
   ATM network.






Garrett & Borden            Standards Track                    [Page 17]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


   For completeness, we consider an edge router with no burst-absorbing
   buffers and an MBS parameter of approximately zero.  In this case it
   is sufficient to set the rate parameters to PCR = SCR = max (R, p_r).
   This amounts to peak-rate allocation of bandwidth, which will not
   usually be very cost effective.  This case may be relevant where the
   IP routers and ATM switches differ substantially in their buffering
   designs.  IP-level users may typically specify much larger burst
   parameters than can be handled in the ATM subnet.  Peak-rate
   bandwidth allocation provides a means to work around this problem.
   It is also true that intermediate tradeoffs can be formulated, where
   the burst-absorbing buffer is less than b bytes, and SCR is set above
   R and below p_r.  Note that jitter-absorbing buffers (C_sum + R
   D_sum) can not be avoided, generally, by increasing ATM rates, unless
   SCR is set to exceed the physical line rate(s) into the edge device
   for the flow.

   For GS over CBR, the value of PCR may be mapped to the RSpec rate R,
   if the edge device has a buffer of size b_r + C_sum + R D_sum.  With
   little or no burst buffering, the requirements resemble the zero-
   buffer case above, and we have PCR = max (R, p_r).  Additional
   buffers sufficient to absorb network jitter, given by C_sum, D_sum,
   MUST always be provided in the edge router, or in the ATM network via
   MBS.

2.5.2 Translating Traffic Descriptors for Controlled Load Service

   The Controlled Load service TSpec has a peak rate, p, a "token
   bucket" rate, r, and a corresponding token bucket depth parameter, b.
   The receiver TSpec values are used to determine resource allocation,
   and a simple mapping for the nrtVBR service category is given by,

        PCR = p_r
        SCR = r_r
        MBS = b_r.

   The discussions in the preceding section on using edge device buffers
   to reduce PCR and/or MBS apply generally to the CLS over nrtVBR case
   as well.  Extra buffers to accommodate jitter accumulated (beyond the
   b_r burst size allowed at the source) MUST be provided.  For CLS,
   there are no Adspec parameters C and D, so the dimensioning of such
   buffers is an implementation design issue.

   For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate
   (MCR) parameter.  Since there is no corresponding signalled bucket
   depth parameter, the edge device SHOULD have a buffer of at least b_r
   bytes, plus additional buffers to absorb jitter.  With ABR, the ATM
   network can quickly throttle the actual transfer rate down to MCR, so
   a source transmitting above that rate can experience high loss at the



Garrett & Borden            Standards Track                    [Page 18]

RFC 2381         Interoperation of CLS and GS with ATM       August 1998


   ingress edge device when the ATM network becomes congested.

   For CBR, the TSpec rate r_r sets a lower bound on PCR, and again, the
   available buffering in the edge device SHOULD be adequate to
   accommodate possible bursts of b_r.

   The REQUIREMENT for CLS that network delays approximate "best-effort
   service under unloaded conditions", is interpreted here to mean that
   it would be sufficient to allocate bandwidth resources so that the
   last byte of a burst of size b_r sees a delay approximately b_r/r_r.
   For example, a network element with no cross-traffic, a work
   conserving scheduler and an output link rate of r_L, might provide
   delays in the range from M/r_L to b_r/r_L, that are much lower than
   b_r/r_r.  While the access to the full link bandwidth (r_L), as
   reflected in this example, is a more literal interpretation of delay
   "under unloaded conditions" for a shared link, an ATM VC may only
   have access to bandwidth equal to its nominal allocation (some
   implementation specific function of SCR and PCR).

2.5.3 Translating Traffic Descriptors for Best Effort Service

   For Best Effort service, there is no traffic description.  The UBR
   service category allows negotiation of PCR simply to allow the source
   to discover the smallest physical bottleneck along the path.  The
   ingress edge router may set PCR to the ATM line rate, and then when
   the VC setup is complete, the returned value indicates an upper bound
   on throughput.  For UBR service, resources may be allocated for the
   overall service (i.e., not per-VC) using the (implementation
   specific) admission control features of the ATM switches.

   Often a service provider will statically configure large VCs with a
   certain bandwidth allocation to handle all best effort traffic
   between two edge routers.  ABR, CBR or nrtVBR VCs are appropriate for
   this design, with traffic parameters set to comfortably accommodate
   the expected traffic load.  See IETF ION specifications for IP over
   ATM signalling [10, 11].

2.6 QoS Classes and Parameters