idnits 2.17.1 draft-ietf-issll-atm-mapping-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 73 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 March 1998) is 9542 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2216 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '17') ** Obsolete normative reference: RFC 1483 (ref. '18') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (ref. '19') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mark W. Garrett, 3 ISSLL WG Bellcore 4 Expires: 12 September 1998 5 Marty Borden, 6 Bay Networks 8 12 March 1998 10 Interoperation of Controlled-Load Service and Guaranteed Service with ATM 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document provides guidelines for mapping service classes, and 34 traffic management features and parameters between Internet and ATM 35 technologies. The service mappings are useful for providing 36 effective interoperation and end-to-end Quality of Service for IP 37 Integrated Services networks containing ATM subnetworks. 39 The discussion and specifications given here support the IP 40 integrated services protocols for Guaranteed Service (GS), 41 Controlled-Load Service (CLS) and the ATM Forum UNI specification, 42 versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service 43 over ATM is also included. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119. (Note, in 48 many cases the use of "MUST" reflects our interpretation of the 49 requirements of a related standard, e.g., ATM Forum UNI 4.0, rsvp, 50 etc.) 51 Table of Contents 53 1.0 Introduction ....................................................... 3 54 1.1 General System Architecture .................................... 4 55 1.2 Related Documents .............................................. 7 56 2.0 Major Protocol Features for Traffic Management and QoS ............. 8 57 2.1 Service Category and Bearer Capability ......................... 8 58 2.1.1 Service Categories for Guaranteed Service ................ 9 59 2.1.2 Service Categories for Controlled Load ................... 10 60 2.1.3 Service Categories for Best Effort ....................... 11 61 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions .... 12 62 2.3 ATM Adaptation Layer ........................................... 13 63 2.4 Broadband Low Layer Information ................................ 14 64 2.5 Traffic Descriptors ............................................ 14 65 2.5.1 Translating Traffic Descriptors for Guaranteed Service ... 15 66 2.5.2 Translating Traffic Descriptors for Controlled Load Service 19 67 2.5.3 Translating Traffic Descriptors for Best Effort Service ....20 68 2.6 QoS Classes and Parameters ..................................... 20 69 2.7 Additional Parameters -- Frame Discard Mode .................... 22 70 3.0 Additional IP-Integrated Services Protocol Features ................ 23 71 3.1 Path Characterization Parameters for IP Integrated Services .... 23 72 3.2 Handling of Excess Traffic ..................................... 24 73 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 26 74 4.0 Miscellaneous Items ................................................ 27 75 4.1 Units Conversion ............................................... 27 76 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28 77 5.1 Encoding GS Using Real-Time VBR ................................ 28 78 5.2 Encoding GS Using CBR .......................................... 30 79 5.3 Encoding GS Using Non-Real-Time VBR ............................ 31 80 5.4 Encoding GS Using ABR .......................................... 31 81 5.5 Encoding GS Using UBR .......................................... 31 82 5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 31 83 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 33 84 6.1 Encoding CLS Using Non-Real-Time VBR ........................... 33 85 6.2 Encoding CLS Using ABR ......................................... 34 86 6.3 Encoding CLS Using CBR ......................................... 36 87 6.4 Encoding CLS Using Real-Time VBR ............................... 36 88 6.5 Encoding CLS Using UBR ......................................... 36 89 6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 36 90 7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 38 91 7.1 Encoding Best Effort Service Using UBR ......................... 38 92 8.0 Security Considerations ............................................ 39 93 9.0 Acknowledgements ................................................... 40 94 Appendix 1 Abbreviations .............................................. 40 95 References ............................................................. 41 96 Authors' Addresses ..................................................... 43 98 1.0 Introduction 100 We consider the problem of providing IP Integrated Services [1] with 101 an ATM subnetwork. This document is intended to be consistent with 102 the rsvp protocol [2] for IP-level resource reservation, although it 103 applies also in the general case where GS and CLS services are 104 supported through other mechanisms. In the ATM network, we consider 105 ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, 5]. The 106 latter uses the more complete service model of the ATM Forum's TM 4.0 107 specification [6, 7]. 109 This is a complex problem with many facets. In this document, we 110 focus on the service types, parameters and signalling elements needed 111 for service interoperation. The resulting service mappings can be 112 used to provide effective end-to-end Quality of Service (QoS) for IP 113 traffic that traverses ATM networks. 115 The IP services considered are Guaranteed Service (GS) [8] and 116 Controlled Load Service (CLS) [9]. We also discuss the default Best 117 Effort Service (BE) in parallel with these. Our recommendations for 118 BE are intended to be consistent with RFC 1755 [10], and [11], which 119 define how ATM VCs can be used in support of normal BE IP service. 120 The ATM services we consider are: 122 CBR Constant Bit Rate 123 rtVBR Real-time Variable Bit Rate 124 nrtVBR Non-real-time Variable Bit Rate 125 UBR Unspecified Bit Rate 126 ABR Available Bit Rate 128 In the case of UNI 3.x signalling, where these service are not all 129 clearly distinguishable, we identify the appropriate available 130 services. 132 We recommend the following service mappings, since they follow most 133 naturally from the service definitions: 135 Guaranteed Service -> CBR or rtVBR 136 Controlled Load -> nrtVBR or ABR (with a minimum cell rate) 137 Best Effort -> UBR or ABR 139 For completeness, however, we provide detailed mappings for all 140 service combinations in Sections 5, 6, 7 and identify how each meets 141 or fails to meet the requirements of the higher level IP services. 142 The reason for not restricting mappings to the most obvious or 143 natural ones is that we cannot predict how widely available all of 144 these services will be as ATM deployment evolves. A number of 145 differences in service definitions, such as the treatment of packets 146 in excess of the flow traffic descriptor, make service mapping a 147 relatively complicated subject. 149 The remainder of this introduction provides a general discussion of 150 the system configuration and other assumptions. Section 2 considers 151 the relevant ATM protocol elements and the corresponding features of 152 Guaranteed, Controlled Load and Best Effort services (the latter 153 being the default "service"). Section 3 discusses a number of 154 remaining features of the IP services and how they can be handled on 155 an ATM subnetwork. Section 4 addresses the conversion of traffic 156 descriptors to account for ATM-layer overheads. Section 5 gives the 157 detailed VC setup parameters for Guaranteed Service, and considers 158 the effect of using each of the ATM service categories. Section 6 159 provides a similar treatment for Controlled Load Service. Section 7 160 considers Best Effort service. 162 This document is only a part of the total solution to providing the 163 interworking of IP integrated services with ATM subnetworks. The 164 important issue of VC management, including flow aggregation, is 165 considered in [12,13,14]. We do not consider how routing, QoS 166 sensitive or not, interacts with the use of ATM VCs. We expect that 167 a considerable degree of implementation latitude will exist, even 168 within the guidelines presented here. Many aspects of interworking 169 between IP and ATM will depend on economic factors, and will not be 170 subject to standardization. 172 1.1 General System Architecture 174 We assume that the reader has a general working knowledge of IP, rsvp 175 and ATM protocols. The network architecture we consider is 176 illustrated in Figure 1. An IP-attached host may send unicast 177 datagrams to another host, or may use an IP multicast address to send 178 packets to all of the hosts which have "joined" the multicast "tree". 179 In either case, a destination host may then use RSVP to establish 180 resource reservation in routers along the internet path for the data 181 flow. 183 An ATM network lies in the path (chosen by the IP routing), and 184 consists of one or more ATM switches. It uses SVCs to provide both 185 resources and QoS within the ATM cloud. These connections are set 186 up, added to (in the case of multipoint trees), torn down, and 187 controlled by the edge devices, which act as both IP routers and ATM 188 interfaces, capable of initiating and managing VCs across the ATM 189 user-to-network (UNI) interface. The edge devices are assumed to be 190 fully functional in both the IP int-serv/RSVP protocols and the ATM 191 UNI protocols, as well as translating between them. 193 ATM Cloud 194 ----------------- 195 H ----\ ( ) /------- H 196 H ---- R -- R -- E-( X -- X -- X )-E -- R -- R -- H 197 H ----/ | ( ) \ 198 | ----------------- \------ H 199 H ----------R 201 Figure 1: Network Architecture with Hosts (H), 202 Routers (R), Edge Devices (E) and ATM 203 Switches (X). 205 When considering the edge devices with respect to traffic flowing 206 from source to destination, the upstream edge device is called the 207 "ingress" point and the downstream device the "egress" point. The 208 edge devices may be considered part of the IP internet or part of the 209 ATM cloud, or both. They process RSVP messages, reserve resources, 210 and maintain soft state (in the control path), and classify and 211 schedule packets (in the data path). They also initiate ATM 212 connections by signalling, and accept or refuse connections signalled 213 to them. They police and schedule cells going into the ATM cloud. 214 The service mapping function occurs when an IP-level reservation 215 (RESV message) triggers the edge device to translate the RSVP service 216 requirements into ATM VC (UNI) semantics. 218 A range of VC management policies are possible, which determine 219 whether a flow initiates a new VC or joins an existing one. VCs are 220 managed according to a combination of standards and local policy 221 rules, which are specific to either the implementation (equipment) or 222 the operator (network service provider). Point-to-multipoint 223 connections within the ATM cloud can be used to support general IP 224 multicast flows. In ATM, a point to multipoint connection can be 225 controlled by the source (or root) node, or a leaf initiated join 226 (LIJ) feature in ATM may be used. The topic of VC management is 227 considered at length in other ISSLL documents [12,13,14]. 229 Figure 2 shows the functions of an edge device, summarizing the work 230 not part of IP or ATM abstractly as an InterWorking Function (IWF), 231 and segregating the control and data planes. 233 IP ATM 234 ____________________ 235 | IWF | 236 | | 237 admission and <--> | service mapping | <--> ATM 238 policy control | VC management | signalling & 239 | address resolution | admission 240 |....................| control 241 | | 242 classification, |ATM Adaptation Layer| cell 243 policing & <--> | Segmentation and | <--> scheduling/ 244 scheduling | Reassembly | shaping 245 | Buffering | 246 ____________________ 248 Figure 2: Edge Device Functions showing the IWF 250 In the logical view of Figure 2, some functions, such as scheduling, 251 are shown separately, since these functions are present on both the 252 IP and ATM sides. However it may be possible in an integrated 253 implementation to combine such functions. 255 The service mapping and VC management functions can be highly 256 interdependent. For example: (i) Multiple integrated-services flows 257 may be aggregated to use one point-to-multipoint VC. In this case, 258 we assume the IP flows are of the same service type and their 259 parameters have been merged appropriately. (ii) The VC management 260 function may choose to allocate extra resources in anticipation of 261 further reservations or based on an empiric of changing TSpecs. 262 (iii) There MUST exist a path for best effort flows and for sending 263 the rsvp control messages. How this interacts with the establishment 264 of VCs for QoS traffic may alter the desired characteristics of those 265 VCs. See [12,13,14] for further details on VC management. 267 Therefore, in discussing the service mapping problem, we will assume 268 that the VC management function of the IWF can always express its 269 result in terms of an IP-level service with some QoS and TSpec. The 270 service mapping algorithm can then identify the appropriate VC 271 parameters as if a new VC were to be created for this service. The 272 VC management function can then use this information consistent with 273 its own policy, which determines whether the resulting action uses 274 new or existing VCs. 276 1.2 Related Documents 278 Earlier ATM Forum documents combined signalling, traffic management 279 and other areas into a single document, e.g., UNI 3.0 [3] and UNI 3.1 280 [4]. The 3.1 release was used to correct errors and fix alignment 281 with the ITU. While UNI 3.0 and 3.1 are incompatible in terms of 282 actual codepoints, the semantics are generally the same. Therefore, 283 we will often refer to UNI 3.x to mean either version of the ATM 284 protocol. 286 After 3.1, the ATM Forum released documents separately for each 287 technical working group. The UNI Signalling 4.0 [5] and Traffic 288 Management 4.0 [6] documents represent a consistent overall ATM 289 protocol, and we will sometime refer to the combination as TM/UNI 290 4.0. 292 Within the IETF, related material includes the work of the rsvp [2], 293 int-serv [1, 8, 9, 15, 16] and ion working groups [10, 11]. Rsvp 294 defines the resource reservation protocol (which is analogous to 295 signalling in ATM). Int-serv defines the behavior and semantics of 296 particular services (analogous to the Traffic Management working 297 group in the ATM Forum). Ion defines interworking of IP and ATM for 298 traditional Best Effort service, and generally covers issues related 299 to IP/ATM routing and addressing. 301 A large number of ATM signalling details are covered in RFC 1755 302 [10]; e.g., differences between UNI 3.0 and UNI 3.1, encapsulation, 303 frame-relay interworking, etc. These considerations extend to IP 304 over ATM with QoS as well. The description given in this document of 305 IP Best Effort service (i.e. the default behavior) over ATM is 306 intended to be consistent with RFC 1755 and it's extension for UNI 307 4.0 [11], and those documents are to be considered definitive. For 308 non-best-effort services, certain IP/ATM features will diverge from 309 the following RFC 1755. We have attempted to note such differences 310 explicitly. (For example, best effort VCs may be taken down on 311 timeout by either edge device, while QoS VCs are only removed by the 312 upstream edge device when the corresponding rsvp reservation is 313 deleted.) 315 Another related document is RFC 1821 [17], which represents an early 316 discussion of issues involved with interoperating IP and ATM 317 protocols for integrated services and QoS. 319 2.0 Major Protocol Features for Traffic Management and QoS 321 The ATM Call Setup is sent by the ingress edge device to the ATM 322 network to establish end-to-end (ATM) service. This setup contains 323 the following information. 325 Service Category/Broadband Bearer Capability 326 AAL Parameters 327 Broadband Low Layer Information 328 Calling and Called Party Addressing Information 329 Traffic Descriptors 330 QoS Class and/or Parameters 331 Additional Parameters of TM/UNI 4.0 333 In this section, we discuss each of these items as they relate to 334 creating ATM VCs suitable for GS, CLS and BE services. We do not 335 discuss routing and addressing at all, since they are (at least 336 presently) independent of QoS. Following the section on service 337 categories, we discuss tagging and conformance definitions for IP and 338 ATM. These do not appear explicitly as set-up parameters in the 339 above list, since they are implied by the policing method used. 341 2.1 Service Category and Bearer Capability 343 The highest level of abstraction distinguishing features of ATM VCs 344 is in the service category or bearer capability. Service categories 345 were introduced in TM/UNI 4.0; previously the bearer capability was 346 used to discriminate at this level. 348 These elements indicate the general properties of a VC: whether there 349 is a real-time delay constraint, whether the traffic is constant or 350 variable rate, the applicable traffic and QoS description parameters 351 and (implicitly) the complexity of some supporting switch mechanisms 352 (e.g., ABR). 354 For UNI 3.0 and UNI 3.1, there are only two distinct options for 355 bearer capabilities (in our context): 357 BCOB-A: constant rate, timing required, unicast/multipoint; 358 BCOB-C: variable rate, timing not required, unicast/multipoint. 360 A third capability, BCOB-X, can be used as a substitute for the above 361 two capabilities, with its dependent parameters (traffic type and 362 timing requirement) set appropriately. The distinction between the 363 BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and 364 BCOB-C constructs is whether the ATM network is to provide pure cell 365 relay service or interwork with other technologies (with 366 interoperable signalling), such as narrowband ISDN. Where this 367 distinction is applicable, the appropriate code SHOULD be used (see 368 [5] and related ITU specs, e.g., I.371). 370 In TM/UNI 4.0 the service categories are: 372 Constant Bit Rate (CBR) 373 Real-time Variable Bit Rate (rtVBR) 374 Non-real-time Variable Bit Rate (nrtVBR) 375 Unspecified Bit Rate (UBR) 376 Available Bit Rate (ABR) 378 The first two of these are real-time services, so that rtVBR is new 379 to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR 380 exists in all specifications, although it is called "best effort" in 381 UNI 3.x. In either case it is indicated by the "best effort" 382 indication flag (and the QoS Class set to 0). 384 The Service Category in TM/UNI 4.0 is encoded into the same signalled 385 Information Element (IE) as the Bearer Capability in UNI 3.x, for the 386 purpose of backward compatibilty. Thus, we use the convention of 387 referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for 388 TM/UNI 4.0 (where the bearer capability is implicit). When we refer 389 to the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we are 390 describing a UNI 3.x signalling message. 392 In principle, it is possible to support any service through the use 393 of BCOB-A/CBR. This is because the CBR service is equivalent to 394 having a "pipe" of a specified bandwidth. However, it may be 395 significantly more efficient to use the other ATM services where 396 applicable and available [17]. 398 2.1.1 Service Categories for Guaranteed Service 400 There are two possible mappings for GS: 402 CBR (BCOB-A) 403 rtVBR 405 Real-time support is REQUIRED for GS. Thus in UNI 3.x, the Bearer 406 Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used. In 407 TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may 408 encourage recovery of allocated bandwidth left unused by a source. 409 It also accommodates more bursty sources with a larger token bucket 410 burst parameter, and permits the use of tagging for excess traffic 411 (see Section 2.2). 413 Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good 414 matches for the GS service. These provide no delay estimates and 415 cannot guarantee consistently low delay for every packet. 417 Specification of BCOB-A or CBR REQUIRES specification of a peak cell 418 rate (PCR). In these cases, PCR is the nominal clearing rate with a 419 nominal jitter toleration (bucket size), CDVT. 421 Specification of rtVBR REQUIRES two rates, PCR and SCR. This models 422 bursty traffic with specified peak and sustainable rates. The 423 corresponding ATM token bucket depth values are CDVT, and CDVT+BT, 424 respectively. 426 2.1.2 Service Categories for Controlled Load 428 There are three possible good mappings for CLS: 430 CBR (BCOB-A) 431 nrtVBR (BCOB-C) 432 ABR 434 Note that under UNI 3.x, there are equivalent services to CBR and 435 nrtVBR, but not ABR. The first, with a CBR/BCOB-A connection, 436 provides a higher level of QoS than is necessary, but it may be 437 convenient to simply allocate a fixed-rate "pipe", which we expect to 438 be ubiquitously supported in ATM networks. However unless this is 439 the only choice available, it would probably be wasteful of network 440 resources. 442 The nrtVBR/BCOB-C category is perhaps the best match, since it 443 provides for allocation of bandwidth and buffers with an additional 444 peak rate indication, similar to the CLS TSpec. Excess traffic can 445 be handled by CLP bit tagging with VBR. 447 The ABR category with a positive MCR aligns with the CLS idea of 448 "best effort with a floor." The ATM network agrees to forward cells 449 with a rate of at least MCR, which MUST be directly converted from 450 the token bucket rate of the receiver TSpec. The bucket size 451 parameter measures approximately the amount of buffer necessary at 452 the IWF. This buffer serves to absorb the bursts allowed by the 453 token bucket, since they cannot be passed directly into an ABR VC. 455 The rtVBR category can be used, although the edge device MUST then 456 determine values for CTD and CDV. Since there are no corresponding 457 IP-level parameters, their values are set as a matter of local 458 policy. 460 The UBR category does not provide enough capability for Controlled 461 Load. The point of CLS is to allow an allocation of resources. This 462 is facilitated by the token bucket traffic descriptor, which is 463 unavailable with UBR. 465 2.1.3 Service Categories for Best Effort 467 All of the service categories have the capability to carry Best 468 Effort service, but the natural service category is UBR (or, in UNI 469 3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or 470 rtVBR clearly could be used, and since the service is not real-time, 471 a nrtVBR connection could also be used. In these cases the rate 472 parameter used reflects a bandwidth allocation in support of the 473 ingress edge device's best effort connectivity to the egress edge 474 router. It would be normal for traffic from many source/destination 475 pairs to be aggregated on this connection; indeed, since Best Effort 476 is the default IP behavior, the individual flows are not normally 477 identified or accounted for. CBR may be a preferred solution in the 478 case where best effort traffic is sufficiently highly aggregated that 479 a simple fixed-rate pipe is efficient. Both CBR and nrt-VBR provide 480 explicit bandwidth allocation which may be useful for billing 481 purposes. In the case of UBR, the network operator SHOULD allocate 482 bandwidth for the overall service through the admission control 483 function, although such allocation is not done explicitly per VC. 485 An ABR connection could similarly be used to support Best Effort 486 traffic. Indeed, the support of data communications protocols such 487 as TCP/IP is the explicit purpose for which ABR was designed. It is 488 conceivable that a separate ABR connection would be made for each IP 489 flow, although the normal case would probably have all IP Best Effort 490 traffic with a common egress router sharing a single ABR connection. 492 The rt-VBR service category may be considered less suitable, simply 493 because both the real-time delay constraint and the use of SCR/BT add 494 unnecessary complexity. 496 See specifications from the IETF ion working group [10, 11] for 497 related work on support of Best Effort service with ATM. 499 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions 501 Each ATM cell header carries a Cell Loss Priority (CLP) bit. Cells 502 with CLP=1 are said to be "tagged" or "marked" and have lower 503 priority. This tagging may be done by the source, to indicate 504 relative priority within the VC, or by a switch, to indicate traffic 505 in violation of policing parameters. Options involving the use of 506 tagging are decided at call setup time. 508 A Conformance Definition is a rule that determines whether a cell is 509 conforming to the traffic descriptor of the VC. The conformance 510 definition is given in terms of a Generic Cell Rate Algorithm (GCRA), 511 also known as a "leaky bucket" algorithm, for CBR and VBR services. 512 The conformance definition also specifies rules for tagging traffic 513 in excess of the {SCR, MBS} GCRA traffic descriptor. (Note, the term 514 "compliance" in ATM is used to describe the behavior of a connection, 515 as opposed to "conformance", which applies to a single cell.) 517 The network may tag cells that are non-conforming, rather than 518 dropping them if the VC set-up requests tagging and the network 519 supports the tagging option. When tagging is used and congestion 520 occurs, a switch MUST attempt to discard tagged cells in preference 521 to discarding CLP=0 cells. However, the mechanism for doing this is 522 completely implementation specific. The behavior that best meets the 523 requirements of IP Integrated Services is where tagged cells are 524 treated as "best effort" in the sense that they are transported when 525 bandwidth is available, queued when buffers are available, and 526 dropped when resources are overcommitted. ATM standards, however, do 527 not explicitly specify treatment of tagged traffic. Providers of GS 528 and CLS service with ATM subnetworks SHOULD ascertain the actual 529 behavior of ATM implementation with respect to tagged cells. 531 Since GS and CLS services REQUIRE excess traffic to be treated as 532 best effort, the tagging option SHOULD always be chosen (if 533 supported) in the VC setup as a means of "downgrading" the cells 534 comprising non-conformant packets. The term "best effort" can be 535 interpreted in two ways. The first is as a service class that, for 536 example, may be implemented as a separate queue. The other sense is 537 more generic, meaning that the network makes a best effort to 538 transport the traffic. A reasonable interpretation of this is that a 539 network with no contending traffic would transport the packet, while 540 a very congested network would drop the packet. A mechanism that 541 tags best effort packets with lower loss priority (such as with the 542 ATM CLP bit) would drop some of these packets, but would not reorder 543 the remaining ones with respect to the conforming portion of the 544 flow. The "best effort" mechanism for excess traffic does not 545 necessarily have to be the same as that for best effort "service", as 546 long as it fits this generic sense of best effort. 548 There are three conformance definitions of VBR service (for both 549 rtVBR and nrtVBR) to consider. In VBR, only the conformance 550 definition VBR.3 supports tagging and applies the GCRA with rate PCR 551 to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the 552 CLP=0 cells. This conformance definition SHOULD always be used with 553 a VBR service supporting IP integrated services. For UBR service, 554 conformance definition UBR.2 supports the use of tagging, but a CLP=1 555 cell does not imply non-conformance; rather, it may be used by the 556 network to indicate congestion. 558 In TM/UNI 4.0 tagging is not a feature of the conformance definitions 559 for the CBR or ABR service categories. (Since conformance 560 definitions are generally network specific, some implementations CBR 561 or ABR may, in fact, use tagging in some way.) Wherever an ATM 562 network does support tagging, in the sense of transporting CLP=1 563 cells on a "best effort" basis, it is a useful and preferable 564 mechanism for handling excess traffic. 566 It is always better for the IWF to tag cells when it can anticipate 567 that the ATM network would do so. This is because the IWF knows the 568 IP packet boundaries and can tag all of the cells corresponding to a 569 packet. If left to the ATM layer UPC, the network would inevitably 570 drop some of the cells of a packet while carrying others, which would 571 then be dropped by the receiver. Therefore, the IWF, knowing the VC 572 GCRA parameters, SHOULD always anticipate the cells which will be 573 tagged by the ATM UPC and tag all of the cells uniformly across each 574 affected packet. See Section 3.2 for further discussion of excess 575 traffic. 577 2.3 ATM Adaptation Layer 579 The AAL type 5 encoding SHOULD be used, as specified in RFC 1483 and 580 RFC 1755. AAL-5 REQUIRES specification of the maximum SDU size in 581 both the forward and reverse directions. Both GS and CLS specify a 582 maximum packet size, M, as part of the TSpec and this value SHOULD be 583 used (corrected for AAL headers) as the maximum SDU in each direction 584 for unicast connections, and for unidirectional point-to-multipoint 585 connections. When multiple flows are aggregated into a single VC, 586 the M parameters of the receiver TSpecs are merged according to rules 587 given in the GS and CLS specs. 589 2.4 Broadband Low Layer Information 591 The B-LLI Information Element is transferred transparently by the ATM 592 network between the edge devices and is used to specify the 593 encapsulation method. Multiple B-LLI IEs may be sent as part of 594 negotiation. The LLC/SNAP encapsulation [18] SHOULD be supported as 595 the default, but "null" or "VC encapsulation" MAY also be allowed. 596 Implementations SHOULD follow RFC 1577 [19] and RFC 1755 [10] for 597 BLLI usage. 599 2.5 Traffic Descriptors 601 The ATM traffic descriptor always contains a peak cell rate (PCR) 602 (for each direction). For VBR services it also contains a 603 sustainable cell rate (SCR) and maximum burst size (MBS). The SCR 604 and MBS form a leaky bucket pair (rate, depth), while the bucket 605 depth parameter for PCR is CDVT. Note that CDVT is not signalled 606 explicitly, but is determined by the network operator, and can be 607 viewed as a measure of the jitter imposed by the network. 609 Since CDVT is generally presumed to be small (equivalent to a few 610 cells of token bucket depth), and cannot be set independently for 611 each connection, it cannot be used to account for the burstiness 612 permitted by b of the IP-layer TSpec. Additional buffering may be 613 needed at the IWF to account for the depth of the token bucket. 615 The ATM Burst Tolerance (BT) is equivalent to MBS (see TM 4.0 [6] for 616 the exact equation). They are both expressions of the bucket depth 617 parameter associated with SCR. The units of BT are time while the 618 units of MBS are cells. Since both SCR and MBS are signalled, they 619 can be computed directly from the IP layer traffic description. The 620 specific manner in which resources are allocated from the traffic 621 description is implementation specific. Note that when translating 622 the traffic parameters, the segmentation overhead and minimum policed 623 unit need to be taken into account (see Section 4.1 below). 625 In ATM UNI Signalling 4.0 there are the notions of Alternative 626 Traffic Descriptors and Minimal Traffic Descriptors. Alternative 627 Traffic Descriptors enumerate other acceptable choices for traffic 628 descriptors and are not considered here. Minimal Traffic Descriptors 629 are used in "negotiation," which refers to the specific way in which 630 an ATM connection is set up. To illustrate, roughly, taking PCR as 631 an example: A minimal PCR and a requested PCR are signalled, the 632 requested PCR being the usual item signalled, and the minimal PCR 633 being the absolute minimum that the source edge device will accept. 634 When both minimal and requested parameters are present, the 635 intermediate switches along the path may reduce the requested PCR to 636 a "comfortable" level. This choice is part of admission control, and 637 is therefore implementation specific. If at any point the requested 638 PCR falls below the minimal PCR then the call is cleared. Minimal 639 Traffic Descriptors can be used to present an acceptable range for 640 parameters and ensure a higher likelihood of call admission. In 641 general, our discussion of connection parameters assumes the values 642 resulting from successful connection setup. 644 The Best Effort indicator (used only with UBR) and Tagging indicators 645 (see Section 2.2) are also part of the signalled information element 646 (IE) containing the traffic descriptor. In the UNI 4.0 traffic 647 descriptor IE there is an additional parameter, the Frame Discard 648 indicator, which is discussed below in Section 2.7. 650 2.5.1 Translating Traffic Descriptors for Guaranteed Service 652 For Guaranteed Service the source TSpec contains peak rate, rate and 653 and bucket depth parameters, p_s, r_s, b_s. The receiver TSpec 654 contains corresponding parameters p_r, r_r, b_r. The (receiver) 655 RSpec also has a rate, R. The two different TSpec rates are intended 656 to support receiver heterogeneity, in the sense that receivers can 657 accept different rates representing different subsets of the sender's 658 traffic. Whenever rates from different receivers differ, the values 659 MUST always be merged appropriately before being mapping into ATM 660 parameters. 662 Note that when the sender and receiver TSpec rates r_s, r_r differ, 663 there is no mechanism specified (in either rsvp or the int-serv 664 specs) for indicating which subset of the traffic is to be 665 transported. Implementation of this feature is therefore completely 666 network specific. The policing and scheduling mechanisms may simply 667 be parameterized with the (lower) receiver rate, resulting in the 668 random loss of traffic sufficient to make up the difference in rates. 670 The receiver TSpec rate describes the traffic for which resources are 671 to be reserved, and may be used for policing, while the RSpec rate 672 (which cannot be smaller) is used (perhaps in an implementation 673 specific way) to modify the allocated service bandwidth in order to 674 reduce the delay. 676 When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic 677 descriptor parameters (PCR, SCR, MBS) can be set cannonically as: 679 PCR = p_r 680 SCR = R 681 MBS = b_r. 683 There are a number of conditions that may lead to different choices. 684 The following discussion is not intended to set hard requirements, 685 but to provide some interpretation and guidance on the bounds of 686 possible parameter mappings. The ingress edge device generally 687 includes a buffer preceding the ATM network interface. This buffer 688 can be used to absorb bursts that fall within the IP-level TSpec, but 689 not within the ATM traffic descriptor. The minimal REQUIREMENT for 690 guaranteed service is that the delay in this buffer MUST NOT exceed 691 b/R, and the delays within the ATM network MUST be accurately 692 accounted for in the values of Adspec parameters C and D advertised 693 by the ingress router (see Section 3.3 below). 695 If either an edge device buffer of size b_r exists or the ATM maximum 696 burst size (MBS) parameter is at least b_r, then the various rate 697 parameters will generally exhibit the following relationship: 699 r_r <= SCR <= R <= PCR <= APB <= line rate 701 r_r <= p_r <= APB 703 APB refers to the General Characterization Parameter, 704 AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion 705 of the PATH message. APB reflects the narrowest bottleneck rate 706 along the path, and so is always no larger than the local line rate. 707 The receiver SHOULD choose a peak rate no greater than APB for the 708 reservation to be accepted, although the source peak rate, p_s, could 709 be higher, as the source does not know the value of APB. There is no 710 advantage to allocating any rate above APB of course, so it is an 711 upper bound for all the other parameters. 713 We might normally expect to find R <= p_r, as would be necessary for 714 the simple mapping of PCR = p_r, SCR = R given above. However, a 715 receiver is free to choose R > p_r to lower the GS delay [8]. In 716 this case, PCR cannot be set below R, because a burst of size b 717 arriving into the buffer MUST be cleared at rate R to keep the first 718 component of GS delay down to b/R. So here we will have PCR = R. It 719 may seem that PCR = p_r would be sufficient to avoid buffer overflow, 720 since data is generated at the source at a rate bounded by p_r. 721 However, setting PCR < R, can result in the delay bound advertised by 722 C and D not being met. Also, traffic is always subject to jitter in 723 the network, and the arrival rate at a network element can exceed p_r 724 for short periods of time. 726 In the case R <= p_r, we may still choose PCR such that R <= PCR < 727 p_r. The edge device buffer is then necessary (and sufficient) to 728 absorb the bursts (limited to size b_r + C_sum + R D_sum) which 729 arrive faster than they depart. For example, it may be the case that 730 the cost of the ATM VC depends on PCR, while the cost of the Internet 731 service reservation is not strongly dependent on the IP-level peak 732 rate. The user may then have an incentive to set p_r to APB, while 733 the operator of the IP/ATM edge router has an incentive to reduce PCR 734 as much as possible. This may be a realistic concern, since the 735 charging models of IP and ATM are historically different as far as 736 usage sensitivity, and the value of p_r, if set close to APB, could 737 be many times the nominal GS allocated rate of R. Thus, we can set 738 PCR to R, with a buffer of size b_r + C_sum + R D_sum, with no loss 739 of traffic, and no violation of the GS delay bound. 741 A more subtle, and perhaps controversial case is where we set SCR to 742 a value below R. The major feature of the GS service is to allow a 743 receiver to specify the allocated rate R to be larger than the rate 744 r_r sufficient to transport the traffic, in order to lower the 745 queueing delay (roughly) from b/r + C_TOT/r + D_TOT to b/R + C_TOT/R 746 + D_TOT. To effectively allocate bandwidth R to the flow, we set SCR 747 to match R. (Note it is unnecessary in any case to set SCR above R, 748 so the relation, SCR <= R, is still true.) It is possible to set SCR 749 to a value as low as r_r, without violating the delay bounds or 750 overflowing the edge device buffer. With PCR = R, a burst of size b 751 will be buffered and sent into the ATM network at rate R, so the last 752 byte suffers delay only b/R. Any further traffic will be limited to 753 rate r_r, which is SCR, so with the arriving and departing rates 754 matched, its delay will also be no more than b/R. 756 While this scenario meets the GS service requirements, the penalty 757 for allocating SCR = r_r rather than R is that the delay in the ATM 758 network will have a component of MBS/SCR, which will be b/r rather 759 than b/R, contained in the D term advertised for the ATM sub-network 760 (see further discussion in Section 3.3 below). It is also true that 761 allocating r instead of R in a portion of the path is rather against 762 the spirit of GS. As mentioned above, this mapping may however be 763 useful in practice in the case where pricing in the ATM network leads 764 to different incentives in the tradeoff between delay and bandwidth 765 than those of the user who buys IP integrated services. 767 Another point of view on parameter mapping suggests that SCR may 768 merely reflect the traffic description, hence SCR = r_r, while the 769 service requirement is expressed in the QoS parameter as CDV = b/R. 770 Thus the ATM network may internally allocate bandwidth R, but it is 771 free to use other methods as well to achieve the delay constraint. 772 Mechanisms such as statistical flow/connection aggregation may be 773 implemented in the ATM network and hidden from the user (or parameter 774 mapping module in the edge router) which sees only the interface 775 implemented in the signalled parameters. 777 Note that this discussion considers an edge device buffer size of 778 b_r. In practice, it may be necessary for the AAL/segmentation 779 module to buffer M bytes in converting packets to cells. Also an 780 additional amount of buffer equal to C_sum + R D_sum is generally 781 necessary to absorb jitter imposed by the upstream network [8]. 783 With ATM, it is possible to have little or no buffer in the edge 784 router, because the ATM VC can be set to accept bursts at peak rate. 785 This may be unusual, since the edge router normally has enough buffer 786 to absorb bursts according to the TSpec token bucket parameters. We 787 consider two cases. First, if PCR >= p_r, then MBS can be set to b_r 788 and no buffering is necessary to absorb non-excessive bursts. The 789 extra buffering needed to absorb jitter can also be transferred to 790 MBS. This effectively moves the buffering across the UNI into the 791 ATM network. 793 For completeness, we consider an edge router with no burst-absorbing 794 buffers and an MBS parameter of approximately zero. In this case it 795 is sufficient to set the rate parameters to PCR = SCR = max (R, p_r). 796 This amounts to peak-rate allocation of bandwidth, which will not 797 usually be very cost effective. This case may be relevant where the 798 IP routers and ATM switches differ substantially in their buffering 799 designs. IP-level users may typically specify much larger burst 800 parameters than can be handled in the ATM subnet. Peak-rate 801 bandwidth allocation provides a means to work around this problem. 802 It is also true that intermediate tradeoffs can be formulated, where 803 the burst-absorbing buffer is less than b bytes, and SCR is set above 804 R and below p_r. Note that jitter-absorbing buffers (C_sum + R 805 D_sum) can not be avoided, generally, by increasing ATM rates, unless 806 SCR is set to exceed the physical line rate(s) into the edge device 807 for the flow. 809 For GS over CBR, the value of PCR may be mapped to the RSpec rate R, 810 if the edge device has a buffer of size b_r + C_sum + R D_sum. With 811 little or no burst buffering, the requirements resemble the zero- 812 buffer case above, and we have PCR = max (R, p_r). Additional 813 buffers sufficient to absorb network jitter, given by C_sum, D_sum, 814 MUST always be provided in the edge router, or in the ATM network via 815 MBS. 817 2.5.2 Translating Traffic Descriptors for Controlled Load Service 819 The Controlled Load service TSpec has a peak rate, p, a "token 820 bucket" rate, r, and a corresponding token bucket depth parameter, b. 821 The receiver TSpec values are used to determine resource allocation, 822 and a simple mapping for the nrtVBR service category is given by, 824 PCR = p_r 825 SCR = r_r 826 MBS = b_r. 828 The discussions in the preceding section on using edge device buffers 829 to reduce PCR and/or MBS apply generally to the CLS over nrtVBR case 830 as well. Extra buffers to accommodate jitter accumulated (beyond the 831 b_r burst size allowed at the source) MUST be provided. For CLS, 832 there are no Adspec parameters C and D, so the dimensioning of such 833 buffers is an implementation design issue. 835 For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate 836 (MCR) parameter. Since there is no corresponding signalled bucket 837 depth parameter, the edge device SHOULD have a buffer of at least b_r 838 bytes, plus additional buffers to absorb jitter. With ABR, the ATM 839 network can quickly throttle the actual transfer rate down to MCR, so 840 a source transmitting above that rate can experience high loss at the 841 ingress edge device when the ATM network becomes congested. 843 For CBR, the TSpec rate r_r sets a lower bound on PCR, and again, the 844 available buffering in the edge device SHOULD be adequate to 845 accommodate possible bursts of b_r. 847 The REQUIREMENT for CLS that network delays approximate "best-effort 848 service under unloaded conditions", is interpreted here to mean that 849 it would be sufficient to allocate bandwidth resources so that the 850 last byte of a burst of size b_r sees a delay approximately b_r/r_r. 851 For example, a network element with no cross-traffic, a work 852 conserving scheduler and an output link rate of r_L, might provide 853 delays in the range from M/r_L to b_r/r_L, that are much lower than 854 b_r/r_r. While the access to the full link bandwidth (r_L), as 855 reflected in this example, is a more literal interpretation of delay 856 "under unloaded conditions" for a shared link, an ATM VC may only 857 have access to bandwidth equal to its nominal allocation (some 858 implementation specific function of SCR and PCR). 860 2.5.3 Translating Traffic Descriptors for Best Effort Service 862 For Best Effort service, there is no traffic description. The UBR 863 service category allows negotiation of PCR simply to allow the source 864 to discover the smallest physical bottleneck along the path. The 865 ingress edge router may set PCR to the ATM line rate, and then when 866 the VC setup is complete, the returned value indicates an upper bound 867 on throughput. For UBR service, resources may be allocated for the 868 overall service (i.e., not per-VC) using the (implementation 869 specific) admission control features of the ATM switches. 871 Often a service provider will statically configure large VCs with a 872 certain bandwidth allocation to handle all best effort traffic 873 between two edge routers. ABR, CBR or nrtVBR VCs are appropriate for 874 this design, with traffic parameters set to comfortably accommodate 875 the expected traffic load. See IETF ION specifications for IP over 876 ATM signalling [10,11]. 878 2.6 QoS Classes and Parameters 880 In UNI 3.x the quality of service is indicated by a single parameter 881 called "QoS Class," which is essentially an index to a network 882 specific table of values for the actual QoS parameters. In TM/UNI 883 4.0 three QoS parameters may be individually signalled, and the 884 signalled values override those implied by the QoS Class, which is 885 still present. These parameters are the Cell Loss Ratio (CLR), Cell 886 Transfer Delay (CTD), and Cell Delay Variation (CDV) [6]. 888 A network provider may choose to associate other parameters, such as 889 Severely Errored Cell Block Ratio, with a QoS Class definition, but 890 these cannot be signalled individually. The ATM Forum UNI 3.0, 3.1 891 and TM 4.0 specs, following prior ITU specs, give vague qualitative 892 definitions for QoS Classes 1 to 4. (QoS Class 0 is well-defined as 893 "no QoS parameters defined".) Since our mapping is based on these 894 specifications, we generally follow this guidance by setting the QoS 895 Class value to 0 for UBR and ABR (as REQUIRED), 1 for CBR and rtVBR 896 and 3 for nrtVBR. Note that the QoS Class follows the ATM service 897 category, and not the IP service, to avoid combination that are 898 unlikely to be supported. For example, if only nrtVBR is available 899 for GS, then choosing QoS Class = 1 would probably result in 900 connection failure. The QoS Class MUST NOT be interpreted as a way 901 to add real-time behavior to an inherently non-real-time service. 903 The ITU has included a standard set of parameter values for a (small) 904 number of QoS Classes in the latest version of Recommendation I.356 905 [20]. Network providers may choose to define further network- 906 specific QoS Classes in addition to these. Note that the QoS class 907 definitions in the new I.356 version might not align with the model 908 we follow from the ATM Forum UNI specs. Apart from these 909 definitions, there is no consistent agreement on QoS Class 910 definitions among providers in practice. 912 The ATM QoS parameters have no explicitly signalled IP layer 913 counterparts. The values that are signalled in the ATM network are 914 determined by the IP service definitions and knowledge of the 915 underlying ATM network characteristics, as explained below. 917 The ingress edge router SHOULD keep a table of QoS information for 918 the set of egress routers that it may establish VCs with. This table 919 may be simplified by using default values, but it will probably be 920 good practice to maintain a table of current data for the most 921 popular egress points. An edge device that initiates VC setup 922 generally needs to have some way to propose initial value for CDV and 923 CTD, even if they are changed by negotiation; so by positing such a 924 table, we are not creating any new design burden. Cached information 925 can be updated when VCs are successfully established, and to the 926 extent that IP-layer reservations can wait for VCs to complete, the 927 values can be refined through iterated negotiation. 929 Both GS and CLS REQUIRE that losses of packets due to congestion be 930 minimized, so that the loss rate is approximately the same as for an 931 unloaded network. The characteristic loss behavior of the physical 932 medium not due to congestion (e.g., bit errors or fading on wireless 933 channels) determines the order of the permitted packet loss rate. 934 The ingress edge device MUST choose a value of CLR that provides the 935 appropriate IP-level packet loss rate. The CLR value may be uniform 936 over all egress points in the ATM network, or may differ, e.g., when 937 wireless or satellite ATM links are in some paths. The determination 938 of CLR MUST account for the effects of packet size distribution and 939 ATM Frame Discard mode (which can change the effective packet loss 940 rate by orders of magnitude [21]). 942 The ingress router will also tabulate values for the Minimum Path 943 Latency (MPL) and estimated queueing delays (D_ATM) for each egress 944 point. The latter will be used as part of the Adspec "D" parameter 945 for GS, but its use here applies to CLS as well (when the VC setup 946 includes delay parameters). MPL represents all constant (non- 947 congestion related) delays, including propagation delay. D_ATM 948 accounts for the variable component of delays in the ATM network. 949 (It may depend on non-signalled parameters such as CDVT.) Given 950 these quantities, a new VC can be set up with delay-related QoS 951 parameters given by 952 CDV = D_ATM 953 CTD = D_ATM + MPL. 955 (CDV and CTD may be adjusted (increased) by the slack term in GS, see 956 Section 3.3 below.) 958 It is interesting (and perhaps unfortunate) to note that in a typical 959 GS/rtVBR service, the delay bound advertised can contain two 960 components of b/R instead of one. Consider the simple case where SCR 961 = R is the rate allocated to the flow in both IP routers and ATM 962 switches along the path, and the buffer allocation is MBS = b. 963 Parekh's theory [22], which is the basis of the GS delay formula [8] 964 states that the b/R delay term occurs only once, because once a burst 965 of size b has been served by a congested node at rate R, the packets 966 will not arrive at a subsequent node as a single burst. However, we 967 can't tell a priori if this bottleneck will occur in the ATM network 968 or elsewhere in the IP network, so the declaration of CDV SHOULD 969 account for it (i.e., CDV >= b/R). Once CDV is set, the ATM network 970 can impose this delay, whether or not the traffic arrives in a burst. 971 Since the delay b/R can also occur elsewhere, it cannot be removed 972 from the first term of the GS delay formula. The ATM b/R delay 973 component appears in the third term of the GS delay formula, D_tot. 974 See Section 3.3 below for more on GS Adspec parameters. This effect 975 may be mitigated when the ATM network employs more efficient 976 statistical resource allocation schemes. 978 2.7 Additional Parameters -- Frame Discard Mode 980 TM/UNI 4.0 allows the user to choose a mode where the ATM network is 981 aware, for the purpose of congestion management, of PDUs larger than 982 an ATM cell (i.e., AAL PDUs that correspond in our context to IP 983 packets). This facilitates implementation of algorithms such as 984 partial packet discard, where a dropped cell causes subsequent cells 985 in the same AAL-5 PDU to be dropped as well. Several other 986 applicable buffer management schemes have been proposed [21, 23]. 988 Frame discard can improve the efficiency and performance of end-to- 989 end protocols such as TCP, since the remaining cells of a damaged PDU 990 are generally useless to the receiver. For IP over ATM, Frame 991 Discard MUST always be indicated, if available. 993 3.0 Additional IP-Integrated Services Protocol Features 995 3.1 Path Characterization Parameters for IP Integrated Services with ATM 997 This section discusses the setting of General Characterization 998 Parameters (GCPs) at an ATM egress edge router. GCPs are signalled 999 from IP source to IP destination, and modified by intermediate nodes 1000 using the Adspec portion of PATH messages in rsvp. The GS-specific 1001 Adspec parameters are discussed below in Section 3.3. These 1002 parameters are denoted as where x is the service and y is the 1003 parameter number. Service number 1 indicates default or general 1004 parameter values. Please refer to [24] for definitions and details. 1006 The IS break bit <1,2> MUST, of course, be left alone by 1007 implementations following these guidelines (as they are presumably 1008 IS-aware). Similarly, the router MUST always increment IS_HOPS 1009 <1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2> 1010 respectively, MUST be set if the support of the service is 1011 inadequate. In general GS is adequately supported by CBR (BCOB-A) 1012 and rtVBR service categories, and not adequately supported by UBR, 1013 ABR and nrtVBR because delays are not controlled. CLS may be 1014 adequately supported by all service categories except UBR (or Best 1015 Effort in UNI 3.x). See Sections 5, 6 for further discussion. 1017 For GS, the ATM network MUST meet the delay performance advertised 1018 through the Adspec parameters, MPL, C, and D. If it cannot 1019 predictably meet these requirements, the GS break bit MUST be set. 1020 Similarly both break bits MUST be set if reservations are honored, 1021 but sufficient resources to avoid congestion loss are not allocated 1022 in practice. If the service break bits are not set, then the 1023 corresponding service hop counters, <2,4>, <5,4>, MUST be 1024 incremented. 1026 The Available Path Bandwidth (APB) parameters indicate the 1027 minimum physical bottleneck rate along the path. This may be 1028 discoverable in an ATM network as the negotiated PCR value for any 1029 UBR VC along the same path. This value MUST be corrected for AAL, 1030 ATM and physical-layer headers, as necessary, to reflect the 1031 effective IP datagram bandwidth. With ATM, it is possible that there 1032 is some policy limitation on the value of PCR, below the physical 1033 link bottleneck. In this case, the advertised value of APB (in 1034 general, and for each service if the values of APB signalled are 1035 service specific) MUST reflect this limit, since excess traffic 1036 beyond this rate will be dropped. (Note that there is no tagging of 1037 traffic in excess of PCR for TM/UNI 4.0.) These values SHOULD 1038 generally be cached by the ingress router for the set of egress 1039 routers with which it typically needs to establish VCs. The APB 1040 parameters are only adjusted down, to reflect the minimum as the 1041 composed value. 1043 In the case of a multipoint VC, several parameters can be different 1044 for each egress point, e.g., because the characteristics of the 1045 physical links of the VC branches differ. When this occurs, the IWF 1046 at the egress routers MUST correct these values in PATH messages as 1047 they exit the ATM network. (We use the word "correct" because the 1048 ingress router SHOULD set the parameters to a value that is 1049 appropriate for the largest number of branches, or a value that would 1050 do the least harm if the egress routers failed to correct such 1051 parameters for each branch.) This is the only case where the egress 1052 router needs to operate on rsvp control messages. (A similar 1053 correction MUST be implemented for any non-rsvp set-up mechanism). 1054 The parameters for which such correction is REQUIRED are the 1055 Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the 1056 Path MTU (although for ATM/AAL-5 this may typically be constant), and 1057 the ATM-specific components of the GS Adspec parameters C_ATM and 1058 D_ATM. 1060 The ingress router table SHOULD store values for the ATM-network MPL 1061 for the various egress points. The composed values are 1062 formed by addition and forwarded along the path. In the cases where 1063 ATM routing chooses different paths, depending on the service 1064 category, for VCs to a given egress point, the table will generally 1065 reflect different values for each service. If the ATM network is 1066 very large and complex, it may become difficult to predict the routes 1067 that VCs will take once they are set up. This could be a significant 1068 source of misconfiguration, resulting in discrepancies between GS 1069 delay advertisements and actual results. The RSpec Slack term may be 1070 useful in mitigating this problem. 1072 AAL-5 will support any message size up to 65,535 bytes, so setting 1073 the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for 1074 the LLC/SNAP header) will generally not be an issue. In the PATH 1075 Adspec, however, the PATH_MTU parameter for each service 1076 SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19]. 1078 3.2 Handling of Excess Traffic 1080 CLS REQUIRES and GS RECOMMENDS that network elements transport 1081 traffic in excess of the TSpec parameters whenever physical resources 1082 (bandwidth, buffers and processing) are available. While excess 1083 traffic SHOULD be supported on a best effort basis, it MUST NOT 1084 interfere with the QoS (delay and loss) of conforming CLS and GS 1085 traffic, nor with normal service of non-reserved best effort traffic. 1087 There are several solutions with ATM: the most attractive is to use a 1088 VBR service category (with an appropriate conformance definition) and 1089 tag excess traffic as low priority using the CLP bit. This avoids 1090 reordering of the flow, but necessitates careful design of the egress 1091 router scheduler. To avoid reordering, the excess traffic can be 1092 queued with conforming traffic. A threshold SHOULD be used to ensure 1093 that conforming traffic is not unnecessarily delayed by the excess. 1094 Also, for GS, the extra delay that would be incurred due to excess 1095 traffic in the queue ahead of conforming packets would have to be 1096 accurately reflected in the delay advertisement. Note that the 1097 ingress router SHOULD tag all cells of each non-conforming packet, 1098 rather than letting the ATM network apply tagging due to ATM-level 1099 non-conformance. 1101 There is no requirement in ATM standards that tagged cells, marked 1102 either by the user or by policing, be transported if possible. 1103 Therefore, the operator of an edge router supporting IP-IS SHOULD 1104 ascertain the actual behavior of the ATM equipment in the path, which 1105 may span multiple administrative domains in the ATM network. If 1106 tagged cells are simply dropped at some point, regardless of load, 1107 then the operator may consider setting the break bit, at least for 1108 CLS service. 1110 The other solutions generally involve a separate VC to carry the 1111 excess. A distinct VC can be set up for each VC supporting a GS or 1112 CLS flow, or, if many flows are aggregated into a single QoS VC, then 1113 another VC can handle the excess traffic for that set of flows. A VC 1114 can be set up to handle all excess traffic from the ingress router to 1115 the egress point. Since the QoS of the excess traffic is not 1116 particularly constrained, the design is quite flexible. However, 1117 using a separate VC may cause misordering of packets within a flow. 1118 The service category for the excess-traffic VC may typically be UBR 1119 or ABR, although one could use CBR or nrtVBR if the excess traffic 1120 were predictable enough to know what rate to allocate. (This 1121 wouldn't normally be expected for excess traffic, though.) 1123 Whether a separate VC is used may be influenced by the design of the 1124 router scheduler. The CLS spec suggests two possible 1125 implementations: one where excess traffic shares the Best Effort 1126 class scheduler allocation, but at lower priority than other best 1127 effort traffic. The other, where a separate allocation is made. The 1128 first would allow excess traffic to use the same VC as normal best 1129 effort traffic, and the second would suggest a separate VC. 1131 TM/UNI 4.0. does not support tagging of traffic in excess of PCR. 1132 Although UNI 3.x does have a separate PCR parameter for CLP=0 cells 1133 only, we do not recommend using this feature for reasons of 1134 interoperability with TM/UNI 4.0 equipment. This restricts CBR VCs 1135 to use solutions other than tagging. The value of PCR can be set 1136 higher than necessary for conformant traffic, in an effort to support 1137 excess traffic on the same VC. In some cases this may be a viable 1138 solution, such as when there is little additional cost imposed for a 1139 high PCR. If PCR can be set as high as APB, then the excess traffic 1140 is fully accommodated. 1142 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term 1144 The Adspec is used by the Guaranteed Service to allow a receiver to 1145 calculate the worst-case delay associated with a GS flow. Three 1146 quantities, C, D, and MPL, are accumulated (by simple addition of 1147 components corresponding to each network element) in the PATH message 1148 from source to receiver. The resulting delay values can be different 1149 for each unique receiver. The maximum delay is computed as 1151 delay <= b_r/R + C_TOT/R + D_TOT + MPL 1153 The Minimum Path Latency (MPL) includes propagation delay, while 1154 b_r/R accounts for bursts due to the source and C and D include other 1155 queueing, scheduling and serialization delays. (We neglect the 1156 effect of maximum packet size and peak rate here; see the GS 1157 specification [8] for a more detailed equation.) The service rate 1158 requested by the receiver, R, can be greater than the TSpec rate, 1159 r_r, resulting in lower delay. The burst size, b_r, is the leaky 1160 bucket parameter from the receiver TSpec. 1162 The values of C and D that a router advertises depend on both the 1163 router packet scheduler and the characteristics of the subnet 1164 attached to the router. Each router (or the source host) takes 1165 responsibility for its downstream subnet in its advertisement. For 1166 example, if the subnet is a simple point-to-point link, the subnet- 1167 specific parts of C and D need to account for the link transmission 1168 rate and MTU. An ATM subnet is generally more complex. 1170 For this discussion, we consider only the ATM subnet-specific 1171 components, denoted C_ATM and D_ATM. The ATM network can be 1172 represented as a "pure delay" element, where the variable queueing 1173 delay, given by CVD is captured in D_ATM, and C_ATM is set to zero. 1174 It is possible to use C_ATM only when the ATM service rate equals R. 1175 This may be the case, for example with a CBR VC with PCR = R. 1176 Usually it will be simpler to just advertise the total delay 1177 variation (CDV) in D_ATM. 1179 As discussed in Section 2.6, the edge router keeps a table with 1180 values of MPL and D_ATM for each egress router it needs to share VCs 1181 with. The value of D_ATM contributes to the D parameter advertised 1182 by the edge router, and SHOULD accurately reflect the CDV that the 1183 router will get in a VC when it is set up. Factors that affect CDV, 1184 such as statistical multiplexing in the ATM network, SHOULD be taken 1185 into account when compiling data for the router's table. In case of 1186 uncertainty, D_ATM can be set to an upper bound. When an RESV 1187 message arrives, causing a VC to be set up, the requested values for 1188 CTD and CDV can be relaxed using the slack term in the receiver 1189 RSpec: 1190 CTD = D_ATM + MPL + S_ATM 1191 CDV = D_ATM + S_ATM. 1193 The term S_ATM is the portion of the slack term applied to the ATM 1194 portion of the path. Recall that the slack term [8] is positive when 1195 the receiver can afford more delay than that computed from the 1196 Adspec. The ATM edge device may take part (or all) of the slack 1197 term, S. The distribution of delay slack among the nodes and subnets 1198 is network specific. 1200 Note that with multipoint VCs the egress edge router may need to 1201 correct advertised values of C and D. See discussion in Section 3.1. 1203 4.0 Miscellaneous Items 1205 4.1 Units Conversion 1207 All rates and token bucket depth parameters that are mapped from IP- 1208 level parameters to ATM parameters MUST be corrected for the effects 1209 of added headers and the segmentation of packets into cells. At the 1210 IP layer, token bucket depths and rates are measured in bytes and 1211 bytes/sec, respectively, whereas for ATM, they are measured in cells 1212 and cells/sec. 1214 Each IP Packet is wrapped into an AAL-5 PDU, having a number of 1215 additional header bytes (8 for LLC/SNAP and perhaps others, e.g. 12 1216 for MPOA, etc.), and an 8-byte AAL-5 trailer. The AAL-5 PDU is then 1217 segmented into multiple ATM cells, each having a 5-byte cell header 1218 followed by a 48-byte cell payload. The number of cells used to 1219 carry an IP packet with 1221 B = number of IP-packet Bytes, 1222 H = number of AAL-5 header bytes (LLC/SNAP etc.) 1223 C = number of cells, 1225 is roughly 1227 C = B/48, 1229 and more precisely 1231 C = floor[(H + B + 8 + 47)/48] 1233 where floor[] is rounds down to the nearest integer. The '8' 1234 accounts for the AAL-5 trailer and the '47' accounts for the last 1235 cell which may be only partially filled. 1237 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service 1239 This section describes how to create ATM VCs appropriately matched 1240 for Guaranteed Service. The key points are that real-time timing is 1241 REQUIRED, that the data flow may have a variable rate, and that 1242 demotion of non-conforming traffic to best effort is REQUIRED to be 1243 in agreement with the definition of GS. For this reason, we prefer 1244 an rtVBR service in which tagging is supported. Another good match 1245 is to use CBR with special handling of any non-conforming traffic, 1246 e.g., through another VC, since a CBR VC will not accommodate traffic 1247 in excess of PCR. 1249 Note, these encodings assume point to multipoint connections, where 1250 the backward channel is not used. If the IP session is unicast only, 1251 then a point-to-point VC may be used and the IWF may make use of the 1252 backward channel, with QoS parameters set appropriately for the 1253 service provided. 1255 We provide a mapping for all combinations of IP service and ATM 1256 service category, and comments indicating whether or not each 1257 combination meets the requirements of the IP-IS service. 1259 5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0) 1261 RtVBR with conformance definition VBR.3 [6] MEETS the requirements of 1262 GS. 1264 AAL 1265 Type 5 1266 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1267 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1268 SSCS Type 0 (Null SSCS) 1270 Traffic Descriptor 1271 Forward PCR CLP=0+1 Note 1 1272 Backward PCR CLP=0+1 0 1273 Forward SCR CLP=0 Note 1 1274 Backward SCR CLP=0 0 1275 Forward MBS (CLP=0) Note 1 1276 Backward MBS (CLP=0) 0 1277 BE indicator NOT included 1278 Forward Frame Discard bit 1 1279 Backward Frame Discard bit 1 1280 Tagging Forward bit 1 (Tagging requested) 1281 Tagging Backward bit 1 (Tagging requested) 1283 Broadband Bearer Capability 1284 Bearer Class 16 (BCOB-X) Note 2 1285 ATM Transfer Capability 9 (Real time VBR) Note 3 1286 Susceptible to Clipping 00 (Not Susceptible) 1287 User Plane Configuration 01 (Point-to-Multipoint) 1289 Broadband Low Layer Information 1290 User Information Layer 2 1291 Protocol 12 (ISO 8802/2) 1292 User Information Layer 3 1293 Protocol 11 (ISO/IEC TR 9577) Note 4 1294 ISO/IEC TR 9577 IPI 204 1296 QoS Class 1297 QoS Class Forward 1 Note 5 1298 QoS Class Backward 1 Note 5 1300 Extended QoS Parameters Note 6 1301 Acceptable Forward CDV 1302 Acceptable Forward CLR 1303 Forward Max CTD 1305 Note 1: See discussion in Section 2.5.1. 1306 Note 2: Value 3 (BCOB-C) can also be used. 1307 If Bearer Class C is chosen the ATC field MUST be absent. 1308 Note 3: The ATC value 19 is not used. The value 19 implies that the 1309 CLR objective applies to the aggregate CLP=0+1 stream and 1310 that does not give desirable treatment of excess traffic. 1311 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1312 be specified. For BE VCs, it can be left unspecified, allowing 1313 the VC to be shared by multiple protocols, following RFC 1755. 1314 Note 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. 1315 Note 6: See discussion in Section 2.6. 1317 5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0) 1319 A CBR VC MEETS the requirements of GS. The main advantage of this is 1320 that CBR is widely supported; the disadvantage is that data flows 1321 might not fill the pipe (utilization loss) and there is no tagging 1322 option available. Excess traffic MUST be handled using a separate 1323 VC. 1325 AAL 1326 Type 5 1327 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1328 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1329 SSCS Type 0 (Null SSCS) 1331 Traffic Descriptor 1332 Forward PCR CLP=0+1 Note 1 1333 Backward PCR CLP=0+1 0 1334 BE indicator NOT included 1335 Forward Frame Discard bit 1 1336 Backward Frame Discard bit 1 1337 Tagging Forward bit 0 (Tagging not requested) 1338 Tagging Backward bit 0 (Tagging not requested) 1340 Broadband Bearer Capability 1341 Bearer Class 16 (BCOB-X) Note 2 1342 ATM Transfer Capability 5 (CBR) Note 3 1343 Susceptible to Clipping 00 (Not Susceptible) 1344 User Plane Configuration 01 (Point-to-Multipoint) 1346 Broadband Low Layer Information 1347 User Information Layer 2 1348 Protocol 12 (ISO 8802/2) 1349 User Information Layer 3 1350 Protocol 11 (ISO/IEC TR 9577) Note 4 1351 ISO/IEC TR 9577 IPI 204 1353 QoS Class 1354 QoS Class Forward 1 Note 5 1355 QoS Class Backward 1 Note 5 1357 Extended QoS Parameters Note 6 1358 Acceptable Forward CDV 1359 Acceptable Forward CLR 1360 Forward Max CTD 1362 Note 1: See discussion in Section 2.5.1. 1364 Note 2: Value 1 (BCOB-A) can also be used. 1365 If Bearer Class A is chosen the ATC field MUST be absent. 1366 Note 3: The ATC value 7 is not used. The value 7 implies CLR 1367 objective applies to the aggregate CLP=0+1 stream and 1368 that does not give desirable treatment of excess traffic. 1369 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1370 be specified. For BE VCs, it can be left unspecified, allowing 1371 the VC to be shared by multiple protocols, following RFC 1755. 1372 Note 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. 1373 Note 6: See discussion in Section 2.6. 1375 5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 1377 NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for 1378 GS. If GS/nrtVBR is used and network utilization is low, the delay 1379 may be `reasonable', but will not be controlled. The encoding of GS 1380 with nrtVBR is the same as that for CLS using nrtVBR. See Section 1381 6.1 below. 1383 5.4 Encoding GS Using ABR (ATM Forum TM/UNI 4.0) 1385 GS using ABR is a very unlikely combination, and DOES NOT meet the 1386 service requirements of GS. The objective of the ABR service is to 1387 provide "low" loss rates. The delay objectives for ABR SHOULD be 1388 expected to be very loose. If ABR were used for GS, the VC 1389 parameters would follow as for CLS over ABR. See Section 6.2. 1391 5.5 Encoding GS Using UBR (ATM Forum TM/UNI 4.0) 1393 The UBR service is the lowest common denominator of the services. It 1394 cannot provide delay or loss guarantees, and therefore DOES NOT meet 1395 the requirements of GS. However if it is used for GS, it will be 1396 encoded in the same way as Best Effort over UBR, with the exception 1397 that the Forward PCR would be determined from the peak rate of the 1398 receiver TSpec. See Section 7.1. 1400 5.6 Encoding GS Using ATM Forum UNI 3.0/3.1 Specifications 1402 It is not recommended to support GS using UNI 3.x VBR mode because 1403 the BCOB-C Bearer Class does not represent real-time behavior. Also, 1404 Appendix F of the UNI 3.1 specification precludes the specification 1405 of traffic type "VBR" with the timing requirement "End to End timing 1406 Required" in conjunction with Bearer Class X. 1408 A CBR VC MEETS the requirements of GS. The following table specifies 1409 the support of GS using CBR. 1411 AAL 1412 Type 5 1413 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1414 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1415 Mode 1 (Message mode) Note 1 1416 SSCS Type 0 (Null SSCS) 1418 Traffic Descriptor 1419 Forward PCR CLP=0 Note 2 1420 Backward PCR CLP=0 0 1421 Forward PCR CLP=0+1 Note 2 1422 Backward PCR CLP=0+1 0 1423 BE indicator NOT included 1424 Tagging Forward bit 1 (Tagging requested) 1425 Tagging Backward bit 1 (Tagging requested) 1427 Broadband Bearer Capability 1428 Bearer Class 16 (BCOB-X) Note 3 1429 Traffic Type 001 (Constant Bit Rate) 1430 Timing Requirements 01 (Timing Required) 1431 Susceptible to Clipping 00 (Not Susceptible) 1432 User Plane Configuration 01 (Point-to-Multipoint) 1434 Broadband Low Layer Information 1435 User Information Layer 2 1436 Protocol 12 (ISO 8802/2) 1437 User Information Layer 3 1438 Protocol 11 (ISO/IEC TR 9577) Note 4 1439 ISO/IEC TR 9577 IPI 204 1441 QoS Class Note 5 1442 QoS Class Forward 1 1443 QoS Class Backward 1 1445 Note 1: Only included for UNI 3.0. 1446 Note 2: See discussion in Section 2.5.1. PCR CLP=0 SHOULD be set identical 1447 to PCR CLP=0+1. Although this could potentially allow a CBR VC 1448 to carry excess traffic as tagged cells, it is not recommended 1449 since it is not supported in UNI 4.0 1450 Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic 1451 Type and Timing Requirements fields are not included. 1453 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1454 be specified. For BE VCs, it can be left unspecified, allowing 1455 the VC to be shared by multiple protocols, following RFC 1755. 1456 Note 5: QoS Parameters are implied by the QoS Class. 1458 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 1460 This section describes how to create ATM VCs appropriately matched 1461 for Controlled Load Service. CLS traffic is partly delay tolerant 1462 and has variable rate. NrtVBR and ABR (TM/UNI 4.0 only) are the best 1463 choices for supporting CLS. 1465 Note, these encodings assume point to multipoint connections where 1466 the backward channel is not used. If the IP session is unicast only, 1467 then a point-to-point VC may be used and the IWF may make use of the 1468 backward channel, with QoS parameters set appropriately for the 1469 service provided. 1471 We provide a mapping for all combinations of IP service and ATM 1472 service category, and comments indicating whether or not each 1473 combination meets the requirements of the IP-IS service. 1475 6.1 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 1477 NrtVBR MEETS the requirements for CLS. 1479 AAL 1480 Type 5 1481 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1482 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1483 SSCS Type 0 (Null SSCS) 1485 Traffic Descriptor 1486 Forward PCR CLP=0+1 Note 1 1487 Backward PCR CLP=0+1 0 1488 Forward SCR CLP=0 Note 1 1489 Backward SCR CLP=0 0 1490 Forward MBS (CLP=0) Note 1 1491 Backward MBS (CLP=0) 0 1492 BE indicator NOT included 1493 Forward Frame Discard bit 1 1494 Backward Frame Discard bit 1 1495 Tagging Forward bit 1 (Tagging requested) 1496 Tagging Backward bit 1 (Tagging requested) 1498 Broadband Bearer Capability 1499 Bearer Class 16 (BCOB-X) Note 2 1500 ATM Transfer Capability 10 (Non-real time VBR) Note 3 1501 Susceptible to Clipping 00 (Not Susceptible) 1502 User Plane Configuration 01 (Point-to-Multipoint) 1504 Broadband Low Layer Information 1505 User Information Layer 2 1506 Protocol 12 (ISO 8802/2) 1507 User Information Layer 3 1508 Protocol 11 (ISO/IEC TR 9577) Note 4 1509 ISO/IEC TR 9577 IPI 204 1511 QoS Class 1512 QoS Class Forward 3 Note 5 1513 QoS Class Backward 3 Note 5 1515 Extended QoS Parameters Note 6 1516 Acceptable Forward CDV 1517 Acceptable Forward CLR 1518 Forward Max CTD 1520 Note 1: See discussion in Section 2.5.2. 1521 Note 2: Value 3 (BCOB-C) can also be used. 1522 If Bearer Class C is used, the ATC field MUST be absent. 1523 Note 3: The ATC value 11 is not used. The value 11 implies CLR 1524 objective applies to the aggregate CLP=0+1 stream and 1525 that does not give desirable treatment of excess traffic. 1526 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1527 be specified. For BE VCs, it can be left unspecified, allowing 1528 the VC to be shared by multiple protocols, following RFC 1755. 1529 Note 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. 1530 Note 6: See discussion in Section 2.6. 1532 6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0) 1534 ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec 1535 rate. 1537 AAL 1538 Type 5 1539 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1540 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1541 SSCS Type 0 (Null SSCS) 1543 Traffic Descriptor 1544 Forward PCR CLP=0+1 Note 1 1545 Backward PCR CLP=0+1 0 1546 Forward MCR CLP=0+1 Note 1 1547 Backward MCR CLP=0+1 0 1548 BE indicator NOT included 1549 Forward Frame Discard bit 1 1550 Backward Frame Discard bit 1 1551 Tagging Forward bit 0 (Tagging not requested) 1552 Tagging Backward bit 0 (Tagging not requested) 1554 Broadband Bearer Capability 1555 Bearer Class 16 (BCOB-X) Note 2 1556 ATM Transfer Capability 12 (ABR) 1557 Susceptible to Clipping 00 (Not Susceptible) 1558 User Plane Configuration 00 (Point-to-Point) 1560 Broadband Low Layer Information 1561 User Information Layer 2 1562 Protocol 12 (ISO 8802/2) 1563 User Information Layer 3 1564 Protocol 11 (ISO/IEC TR 9577) Note 3 1565 ISO/IEC TR 9577 IPI 204 1567 QoS Class 1568 QoS Class Forward 0 Note 4 1569 QoS Class Backward 0 Note 4 1571 Extended QoS Parameters Note 5 1572 Acceptable Forward CDV 1573 Acceptable Forward CLR 1574 Forward Max CTD 1576 ABR Setup Parameters Note 6 1577 ABR Additional Parameters Note 6 1579 Note 1: See discussion in Section 2.5.2. 1580 Note 2: Value 3 (BCOB-C) can also be used. 1581 If Bearer Class C is chosen the ATC field MUST be absent. 1582 Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1583 be specified. For BE VCs, it can be left unspecified, allowing 1584 the VC to be shared by multiple protocols, following RFC 1755. 1585 Note 4: Cf ITU Rec. I.356 [20] for new QoS Class definitions. 1586 Note 5: See discussion in Section 2.6. 1587 Note 6: The ABR-specific parameters are beyond the scope of this document. 1588 These generally depend on local implementation and not on values 1589 mapped from IP level service parameters (except for MCR). 1590 See [6, 11] for further information. 1592 6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0) 1594 Although CBR does not explicitly take into account the variable rate 1595 of source data, it may be convenient to use ATM connectivity between 1596 edge routers to provide a simple "pipe" service, as a leased line 1597 replacement. Since no tagging option is available with CBR, excess 1598 traffic MUST be handled using a separate VC. Under this condition, 1599 CBR MEETS the requirements of CLS. 1601 To use CBR for CLS, the same encoding for GS over CBR (Section 5.2) 1602 would be used. See discussion in Section 2.5.2. 1604 6.4 Encoding CLS Using Real-Time VBR (ATM Forum TM/UNI 4.0) 1606 The encoding of CLS using rtVBR implies a hard limit on the end-to- 1607 end delay in the ATM network. This creates more complexity in the VC 1608 setup than the CLS service requires, and is therefore not a preferred 1609 combination, although it DOES MEET the requirements of CLS. 1611 If rtVBR is used to encode CLS, then the encoding is essentially the 1612 same as that for GS. See discussions in Section 5.1 and Section 1613 2.5.2. 1615 6.5 Encoding CLS Using UBR (ATM Forum TM/UNI 4.0) 1617 This encoding gives no QoS guarantees and DOES NOT MEET the 1618 requirements of CLS. If used, it is coded in the same way as for BE 1619 over UBR (Section 7.1), except that the PCR would be determined from 1620 the peak rate of the receiver TSpec. 1622 6.6 Encoding CLS Using ATM Forum UNI 3.0/3.1 Specifications 1624 This encoding is equivalent to the nrtVBR service category. It MEETS 1625 the requirements of CLS. 1627 AAL 1628 Type 5 1629 Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1630 Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes 1631 Mode 1 (Message mode) Note 1 1632 SSCS Type 0 (Null SSCS) 1634 Traffic Descriptor 1635 Forward PCR CLP=0+1 Note 2 1636 Backward PCR CLP=0+1 0 1637 Forward SCR CLP=0 Note 2 1638 Backward SCR CLP=0 0 1639 Forward MBS (CLP=0) Note 2 1640 Backward MBS (CLP=0) 0 1641 BE indicator NOT included 1642 Tagging Forward bit 1 (Tagging requested) 1643 Tagging Backward bit 1 (Tagging requested) 1645 Broadband Bearer Capability 1646 Bearer Class 16 (BCOB-X) Note 3 1647 Traffic Type 010 (Variable Bit Rate) 1648 Timing Requirements 00 (No Indication) 1649 Susceptible to Clipping 00 (Not Susceptible) 1650 User Plane Configuration 01 (Point-to-Multipoint) 1652 Broadband Low Layer Information 1653 User Information Layer 2 1654 Protocol 12 (ISO 8802/2) 1655 User Information Layer 3 1656 Protocol 11 (ISO/IEC TR 9577) Note 4 1657 ISO/IEC TR 9577 IPI 204 1659 QoS Class 1660 QoS Class Forward 3 Note 5 1661 QoS Class Backward 3 Note 5 1663 Note 1: Only included for UNI 3.0. 1664 Note 2: See discussion in Section 2.5.2. 1665 Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic 1666 Type and Timing Requirements fields are not included. 1667 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1668 be specified. For BE VCs, it can be left unspecified, allowing 1669 the VC to be shared by multiple protocols, following RFC 1755. 1670 Note 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. 1671 QoS Parameters are implied by the QoS Class. 1673 7.0 Summary of ATM VC Setup Parameters for Best Effort Service 1675 This section is provided for completeness only. The IETF ION working 1676 group documents on ATM signalling support for IP over ATM [10, 11] 1677 provide definitive specifications for Best Effort IP service over 1678 ATM. 1680 The best-matched ATM service category to IP Best Effort is UBR. We 1681 provide the setup details for this case below. The BE service does 1682 not involve reservation of resources. ABR and nrtVBR are also well 1683 suited to BE service. See discussion in Section 2.1.3. 1685 Note, VCs supporting best effort service are usually point to point, 1686 rather than point to multipoint, and the backward channels of VCs are 1687 used. In cases where VCs are set up to support best effort multicast 1688 sessions, multipoint VCs can be used and the backward channels would 1689 be not have resources reserved. Related situations include transport 1690 of excess traffic on IP-multicast QoS sessions, or to support the 1691 subset of multicast end systems that have not made rsvp reservations. 1692 See the discussion on VC management in [12]. 1694 7.1 Encoding Best Effort Service Using UBR (ATM Forum TM/UNI 4.0) 1696 AAL 1697 Type 5 1698 Forward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5) 1699 Backward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5) 1700 SSCS Type 0 (Null SSCS) 1702 Traffic Descriptor 1703 Forward PCR CLP=0+1 Note 1 1704 Backward PCR CLP=0+1 0 1705 BE indicator included 1706 Forward Frame Discard bit 1 1707 Backward Frame Discard bit 1 1708 Tagging Forward bit 1 (Tagging requested) 1709 Tagging Backward bit 1 (Tagging requested) 1711 Broadband Bearer Capability 1712 Bearer Class 16 (BCOB-X) Note 2 1713 ATM Transfer Capability 10 (Non-real time VBR) 1714 Susceptible to Clipping 00 (Not Susceptible) 1715 User Plane Configuration 01 (Point-to-Multipoint) 1717 Broadband Low Layer Information 1718 User Information Layer 2 1719 Protocol 12 (ISO 8802/2) Note 3 1721 QoS Class 1722 QoS Class Forward 0 1723 QoS Class Backward 0 1725 Note 1: See discussion in Section 2.5.3. 1726 Note 2: Value 3 (BCOB-C) can also be used. 1727 If Bearer Class C is used, the ATC field MUST be absent 1728 Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD 1729 be specified. For BE VCs, it can be left unspecified, allowing 1730 the VC to be shared by multiple protocols, following RFC 1755. 1732 8.0 Security Considerations 1734 IP Integrated Services (including rsvp) and ATM are both complex 1735 resource reservation protocols, and SHOULD be expected to have 1736 complex feature interactions. 1738 Differences in IP and ATM billing styles could cause unforeseen 1739 problems since RESV messages can set up VCs. For example, an end- 1740 user paying a flat rate for (non-rsvp aware) internet service may 1741 send an rsvp RESV message that encounters a (perhaps distant) ATM 1742 network with a usage-sensitive billing model. Insufficient 1743 authentication could result in services being accidentally billed to 1744 an innocent third party, intentional theft of service, or malicious 1745 denial of service attacks where high volumes of reservations consume 1746 transport or processing resources at the edge devices. 1748 The difference in styles of handling excess traffic could result in 1749 denial of service attacks where the ATM network uses transport 1750 resources (bandwidth, buffers) or connection processing resources 1751 (switch processor cycles) in an attempt to accommodate excess traffic 1752 that was admitted by the internet service. 1754 Problems associated with translation of resource reservations at edge 1755 devices are probably more complex and susceptible to abuse when the 1756 IP-ATM edge is also an administrative boundary between service 1757 providers. Note also that administrative boundaries can exist within 1758 the ATM cloud, i.e., the ingress and egress edge devices are operated 1759 by different service providers. 1761 Note, the ATM Forum Security Working Group is currently defining 1762 ATM-level security features such as data encryption and signalling 1763 authentication. See also the security issues raised in the rsvp 1764 specification [2]. 1766 9.0 Acknowledgements 1768 The authors received much useful input from the members of the ISSLL 1769 working group. In particular, thanks to Drew Perkins and Jon Bennett 1770 of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh 1771 of Bellcore. 1773 Appendix 1 Abbreviations 1775 AAL ATM Adaptation Layer 1776 ABR Available Bit Rate 1777 APB Available Path Bandwidth (int-serv GCP) 1778 ATC ATM Transfer Capability 1779 ATM Asynchronous Transfer Mode 1780 B-LLI Broadband Low Layer Information 1781 BCOB Broadband Connection-Oriented Bearer Capability 1782 BCOB-{A,C,X} Bearer Class A, C, or X 1783 BE Best Effort 1784 BT Burst Tolerance 1785 CBR Constant Bit Rate 1786 CDV Cell Delay Variation 1787 CDVT Cell Delay Variation Tolerance 1788 CLP Cell Loss Priority (bit) 1789 CLR Cell Loss Ratio 1790 CLS Controlled Load Service 1791 CPCS Common Part Convergence Sublayer 1792 CTD Cell Transfer Delay 1793 EOM End of Message 1794 GCP General Characterization Parameter 1795 GCRA Generic Cell Rate Algorithm 1796 GS Guaranteed Service 1797 IE Information Element 1798 IETF Internet Engineering Task Force 1799 ION IP Over Non-broadcast multiple access networks 1800 IP Internet Protocol 1801 IPI Initial Protocol Identifier 1802 IS Integrated Services 1803 ISSLL Integrated Services over Specific Link Layers 1804 ITU International Telecommunication Union 1805 IWF Interworking Function 1806 LIJ Leaf Initiated Join 1807 LLC Logical Link Control 1808 MBS Maximum Burst Size 1809 MCR Minimum Cell Rate 1810 MPL Minimum Path Latency 1811 MTU Maximum Transfer Unit 1812 nrtVBR Non-real-time VBR 1813 PCR Peak Cell Rate 1814 PDU Protocol Data Unit 1815 PVC Permanent Virtual Connection 1816 QoS Quality of Service 1817 RESV Reservation Message (of rsvp protocol) 1818 RFC Request for Comments 1819 RSVP Resource Reservation Protocol 1820 RSpec Reservation Specification 1821 rtVBR Real-time VBR 1822 SCR Sustainable Cell Rate 1823 SDU Service Data Unit 1824 SNAP Subnetwork Attachment Point 1825 SSCS Service-Specific Convergence Sub-layer 1826 SVC Switched Virtual Connection 1827 TCP Transport Control Protocol 1828 TM Traffic Management 1829 TSpec Traffic Specification 1830 UBR Unspecified Bit Rate 1831 UNI User-Network Interface 1832 UPC Usage Parameter Control (ATM traffic policing function) 1833 VBR Variable Bit Rate 1834 VC (ATM) Virtual Connection 1836 REFERENCES 1838 [1] R. Braden, D. Clark and S. Shenker, "Integrated Services in the 1839 Internet Architecture: an Overview", RFC 1633, June 1994. 1841 [2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 1842 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 1843 Specification", RFC 2205, September 1997. 1845 [3] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1846 sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. 1848 [4] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1849 sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. 1851 [5] The ATM Forum, "ATM User-Network Interface (UNI) Signalling 1852 Specification, Version 4.0", July 1996. Available at 1853 ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps. 1855 [6] The ATM Forum, "ATM Traffic Management Specification, Version 1856 4.0", April 1996. Available at 1857 ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps. 1859 [7] M. W. Garrett, "A Service Architecture for ATM: From 1860 Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3, 1861 pp. 6-14, May 1996. 1863 [8] S. Shenker, C. Partridge and R. Guerin, "Specification of 1864 Guaranteed Quality of Service", RFC 2212, September 1997. 1866 [9] J. Wroclawski, "Specification of the Controlled-Load Network 1867 Element Service", RFC 2211, September 1997. 1869 [10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. 1870 Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru- 1871 ary 1995. 1873 [11] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM 1874 UNI 4.0 Update", Internet Draft, October 1997. 1877 [12] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. 1878 Krawczyk, "A Framework for Integrated Services and RSVP over 1879 ATM", Internet Draft, July 1997. 1882 [13] L. Berger, "RSVP over ATM Implementation Requirements", Internet 1883 Draft, January 1998. 1885 [14] L. Berger, "RSVP over ATM Implementation Guidelines", Internet 1886 Draft, January 1998. 1888 [15] S. Shenker and J. Wroclawski, "Network Element Service Specifi- 1889 cation Template", RFC 2216, September 1997. 1891 [16] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 1892 RFC 2210, September 1997. 1894 [17] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of 1895 Real-time Services in an IP-ATM Network Architecture", RFC 1821, 1896 August 1995. 1898 [18] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 1899 Layer 5", RFC 1483, July 1993. 1901 [19] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January 1902 1994. 1904 [20] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer per- 1905 formance", International Telecommunication Union, Geneva, 1906 October 1996. 1908 [21] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net- 1909 works", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633- 1910 41, May 1995. 1912 [22] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing 1913 Approach to Flow Control in Integrated Services Networks: The 1914 Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2, 1915 pp. 137-150, April 1994. 1917 [23] S. Floyd, V. Jacobson, "Link-sharing and Resource Management 1918 Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, 1919 No. 4, August 1995. 1921 [24] S. Shenker and J. Wroclawski, "General Characterization Parame- 1922 ters for Integrated Service Network Elements", RFC 2215, Sep- 1923 tember 1997. 1925 Authors' Addresses 1927 Mark W. Garrett Marty Borden 1928 Bellcore Bay Networks 1929 445 South Street 42 Nagog Park 1930 Morristown, NJ 07960 Acton MA, 01720 1931 USA USA 1933 phone: +1 201 829-4439 phone: +1 508 266-1011 1934 email: mwg@bellcore.com email: mborden@baynetworks.com