idnits 2.17.1 draft-ietf-issll-atm-mapping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) 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 76 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1229 has weird spacing: '...mber of usefu...' -- 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 (21 November 1997) is 9643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2216 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '17') ** Obsolete normative reference: RFC 1483 (ref. '18') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (ref. '19') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 13 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: 21 May 1998 5 Marty Borden, 6 New Oak Communications 8 21 November 1997 10 Interoperation of Controlled-Load Service and Guaranteed Service with ATM 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document provides guidelines for mapping service classes, and 34 traffic management features and parameters between Internet and ATM 35 technologies. The service mappings are useful for providing 36 effective interoperation and end-to-end Quality of Service for IP 37 Integrated Services networks containing ATM subnetworks. 39 The discussion and specifications given here support the IP 40 integrated services protocols for Guaranteed Service (GS), 41 Controlled-Load Service (CLS) and the ATM Forum UNI specification, 42 versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service 43 over ATM is also included. 45 Table of Contents 47 1.0 Introduction ....................................................... 3 48 1.1 General System Architecture .................................... 4 49 1.2 Related Documents .............................................. 7 51 2.0 Major Protocol Features for Traffic Management and QoS ............. 7 52 2.1 Service Category and Bearer Capability ......................... 8 53 2.1.1 Service Categories for Guaranteed Service ................ 9 54 2.1.2 Service Categories for Controlled Load ................... 10 55 2.1.3 Service Categories for Best Effort ....................... 11 56 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions .... 11 57 2.3 ATM Adaptation Layer ........................................... 13 58 2.4 Broadband Low Layer Information ................................ 13 59 2.5 Traffic Descriptors ............................................ 14 60 2.5.1 Translating Traffic Descriptors for Guaranteed Service ... 15 61 2.5.2 Translating Traffic Descriptors for Controlled Load Service 18 62 2.5.3 Translating Traffic Descriptors for Best Effort Service ....19 63 2.6 QoS Classes and Parameters ..................................... 19 64 2.7 Additional Parameters -- Frame Discard Mode .................... 22 66 3.0 Additional IP-Integrated Services Protocol Features ................ 22 67 3.1 Path Characterization Parameters for IP Integrated Services .... 22 68 3.2 Handling of Excess Traffic ..................................... 24 69 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 25 71 4.0 Miscellaneous Items ................................................ 26 72 4.1 Units Conversion ............................................... 26 74 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28 75 5.1 Encoding GS Using Real-Time VBR ................................ 28 76 5.2 Encoding GS Using CBR .......................................... 30 77 5.3 Encoding GS Using Non-Real-Time VBR ............................ 31 78 5.4 Encoding GS Using ABR .......................................... 31 79 5.5 Encoding GS Using UBR .......................................... 31 80 5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 32 82 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 33 83 6.1 Encoding CLS Using ABR ......................................... 34 84 6.2 Encoding CLS Using Non-Real-Time VBR ........................... 35 85 6.3 Encoding CLS Using Real-Time VBR ............................... 36 86 6.4 Encoding CLS Using CBR ......................................... 37 87 6.5 Encoding CLS Using UBR ......................................... 37 88 6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 37 90 7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 38 91 7.1 Encoding Best Effort Service Using UBR ......................... 39 93 8.0 Security ........................................................... 39 94 9.0 Acknowledgements ................................................... 39 96 Appendix 1 Abbreviations .............................................. 40 97 References ............................................................. 41 98 Authors' Addresses ..................................................... 43 100 1.0 Introduction 102 We consider the problem of providing IP Integrated Services [1] with 103 an ATM subnetwork. This document is intended to be consistent with 104 the rsvp protocol [2] for IP-level resource reservation, although it 105 applies also in the general case where GS and CLS services are 106 supported through other mechanisms. In the ATM network, we consider 107 ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, 5]. The 108 latter uses the more complete service model of the ATM Forum's TM 4.0 109 specification [6, 7]. 111 This is a complex problem. In this document, we focus on the service 112 types, parameters and signalling elements needed for service 113 interoperation. The resulting service mappings can be used to 114 provide effective end-to-end Quality of Service (QoS) for IP traffic 115 that traverses ATM networks. 117 The IP services considered are Guaranteed Service (GS) [8] and 118 Controlled Load Service (CLS) [9]. We also discuss the default Best 119 Effort Service (BE) in parallel with these. Our recommendations for 120 BE are intended to be consistent with RFC 1755 [10], and its revision 121 [11], which define how ATM VCs can be used in support of normal BE IP 122 service. The ATM services we consider are: 124 CBR Constant Bit Rate 125 rtVBR Real-time Variable Bit Rate 126 nrtVBR Non-real-time Variable Bit Rate 127 UBR Unspecified Bit Rate 128 ABR Available Bit Rate 130 In the case of UNI 3.x signalling, where these service are not all 131 clearly distinguishable, we identify the appropriate available 132 services. 134 We recommend the following service mappings, since they follow most 135 naturally from the service definitions: 137 Guaranteed Service -> CBR or rtVBR 138 Controlled Load -> nrtVBR or ABR (with a minimum cell rate) 139 Best Effort -> UBR or ABR 141 For completeness, however, we provide detailed mappings for all 142 service combinations in Sections 5, 6, 7 and identify how each meets 143 or fails to meet the requirements of the higher level IP services. 144 The reason for not restricting mappings to the most obvious or 145 natural ones is that we cannot predict how widely available all of 146 these services will be as ATM deployment evolves. A number of 147 differences in service definitions, such as the treatment of packets 148 in excess of the flow traffic descriptor, make service mapping a 149 relatively complicated subject. 151 The remainder of this introduction provides a general discussion of 152 the system configuration and other assumptions. Section 2 considers 153 the relevant ATM protocol elements and the corresponding features of 154 Guaranteed, Controlled Load and Best Effort services (the latter 155 being the default "service"). Section 3 discusses a number of 156 remaining features of the IP services and how they can be handled on 157 an ATM subnetwork. Section 4 addresses the conversion of traffic 158 descriptors to account for ATM-layer overheads. Section 5 gives the 159 detailed VC setup parameters for Guaranteed Service, and considers 160 the effect of using each of the ATM service categories. Section 6 161 provides a similar treatment for Controlled Load Service. Section 7 162 considers Best Effort service. 164 This document is only a part of the total solution to providing the 165 interworking of IP integrated services with ATM subnetworks. The 166 important issue of VC management, including flow aggregation, is 167 considered in [12,13,14]. We do not consider how routing, QoS 168 sensitive or not, interacts with the use of ATM VCs. We expect that 169 a considerable degree of implementation latitude will exist, even 170 within the guidelines presented here. Many aspects of interworking 171 between IP and ATM will depend on economic factors, and will not be 172 subject to standardization. 174 1.1 General System Architecture 176 We assume that the reader has a general working knowledge of IP, rsvp 177 and ATM protocols. The network architecture we consider is 178 illustrated in Figure 1. An IP-attached host may send unicast 179 datagrams to another host, or may use an IP multicast address to send 180 packets to all of the hosts which have "joined" the multicast "tree". 181 In either case, a destination host may then use RSVP to establish 182 resource reservation in routers along the internet path for the data 183 flow. 185 An ATM network lies in the path (chosen by the IP routing), and 186 consists of one or more ATM switches. It uses SVCs to provide both 187 resources and QoS within the ATM cloud. These connections are set 188 up, added to (in the case of multipoint trees), torn down, and 189 controlled by the edge devices, which act as both IP routers and ATM 190 interfaces, capable of initiating and managing VCs across the ATM 191 user-to-network (UNI) interface. The edge devices are assumed to be 192 fully functional in both the IP int-serv/RSVP protocols and the ATM 193 UNI protocols, as well as translating between them. 195 ATM Cloud 196 ------------------ 197 H ----\ ( ) /------- H 198 H ---- R -- R -- E --( ATM Sw -- ATM Sw ) -- E -- R -- R -- H 199 H ----/ | ( ) \ 200 | ------------------ \------ H 201 H ----------R 203 Figure 1: Network Architecture with Hosts (H), 204 Routers (R) and Edge Devices (E). 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 should initiate a new VC or join an existing one. VCs 221 are 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 working group drafts [12,13,14]. 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 required of 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 characteristics required of 266 those VCs. See [12,13,14] 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 signaling, traffic management 280 and other areas into a single document, e.g., UNI 3.0 [3] and UNI 3.1 281 [4]. 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 [5] and Traffic 289 Management 4.0 [6] 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 [2], 294 int-serv [1, 8, 9, 15, 16] and ion working groups [10, 11]. 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 required of a VC: 350 whether there is a real-time delay constraint, whether the traffic is 351 constant or variable rate, the applicable traffic and QoS description 352 parameters and (implicitly) the complexity of some supporting switch 353 mechanisms (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 GS requires real-time support. Thus in UNI 3.x, the bearer class 407 BCOB-A (or an equivalent BCOB-X formulation) must be used. In TM/UNI 408 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 Specification of BCOB-A or CBR requires specification of a peak cell 419 rate (PCR). In these cases, PCR is the nominal clearing rate with a 420 nominal jitter toleration (bucket size), CDVT. 422 Specification of rtVBR requires two rates, PCR and SCR. This models 423 bursty traffic with specified peak and sustainable rates. The 424 corresponding ATM token bucket depth values are CDVT, and CDVT+BT, 425 respectively. 427 2.1.2 Service Categories for Controlled Load 429 There are three possible good mappings for CLS: 431 CBR (BCOB-A) 432 ABR 433 nrtVBR (BCOB-C) 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. 447 The ABR category with a positive MCR aligns with the CLS idea of 448 "best effort with a floor." The ATM network agrees to forward cells 449 with a rate of at least MCR, which should be directly converted from 450 the token bucket rate of the receiver TSpec. The bucket size 451 parameter measures approximately the amount of buffer required at the 452 IWF. This buffer serves to absorb the bursts allowed by the token 453 bucket, since they cannot be passed directly into an ABR VC. 455 The rtVBR category can be used, although the edge device must 456 determine values for CTD and CDV. Since there are no corresponding 457 IP-level parameters, their values are set as a matter of local 458 policy. 460 The UBR category does not provide enough capability for Controlled 461 Load. The point of CLS is to allow an allocation of resources. This 462 is facilitated by the token bucket traffic descriptor, which is 463 unavailable with UBR. 465 2.1.3 Service Categories for Best Effort 467 All of the service categories have the capability to carry Best 468 Effort service, but the natural service category is UBR (or, in UNI 469 3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or 470 rtVBR clearly could be used, and since the service is not real-time, 471 a nrtVBR connection could also be used. In these cases the rate 472 parameter used reflects a bandwidth allocation in support of the 473 ingress edge device's best effort connectivity to the egress edge 474 router. It would be normal for traffic from many source/destination 475 pairs to be aggregated on this connection; indeed, since Best Effort 476 is the default IP behavior, the individual flows are not normally 477 identified or accounted for. CBR may be a preferred solution in the 478 case where best effort traffic is sufficiently highly aggregated that 479 a simple fixed-rate pipe is efficient. Both CBR and nrt-VBR provide 480 explicit bandwidth allocation which may be useful for billing 481 purposes. 483 An ABR connection could similarly be used to support Best Effort 484 traffic. Indeed, the support of data communications protocols such 485 as TCP/IP is the explicit purpose for which ABR was designed. It is 486 conceivable that a separate ABR connection would be made for each IP 487 flow, although the normal case would probably have all IP Best Effort 488 traffic with a common egress router sharing a single ABR connection. 490 The rt-VBR service category may be considered less suitable, simply 491 because both the real-time delay constraint and the use of SCR/BT add 492 unnecessary complexity. 494 See specifications from the IETF ion working group [10, 11] for 495 related work on support of Best Effort service with ATM. 497 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions 499 Each ATM cell header carries a Cell Loss Priority (CLP) bit. Cells 500 with CLP=1 are said to be "tagged" or "marked" and have lower 501 priority. This tagging may be done by the source, to indicate 502 relative priority within the VC, or by a switch, to indicate traffic 503 in violation of policing parameters. Options involving the use of 504 tagging are decided at call setup time. 506 A Conformance Definition is a rule that determines whether a cell is 507 conforming to the traffic descriptor of the VC. The conformance 508 definition is given in terms of a Generic Cell Rate Algorithm (GCRA), 509 also known as a "leaky bucket" algorithm, for CBR and VBR services. 510 (UBR and ABR have network implementation-specific conformance 511 definitions. Note, the term "compliance" in ATM is used to describe 512 the behavior of a connection, as opposed to "conformance", which 513 applies to a single cell.) 515 The network may tag cells that are non-conforming, rather than 516 dropping them if the VC set-up requests tagging and the network 517 supports the tagging option. When congestion occurs, a switch must 518 attempt to discard tagged cells in preference to discarding CLP=0 519 cells. However, the mechanism for doing this is completely 520 implementation specific. The behavior that best meets the 521 requirements of IP Integrated Services is where tagged cells are 522 treated as "best effort" in the sense that they are transported when 523 bandwidth is available, queued when buffers are available, and 524 dropped when resources are overcommitted. ATM standards, however, do 525 not explicitly specify treatment of tagged traffic. Providers of GS 526 and CLS service with ATM subnetworks should ascertain the actual 527 behavior of ATM implementation with respect to tagged cells. 529 Since GS and CLS services require excess traffic to be treated as 530 best effort, the tagging option should always be chosen (if 531 supported) in the VC setup as a means of "downgrading" the cells 532 comprising non-conformant packets. The term "best effort" can be 533 interpreted in two ways. The first is as a service class that, for 534 example, may be implemented as a separate queue. The other sense is 535 more generic, meaning that the network makes a best effort to 536 transport the traffic. A reasonable interpretation of this is that a 537 network with no contending traffic would transport the packet, while 538 a very congested network would drop the packet. A mechanism that 539 tags best effort packets with lower loss priority (such as with the 540 ATM CLP bit) would drop some of these packets, but would not reorder 541 the remaining ones with respect to the conforming portion of the 542 flow. The "best effort" mechanism for excess traffic does not 543 necessarily have to be the same as that for best effort "service", as 544 long as it fits this generic sense of best effort. 546 There are three conformance definitions of VBR service (for both 547 rtVBR and nrtVBR) to consider. In VBR, only the conformance 548 definition VBR.3 supports tagging and applies the GCRA with rate PCR 549 to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the 550 CLP=0 cells. This conformance definition should always be used with 551 a VBR service supporting IP integrated services. For UBR service, 552 conformance definition UBR.2 supports the use of tagging, but a CLP=1 553 cell does not imply non-conformance; rather, it may be used to 554 indicate network congestion. 556 In TM/UNI 4.0 tagging does not apply to the CBR or ABR services. 557 More precisely, the conformance definitions listed in TM 4.0 for CBR 558 and ABR do not use tagging. Since conformance definitions are 559 network specific, it may be possible that implementations of CBR or 560 ABR with tagging can exist. Wherever an ATM network does support 561 tagging, in the sense of transporting CLP=1 cells on a "best effort" 562 basis, it is a useful and preferable mechanism for handling excess 563 traffic. 565 It is always better for the IWF to tag cells when it can anticipate 566 that the ATM network would do so. This is because the IWF knows the 567 IP packet boundaries and can tag all of the cells corresponding to a 568 packet. If left to the ATM layer UPC, the network would inevitably 569 drop some of the cells of a packet while carrying others, which would 570 then be dropped by the receiver. Therefore, the IWF, knowing the VC 571 GCRA parameters, should always anticipate the cells which will be 572 tagged by the ATM UPC and tag all of the cells uniformly across each 573 affected packet. 575 2.3 ATM Adaptation Layer 577 The AAL type 5 encoding must be used, as specified in RFC 1483 and 578 RFC 1755. AAL5 requires specification of the maximum SDU size in both 579 the forward and reverse directions. Both GS and CLS specify a maximum 580 packet size as part of the TSpec and this value shall be used as the 581 maximum SDU in each direction for unicast connections, and for 582 unidirectional point-to-multipoint connections. When multiple flows 583 are aggregated into a single VC, the M parameters of the receiver 584 TSpecs are merged according to rules given in the GS and CLS specs. 586 2.4 Broadband Low Layer Information 588 The B-LLI Information Element is transferred transparently by the ATM 589 network between the edge devices and is used to specify the 590 encapsulation method. Multiple B-LLI IEs may be sent as part of 591 negotiation. The default encapsulation LLC/SNAP [18] must be 592 supported as specified in RFC 1577 [19] and RFC 1755 [10]. See RFC 593 1755 for information on additional encapsulations. 595 2.5 Traffic Descriptors 597 The ATM traffic descriptor always contains a peak cell rate (PCR) 598 (for each direction). For variable rate services it also contains a 599 sustainable cell rate (SCR) and maximum burst size (MBS). The SCR 600 and MBS form a leaky bucket pair (rate, depth), while the bucket 601 depth parameter for PCR is CDVT. Note that CDVT is not signalled 602 explicitly, but is determined by the network operator, and serves as 603 a measure of the jitter imposed by the network. 605 Since CDVT is generally presumed to be small (equivalent to a few 606 cells of token bucket depth), and cannot be set independently for 607 each connection, it cannot be used to account for the burstiness 608 permitted by b of the IP-layer TSpec. Additional buffering is needed 609 at the IWF to account for the depth of the token bucket. 611 The ATM Burst Tolerance (BT) is equivalent to MBS (see TM 4.0 [6] for 612 the exact equation). They are both expressions of the bucket depth 613 parameter that goes with SCR. The units of BT is time while the 614 units of MBS is cells. Since both SCR and MBS are signalled, they 615 can be computed directly from the IP layer traffic description. The 616 specific manner in which resources are allocated from the traffic 617 description is implementation specific. Note that when translating 618 the traffic parameters, the segmentation overhead and minimum policed 619 unit need to be taken into account (see Section 4.1 below). 621 In ATM UNI Signalling 4.0 there are the notions of Alternative 622 Traffic Descriptors and Minimal Traffic Descriptors. Alternative 623 Traffic Descriptors enumerate other acceptable choices for traffic 624 descriptors and are not considered here. Minimal Traffic Descriptors 625 are used in "negotiation," which refers to the specific way in which 626 an ATM connection is set up. To illustrate, roughly, taking PCR as 627 an example: A minimal PCR and a requested PCR are signalled, the 628 requested PCR being the usual item signalled, and the minimal PCR 629 being the absolute minimum that the source edge device will accept. 630 When sensing the existence of both minimal and requested parameters, 631 the intermediate switches along the path may reduce the requested PCR 632 to a "comfortable" level. This choice is part of admission control, 633 and is therefore implementation dependent. If at any point the 634 requested PCR falls below the minimal PCR then the call is cleared. 635 Minimal Traffic Descriptors can be used to present an acceptable 636 range for parameters and ensure a higher likelihood of call 637 admission. In general, our discussion of connection parameters 638 assumes the values resulting from successful connection setup. 640 The Best Effort indicator (used only with UBR) and Tagging indicators 641 are also part of the signalled information element (IE) containing 642 the traffic descriptor. In the UNI 4.0 traffic descriptor IE there 643 is an additional parameter, the Frame Discard indicator, which is 644 discussed below in Section 2.7. 646 2.5.1 Translating Traffic Descriptors for Guaranteed Service 648 For Guaranteed Service the source TSpec contains peak rate, rate and 649 and bucket depth parameters, p_s, r_s, b_s. The receiver TSpec 650 contains corresponding parameters p_r, r_r, b_r. The (receiver) 651 RSpec also has a rate, R. The two different TSpec rates are intended 652 to support receiver heterogeneity, in the sense that receivers can 653 accept different rates representing different subsets of the sender's 654 traffic. Whenever rates from different receivers differ, the values 655 will always be merged appropriately before being mapping into ATM 656 parameters. 658 Note that when the sender and receiver TSpec rates r_s, r_r differ, 659 there is no mechanism specified (in either rsvp or the int-serv 660 specs) for indicating which subset of the traffic is to be 661 transported. Implementation of this feature is therefore completely 662 network specific. Hence the ambiguity in how policing and scheduling 663 use the two rates is an inherent and currently unresolved issue in 664 IP-IS technology. 666 The receiver TSpec rate describes the traffic for which resources are 667 to be reserved, and may be used for policing, while the RSpec rate 668 (which cannot be smaller) is the allocated service bandwidth (or 669 strictly speaking, a lower bound on this). A receiver increases R 670 over r_r to reduce the delay. 672 When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic 673 descriptor parameters (PCR, SCR, MBS) can often be set cannonically 674 as: 676 PCR = p_r 677 SCR = R 678 MBS = b_r. 680 There are a number of conditions that may lead to different choices. 681 The following discussion is not intended so much to set hard 682 requirements, but to provide some interpretation and guidance on the 683 bounds of possible parameter mappings. The ingress edge device 684 generally includes a buffer preceding the ATM network interface. 685 This buffer can be used to absorb bursts that fall within the IP- 686 level TSpec, but not within the ATM traffic descriptor. The minimal 687 requirement for guaranteed service is that the delay in this buffer 688 may not exceed b/R, and the delays within the ATM network must be 689 accurately accounted for in the values of Adspec parameters C and D 690 advertised by the ingress router (see Section 3.3 below). 692 In general, if either an edge device buffer of size b_r exists or the 693 ATM maximum burst size (MBS) parameter is at least b_r, then the 694 various rate parameters will generally exhibit the following 695 relationship: 697 r_r <= SCR <= R <= PCR <= APB <= line rate 699 r_r <= p_r <= APB 701 APB refers to the General Characterization Parameter, 702 AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion 703 of the PATH message. APB reflects the narrowest bottleneck rate 704 along the path, and so is always bounded by the local line rate. The 705 receiver must choose a peak rate no greater than APB for the 706 reservation to be accepted, although the source peak rate, p_s, could 707 be higher, as the source does not know the value of APB. There is no 708 advantage to allocating any rate above APB of course, so it is an 709 upper bound for all the other parameters. 711 We might normally expect to find R <= p_r, as would be necessary for 712 the simple mapping of PCR = p_r, SCR = R given above. However, a 713 receiver is free to choose R > p_r to lower the GS delay [8]. In 714 this case, PCR cannot be set below R, because a burst of size b 715 arriving into the buffer must be cleared at rate R to keep the first 716 component of GS delay down to b/R. So here we will have PCR = R. 718 In the case R <= p_r, we may still choose R <= PCR < p_r. The edge 719 device buffer is then necessary (and sufficient) to absorb the bursts 720 (limited to size b_r) which arrive faster than they depart. For 721 example, it may be the case that the cost of the ATM VC depends on 722 PCR, while the cost of the Internet service reservation is not 723 strongly dependent on the IP-level peak rate. The user may the have 724 an incentive to set p_r to APB, while the operator of the IP/ATM edge 725 router has an incentive to reduce PCR as much as possible. This may 726 be a realistic concern, since the charging models of IP and ATM are 727 historically different as far as usage sensitivity, and the value of 728 p_r, if set close to APB, could be many times the nominal GS 729 allocated rate of R. Thus, we can set PCR to R, with a buffer of 730 size b, with no loss of traffic, and no violation of the GS delay 731 bound. 733 A more subtle, and perhaps controversial case is where we set SCR to 734 a value below R. The major feature of the GS service is to allow a 735 receiver to specify the allocated rate R to be larger than the rate 736 r_r sufficient to transport the traffic, in order to lower the 737 queueing delay (roughly) from b/r + C_TOT/r + D_TOT to b/R + C_TOT/R 738 + D_TOT. To effectively allocate bandwidth R to the flow, we set SCR 739 to match R. (Note it is unnecessary in any case to set SCR above R, 740 so the relation, SCR <= R, is still true.) It is possible to set SCR 741 to a value as low as r_r, without violating the delay bounds or 742 overflowing the edge device buffer. With PCR = R, a burst of size b 743 will be buffered and sent into the ATM network at rate R, so the last 744 byte suffers delay only b/R. Any further traffic will be limited to 745 rate r_r, which is SCR, so with the arriving and departing rates 746 matched, its delay will also be no more than b/R. 748 While this scenario meets the GS service requirements, the penalty 749 for allocating SCR = r_r rather than R is that the delay in the ATM 750 network will have a component of MBS/SCR, which will be b/r rather 751 than b/R, contained in the D term advertised for the ATM sub-network 752 (see further discussion in Section 3.3 below). It is also true that 753 allocating r instead of R in a portion of the path is rather against 754 the spirit of GS. As mentioned above, this mapping may however be 755 useful in practice in the case where pricing in the ATM network leads 756 to different incentives in the tradeoff between delay and bandwidth 757 than those of the user who buys IP integrated services. 759 Another point of view on parameter mapping suggests that SCR should 760 merely reflect the traffic description, hence SCR = r_r, while the 761 service requirement is expressed in the QoS parameter as CDV = b/R. 762 Thus the ATM network may internally allocate bandwidth R, but it is 763 free to use other methods as well to achieve the delay constraint. 764 Mechanisms such as statistical flow/connection aggregation may be 765 implemented in the ATM network and hidden from the user (or parameter 766 mapping module in the edge router) which sees only the interface 767 implemented in the signalled parameters. 769 Note that this discussion considers an edge device buffer size of 770 b_r. In practice, it may be necessary for the AAL/segmentation 771 module to buffer M bytes in converting packets to cells. Also an 772 additional amount of buffer equal to C_sum + R D_sum is generally 773 necessary to absorb jitter imposed by the upstream network [8]. 775 With ATM, it is possible to have little or no buffer in the edge 776 router, because the ATM VC can be set to accept bursts at peak rate. 777 This may be unusual, since the edge router normally has enough buffer 778 to absorb bursts according to the TSpec token bucket parameters. We 779 consider two cases. First, if PCR >= p_r, then MBS can be set to b_r 780 and no buffering is necessary to absorb normal bursts. The extra 781 buffering needed to absorb jitter can also be transferred to MBS. 783 This effectively moves the buffering across the UNI into the ATM 784 network. 786 For completeness, we consider an edge router with no burst-absorbing 787 buffers and an MBS parameter of approximately zero. In this case it 788 is sufficient to set the rate parameters to PCR = SCR = max (R, p_r). 789 This amounts to peak-rate allocation of bandwidth, which will not 790 usually be very cost effective. One reason for mentioning this case 791 might be that IP routers and ATM switches differ so substantially in 792 their buffering designs that IP-level users typically specify much 793 larger burst parameters than can be handled in the ATM subnet. 794 Peak-rate bandwidth allocation provides a means to work around this 795 problem. It is also true that intermediate tradeoffs can be 796 formulated, where the burst-absorbing buffer is less than b bytes, 797 and SCR is set above R and below p_r. Note that jitter-absorbing 798 buffers (C_sum + R D_sum) can not be avoided, generally, by 799 increasing ATM rates, unless SCR is set to exceed the physical line 800 rate(s) into the edge device for the flow. 802 For GS over CBR, the value of PCR may be mapped to the RSpec rate R, 803 if the edge device has a buffer of size b_r. With little or no burst 804 buffering, the requirements resemble the zero-buffer case above, and 805 we have PCR = max (R, p_r). Additional buffers sufficient to absorb 806 network jitter, given by C_sum, D_sum, must always be provided in the 807 edge router, or in the ATM network via MBS. 809 2.5.2 Translating Traffic Descriptors for Controlled Load Service 811 The Controlled Load service TSpec has a peak rate, p, a "token 812 bucket" rate, r, and a corresponding token bucket depth parameter, b. 813 The receiver TSpec values are used to determine resource allocation, 814 and a simple mapping for the nrtVBR service category is given by, 816 PCR = p_r 817 SCR = r_r 818 MBS = b_r. 820 The discussions in the preceding section on using edge device buffers 821 to reduce PCR, increasing buffers to reduce PCR and trading off 822 between such buffers and MBS, apply generally to the CLS over nrtVBR 823 case as well. Extra buffers to accommodate jitter accumulated 824 (beyond the b_r burst size allowed at the source) must be provided. 825 For CLS, there are no Adspec parameters C and D, so the estimation of 826 such buffers is an implementation design issue. 828 For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate 829 (MCR) parameter. Since there is no corresponding signalled bucket 830 depth parameter, the edge device must have a buffer of at least b_r 831 bytes. Since the actual transfer rate can vary substantially with 832 ABR, the buffering should not be made so large that the, in an 833 attempt to avoid loss, that delays exceed higher-layer timeouts, 834 e.g., TCP retransmission. 836 For CBR, the TSpec rate r_r sets a lower bound on PCR, and again, the 837 available buffering in the edge device must be adequate to 838 accommodate possible bursts of b_r. 840 The requirement for CLS that network delays approximate "best-effort 841 service under unloaded conditions", is interpreted here to mean that 842 an allocation of (at least) r_r, resulting in the last byte of a 843 burst of size b_r having delay approximately b_r/r_r, is sufficient. 844 A network element e.g., with no cross-traffic, work conserving 845 scheduling and output link rate of r_L might provide delays in the 846 range from M/r_L to b_r/r_L, which may be much better. 848 2.5.3 Translating Traffic Descriptors for Best Effort Service 850 For Best Effort service, there is no traffic description. The UBR 851 service category allows negotiation of PCR, simply to allow the 852 source to discover the smallest physical bottleneck along the path. 853 (The ingress edge router should set PCR to the ATM line rate, and may 854 wish to make use of the returned value when the VC is set up.) Often 855 a service provider will want to statically configure large VCs with a 856 certain bandwidth allocation to handle all best effort traffic 857 between two edge routers. ABR, CBR or nrtVBR VCs are appropriate for 858 this with traffic parameters set to comfortably accommodate the 859 expected traffic load. See [10,11]. 861 2.6 QoS Classes and Parameters 863 In UNI 3.x the quality of service is indicated by a single parameter 864 called "QoS Class," which is essentially an index to a network 865 specific table of values for the actual QoS parameters. In TM/UNI 866 4.0 three QoS parameters may be individually signalled, and the 867 signalled values override those implied by the QoS Class, which is 868 still present. These parameters are the Cell Loss Ratio (CLR), Cell 869 Transfer Delay (CTD), and Cell Delay Variation (CDV) [6]. 871 A network provider may choose to associate other parameters, such as 872 Severely Errored Cell Block Ratio, with a QoS Class definition, but 873 these cannot be signalled individually. The ATM Forum UNI 3.0, 3.1 874 and TM 4.0 specs, following prior ITU specs, give vague qualitative 875 definitions for QoS Classes 1 to 4. (QoS Class 0 is well-defined as 876 "no QoS parameters defined".) Since our mapping is based on these 877 specifications, we generally follow this guidance by setting QoS 878 Class value to 0 for UBR and ABR (as required), 1 for CBR and rtVBR 879 and 3 for nrtVBR. Note that the QoS Class follows the ATM service 880 category, and not the IP service, to avoid combination that are 881 unlikely to be supported. For example, if only nrtVBR is available 882 for GS, then choosing QoS Class = 1 would probably result in 883 connection failure, rather than a way to add real-time behavior to an 884 inherently non-real-time service. 886 The ITU has recently included a standard set of parameter values for 887 a (small) number of QoS Classes in the latest version of 888 Recommendation I.356, October 1996. Network providers may choose to 889 define further network-specific QoS Classes in addition to these. 890 Note that the QoS class definitions in the new I.356 version may not 891 align with the model we follow from the UNI specs. Apart from these 892 definitions, the problem of agreement between network providers as to 893 the definition of QoS Classes has not, to our knowledge, been 894 addressed. 896 The ATM QoS parameters have no explicitly signalled IP layer 897 counterparts. The values that should be signalled in the ATM network 898 are determined by knowledge of certain network characteristics and 899 the IP service definitions. 901 The ingress edge router must keep a table of QoS information for the 902 set of egress routers that it may establish VCs with. This table may 903 be simplified by using default values, but it will probably be good 904 network practice to maintain a table of current data for the most 905 popular egress points. An ATM network generally needs to have some 906 way to propose initial value for CDV and CTD, even if changed by 907 negotiation; so by positing such a table, we are not creating any new 908 design burden. Cached information can be updated when VCs are 909 successfully established, and to the extent that IP-layer 910 reservations can wait for VCs to complete, the values can be refined 911 through iterated negotiation. In general the construction of this 912 table is implementation specific. 914 Both GS and CLS require that losses of packets due to congestion 915 should be minimized, so that the loss rate is approximately the same 916 as for an unloaded network. The characteristic loss behavior of the 917 link-layer medium not due to congestion (e.g., bit errors or fading 918 on wireless channels) determines the order of the permitted packet 919 loss rate. The ingress edge device will choose a value of CLR that 920 provides the appropriate IP-level packet loss rate. The CLR value 921 may be uniform over all egress points in the ATM network, or may 922 differ, e.g., when wireless or satellite ATM links in the path. The 923 determination of CLR should account for the effects of packet size 924 distribution and ATM Frame Discard mode (which can change the 925 effective packet loss rate by orders of magnitude, given the same 926 underlying cell loss rate [20]). 928 The ingress router will also tabulate values for the Minimum Path 929 Latency (MPL) and estimated queueing delays (D_ATM) for each egress 930 point. The latter will be used as part of the Adspec "D" parameter 931 for GS, but its use here applies to CLS as well. MPL represents all 932 non-congestion related delays, including propagation delay. D_ATM 933 accounts for the variable component of delays in the ATM network. 934 (It may depend on parameters such as CDVT, etc.) Hence, when a VC is 935 set up, the delay-related QoS parameters are given by 937 CDV = D_ATM 938 CTD = D_ATM + MPL. 940 (CDV and CTD may be increased by the slack term in GS, see Section 941 3.3 below.) For rtVBR, the value of CDV will generally have a 942 component of MBS/SCR analogous to the b/R term in the delay of GS 943 service. It may have other components that depend on the ATM switch 944 implementation. In cases where the ATM network uses statistical 945 resource allocation methods, it may be possible to establish VCs with 946 CDV less than MBS/SCR. This capability should be reflected in the 947 D_ATM values advertised in GS and used to determine CDV in for VCs 948 supporting both GS and CLS. 950 It is interesting (and perhaps unfortunate) to note that in a typical 951 GS/rtVBR service, the delay bound advertised can contain two 952 components of b/R instead of one. Consider the case where SCR = R 953 and MBS = b. Parekh's theory, which is the basis of the GS delay 954 formula [8] states that the b/R delay term occurs only once, because 955 once a burst of size b has been served by a congested node at rate R, 956 the packets will not arrive at a subsequent node as a single burst. 957 However, we can't tell if this bottleneck will occur in the ATM 958 network or elsewhere in the IP network, so the declaration of CDV 959 must account for it. Once CDV is set, the ATM network can impose 960 that delay. Since the delay b/R can also occur elsewhere, it cannot 961 be removed from the first term of the GS delay formula. The ATM b/R 962 delay component appears in the third term, D_tot. See Section 3.3 963 below for more on GS Adspec parameters. This effect may be 964 unapparent when the ATM network employs more efficient statistical 965 resource allocation schemes. 967 2.7 Additional Parameters -- Frame Discard Mode 969 TM/UNI 4.0 allows the user to choose a mode where the ATM network is 970 aware, for the purpose of congestion management, of PDUs larger than 971 an ATM cell (i.e., AAL PDUs that correspond in our context to IP 972 packets). This facilitates implementation of algorithms such as 973 partial packet discard, where a dropped cell causes subsequent cells 974 in the AAL5 PDU to be dropped as well. Several other applicable 975 buffer management schemes have been proposed [20, 21]. 977 Frame discard can improve efficiency and the performance of end-to- 978 end protocols such as TCP, since the remaining cells of a damaged PDU 979 are generally useless to the receiver. For IP over ATM, Frame 980 Discard should always be indicated, if available. 982 3.0 Additional IP-Integrated Services Protocol Features 984 3.1 Path Characterization Parameters for IP Integrated Services with ATM 986 This section discusses the setting of General Characterization 987 Parameters (GCPs) at an ATM egress edge router. GCPs are signalled 988 from source to destination, and modified by intermediate nodes using 989 the Adspec portion of PATH messages in rsvp. The GS-specific Adspec 990 parameters are discussed below in Section 3.3. These parameters are 991 denoted as where x is the service and y is the parameter 992 number. Service number 1 indicates default or general parameter 993 values. Please refer to [22] for definitions and details. 995 The IS break bit <1,2> should, of course, be left alone by 996 implementations following these guidelines (as they are presumably 997 IS-aware). Similarly, the router should always increment IS_HOPS 998 <1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2> 999 respectively, should be set if the support of the service is 1000 inadequate. In general GS is adequately supported by CBR (BCOB-A) 1001 and rtVBR service categories, and not adequately supported by UBR, 1002 ABR and nrtVBR because delays are not controlled. CLS may be 1003 adequately supported by all service categories except UBR (or Best 1004 Effort in UNI 3.x). See Sections 5, 6 for further discussion. 1006 For GS, the ATM network must meet the delay performance advertised 1007 through the Adspec parameters, MPL, C, and D. If it cannot 1008 predictably meet these requirements, the GS break bit should be set. 1009 Similarly both break bits should be set if reservations are honored, 1010 but sufficient resources to avoid congestion loss are not allocated 1011 in practice. If the service break bits are not set, then the 1012 corresponding service hop counters, <2,4>, <5,4>, should be 1013 incremented. 1015 The Available Path Bandwidth (APB) parameters indicate the 1016 minimum physical bottleneck rate along the path. This may be 1017 discoverable in an ATM network as the negotiated PCR value for a UBR 1018 VC along the path. This value should be corrected for AAL, ATM and 1019 physical-layer headers, as necessary, to reflect the effective IP 1020 datagram bandwidth. With ATM, it is possible that there is some 1021 policy limitation on the value of PCR, below the physical link 1022 bottleneck. In this case, the advertised value of APB (in general 1023 and for each service if different) should reflect this limit, since 1024 excess traffic beyond this rate will be dropped. (Note that there is 1025 no tagging of traffic in excess of PCR for TM/UNI 4.0.) These values 1026 should generally be cached by the ingress router for the set of 1027 egress routers that it typically needs to establish VCs to. The 1028 Adspec parameters are only adjusted down, to reflect the 1029 minimum as the composed value. 1031 In the case of a multipoint VC, several parameters can be different 1032 for each egress point. In this case, the IWF at the egress routers 1033 must correct these values in PATH messages as they exit the ATM 1034 network. This is the only case where the egress router needs to 1035 operate on rsvp control messages. (A similar correction must be 1036 implemented for any non-rsvp set-up mechanism). The parameters that 1037 require such correction are specifically the Available Path Bandwidth 1038 (APB), the Minimum Path Latency (MPL), the Path MTU (although for 1039 ATM/AAL5 this may typically be constant), and the ATM-specific 1040 components of the GS Adspec parameters C_ATM and D_ATM. 1042 The ingress router table must store values for the ATM-network MPL 1043 for the various egress points. The composed values are 1044 formed by addition and forwarded along the path. In the cases where 1045 ATM routing chooses different paths for VCs to a given egress point, 1046 depending on the service category, the table will generally reflect 1047 different values for each service. If the ATM network is very large 1048 and complex, it may become difficult to predict the routes that VCs 1049 will take once they are set up. This could be a significant source 1050 of misconfiguration, resulting in discrepancies between GS delay 1051 advertisements and actual results. The RSpec Slack term may be 1052 useful in mitigating this problem. 1054 AAL 5 will support any message size up to 65,535 bytes, so setting 1055 the AAL SDU to the receiver TSpec M parameter value should generally 1056 not be a issue. In the PATH Adspec, however, the PATH_MTU parameter 1057 for each service should be set to 9180 bytes, which is the 1058 default MTU for AAL 5. 1060 3.2 Handling of Excess Traffic 1062 CLS requires and GS recommends that network elements transport 1063 traffic in excess of the TSpec parameters whenever physical resources 1064 (bandwidth, buffers and processing) are available. While excess 1065 traffic should be supported on a best effort basis, it should not 1066 interfere with the QoS (delay and loss) of conforming CLS and GS 1067 traffic, nor with normal service of non-reserved best effort traffic. 1069 There are several solutions with ATM: the most attractive is to use a 1070 VBR service category (with an appropriate conformance definition) and 1071 tag excess traffic as low priority using the CLP bit. This avoids 1072 reordering of the flow, but requires care in the design of the egress 1073 router scheduler. To avoid reordering, the excess traffic would be 1074 queued with conforming traffic. A threshold must be used to ensure 1075 that conforming traffic is not unnecessarily delayed by the excess. 1076 Also, for GS, the extra delay that would be incurred due to excess 1077 traffic below the threshold would have to be accurately reflected in 1078 the delay advertisement. Note that the egress router should 1079 uniformly tag all the cells of each non-conforming packet, rather 1080 than letting the ATM network apply tagging due to ATM-level non- 1081 conformance. 1083 There is no requirement in ATM standards that tagged cells, marked 1084 either by the user or by policing, must be transported if possible. 1085 Therefore, the operator of an edge router supporting IP-IS should 1086 ascertain the actual behavior of the ATM equipment in the path, which 1087 may span multiple administrative domains in the ATM network. If 1088 tagged cells are simply dropped at some point, regardless of load, 1089 then the operator may consider setting the break bit, at least for 1090 CLS service. 1092 The other solutions generally involve a separate VC to carry the 1093 excess. A distinct VC can be set up for each VC supporting a GS or 1094 CLS flow, or, if many flows are aggregated into a single QoS VC, then 1095 another VC can handle the excess traffic for that set of flows. A VC 1096 can be set up to handle all excess traffic from the ingress router to 1097 the egress point. Since the QoS of the excess traffic is not 1098 particularly constrained, the design is quite flexible. The service 1099 category for the excess-traffic VC may typically be UBR or ABR, 1100 although one could use CBR or nrtVBR if the excess traffic were 1101 predictable enough to know what rate to allocate. (This wouldn't 1102 normally be expected for excess traffic, though.) 1104 Whether a separate VC is used may be influenced by the design of the 1105 router scheduler. The CLS spec suggests two possible 1106 implementations: one where excess traffic shares the Best Effort 1107 class scheduler allocation, but at lower priority than other best 1108 effort traffic. The other where a separate allocation is made. The 1109 first would allow excess traffic to use the same VC as normal best 1110 effort traffic, and the second would suggest a separate VC. 1112 TM/UNI 4.0. does not support tagging of traffic in excess of PCR. 1113 Although UNI 3.x does have a separate PCR parameter for CLP=0 cells 1114 only, we do not recommend using this feature for reasons of 1115 interoperability. This restricts CBR VCs to use solutions other than 1116 tagging. The value of PCR can be set higher than necessary for 1117 conformant traffic, in an effort to support excess traffic on the 1118 same VC. In some cases this may be a viable solution, such as when 1119 there is little additional cost imposed for a high PCR. If PCR can 1120 be set as high as APB, then the excess traffic is fully accommodated. 1122 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term 1124 The Adspec is used by the Guaranteed Service to allow a receiver to 1125 calculate the worst-case delay associated with a GS flow. Three 1126 quantities, C, D, and MPL, are accumulated (by simple addition of 1127 components corresponding to each network element) in the PATH message 1128 from source to receiver. The resulting delay values can be different 1129 for each unique receiver. The maximum delay is then computed as 1131 delay <= b_r/R + C_TOT/R + D_TOT + MPL 1133 The Minimum Path Latency (MPL) includes propagation delay, while 1134 b_r/R accounts for bursts and C and D include other queueing, 1135 scheduling and serialization delays. (We neglect the effect of 1136 maximum packet size and peak rate here; see the GS specification [8] 1137 for a more detailed equation.) The service rate requested by the 1138 receiver, R, can be greater than the TSpec rate, r_r, resulting in 1139 lower delay. The burst size, b_r, is the leaky bucket parameter from 1140 the receiver TSpec. 1142 The values of C and D that a router advertises depend on both the 1143 router packet scheduler, and the characteristics of the subnet 1144 attached to the router. Each router (or the source host) takes 1145 responsibility for its downstream subnet in its advertisement. For 1146 example, if the subnet is a simple point-to-point link, the subnet- 1147 specific parts of C and D need to account for the link transmission 1148 rate and MTU. An ATM subnet is generally more complex. 1150 For this discussion, we consider only the ATM subnet-specific 1151 components, denoted C_ATM and D_ATM. The ATM network can be 1152 represented as a "pure delay" element, where the variable queueing 1153 delay, given by CVD is captured in D_ATM, and C_ATM = 0. It is 1154 possible to use C_ATM only when the ATM service rate equals R. This 1155 may be the case, for example with a CBR VC with PCR = R. Usually it 1156 will be simpler to just advertise the total delay variation (CDV) in 1157 D_ATM. 1159 As discussed in Section 2.6, the edge router keeps a table with 1160 values of MPL and D_ATM for each egress router it needs to share VCs 1161 with. The values of D_ATM contribute to the D parameter advertised 1162 by the edge router, and should accurately reflect the CDV that the 1163 router will get in a VC when it is set up. Factors that affect CDV, 1164 such as statistical multiplexing in the ATM network, should be taken 1165 into account when compiling data for the router's table. In case of 1166 uncertainty, D_ATM can be set to an upper bound. 1168 When a RESV message arrives, causing a VC to be set up, the requested 1169 values for CTD and CDV can be relaxed using the slack term in the 1170 receiver RSpec: 1172 CTD = D_ATM + MPL + S_ATM 1173 CDV = D_ATM + S_ATM. 1175 The term S_ATM is the portion of the slack term applied to the ATM 1176 portion of the path. Recall that the slack term [8] is positive when 1177 the receiver can afford more delay than that computed from the 1178 Adspec. The ATM edge device may take part (or all) of the slack term 1179 S. The distribution of delay slack among the nodes and subnets is 1180 network specific. 1182 Note that with multipoint VCs the egress edge router may need to 1183 correct advertised values of C and D. See discussion in Section 3.1. 1185 4.0 Miscellaneous Items 1187 4.1 Units Conversion 1189 All rates and token bucket depth parameters that are mapped from IP- 1190 level parameters to ATM parameters must be corrected for the effects 1191 of cell headers, AAL headers and segmentation of packets into cells. 1192 At the IP layer, bucket depths and rates are measured in bytes and 1193 bytes/sec, respectively, whereas for ATM, they are measured in cells 1194 and cells/sec. 1196 Packets are segmented into 53 byte cells of which the first 5 bytes 1197 are header information. For 1199 B = number of Bytes, 1200 C = number of cells, 1202 a rough approximation between the token bucket parameters (rate and 1203 bucket depth) is 1205 C = B/48. 1207 This is actually a lower bound on C and does not take into account 1208 the extra padding at the end of a partially filled cell, or the 8 1209 byte trailer in the last cell of an AAL5 encoding. The actual 1210 relationship between the number of cells and bytes of one packet is 1212 C = 1 + int(B/48) + x, 1214 where x = 1 if B mod 48 > 41 1215 0 otherwise. 1217 where int() is the rounding down operation. The third term is 0 or 1218 1 and is 1 only when the remainder of B/48 is 41 or more. (An 1219 additional cell is needed because the 41 bytes plus 8 byte trailer 1220 will not fit in a cell.) 1222 The above formula is not particularly amenable to engineering 1223 considerations. By equating the number of bytes before and after 1224 segmentation we have 1226 48 C = B + 8 + A, 1228 where A is the additional padding used in the last 2 cells and has 1229 the range 0 <= A <= 47. From this we obtain a number of useful 1230 observations. 1232 For example, if one believes that the packet lengths are uniformly 1233 distributed mod 48, then on average, 48 C = B + 8 + 47/2, or C = B/48 1234 + .65625. 1236 We can also make use of the upper bound on A to state that 48 C <= B 1237 + 55. This is true for any one packet. Considering the number of 1238 bytes in a stream of P packets, we have 1240 48 C <= B + 55 P. 1242 The number of packets P may not be a readily available quantity. 1243 However, in terms of the minimum policed unit m, we know that P * m 1244 <= B. Hence P <= B/m and 48 C <= B ( 1 + 55/m). That is, 1246 C <= B/48 * (1 + 55/m). 1248 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service 1250 This section describes how to create ATM VCs appropriately matched 1251 for Guaranteed Service. The key points differentiating among ATM 1252 choices are that real-time timing is required, that the data flow may 1253 have a variable rate, and that demotion of non-conforming traffic to 1254 best effort is required to be in agreement with the definition of GS. 1255 For this reason, we prefer an rtVBR service in which tagging is 1256 supported. Another good match is to use CBR with special handling of 1257 any non-conforming traffic, e.g., through another VC, since a CBR VC 1258 will not accommodate traffic in excess of PCR. 1260 Note, these encodings assume point to multipoint connections, where 1261 the backward channel is not used. If the IP session is unicast only, 1262 then a point-to-point VC may be used and the IWF may make use of the 1263 backward channel, provided that the QoS parameters are mapped 1264 consistently for the service provided. 1266 5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0) 1268 AAL 1269 Type 5 1270 Forward CPCS-SDU Size parameter M of receiver TSpec 1271 Backward CPCS-SDU Size 0 1272 SSCS Type 0 (Null SSCS) 1274 Traffic Descriptor 1275 Forward PCR CLP=0+1 Note 1 1276 Backward PCR CLP=0+1 0 1277 Forward SCR CLP=0 Note 1 1278 Backward SCR CLP=0 0 1279 Forward MBS (CLP=0) Note 1 1280 Backward MBS (CLP=0) 0 1281 BE indicator NOT included 1282 Forward Frame Discard bit 1 1283 Backward Frame Discard bit 1 1284 Tagging Forward bit 1 (Tagging requested) 1285 Tagging Backward bit 1 (Tagging requested) 1287 Broadband Bearer Capability 1288 Bearer Class 16 (BCOB-X) Note 2 1289 ATM Transfer Capability 9 (Real time VBR) Note 3 1290 Susceptible to Clipping 00 (bit encoding for Not 1291 susceptible) 1292 User Plane Configuration 01 (bit encoding for pt-to-mpt) 1294 Broadband Low Layer Information 1295 User Information Layer 2 1296 Protocol 12 (ISO 8802/2) 1297 User Information Layer 3 1298 Protocol 11 (ISO/IEC TR 9577) Note 4 1299 ISO/IEC TR 9577 IPI 204 1301 QoS Class 1302 QoS Class Forward 1 Note 5 1303 QoS Class Backward 1 Note 5 1305 QoS Parameters Note 6 1306 Acceptable Forward CDV 1307 Acceptable Forward CLR 1308 Forward Max CTD 1310 Note 1: See discussion Section 2.5.1. 1311 Note 2: Value 3 (BCOB-C) can also be used. 1312 Note 3: The ATC value 19 is not used. The value 19 implies CLR 1313 objective applies to the aggregate CLP=0+1 stream and 1314 that does not give desirable treatment of excess 1315 traffic in the case of IP. 1316 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol should 1317 be specified. For BE VCs, it can be left unspecified, allowing 1318 the VC to be shared by multiple protocols, following RFC 1755. 1319 Note 5: Cf ITU I.365 (Oct 1996) for new QoS Class definitions. 1320 Note 6: See Section 2.6 for the values to be used. 1322 5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0) 1324 It is also possible to support GS using a CBR "pipe." The advantage 1325 of this is that CBR is probably supported; the disadvantage is that 1326 data flows may not fill the pipe (utilization loss) and there is no 1327 tagging option available. 1329 AAL 1330 Type 5 1331 Forward CPCS-SDU Size parameter M of receiver TSpec 1332 Backward CPCS-SDU Size parameter M of receiver TSpec 1333 SSCS Type 0 (Null SSCS) 1335 Traffic Descriptor 1336 Forward PCR CLP=0+1 Note 1 1337 Backward PCR CLP=0+1 0 1338 BE indicator NOT included 1339 Forward Frame Discard bit 1 1340 Backward Frame Discard bit 1 1341 Tagging Forward bit 0 (Tagging not requested) 1342 Tagging Backward bit 0 (Tagging not requested) 1344 Broadband Bearer Capability 1345 Bearer Class 16 (BCOB-X) Note 2 1346 ATM Transfer Capability 5 (CBR) Note 3, 4 1347 Susceptible to Clipping 00 (bit encoding for Not 1348 susceptible) 1349 User Plane Configuration 01 (bit encoding for pt-to-mpt) 1351 Broadband Low Layer Information 1352 User Information Layer 2 1353 Protocol 12 (ISO 8802/2) 1354 User Information Layer 3 1355 Protocol 11 (ISO/IEC TR 9577) Note 5 1356 ISO/IEC TR 9577 IPI 204 1358 QoS Class 1359 QoS Class Forward 1 Note 6 1360 QoS Class Backward 1 Note 6 1362 QoS Parameters Note 7 1363 Acceptable Forward CDV 1364 Acceptable Forward CLR 1365 Forward Max CTD 1367 Note 1: See discussion Section 2.5.1. 1368 Note 2: Value 1 (BCOB-A) can also be used. 1369 Note 3: If bearer class A is chosen the ATC field must be absent. 1370 Note 4: The ATC value 7 is not used. The value 7 implies CLR 1371 objective applies to the aggregate CLP=0+1 stream and 1372 that does not give desirable treatment of excess 1373 traffic in the case of IP. 1374 Note 5: 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 6: Cf ITU I.365 (Oct 1996) for new QoS Class definitions. 1379 Note 7: See Section 2.6 for the values to be used. 1381 5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 1383 The remaining ATM service categories, including nrtVBR, do not 1384 provide delay guarantees and cannot be recommended as the best fits. 1385 However in some circumstances, the best fits may not be available. 1387 If nrtVBR is used, no hard delay can be given. However by using a 1388 variable rate service with low utilization, delay may be 1389 `reasonable', but not controlled. The encoding of GS as nrtVBR is 1390 the same as that for CLS using nrtVBR, except that the Forward PCR 1391 would be derived from the TSpec peak rate. See Section 6.2 below. 1393 5.4 Encoding GS Using ABR (ATM Forum TM/UNI 4.0) 1395 GS using ABR is a very unlikely combination. The objective of the 1396 ABR service is to provide "low" loss rates. The delay objectives for 1397 ABR should be expected to be very loose. If ABR were used for GS, 1398 the VC parameters would follow as for CLS over ABR. See Section 6.1. 1400 5.5 Encoding GS Using UBR (ATM Forum TM/UNI 4.0) 1402 The UBR service is the default lowest common denominator of the 1403 services. It cannot provide delay or loss guarantees. However if it 1404 is used for GS, it will be encoded in the same way as Best Effort 1405 over UBR, with the exception that the PCR would be determined from 1406 the peak rate of the receiver TSpec. See Section 7.1. 1408 5.6 Encoding GS Using ATM Forum UNI 3.0/3.1 Specifications 1410 It is not recommended to support GS using UNI 3.x VBR mode for the 1411 following reasons. The Class C bearer class does not represent 1412 real-time behavior. Appendix F of UNI 3.1 specification precludes 1413 the specification of traffic type "VBR" with the timing requirement 1414 "End to End timing Required" in conjunction with bearer class X. 1416 It is possible to support GS using a CBR "pipe." The following 1417 table specifies the support of GS using CBR. 1419 AAL 1420 Type 5 1421 Forward CPCS-SDU Size parameter M of receiver TSpec 1422 Backward CPCS-SDU Size parameter M of receiver TSpec 1423 Mode 1 (Message mode) Note 1 1424 SSCS Type 0 (Null SSCS) 1426 Traffic Descriptor 1427 Forward PCR CLP=0 Note 2 1428 Backward PCR CLP=0 0 1429 Forward PCR CLP=0+1 Note 2 1430 Backward PCR CLP=0+1 0 1431 BE indicator NOT included 1432 Tagging Forward bit 1 (Tagging requested) 1433 Tagging Backward bit 1 (Tagging requested) 1435 Broadband Bearer Capability 1436 Bearer Class 16 (BCOB-X) Note 3 1437 Traffic Type 001 (bit encoding for Constant Bit 1438 Rate) 1439 Timing Requirements 01 (bit encoding for Timing 1440 Required) 1441 Susceptible to Clipping 00 (bit encoding for Not 1442 susceptible) 1443 User Plane Configuration 01 (bit encoding for pt-to-mpt) 1445 Broadband Low Layer Information 1446 User Information Layer 2 1447 Protocol 12 (ISO 8802/2) 1448 User Information Layer 3 1449 Protocol 11 (ISO/IEC TR 9577) Note 4 1450 ISO/IEC TR 9577 IPI 204 1452 QoS Class 1453 QoS Class Forward 1 1454 QoS Class Backward 1 1456 QoS Parameters 1457 Parameters are implied by the QOS Class 1459 Note 1: Only included for UNI 3.0. 1460 Note 2: See discussion, Section 2.5.1. PCR CLP=0 should be set identical 1461 to PCR CLP=0+1. Although this could potentially allow a CBR VC 1462 to carry excess traffic as tagged cells, it is not recommended 1463 since it is not supported in UNI 4.0 1464 Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic 1465 Type and Timing Requirements fields are not included. 1466 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol should 1467 be specified. For BE VCs, it can be left unspecified, allowing 1468 the VC to be shared by multiple protocols, following RFC 1755. 1470 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 1472 This section describes how to create ATM VCs appropriately matched 1473 for Controlled Load. CLS traffic is partly delay tolerant and of 1474 variable rate. NrtVBR and ABR (for TM/UNI 4.0 only) are the best 1475 choices in supporting CLS. 1477 Note, these encodings assume point to multipoint connections, where 1478 the backward channel is not used. If the IP session is unicast only, 1479 then a point-to-point VC may be used and the IWF may make use of the 1480 backward channel, provided that the QoS parameters are mapped 1481 consistently for the service provided. 1483 6.1 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0) 1485 AAL 1486 Type 5 1487 Forward CPCS-SDU Size parameter M of receiver TSpec 1488 Backward CPCS-SDU Size parameter M of receiver TSpec 1489 SSCS Type 0 (Null SSCS) 1491 Traffic Descriptor 1492 Forward PCR CLP=0+1 Note 1 1493 Backward PCR CLP=0+1 0 1494 Forward MCR CLP=0+1 Note 1 1495 Backward MCR CLP=0+1 0 1496 BE indicator NOT included 1497 Forward Frame Discard bit 1 1498 Backward Frame Discard bit 1 1499 Tagging Forward bit 0 (Tagging not requested) 1500 Tagging Backward bit 0 (Tagging not requested) 1502 Broadband Bearer Capability 1503 Bearer Class 16 (BCOB-X) Note 2 1504 ATM Transfer Capability 12 (ABR) 1505 Traffic Type 010 (Variable Bit Rate) 1506 Timing Requirements 10 (Timing Not Required) 1507 Susceptible to Clipping 00 (Not susceptible) 1508 User Plane Configuration 00 (For pt-to-pt) 1510 Broadband Low Layer Information 1511 User Information Layer 2 1512 Protocol 12 (ISO 8802/2) 1513 User Information Layer 3 1514 Protocol 11 (ISO/IEC TR 9577) Note 3 1515 ISO/IEC TR 9577 IPI 204 1517 QoS Class 1518 QoS Class Forward 0 Note 4 1519 QoS Class Backward 0 Note 4 1521 QoS Parameters Note 5 1522 Acceptable Forward CDV 1523 Acceptable Forward CLR 1524 Forward Max CTD 1526 ABR Setup Parameters Note 6 1527 ABR Additional Parameters Note 6 1529 Note 1: See discussion, Section 2.5.2. 1530 Note 2: Value 3 (BCOB-C) can also be used. 1531 Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol should 1532 be specified. For BE VCs, it can be left unspecified, allowing 1533 the VC to be shared by multiple protocols, following RFC 1755. 1534 Note 4: Cf ITU I.365 (Oct 1996) for new QoS Class definitions. 1535 Note 5: See Section 2.6 for the values to be used. 1536 Note 6: The ABR-specific parameters are beyond the scope of this document. 1537 These generally depend on local implementation and not on values 1538 mapped from IP level service parameters (with the exception of MCR). 1539 See [6, 11] for further information. 1541 6.2 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 1542 AAL 1543 Type 5 1544 Forward CPCS-SDU Size parameter M of receiver TSpec 1545 Backward CPCS-SDU Size parameter M of receiver TSpec 1546 SSCS Type 0 (Null SSCS) 1548 Traffic Descriptor 1549 Forward PCR CLP=0+1 Note 1 1550 Backward PCR CLP=0+1 0 1551 Forward SCR CLP=0 Note 1 1552 Backward SCR CLP=0 0 1553 Forward MBS (CLP=0) Note 1 1554 Backward MBS (CLP=0) 0 1555 BE indicator NOT included 1556 Forward Frame Discard bit 1 1557 Backward Frame Discard bit 1 1558 Tagging Forward bit 1 (Tagging requested) 1559 Tagging Backward bit 1 (Tagging requested) 1561 Broadband Bearer Capability 1562 Bearer Class 16 (BCOB-X) Note 2 1563 ATM Transfer Capability 10 (Non-real time VBR) Note 3, 4 1564 Susceptible to Clipping 00 (bit encoding Not susceptible) 1565 User Plane Configuration 01 (bit encoding pt-to-mpt) 1567 Broadband Low Layer Information 1568 User Information Layer 2 1569 Protocol 12 (ISO 8802/2) 1570 User Information Layer 3 1571 Protocol 11 (ISO/IEC TR 9577) Note 5 1572 ISO/IEC TR 9577 IPI 204 1574 QoS Class 1575 QoS Class Forward 3 Note 6 1576 QoS Class Backward 3 Note 6 1578 QoS Parameters Note 7 1579 Acceptable Forward CDV 1580 Acceptable Forward CLR 1581 Forward Max CTD 1583 Note 1: See discussion, Section 2.5.2. 1584 Note 2: Value 3 (BCOB-C) can also be used. 1585 Note 3: If bearer class C is used, the ATC field must be absent 1586 Note 4: The ATC value 11 is not used. The value 11 implies CLR 1587 objective applies to the aggregate CLP=0+1 stream and 1588 that does not give desirable treatment of excess 1589 traffic in the case of IP. 1590 Note 5: For QoS VCs supporting GS or CLS, the layer 3 protocol should 1591 be specified. For BE VCs, it can be left unspecified, allowing 1592 the VC to be shared by multiple protocols, following RFC 1755. 1593 Note 6: Cf ITU I.365 (Oct 1996) for new QoS Class definitions. 1594 Note 7: See Section 2.6 for the values to be used. 1596 6.3 Encoding CLS Using Real-Time VBR (ATM Forum TM/UNI 4.0) 1598 The encoding of CLS using rtVBR imposes a hard limit on the delay, 1599 which is specified as an end-to-end delay in the ATM network. This 1600 is more stringent than the CLS service requires. 1602 If rtVBR is used to encode CLS, then the encoding is essentially the 1603 same as that for GS. See Section 5.1 and discussion in Section 1604 2.5.2. 1606 6.4 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0) 1608 Although CBR does not explicitly take into account the variable rate 1609 of source data, it may be convenient to use ATM connectivity between 1610 edge routers to provide a simple "pipe" service, as a leased line 1611 replacement. 1613 To use CBR for CLS, the same encoding for GS over CBR (Section 5.2 1614 would be used. See Section 2.5.2. 1616 6.5 Encoding CLS Using UBR (ATM Forum TM/UNI 4.0) 1618 This encoding gives no QoS guarantees. If used, it is coded in the 1619 same way as for BE over UBR, except that the PCR would be determined 1620 from the peak rate of the receiver TSpec. See Section 7.1. 1622 6.6 Encoding CLS Using ATM Forum UNI 3.0/3.1 Specifications 1623 This encoding is equivalent to the nrtVBR service category. 1625 AAL 1626 Type 5 1627 Forward CPCS-SDU Size parameter M of receiver TSpec 1628 Backward CPCS-SDU Size 0 1629 Mode 1 (Message mode) Note 1 1630 SSCS Type 0 (Null SSCS) 1632 Traffic Descriptor 1633 Forward PCR CLP=0+1 Note 2 1634 Backward PCR CLP=0+1 0 1635 Forward SCR CLP=0 Note 2 1636 Backward SCR CLP=0 0 1637 Forward MBS (CLP=0) Note 2 1638 Backward MBS (CLP=0) 0 1639 BE indicator NOT included 1640 Tagging Forward bit 1 (Tagging requested) 1641 Tagging Backward bit 1 (Tagging requested) 1643 Broadband Bearer Capability 1644 Bearer Class 16 (BCOB-X) Note 3 1645 Traffic Type 010 (bit encoding for Variable Bit 1646 Rate) 1647 Timing Requirements 00 (bit encoding for No Indication) 1648 Susceptible to Clipping 00 (bit encoding for Not 1649 susceptible) 1650 User Plane Configuration 01 (bit encoding for For pt-to-mpt) 1652 Broadband Low Layer Information 1653 User Information Layer 2 1654 Protocol 12 (ISO 8802/2) 1655 User Information Layer 3 1656 Protocol 11 (ISO/IEC TR 9577) Note 4 1657 ISO/IEC TR 9577 IPI 204 1659 QoS Class 1660 QoS Class Forward 3 1661 QoS Class Backward 3 1663 QoS Parameters 1664 Parameters are implied by the QOS Class 1666 Note 1: Only included for UNI 3.0. 1667 Note 2: See discussion, 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. 1674 7.0 Summary of ATM VC Setup Parameters for Best Effort Service 1676 This section should be considered informational only. RFC 1755 [10] and 1677 the IETF ION working group draft on ATM signalling support for IP over 1678 ATM using UNI 4.0 [11] provide more definitive specification of Best 1679 Effort IP service over ATM. 1681 The best-matched ATM service category to IP Best Effort is UBR. We 1682 provide the setup details for this case below. The BE service does not 1683 require reservation of resources. 1685 Note, VCs supporting best effort service are usually point to point, 1686 rather than point to multipoint, and the backward channels of VCs are 1687 used. In specific cases where VCs are set up to support best effort 1688 multicast sessions, multipoint VCs can be used and the backward channels 1689 would be not have resources reserved. Related situations include 1690 transport of excess traffic on IP-multicast QoS sessions, or to support 1691 the subset of multicast end systems that have not made rsvp 1692 reservations. 1694 7.1 Encoding Best Effort Service Using UBR (ATM Forum TM/UNI 4.0) 1696 AAL 1697 Type 5 1698 Forward CPCS-SDU Size 9180 (default MTU for AAL5) 1699 Backward CPCS-SDU Size 9180 (default MTU for AAL5) 1700 SSCS Type 0 (Null SSCS) 1702 Traffic Descriptor 1703 Forward PCR CLP=0+1 Note 1 1704 Backward PCR CLP=0+1 0 1705 BE indicator included 1706 Forward Frame Discard bit 1 1707 Backward Frame Discard bit 1 1708 Tagging Forward bit 1 (Tagging requested) 1709 Tagging Backward bit 1 (Tagging requested) 1711 Broadband Bearer Capability 1712 Bearer Class 16 (BCOB-X) Note 2 1713 ATM Transfer Capability 10 (Non-real time VBR) Note 3 1714 Susceptible to Clipping 00 (bit encoding for Not susceptible) 1715 User Plane Configuration 01 (bit encoding for pt-to-mpt) 1717 Broadband Low Layer Information 1718 User Information Layer 2 1719 Protocol 12 (ISO 8802/2) Note 4 1721 QoS Class 1722 QoS Class Forward 0 1723 QoS Class Backward 0 1725 Note 1: See discussion, Section 2.5.3. 1726 Note 2: Value 3 (BCOB-C) can also be used. 1727 Note 3: If bearer class C is used, the ATC field must be absent 1728 Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol should 1729 be specified. For BE VCs, it can be left unspecified, allowing 1730 the VC to be shared by multiple protocols, following RFC 1755. 1732 8.0 Security 1734 Some security issues are raised in the rsvp specification [2], which 1735 would apply here as well. There are no additional security 1736 considerations raised in this document. 1738 9.0 Acknowledgements 1740 The authors would like to thank the members of the ISSLL working 1741 group for their input. In particular, thanks to Drew Perkins and Jon 1742 Bennett of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha 1743 Ramesh of Bellcore. 1745 Appendix 1 Abbreviations 1747 AAL ATM Adaptation Layer 1748 ABR Available Bit Rate 1749 APB Available Path Bandwidth (int-serv GCP) 1750 ATM Asynchronous Transfer Mode 1751 B-LLI Broadband Low Layer Information 1752 BCOB Broadband Connection-Oriented Bearer Capability 1753 BCOB-{A,C,X} Bearer Class A, C, or X 1754 BE Best Effort 1755 BT Burst Tolerance 1756 CBR Constant Bit Rate 1757 CDV Cell Delay Variation 1758 CDVT Cell Delay Variation Tolerance 1759 CLP Cell Loss Priority (bit) 1760 CLR Cell Loss Ratio 1761 CLS Controlled Load Service 1762 CPCS Common Part Convergence Sublayer 1763 CTD Cell Transfer Delay 1764 EOM End of Message 1765 FFS For Further Study 1766 GCP General Characterization Parameter 1767 GCRA Generic Cell Rate Algorithm 1768 GS Guaranteed Service 1769 IE Information Element 1770 IETF Internet Engineering Task Force 1771 IP Internet Protocol 1772 IPI Initial Protocol Identifier 1773 IS Integrated Services 1774 ISSLL Integrated Services over Specific Link Layers 1775 ITU International Telecommunication Union 1776 IWF Interworking Function 1777 LIJ Leaf Initiated Join 1778 LLC Logical Link Control 1779 MBS Maximum Burst Size 1780 MCR Minimum Cell Rate 1781 MPL Minimum Path Latency 1782 MTU Maximum Transfer Unit 1783 nrtVBR Non-real-time VBR 1784 PCR Peak Cell Rate 1785 PDU Protocol Data Unit 1786 PVC Permanent Virtual Connection 1787 QoS Quality of Service 1788 RESV Reservation Message (of rsvp protocol) 1789 RFC Request for Comment 1790 RSVP Resource Reservation Protocol 1791 RSpec Reservation Specification 1792 rtVBR Real-time VBR 1793 SCR Sustained Cell Rate 1794 SDU Service Data Unit 1795 SNAP Subnetwork Attachment Point 1796 SSCS Service-Specific Convergence Sub-layer 1797 SVC Switched Virtual Connection 1798 Sw Switch 1799 TCP Transport Control Protocol 1800 TM Traffic Management 1801 TSpec Traffic Specification 1802 UBR Unspecified Bit Rate 1803 UNI User-Network Interface 1804 UPC Usage Parameter Control (ATM traffic policing function) 1805 VBR Variable Bit Rate 1806 VC (ATM) Virtual Connection 1808 REFERENCES 1810 [1] R. Braden, D. Clark and S. Shenker, "Integrated Services in the 1811 Internet Architecture: an Overview", RFC 1633, June 1994. 1813 [2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 1814 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 1815 Specification", RFC 2205, September 1997. 1817 [3] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1818 sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. 1820 [4] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1821 sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. 1823 [5] The ATM Forum, "ATM User-Network Interface (UNI) Signalling 1824 Specification, Version 4.0", July 1996. Publication by Prentice 1825 Hall pending; available at ftp://ftp.atmforum.com/pub/approved- 1826 specs/af-sig-0061.000.ps. 1828 [6] The ATM Forum, "ATM Traffic Management Specification, Version 1829 4.0", April 1996. Publication by Prentice Hall pending, avail- 1830 able at ftp://ftp.atmforum.com/pub/approved-specs/af-tm- 1831 0056.000.ps. 1833 [7] M. W. Garrett, "A Service Architecture for ATM: From Applica- 1834 tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6- 1835 14, May 1996. 1837 [8] S. Shenker, C. Partridge and R. Guerin, "Specification of 1838 Guaranteed Quality of Service", RFC 2212, September 1997. 1840 [9] J. Wroclawski, "Specification of the Controlled-Load Network 1841 Element Service", RFC 2211, September 1997. 1843 [10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. 1844 Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru- 1845 ary 1995. 1847 [11] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM 1848 UNI 4.0 Update", Internet Draft, October 1997. 1851 [12] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. 1852 Krawczyk, "A Framework for Integrated Services and RSVP over 1853 ATM", Internet Draft, July 1997. 1856 [13] L. Berger, "RSVP over ATM Implementation Requirements", Internet 1857 Draft, July 1997. 1859 [14] L. Berger, "RSVP over ATM Implementation Guidelines", Internet 1860 Draft, July 1997. 1862 [15] S. Shenker and J. Wroclawski, "Network Element Service Specifi- 1863 cation Template", RFC 2216, September 1997. 1865 [16] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 1866 RFC 2210, September 1997. 1868 [17] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of 1869 Real-time Services in an IP-ATM Network Architecture", RFC 1821, 1870 August 1995. 1872 [18] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 1873 Layer 5", RFC 1483, July 1993. 1875 [19] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January 1876 1994. 1878 [20] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net- 1879 works", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633- 1880 -41, May 1995, 1882 [21] S. Floyd, V. Jacobson, "Link-sharing and Resource Management 1883 Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, 1884 No. 4, August 1995. 1886 [22] S. Shenker and J. Wroclawski, "General Characterization Parame- 1887 ters for Integrated Service Network Elements", RFC 2215, Sep- 1888 tember 1997. 1890 Authors' Addresses 1892 Mark W. Garrett Marty Borden 1893 Bellcore New Oak Communications, Inc. 1894 445 South Street 42 Nagog Park 1895 Morristown, NJ 07960 Acton MA, 01720 1896 USA USA 1898 phone: +1 201 829-4439 phone: +1 508 266-1011 1899 email: mwg@bellcore.com email: mborden@newoak.com