rfc2381.txt

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

   In UNI 3.x the quality of service is indicated by a single parameter
   called "QoS Class," which is essentially an index to a network
   specific table of values for the actual QoS parameters.  In TM/UNI
   4.0 three QoS parameters may be individually signalled, and the
   signalled values override those implied by the QoS Class, which is
   still present.  These parameters are the Cell Loss Ratio (CLR), Cell
   Transfer Delay (CTD), and Cell Delay Variation (CDV) [6].





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


   A network provider may choose to associate other parameters, such as
   Severely Errored Cell Block Ratio, with a QoS Class definition, but
   these cannot be signalled individually.  The ATM Forum UNI 3.0, 3.1
   and TM 4.0 specs, following prior ITU specs, give vague qualitative
   definitions for QoS Classes 1 to 4.  (QoS Class 0 is well-defined as
   "no QoS parameters defined".)  Since our mapping is based on these
   specifications, we generally follow this guidance by setting the QoS
   Class value to 0 for UBR and ABR (as REQUIRED), 1 for CBR and rtVBR
   and 3 for nrtVBR.  Note that the QoS Class follows the ATM service
   category, and not the IP service, to avoid combination that are
   unlikely to be supported.  For example, if only nrtVBR is available
   for GS, then choosing QoS Class = 1 would probably result in
   connection failure.  The QoS Class MUST NOT be interpreted as a way
   to add real-time behavior to an inherently non-real-time service.

   The ITU has included a standard set of parameter values for a (small)
   number of QoS Classes in the latest version of Recommendation I.356
   [21].  Network providers may choose to define further network-
   specific QoS Classes in addition to these.  Note that the QoS class
   definitions in the new I.356 version might not align with the model
   we follow from the ATM Forum UNI specs.  Apart from these
   definitions, there is no consistent agreement on QoS Class
   definitions among providers in practice.

   The ATM QoS parameters have no explicitly signalled IP layer
   counterparts.  The values that are signalled in the ATM network are
   determined by the IP service definitions and knowledge of the
   underlying ATM network characteristics, as explained below.

   The ingress edge router SHOULD keep a table of QoS information for
   the set of egress routers that it may establish VCs with.  This table
   may be simplified by using default values, but it will probably be
   good practice to maintain a table of current data for the most
   popular egress points.  An edge device that initiates VC setup
   generally needs to have some way to propose initial value for CDV and
   CTD, even if they are changed by negotiation; so by positing such a
   table, we are not creating any new design burden.  Cached information
   can be updated when VCs are successfully established, and to the
   extent that IP-layer reservations can wait for VCs to complete, the
   values can be refined through iterated negotiation.

   Both GS and CLS REQUIRE that losses of packets due to congestion be
   minimized, so that the loss rate is approximately the same as for an
   unloaded network.  The characteristic loss behavior of the physical
   medium not due to congestion (e.g., bit errors or fading on wireless
   channels) determines the order of the permitted packet loss rate.
   The ingress edge device MUST choose a value of CLR that provides the
   appropriate IP-level packet loss rate.  The CLR value may be uniform



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


   over all egress points in the ATM network, or may differ, e.g., when
   wireless or satellite ATM links are in some paths.  The determination
   of CLR MUST account for the effects of packet size distribution and
   ATM Frame Discard mode (which can change the effective packet loss
   rate by orders of magnitude [22]).

   The ingress router will also tabulate values for the Minimum Path
   Latency (MPL) and estimated queueing delays (D_ATM) for each egress
   point.  The latter will be used as part of the Adspec "D" parameter
   for GS, but its use here applies to CLS as well (when the VC setup
   includes delay parameters).  MPL represents all constant (non-
   congestion related) delays, including propagation delay.  D_ATM
   accounts for the variable component of delays in the ATM network.
   (It may depend on non-signalled parameters such as CDVT.)  Given
   these quantities, a new VC can be set up with delay-related QoS
   parameters given by

        CDV = D_ATM
        CTD = D_ATM + MPL.

   (CDV and CTD may be adjusted (increased) by the slack term in GS, see
   Section 3.3 below.)

   It is interesting (and perhaps unfortunate) to note that in a typical
   GS/rtVBR service, the delay bound advertised can contain two
   components of b/R instead of one.  Consider the simple case where SCR
   = R is the rate allocated to the flow in both IP routers and ATM
   switches along the path, and the buffer allocation is MBS = b.
   Parekh's theory [23], which is the basis of the GS delay formula [8]
   states that the b/R delay term occurs only once, because once a burst
   of size b has been served by a congested node at rate R, the packets
   will not arrive at a subsequent node as a single burst.  However, we
   can't tell a priori if this bottleneck will occur in the ATM network
   or elsewhere in the IP network, so the declaration of CDV SHOULD
   account for it (i.e., CDV >= b/R).  Once CDV is set, the ATM network
   can impose this delay, whether or not the traffic arrives in a burst.
   Since the delay b/R can also occur elsewhere, it cannot be removed
   from the first term of the GS delay formula.  The ATM b/R delay
   component appears in the third term of the GS delay formula, D_tot.
   See Section 3.3 below for more on GS Adspec parameters.  This effect
   may be mitigated when the ATM network employs more efficient
   statistical resource allocation schemes.









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


2.7 Additional Parameters -- Frame Discard Mode

   TM/UNI 4.0 allows the user to choose a mode where the ATM network is
   aware, for the purpose of congestion management, of PDUs larger than
   an ATM cell (i.e., AAL PDUs that correspond in our context to IP
   packets).  This facilitates implementation of algorithms such as
   partial packet discard, where a dropped cell causes subsequent cells
   in the same AAL-5 PDU to be dropped as well.  Several other
   applicable buffer management schemes have been proposed [22, 24].

   Frame discard can improve the efficiency and performance of end-to-
   end protocols such as TCP, since the remaining cells of a damaged PDU
   are generally useless to the receiver.  For IP over ATM, Frame
   Discard MUST always be indicated, if available.

3.0 Additional IP-Integrated Services Protocol Features

3.1 Path Characterization Parameters for IP Integrated Services with ATM

   This section discusses the setting of General Characterization
   Parameters (GCPs) at an ATM egress edge router.  GCPs are signalled
   from IP source to IP destination, and modified by intermediate nodes
   using the Adspec portion of PATH messages in rsvp.  The GS-specific
   Adspec parameters are discussed below in Section 3.3.  These
   parameters are denoted as <x,y> where x is the service and y is the
   parameter number.  Service number 1 indicates default or general
   parameter values.  Please refer to [25] for definitions and details.

   The IS break bit <1,2> MUST, of course, be left alone by
   implementations following these guidelines (as they are presumably
   IS-aware).  Similarly, the router MUST always increment IS_HOPS
   <1,4>.  The GS and CLS service-specific break bits, <2,2> and <5,2>
   respectively, MUST be set if the support of the service is
   inadequate.  In general GS is adequately supported by CBR (BCOB-A)
   and rtVBR service categories, and not adequately supported by UBR,
   ABR and nrtVBR because delays are not controlled.  CLS may be
   adequately supported by all service categories except UBR (or Best
   Effort in UNI 3.x).  See Sections 5, 6 for further discussion.

   For GS, the ATM network MUST meet the delay performance advertised
   through the Adspec parameters, MPL, C, and D.  If it cannot
   predictably meet these requirements, the GS break bit MUST be set.
   Similarly both break bits MUST be set if reservations are honored,
   but sufficient resources to avoid congestion loss are not allocated
   in practice.  If the service break bits are not set, then the
   corresponding service hop counters, <2,4>, <5,4>, MUST be
   incremented.




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


   The Available Path Bandwidth (APB) parameters <x,6> indicate the
   minimum physical bottleneck rate along the path.  This may be
   discoverable in an ATM network as the negotiated PCR value for any
   UBR VC along the same path.  This value MUST be corrected for AAL,
   ATM and physical-layer headers, as necessary, to reflect the
   effective IP datagram bandwidth.  With ATM, it is possible that there
   is some policy limitation on the value of PCR, below the physical
   link bottleneck.  In this case, the advertised value of APB (in
   general, and for each service if the values of APB signalled are
   service specific) MUST reflect this limit, since excess traffic
   beyond this rate will be dropped.  (Note that there is no tagging of
   traffic in excess of PCR for TM/UNI 4.0.)  These values SHOULD
   generally be cached by the ingress router for the set of egress
   routers with which it typically needs to establish VCs.  The APB
   parameters are only adjusted down, to reflect the minimum as the
   composed value.

   In the case of a multipoint VC, several parameters can be different
   for each egress point, e.g., because the characteristics of the
   physical links of the VC branches differ.  When this occurs, the IWF
   at the egress routers MUST correct these values in PATH messages as
   they exit the ATM network.  (We use the word "correct" because the
   ingress router SHOULD set the parameters to a value that is
   appropriate for the largest number of branches, or a value that would
   do the least harm if the egress routers failed to correct such
   parameters for each branch.)  This is the only case where the egress
   router needs to operate on rsvp control messages.  (A similar
   correction MUST be implemented for any non-rsvp set-up mechanism).
   The parameters for which such correction is REQUIRED are the
   Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the
   Path MTU (although for ATM/AAL-5 this may typically be constant), and
   the ATM-specific components of the GS Adspec parameters C_ATM and
   D_ATM.

   The ingress router table SHOULD store values for the ATM-network MPL
   <x,7> for the various egress points.  The composed values <x,8> are
   formed by addition and forwarded along the path.  In the cases where
   ATM routing chooses different paths, depending on the service
   category, for VCs to a given egress point, the table will generally
   reflect different values for each service.  If the ATM network is
   very large and complex, it may become difficult to predict the routes
   that VCs will take once they are set up.  This could be a significant
   source of misconfiguration, resulting in discrepancies between GS
   delay advertisements and actual results.  The RSpec Slack term may be
   useful in mitigating this problem.

   AAL-5 will support any message size up to 65,535 bytes, so setting
   the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for



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


   the LLC/SNAP header) will generally not be an issue.  In the PATH
   Adspec, however, the PATH_MTU parameter <x,10> for each service
   SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19].

3.2 Handling of Excess Traffic

   For IP Integrated Services, network elements will transport traffic
   in excess of the TSpec parameters whenever physical resources
   (bandwidth, buffers and processing) are available.  (In CLS a
   "network element MUST attempt to forward the excess traffic on a
   best-effort basis" under certain conditions; and in GS a traffic
   policers "SHOULD relegate non-conforming datagrams to best effort".)
   While excess traffic SHOULD be supported on a best effort basis, it
   MUST NOT interfere with the QoS (delay and loss) of conforming CLS
   and GS traffic, nor with normal service of non-reserved best effort
   traffic.

   There are several solutions with ATM: the most attractive is to use a
   VBR service category (with an appropriate conformance definition) and
   tag excess traffic as low priority using the CLP bit.  This avoids
   reordering of the flow, but necessitates careful desi