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