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