rfc2381.txt

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

   controlled by the source (or root) node, or a leaf initiated join
   (LIJ) feature in ATM may be used.  The topic of VC management is
   considered at length in other ISSLL documents [13, 14, 15].

   Figure 2 shows the functions of an edge device, summarizing the work
   not part of IP or ATM abstractly as an InterWorking Function (IWF),
   and segregating the control and data planes.











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


   IP                                                ATM
                         ____________________
                        |        IWF         |
                        |                    |
   admission and   <--> | service mapping    | <-->  ATM
   policy control       | VC management      |       signalling &
                        | address resolution |       admission
                        |....................|       control
                        |                    |
   classification,      |ATM Adaptation Layer|       cell
   policing &      <--> | Segmentation and   | <-->  scheduling/
   scheduling           |  Reassembly        |       shaping
                        | Buffering          |
                         ____________________

           Figure 2: Edge Device Functions showing the IWF


   In the logical view of Figure 2, some functions, such as scheduling,
   are shown separately, since these functions are present on both the
   IP and ATM sides.  However it may be possible in an integrated
   implementation to combine such functions.

   The service mapping and VC management functions can be highly
   interdependent.  For example: (i) Multiple integrated-services flows
   may be aggregated to use one point-to-multipoint VC.  In this case,
   we assume the IP flows are of the same service type and their
   parameters have been merged appropriately.  (ii) The VC management
   function may choose to allocate extra resources in anticipation of
   further reservations or based on an empiric of changing TSpecs.
   (iii) There MUST exist a path for best effort flows and for sending
   the rsvp control messages.  How this interacts with the establishment
   of VCs for QoS traffic may alter the desired characteristics of those
   VCs.  See [13, 14, 15] for further details on VC management.

   Therefore, in discussing the service mapping problem, we will assume
   that the VC management function of the IWF can always express its
   result in terms of an IP-level service with some QoS and TSpec.  The
   service mapping algorithm can then identify the appropriate VC
   parameters as if a new VC were to be created for this service.  The
   VC management function can then use this information consistent with
   its own policy, which determines whether the resulting action uses
   new or existing VCs.








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


1.2 Related Documents

   Earlier ATM Forum documents combined signalling, traffic management
   and other areas into a single document, e.g., UNI 3.0 [4] and UNI 3.1
   [5].  The 3.1 release was used to correct errors and fix alignment
   with the ITU.  While UNI 3.0 and 3.1 are incompatible in terms of
   actual codepoints, the semantics are generally the same.  Therefore,
   we will often refer to UNI 3.x to mean either version of the ATM
   protocol.

   After 3.1, the ATM Forum released documents separately for each
   technical working group.  The UNI Signalling 4.0 [6] and Traffic
   Management 4.0 [7] documents represent a consistent overall ATM
   protocol, and we will sometime refer to the combination as TM/UNI
   4.0.

   Within the IETF, related material includes the work of the rsvp [3],
   int-serv [2, 9, 10, 16, 17] and ion working groups [11, 12].  Rsvp
   defines the resource reservation protocol (which is analogous to
   signalling in ATM). Int-serv defines the behavior and semantics of
   particular services (analogous to the Traffic Management working
   group in the ATM Forum).  Ion defines interworking of IP and ATM for
   traditional Best Effort service, and generally covers issues related
   to IP/ATM routing and addressing.

   A large number of ATM signalling details are covered in RFC 1755
   [10]; e.g., differences between UNI 3.0 and UNI 3.1, encapsulation,
   frame-relay interworking, etc.  These considerations extend to IP
   over ATM with QoS as well.  The description given in this document of
   IP Best Effort service (i.e. the default behavior) over ATM is
   intended to be consistent with RFC 1755 and it's extension for UNI
   4.0 [11], and those documents are to be considered definitive.  For
   non-best-effort services, certain IP/ATM features will diverge from
   the following RFC 1755.  We have attempted to note such differences
   explicitly.  (For example, best effort VCs may be taken down on
   timeout by either edge device, while QoS VCs are only removed by the
   upstream edge device when the corresponding rsvp reservation is
   deleted.)

   Another related document is RFC 1821 [17], which represents an early
   discussion of issues involved with interoperating IP and ATM
   protocols for integrated services and QoS.









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


2.0 Major Protocol Features for Traffic Management and QoS

   The ATM Call Setup is sent by the ingress edge device to the ATM
   network to establish end-to-end (ATM) service.   This setup contains
   the following information.

        Service Category/Broadband Bearer Capability
        AAL Parameters
        Broadband Low Layer Information
        Calling and Called Party Addressing Information
        Traffic Descriptors
        QoS Class and/or Parameters
        Additional Parameters of TM/UNI 4.0

   In this section, we discuss each of these items as they relate to
   creating ATM VCs suitable for GS, CLS and BE services.  We do not
   discuss routing and addressing at all, since they are (at least
   presently) independent of QoS.  Following the section on service
   categories, we discuss tagging and conformance definitions for IP and
   ATM.  These do not appear explicitly as set-up parameters in the
   above list, since they are implied by the policing method used.

2.1 Service Category and Bearer Capability

   The highest level of abstraction distinguishing features of ATM VCs
   is in the service category or bearer capability.  Service categories
   were introduced in TM/UNI 4.0; previously the bearer capability was
   used to discriminate at this level.

   These elements indicate the general properties of a VC: whether there
   is a real-time delay constraint, whether the traffic is constant or
   variable rate, the applicable traffic and QoS description parameters
   and (implicitly) the complexity of some supporting switch mechanisms
   (e.g., ABR).

   For UNI 3.0 and UNI 3.1, there are only two distinct options for
   bearer capabilities (in our context):

        BCOB-A:  constant rate, timing required, unicast/multipoint;
        BCOB-C:  variable rate, timing not required, unicast/multipoint.

   A third capability, BCOB-X, can be used as a substitute for the above
   two capabilities, with its dependent parameters (traffic type and
   timing requirement) set appropriately.  The distinction between the
   BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and
   BCOB-C constructs is whether the ATM network is to provide pure cell
   relay service or interwork with other technologies (with
   interoperable signalling), such as narrowband ISDN.  Where this



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


   distinction is applicable, the appropriate code SHOULD be used (see
   [5] and related ITU specs, e.g., I.371).

   In TM/UNI 4.0 the service categories are:

        Constant Bit Rate (CBR)
        Real-time Variable Bit Rate (rtVBR)
        Non-real-time Variable Bit Rate (nrtVBR)
        Unspecified Bit Rate (UBR)
        Available Bit Rate (ABR)

   The first two of these are real-time services, so that rtVBR is new
   to TM/UNI 4.0.  The ABR service is also new to TM/UNI 4.0.  UBR
   exists in all specifications, although it is called "best effort" in
   UNI 3.x.  In either case it is indicated by the "best effort"
   indication flag (and the QoS Class set to 0).

   The Service Category in TM/UNI 4.0 is encoded into the same signalled
   Information Element (IE) as the Bearer Capability in UNI 3.x, for the
   purpose of backward compatibilty.  Thus, we use the convention of
   referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for
   TM/UNI 4.0 (where the bearer capability is implicit).  When we refer
   to the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we are
   describing a UNI 3.x signalling message.

   In principle, it is possible to support any service through the use
   of BCOB-A/CBR.  This is because the CBR service is equivalent to
   having a "pipe" of a specified bandwidth.  However, it may be
   significantly more efficient to use the other ATM services where
   applicable and available [17].

2.1.1 Service Categories for Guaranteed Service

   There are two possible mappings for GS:

        CBR (BCOB-A)
        rtVBR

   Real-time support is REQUIRED for GS.  Thus in UNI 3.x, the Bearer
   Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used.  In
   TM/UNI 4.0 either CBR or rtVBR is appropriate.  The use of rtVBR may
   encourage recovery of allocated bandwidth left unused by a source.
   It also accommodates more bursty sources with a larger token bucket
   burst parameter, and permits the use of tagging for excess traffic
   (see Section 2.2).






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


   Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good
   matches for the GS service.  These provide no delay estimates and
   cannot guarantee consistently low delay for every packet.

   For BCOB-A or CBR, specification of a peak cell rate (PCR) is
   REQUIRED by ATM standards.  In these cases, PCR is the nominal
   clearing rate with a nominal jitter toleration (bucket size), CDVT.

   When rtVBR is specifed, two rates, PCR and SCR are REQUIRED (by ATM
   standards).  This models bursty traffic with specified peak and
   sustainable rates.  The corresponding ATM token bucket depth values
   are CDVT, and CDVT+BT, respectively.

2.1.2 Service Categories for Controlled Load

   There are three possible good mappings for CLS: