idnits 2.17.1 draft-ietf-issll-atm-mapping-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 838 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1264, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1270, 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' == Outdated reference: A later version (-04) exists of draft-ietf-intserv-ctrl-load-svc-03 -- 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) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mark W. Garrett, 3 Bellcore 5 Marty Borden, 6 New Oak, Inc. 8 November, 1996. 10 Interoperation of Controlled-Load and Guaranteed-Service with ATM 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 27 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 Service mappings are an important aspect of effective interoperation 34 between Internet Integrated Services and ATM networks. Both Internet 35 and ATM technologies have well-defined service architectures. These 36 include definitions of several services and associated parameters 37 which quantify source traffic and Quality of Service (QoS) 38 requirements. 40 This draft provides mappings between IP and ATM services which will 41 facilitate effective end-to-end Quality of Service for IP networks 42 containing ATM subnetworks. We discuss the various features of 43 Guaranteed Service and Controlled Load Service, and identify 44 appropriate mechanisms in ATM Virtual Circuits (VCs), which 45 facilitate these services. 47 0.0 What's New in This Version 49 Section 3.2 on use of AdSpec in Guaranteed Service. 51 Expanded Section 2.5 on traffic descriptor mapping. 53 Placeholder Section 3.1 on handling of excess traffic 55 Mention of new I.356 version, which changes ITU QoS class definitions. 57 General cleanup of text. 59 1.0 Introduction 61 We consider the problem of providing IP Integrated Services [1] with 62 an ATM subnetwork. This document is intended to be consistent with 63 the rsvp protocol [2] for IP-level resource reservation (although it 64 is independent of rsvp to the extent that GS and CLS services could 65 be supported through another mechanism). In the ATM network, we 66 consider ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, 67 5]. The latter uses the more complete service model of The ATM 68 Forum's TM 4.0 specification [6, 7]. 70 This is a complex problem with many facets. In this draft, we focus 71 on the service types, parameters and signalling elements needed for 72 service interoperation. The resulting service mappings can be used 73 to provide effective end-to-end Quality of Service (QoS) for IP 74 traffic that traverses ATM networks. 76 The IP services considered are Guaranteed Service (GS) [8] and 77 Controlled Load Service (CLS) [9]. We also treat the default Best 78 Effort Service (BE) in parallel with these. Our recommendations for 79 BE are intended to be consistent with RFC 1755 [10], and its revision 80 (still in progress) [11], which defines how ATM VCs can be used in 81 support of normal BE IP service. The ATM services we consider are: 83 CBR Constant Bit Rate 84 rtVBR Real-time Variable Bit Rate 85 nrtVBR Non-real-time Variable Bit Rate 86 UBR Unspecified Bit Rate 87 ABR Available Bit Rate 89 (Note, Appendix 1 provides definitions for all abbreviations.) In 90 the case of UNI 3.0 and 3.1 signaling, where these service are not 91 all clearly distinguishable, we identify equivalent services where 92 possible. 94 The service mappings which follow most naturally from the service 95 definitions are as follows: 97 Guaranteed Service -> CBR or rtVBR 98 Controlled Load -> nrtVBR or ABR (with a minimum cell rate) 99 Best Effort -> UBR or ABR 101 For completeness we provide detailed mappings for all service 102 combinations and identify how each meets or fails to meet the 103 requirements of the higher level IP services. The reason for not 104 restricting mappings to the most obvious or natural ones is that we 105 cannot assume now that these services will always be ubiquitously 106 available. A number of details, such as treatment of packets in 107 excess of the flow traffic descriptor, make service mapping a 108 complicated subject, which cannot be expressed briefly and accurately 109 at the same time. 111 The remainder of this introduction provides a general discussion of 112 the system configuration and other assumptions. Section 2 considers 113 the relevant ATM protocol elements and their effects as related to 114 Guaranteed, Controlled Load and Best Effort services (the latter 115 being the default "service"). Section 3 discusses a number of 116 important features of the IP services and how they can be handled on 117 an ATM subnetwork. Section 4 addresses a few miscellaneous problems 118 which are neither distinctly IP nor ATM. Section 5 gives detailed VC 119 setup parameters for Guaranteed Service, and considers the effect of 120 using each of the ATM service categories. Section 6 provides a 121 similar treatment for Controlled Load Service. Section 7 considers 122 Best Effort service. 124 This document is only a part of the total solution to providing the 125 interworking of IP integrated services with ATM subnetworks. The 126 important issue of VC management, including flow aggregation, is 127 considered in [12]. We do not consider how routing -- QoS sensitive 128 or not -- interacts with the use of VCs, especially in the case of 129 multicast (or point-to-multipoint) flows. We expect that a 130 considerable degree of implementation latitude will exist, even 131 within the guidelines presented here. Many aspects of interworking 132 between IP and ATM will depend on economic factors, and will not be 133 subject to standardization. 135 1.1 General System Architecture 137 We assume that the reader has a general working knowledge of IP, rsvp 138 and ATM protocols. The network architecture we consider is 139 illustrated in Figure 1, below. An IP-attached host may send unicast 140 datagrams to another host, or may use an IP multicast address to send 141 packets to all of the hosts which have "joined" the multicast "tree". 142 In either case, a destination host may then use RSVP to establish 143 resource reservation in routers along the internet path for the data 144 flow. 146 An ATM network lies in the path (chosen by the IP routing), and 147 consists of one or many ATM switches. It uses VCs to provide both 148 resources and QoS within the ATM cloud. These connections are set 149 up, added to (in the case of multipoint trees), torn down, and 150 controlled by the edge devices, which act as both IP routers and ATM 151 interfaces, capable of initiating and managing VCs across the ATM 152 user-to-network (UNI) interface. The edge devices are assumed to be 153 fully functional in both the IP int-serv/RSVP protocols and the ATM 154 UNI protocols, as well as translating between them. 156 ATM Cloud 157 ------------------ 158 H ---- ( ) /------- H 159 H ---- R -- R -- E --( ATM Sw -- ATM Sw ) -- E -- R -- R -- H 160 H ----/ | ( ) ( 161 | ------------------ ------- H 162 H ----------R 164 Figure 1: Network Architecture with hosts (H), 165 Routers (R) and Edge Devices (E). 167 The edge devices may be considered part of the IP internet or part of 168 the ATM cloud, or both. This is not an issue since they must provide 169 capabilities of both environments. The edge devices have normal RSVP 170 capability to process RSVP messages, reserve resources, and maintain 171 soft state (in the control path), and to classify and schedule 172 packets (in the data path). They also have the normal ATM 173 capabilities to initiate connections by signaling, and to accept or 174 refuse connections signaled to them. They police and schedule cells 175 going into the ATM cloud. An IP-level reservation (RESV message) 176 triggers the edge device to translate the RSVP service requirements 177 into ATM VC (UNI) semantics. 179 A range of VC management policies are possible, which determine 180 whether a flow should initiate a new VC or join an existing one. VCs 181 are managed according to a combination of standards and local policy 182 rules, which are specific to either the implementation (equipment) or 183 the operator (network service provider). Point-to-multipoint 184 connections within the ATM cloud can be used to support general IP 185 multicast flows. In ATM, a point to multipoint connection can be 186 controlled by the source (or root) node, or a leaf initiated join 187 (LIJ) feature in ATM may be used. Note, the topic of VC management 188 and mapping of flows onto VCs is considered at length in another 189 issll working group draft [12]. 191 will be written, either in as part of this draft or another one from 192 the issll working group at some point. 194 Figure 2 shows the functions of an edge device, summarizing the work 195 not part of IP or ATM abstractly as an InterWorking Function (IWF), 196 and segregating the control and data planes. (Note: for expositional 197 convenience, policy control and other control functions are included 198 as part of the admission control in the diagram.) 200 IP ATM 201 ____________________ 202 | IWF | 203 | | 204 admission <--> | service mapping | <--> ATM 205 control | VC management | signalling & 206 | address resolution | admission 207 |....................| control 208 | | 209 classification/ |ATM Adaptation Layer| cell 210 policing & <--> | Segmentation and | <--> scheduling/ 211 scheduling | Reassembly | shaping 212 | Buffering | 213 ____________________ 215 Figure 2: Edge Device Functions showing the IWF 217 In the logical view of Figure 2, some functions, such as scheduling, 218 are shown separately, since these functions are required of both the 219 IP and ATM sides. However it may be possible in an integrated 220 implementation to combine such functions. 222 It is not possible to completely separate the service mapping and VC 223 management functions. Several illustrative examples come to mind: 224 (i) Multiple integrated-services flows may be aggregated to use one 225 point-to-multipoint VC. In this case, we assume the IP flows are of 226 the same service type and their parameters have been merged 227 appropriately. (ii) The VC management function may choose to 228 allocate extra resources in anticipation of further reservations or 229 based on an empiric of changing TSpecs. (iii) There must exist a 230 path for best effort flows and for sending the rsvp control messages. 231 How this interacts with the establishment of VCs for QoS traffic may 232 alter the characteristics required of those VCs. See [12] for 233 further details on VC management. 235 Therefore, in discussing the service-mapping problem, we will assume 236 that the VC management function of the IWF can always express its 237 result in terms of an IP-level service with some QoS and TSpec. The 238 service mapping algorithm, which is the subject of this draft, can 239 then identify the appropriate VC parameters, whether the resulting 240 action is initiation of a new VC, the addition/deletion of a leaf to 241 an existing multipoint tree, or the modification of an existing VC to 242 one of another description. 244 1.2 Related Documents 246 Earlier ATM Forum documents were called UNI 3.0 and UNI 3.1. The 3.1 247 release was used to correct errors and fix alignment with the ITU. 248 Unfortunately UNI 3.0 and 3.1 are incompatible. However this is in 249 terms of actual codepoints, not semantics. Therefore, descriptions 250 of parameter values can generally be used for both. 252 After 3.1, the ATM Forum decided to release documents separately for 253 each technical working group. The Traffic Management and Signalling 254 4.0 documents are available publically at ftp.atmforum.com/pub. We 255 refer to the combination of traffic management and signalling as 256 TM/UNI 4.0, although specific references may be made to the TM 4.0 257 specification or the UNI SIG 4.0 specification. 259 Within the IETF area, related material includes the work of the rsvp 260 [2], int-serv [1, 8, 9, 13, 14] and ion working groups [10, 11] of 261 the IETF. Rsvp defines the resource reservation protocol (which is 262 analogous to signaling in ATM). Int-serv defines the behavior and 263 semantics of particular services (analogous e.g., to the Traffic 264 Management working group in the ATM Forum). Ion defines interworking 265 of IP and ATM for traditional Best Effort service, and covers all 266 issues related to routing and addressing. 268 RFC 1821 [15], represent an early discussions of issues involved with 269 interoperating IP and ATM protocols for integrated services and QoS. 271 2.0 Discussion of ATM Protocol Features 273 In this section, we discuss each of the items that must be specified 274 in the setup of an ATM VC. For each of these we discuss which 275 specified items and values may be most appropriate for each of the 276 three integrated services. 278 The ATM Call Setup is sent by the edge device to the ATM network to 279 establish end-to-end (ATM) service. This setup contains the 280 following information. 282 Service Category/Broadband Bearer Capability 283 AAL Parameters 284 Broadband Low Layer Information 285 Calling and Called Party Addressing Information 286 Traffic Descriptors 287 QoS Parameters 288 Additional Parameters of TM/UNI 4.0 290 We will discuss each of these, except addressing information, as they 291 relate to the translation of GS and CLS to ATM services. Following 292 the discussion of the service categories, we discuss the tagging and 293 conformance definitions for IP and ATM, since the policing method is 294 implicit in the call setup. We then continue with mappings of the 295 other parameters and information elements. 297 2.1 Service Category and Bearer Capability 299 The highest level of abstraction distinguishing features of ATM VCs 300 is in the service category or bearer capability. Service categories 301 were introduced in TM/UNI 4.0; previously the bearer capability was 302 used to discriminate at this level. 304 In each version of the ATM specifications, these indicate the general 305 properties required of a VC: whether there is a real-time delay 306 constraint, whether the traffic is constant or variable rate, the 307 applicable traffic and QoS description parameters and (implicitly) 308 the complexity of some supporting switch mechanisms. 310 For UNI 3.0 and UNI 3.1, there are only two distinct options for 311 bearer capabilities (in our context): 313 BCOB-A: constant rate, timing required, unicast/multipoint; 314 BCOB-C: variable rate, timing not required, unicast/multipoint. 316 There is a third capability, BCOB-X, but in the case of AAL5 (which 317 we require -- see below) it can be used interchangeably and 318 consistently with the above two capabilities. 320 In TM/UNI 4.0 the service categories are: 322 Constant Bit Rate (CBR) 323 Real-time Variable Bit Rate (rtVBR) 324 Non-real-time Variable Bit Rate (nrtVBR) 325 Unspecified Bit Rate (UBR) 326 Available Bit Rate (ABR) 328 The first two of these are real-time services, so that rtVBR is new 329 to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR 330 exists in all specifications, except perhaps in name, through the 331 ``best effort'' indication flag and/or the QoS Class 0. 333 The encoding used in 4.0 is consistent with the earlier versions. 334 For example, the Service Category is indicated solely by the 335 combination of the Bearer Capability and the Best Effort indication 336 flag. 338 In principle, it is possible to support any foreseeable service 339 through the use of BCOB-A/CBR. This is because the CBR service is 340 equivalent to having a ``pipe'' with specified bandwidth/timing. 341 However, it may be desirable to make better use of the ATM network's 342 resources by using other, less demanding, services when available. 343 (See RFC 1821 for a discussion of this [15].) 345 2.1.1 Service Categories for Guaranteed Service 347 There are two possible mappings for GS: 349 CBR (BCOB-A) 350 rtVBR 352 GS requires real-time support, that is, timing is required. Thus in 353 UNI 3.x, the bearer class BCOB-A (or an equivalent BCOB-X 354 formulation) must be used. In TM/UNI 4.0 either CBR or rtVBR is 355 appropriate. In both cases, GS would use a value of CLR 356 appropriately low for the link (i.e., such that congestion losses are 357 dominated by losses due to bit errors). The use of rtVBR may 358 encourage recovery of allocated bandwidth left unused by a source. 359 It also accomm odates more bursty sources with a larger bucket 360 parameter, and permits the use of tagging for excess traffic (see 361 Section 2.2). 363 Neither the BCOB-C bearer class, nor nrtVBR, UBR, ABR are good 364 matches for the GS service. These provide no delay estimates and 365 cannot guarantee consistently low delay for every packet. 367 Specification of BCOB-A or CBR requires specification of a PCR. The 368 PCR should be specified as the the token bucket rate parameter, with 369 appropriate conversion from bytes to cells (accounting for overhead), 370 of the GS TSpec. For both of these, the network provides a nominal 371 clearing rate of PCR with jitter toleration (bucket size) CDVT, 372 specified in a network specific manner (see below). 374 Specification of rtVBR requires the specification of two rates, SCR 375 and PCR. This models bursty traffic with specified peak and average 376 rates. With rtVBR, it is appropriate to map the PCR to the line rate 377 of incoming traffic and the SCR to the GS TSpec bucket rate. The ATM 378 bucket sizes are CDVT, in a network specific manner, and CDVT+BT, 379 respectively for the PCR and SCR parameters (see below). 381 2.1.2 Service Categories for Controlled Load 383 There are three possible mappings for CLS: 385 CBR (BCOB-A) 386 ABR 387 nrtVBR (BCOB-C) 389 Note that under UNI 3.x, only the first and third choices are 390 applicable. The first, with a CBR/BCOB-A connection, provides a 391 higher level of QoS than is necessary, but it may be convenient to 392 simply allocate a fixed-rate ``pipe'', which should be ubiquitously 393 supported in ATM networks. However unless this is the only choice 394 available, this will probably be wasteful of network resources. 396 The ABR category with a positive MCR aligns with the CLS idea of 397 ``best effort with floor.'' The ATM network agrees to forward cells 398 with a rate of at least MCR, which should be directly converted from 399 the token bucket rate of the TSpec. The bucket size parameter 400 measures approximately the amount of buffer required at the IWF. 402 The nrtVBR/BCOB-C category can also be used. The rtVBR category can 403 be used, although the edge device must choose a value for CTD and CDV 404 as a matter of local policy. 406 The UBR category does not provide enough capability for Controlled 407 Load. The point of CLS is to allow an allocation of resources, which 408 is facilitated by the token bucket traffic descriptor, and is 409 unavailable in UBR. 411 2.1.3 Service Categories for Best Effort 413 Any of the service categories has the capability to carry Best Effort 414 service, but the natural service category is UBR (or, in UNI 3.x, 415 BCOB-C or BCOB-X, with the best effort indicator flag). A CBR or 416 rtVBR clearly could be used, and since the service is not real-time, 417 a nrtVBR connection could also be used. In these cases the rate 418 parameter used reflects a bandwidth allocation in support of the edge 419 device's best effort connectivity to the far edge router. It would 420 be normal for many flows to be aggregated on this connection; indeed, 421 since Best Effort is the default IP behavior, the individual flows 422 are not necessarily identified or accounted for. CBR may be a 423 preferred solution in the case where best effort traffic is 424 sufficiently highly aggregated that a simple fixed-rate pipe is 425 efficient. An ABR connection could similarly be used to support Best 426 Effort traffic. This is the purpose for which ABR was specifically 427 designed. It is conceivable that a separate ABR connection would be 428 made for different IP flows, although the normal case would probably 429 have all IP Best Effort traffic with a common exit router sharing a 430 single ABR connection. 432 See specifications from the IETF ion working group [10, 11] for 433 related work on support of Best Effort service with ATM. 435 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions 437 An ATM header carries the Cell Loss Priority (CLP) bit. Cells with 438 bit CLP=1 are said to have been tagged and have lower priority. This 439 tagging may have been done by the source or an upstream switch. 440 Options involving the use of tagging are decided at call setup time. 442 A Conformance Definition is a rule that determines whether a cell is 443 conforming to the traffic descriptor of the VC. The conformance 444 definition is given in terms of a Generic Cell Rate Algorithm (GCRA), 445 also known as a "leaky bucket" algorithm, for CBR and VBR services. 446 (UBR and ABR have network-specific conformance definitions. Note, 447 the term "compliance" in ATM is used to describe the behavior of a 448 connection.) 450 The network may tag cells which are non-conforming, rather than 451 dropping them only if the VC is set up to request tagging and the 452 network supports the tagging option. When congestion occurs, a 453 switch must attempt to discard tagged cells in preference to the 454 discarding of CLP=0 cells. However, the mechanism for doing this is 455 completely implementation specific. Tagged cells are treated with a 456 behavior which is Best Effort in the sense that they are transported 457 when bandwidth is available, queued when buffers are available, and 458 dropped when the resources are overcommitted. 460 Since GS and CLS services require excess traffic to be treated as 461 Best Effort, the tagging option should always be chosen (if 462 supported) in the VC setup as a means of ``downgrading'' non- 463 conformant cells. However, we wish to point out that the term ``best 464 effort'' seems to be used with two distinguishable meanings in the 465 int-serv specs. The first interpretation is that of a service class 466 that, in some typical scheduler implementations, would correspond to 467 a separate queue. Placing excess traffic in best effort in this 468 sense would be giving it lower delay priority. The other sense is 469 more generic, meaning that the network would make a best effort to 470 transport the traffic. A reasonable expectation is that a network 471 with no contending traffic would transport the packet, while a very 472 congested network would drop the packet. A packet that could be 473 tagged with lower loss priority (such as the ATM CLP bit) would be 474 more likely to be dropped, but would not normally be transported out 475 of order with respect to the conforming portion of the flow. Such a 476 mechanism would agree with the latter definition of best effort, but 477 not the former. 479 In TM/UNI 4.0 tagging does not apply to the CBR or ABR services. 480 However, there are three conformance definitions of VBR service (for 481 both rtVBR and nrtVBR) to consider. In VBR, only the conformance 482 definition VBR.3 supports tagging and applies the GCRA with PCR to 483 the aggregate CLP=0+1 cells, and another GCRA with SCR to the CLP=0 484 cells. Thus this conformance definition should always be used in 485 support of IP integrated services. For UBR service, conformance 486 definition UBR.2 supports the use of tagging, but a CLP=1 cell does 487 not imply non-conformance; it may be a hint of network congestion. 489 Once an ATM connection is established, the use of the conformance 490 definition and resulting policing action is mandatory. Since the 491 conformance algorithm operates on cells, when mapping rates and 492 bucket sizes from IP services to corresponding ATM parameters, a 493 correction needs to be made (at call setup time) for the ATM 494 segmentation overhead. Unfortunately this overhead, as a ratio, 495 depends on packet length, with the overhead largest for small 496 packets. Thus the appropriate correction could be based on minimum 497 packet size, expected packet size, or otherwise in a network specific 498 manner, determined at the edge device IWF. 500 2.3 ATM Adaptation Layer 502 The AAL type 5 encoding must be used, as specified in RFC 1483 and 503 RFC 1755. AAL5 requires specification of the maximum SDU size in both 504 the forward and reverse directions. Both GS and CLS specify a maximum 505 packet size as part of the TSpec and this value shall be used as the 506 maximum SDU in each direction for unicast connections, but only in 507 one direction for point-to-multipoint connections, which are 508 unidirectional. When more than one flow aggregated into a single VC, 509 the TSpecs are merged to yield the largest packet size. In no case 510 can this exceed 65535 (or, of course, the MTU of the link). 512 2.4 Broadband Low Layer Information 514 The B-LLI Information Element is transferred transparently by the ATM 515 network between the edge devices and is used to specify the 516 encapsulation method. Multiple B-LLI IEs may be sent as part of 517 negotiation. The default encapsulation LLC/SNAP [16] must be 518 supported as specified in RFC 1577 and RFC 1755. Additional 519 encapsulations are discussed in RFC 1755 and we refer to the 520 discussion there. 522 2.5 Traffic Descriptors 524 The ATM traffic descriptor always contains specification of a peak 525 cell rate (PCR) (in each direction). For variable rate services it 526 also contains specification of a sustainable cell rate (SCR) and 527 maximum burst size (MBS). The SCR and MBS form a leaky bucket pair 528 (rate, depth), while the bucket depth parameter for PCR is CDVT. 529 Note that CDVT is not signaled explicitly, but is determined by the 530 network operator, and serves as a measure of the jitter imposed by 531 the network. 533 Since CDVT is not signaled, and is presumed to be small, the leaky 534 bucket traffic descriptor (TSpec) of the Internet service cannot 535 always be directly mapped into PCR/CDVT parameters. Additional 536 buffering is needed at the IWF to account for the depth of the 537 bucket. 539 The Burst Tolerance is related to MBS (see TM 4.0 for details). 540 Roughly, they are both expressions of the bucket depth parameter that 541 goes with SCR. The units of BT is time while the units of MBS is 542 cells. Since both SCR and MBS are signalled, they can be computed 543 directly from the IP layer traffic description. The specific manner 544 in which resources are allocated from the traffic description is 545 implementation specific. Note that when translating the traffic 546 parameters, the segmentation overhead and minimum policed unit need 547 to be taken into account (see Section 4.2 below). 549 In ATM UNI SIG 4.0 there are the notions of Alternative Traffic 550 Descriptors and Minimal Traffic Descriptors. Alternative Traffic 551 Descriptors enumerate other acceptable choices for traffic 552 descriptors and are not considered here. Minimal Traffic Descriptors 553 are used in ``negotiation,'' which refers to the specific way in 554 which an ATM connection is set up. Very roughly it works like this, 555 taking PCR as an example: A minimal PCR and a requested PCR are 556 signalled, the requested PCR being the usual item signalled, and the 557 minimal PCR being the absolute minimum that the source edge device 558 will accept. When sensing the existence of both minimal and 559 requested parameters, the intermediate switches along the path may 560 reduce the requested PCR to a ``comfortable'' level. This choice is 561 part of admission control, and is therefore implementation dependent. 562 If at any point the requested PCR falls below the minimal PCR then 563 the call is cleared. Minimal Traffic Descriptors can be used to 564 present an acceptable range for parameters and ensure a higher 565 likelihood of call admission. Whether anything more specific about 566 Minimal Traffic Descriptors needs to be said here is left for further 567 study (FFS). In general, our discussion of connection parameters 568 assumes the values resulting from successful connection setup. 570 The Best Effort indicator (used only with UBR) and Tagging indicators 571 are also part of the signaled information element (IE) containing the 572 traffic descriptor. In the UNI SIG 4.0 traffic descriptor IE there 573 is an additional parameter, the Frame Discard indicator (see Section 574 2.7). 576 2.5.1 Translating Traffic Descriptors for Guaranteed Service 578 For Guaranteed Service there is a peak rate, p, a source Tspec rate, 579 r_s, a receiver Tspec rate r_r, and an Rspec rate, R. The two Tspec 580 rates are intended to support receiver heterogeneity, in the sense 581 that different receivers can accept different rates representing 582 subsets of the sender's traffic. In this document we leave this 583 feature for further study (FFS), and assume the two Tspec rates are 584 always identical. The Tspec rate describes the traffic itself, and 585 is used for policing, while the Rspec rate (which cannot be smaller) 586 is the allocated service rate. A receiver increases R over r to 587 reduce the delay. 589 When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic 590 descriptor parameters (PCR, SCR, MBS) can be set within the following 591 bounds: 593 R <= PCR <= min(p, line rate) 594 r <= SCR <= PCR 595 b <= MBS. 597 Note that a receiver can choose R > p to lower the delay. This 598 leaves the first equation somewhat subject to interpretation. If a 599 receiver chooses R > line rate, it seems clear that the admission 600 control would simply reject the reservation. 602 The edge device has a buffer preceding the ATM network which must be 603 sufficient to absorb bursts arriving faster than they can be admitted 604 into the ATM network. For example, parameters may be set as PCR = R, 605 SCR = r, MBS = b. The edge device buffer of size b would absorb a 606 burst sent at any IP-level peak rate. Although this buffer exists, 607 the ATM network must accept bursts at rate PCR, at least R, to ensure 608 that the edge device delay is no greater than b/R. Since this buffer 609 is not in the ATM network, its delay is not included in D_ATM. 611 For GS over CBR, the service rate is mapped to the PCR parameter, 612 using the same constraint for PCR given above. The edge device again 613 requires adequate buffering to accommodate the TSpec bucket depth and 614 ensure delay before entering the ATM network of no more than b/R. If 615 PCR is greater than R, the buffer requirement may be relaxed 616 accordingly. 618 2.5.2 Translating Traffic Descriptors for Controlled Load Service 620 Controlled Load service has a peak rate, p, a Tspec rate, r, and a 621 corresponding bucket depth parameter, b. The ATM traffic parameters 622 for nrtVBR service category are constrained by 624 r <= SCR <= PCR <= min(p, line rate) 625 b <= MBS. 627 For ABR VCs, the Tspec rate would be used to set the minimum cell 628 rate (MCR) parameter. The bucket depth parameter does not map 629 directly to a signalled ATM parameter, so the edge device must have a 630 buffer of at least b bytes. 632 For CBR, the Tspec rate sets a lower bound on PCR, and again, the 633 available buffering in the edge device must be adequate to 634 accommodate possible bursts. 636 2.5.2 Translating Traffic Descriptors for Best Effort Service 638 For Best Effort service, there is no traffic description. The UBR 639 service category allows negotiation of PCR, simply to allow the 640 source to discover the smallest physical bottleneck along the path. 642 2.6 QoS Classes and Parameters 644 In TM/UNI 4.0 the three QoS parameters may be individually signalled. 645 These parameters are the Cell Loss Ratio (CLR), Cell Transfer Delay 646 (CTD), and Cell Delay Variation (CDV). In UNI 3.x the setup message 647 includes only the QoS Class, which is essentially an index to a 648 network specific table of values for these three parameters. A 649 network provider may choose to associate other parameters, such as 650 Severely Errored Cell Block Ratio, but these are less well understood 651 and accepted compared to the basic loss, delay and jitter parameters 652 mentioned here. The ITU has recently included a standard set of 653 parameter values for a (small) number of QoS classes in the latest 654 version of Recommendation I.356, October 1996. The network provider 655 may choose to define further network-specific QoS classes in addition 656 to these. The problem of agreement between network providers as to 657 the definition of QoS classes is completely unaddressed to date. We 658 will adopt a convention expressed in UNI 3.x, that assumes that QoS 659 class 1 is appropriate for low-delay, low-loss CBR connections, and 660 QoS class 3 is appropriate for variable rate connections with loss 661 and delay roughly appropriate for non-real-time data applications. 662 Note that the QoS class definitions in the new I.356 version may not 663 align with this model. 665 Since no IP layer counterparts to these ATM QoS parameters exist in 666 any of the IP services, they must be set by policy of the edge 667 device. The QoS classes can be chosen relatively easily. QoS class 668 1 should be used with Guaranteed Service and QoS class 3 should be 669 used with Controlled Load Service. Best Effort Service always gets 670 QoS class 0, which is unspecified QoS by definition. There are two 671 issues which amount to the same thing: First, the choice of 672 individually signalled parameter values (under TM/UNI 4.0) for GS and 673 CLS is the edge device policy. The second issue is choosing 674 parameter values for the two QoS classes, which is the ATM network 675 policy. If the same network operator controls both, then these 676 problems are identical; if not, an agreement to make the values 677 identical would be extremely desirable. 679 Note that we have mapped QoS class 1 and 3 onto Guaranteed and 680 Controlled Load service respectively. This is regardless of what 681 service category is used. So when running CLS over a CBR pipe, it 682 would not be inappropriate to use QoS class 3. This leaves the delay 683 unspecified (or much looser than with QoS 1). These comments should 684 be taken as preliminary, as these issues are far from clear, and 685 industry consensus should be sought. 687 2.7 Additional Parameters -- Frame Discard Mode 689 In TM/UNI 4.0 ATM allows the user to choose a mode where a dropped 690 cell causes all cells up to the last remaining in the AAL5 PDU to be 691 also dropped. This improves efficiency and the behavior of end-to- 692 end protocols such as TCP, since the remaining cells of a damaged PDU 693 are useless to the receiver. For IP over ATM, Frame Discard should 694 always be used in both directions, if available, for all services. 696 3.0 Discussion of IP-IS Protocol Features 698 3.1 Handling of Excess Traffic 700 (Placeholder for text.) 702 3.2 Use of AdSpec in Guaranteed Service with ATM 704 The AdSpec is a feature of Guaranteed Service which allows a receiver 705 to calculate the worst-case delay associated with a GS flow. Three 706 quantities, C, D, and MPL, are accumulated (by simple addition of 707 components, one for each network element) in the PATH message from 708 source to receiver. The resulting values can be different for each 709 unique receiver. The maximum delay is then found by 711 delay <= b/R + C/R + D + MPL 713 The Maximum Path Latency (MPL) includes propagation delay and any 714 other unavoidable system delays. (We neglect the effect of maximum 715 packet size and peak rate here; see the GS specification [8] for the 716 more detailed equation.) The service rate requested by the receiver, 717 R, can be greater than the sender's Tspec rate, r. The effect of the 718 larger R is to allocate more bandwidth and, through this equation, 719 lower the packet delay. The burst size, b, is the leaky bucket 720 parameter from the Tspec, and is not changed by the receiver in the 721 Rspec. 723 The values of C and D which a router advertise will depend on both 724 the particular packet scheduling algorithm used in the router, and 725 the characteristics of the subnet attached to the router. We assume 726 here that each router (or the source host) takes responsibility for 727 its downstream subnet only. If the subnet is a simple point-to-point 728 link, then the subnet-specific parts of C and D will account for the 729 link transmission rate and MTU. An ATM subnet is more complex. 731 The edge router will always have an internal packet scheduler, which 732 will contribute to C and D. For this discussion we consider only the 733 ATM subnet-specific components. We further assume that the ATM 734 network will be represented as a "pure delay" element, contributing a 735 component to D, but not to C. The reason for this is that C would 736 depend on details of the cell scheduling algorithm inside the ATM 737 switches, which is not known by the edge device, where the AdSpec 738 parameters are accumulated. (In the special case where the edge 739 device does have enough information to modify C, it would not be 740 precluded.) Generally the delay behavior of the whole ATM cloud may 741 be expressed abstractly as a fixed constant D_ATM. 743 Since the AdSpec values are incremented before any reservation is 744 made, the edge device must have some knowledge about the VC which 745 would be set up in case a reservation were made. This does not 746 really add to the complexity of the device, since it must also have 747 this information in order to make an intelligent VC setup request. 748 For example, the edge device may have a cached table with the 749 propagation delay and a reasonable additional delay budget, from 750 which it composes a value of CTD for the VC setup. The device may 751 learn such information through VC setup negotiation, and, indeed, 752 there may be no other way to obtain that information. However, it 753 seems reasonable that these values would be cached for later use when 754 new VCs to the same egress router need to be established. 756 Therefore, we will presume a table with values of MPL (which includes 757 propagation delay) and expected queueing delays for each possible 758 egress edge device. (How such a table is maintained is 759 implementation specific.) The latter quantity is simply D_ATM, the 760 value added to the AdSpec D term to account for the ATM network. 761 When a RESV message arrives, causing a VC to be set up, the requested 762 value for CTD should then be given by 764 CTD = D_ATM + MPL + S_ATM. 766 The last term, S_ATM is the portion of the slack term applied to the 767 ATM portion of the path. Recall that the slack term [8] is positive 768 when the receiver can afford more delay than that computed from the 769 AdSpec. The ATM edge device may take part (or all) of the slack term 770 to relax the delay constraint on the ATM VC. The distribution of 771 delay slack among the nodes and subnets is network specific. 773 An important detail to note is the relationship between the b/R term 774 of the (Internet) delay and the corresponding MBS/SCR in the ATM 775 network, when using a VBR VC. The term b/R accounts for the delay 776 experienced by the last byte of a burst, of size b, which encounters 777 a congested node. In the simple ideal case, where the scheduling 778 algorithm emulates a fixed rate server, at rate R, the delay of the 779 last byte is b/R. Once this occurs, the stream has been smoothed, 780 and such a delay will not occur at later congested nodes, as long as 781 they also serve at rate R. The form of the delay equation expresses 782 this ideal behavior with C and D acting as error terms. Now, since 783 the delay which smooths the burst can occur outside of the ATM cloud, 784 the b/R term cannot include any delay within the ATM cloud. However, 785 a burst of size MBS is permitted to enter the ATM network, and it may 786 be served at a rate no greater than SCR. We might reasonably expect 787 a queueing delay of MBS/SCR to occur at a congested ATM switch. If 788 the ATM network will impose this delay, then it must be included in 789 the value of D_ATM advertised. If the ATM network can increase its 790 bandwidth allocation (e.g., due to CTD being lower than MBS/SCR), to 791 decrease this delay, then this behavior should be reflected in the 792 value of D_ATM. So, the information from which the edge device 793 determines D_ATM must reflect an accurate abstraction of the actual 794 behavior of the ATM network. To the extent that D_ATM is approximate 795 (and it must be an upper bound on the actual delay), it reduces the 796 chance that the VC setup will succeed, and/or increases its cost. 798 4.0 Discussion of Miscellaneous Items 800 4.1 Units Conversion 802 In the integrated services domain, bucket sizes and rates are 803 measured in bytes and bytes/sec, respectively, whereas for ATM, they 804 are measured in cells and cells/sec. 806 Packets are segmented into 53 byte cells of which the first 5 bytes 807 are header information. For 809 B = number of Bytes, 810 C = number of cells, 812 a rough approximation between the token bucket parameters (rate and 813 bucket depth) is 815 C = B/48. 817 This is actually a lower bound on C and does not take into account 818 the extra padding at the end of a partially filled cell, or the 8 819 byte trailer in the last cell of an AAL5 encoding. The actual 820 relationship between the number of cells and bytes of one packet is 822 C = 1 + int(B/48) + x, 823 where x = 1 if B mod 48 > 41 824 0 otherwise. 826 where int() is the rounding down operation. The third term is 0 or 827 1 and is 1 only when the remainder of B/48 is 41 or more. (An 828 additional cell is needed because the 41 bytes plus 8 byte trailer 829 will not fit in a cell.) 831 The above formula is not particularly amenable to engineering 832 considerations. By equating the number of bytes before and after 833 segmentation we have 835 48 C = B + 8 + A, 837 where A is the additional padding used in the last 2 cells and has 838 the range 0 <= A <= 47. From this we obtain a number of useful 839 observations. 841 For example, if one believes that the packet lengths are uniformly 842 distributed mod 48, then on average, 48 C = B + 8 + 47/2, or C = B/48 843 + .65625. 845 We can also make use of the upper bound on A to state that 48 C <= B 846 + 55. This is true for any one packet. Considering the number of 847 bytes in a stream of P packets, we have 849 48 C <= B + 55 P. 851 The number of packets P may not be a readily available quantity. 852 However, in terms of the minimum policed unit m, we know that P * m 853 <= B. Hence P <= B/m and 48 C <= B ( 1 + 55/m). That is, 855 C <= B/48 * (1 + 55/m). 857 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service 859 This section describes how to create ATM VCs appropriately matched 860 for Guaranteed Service. The key points differentiating among ATM 861 choices are that real-time timing is required, that the data flow may 862 have a variable rate, and that demotion of non-conforming traffic to 863 best effort is required to be in agreement with the definition of GS. 864 For this reason, we prefer an rtVBR service in which tagging is 865 supported. Another good match is to use CBR with special handling of 866 any non-conforming traffic. 868 The encodings assume a point-to-multipoint connection. For a unicast 869 connection, the backward parameters would be equal to the forward 870 parameters. 872 5.1 Encoding GS Using Real-Time VBR 874 AAL 875 Type 5 876 Forward CPCS-SDU Size parameter M of TSpec 877 Backward CPCS-SDU Size 0 878 Mode 1 (Message mode) Note 1 879 SSCS Type 0 (Null SSCS) 881 Traffic Descriptor 882 Forward PCR CLP=0+1 Note 6 883 Backward PCR CLP=0+1 0 884 Forward SCR CLP=0 Note 6 885 Backward SCR CLP=0 0 886 Forward MBS (CLP=0) Note 6 887 Backward MBS (CLP=0) 0 888 BE indicator NOT included 889 Forward Frame Discard bit 1 Note 2 890 Backward Frame Discard bit 1 Note 2 891 Tagging Forward bit 1 (Tagging requested) Note 2 892 Tagging Backward bit 0 (No Tagging) Note 2 894 Broadband Bearer Capability 895 Bearer Class 16 (BCOB-X) Note 3 896 ATM Transfer Capability 9 Note 2 897 Traffic Type 010 (Variable Bit Rate) 898 Timing Requirements 01 (Timing Required) 899 Susceptible to Clipping 00 (Not susceptible) 900 User Plane Configuration 01 (For pt-to-mpt) 902 Broadband Low Layer Information 903 Layer 2 protocol 12 (ISO 8802/2) 904 Layer 3 protocol 204 (ISO/IEC TR 9577) 906 QoS Class 907 QoS Class Forward 1 Note 4 908 QoS Class Backward 1 Note 4 910 QoS Parameters 911 Transit Delay 100ms Notes 2,5 912 Forward CLR (CLP=0) 1.0e-9 Notes 2,5,7 913 Backward CLR (CLP=0) 1.0e-9 Notes 2,5,7 914 Forward CDV 30ms Notes 2,5 915 Backward CDV 30ms Notes 2,5 917 Note 1: Only included for UNI 3.0. 918 Note 2: Only included in TM/UNI 4.0. 919 Note 3: Value 1 (BCOB-A) can also be used. 920 Note 4: Optional in TM/UNI 4.0. Cf ITU I.365 (Oct 1996) for new definition. 921 Note 5: Values chosen to initiate discussion. May be network specific. 922 Note 6: See discussion on AdSpec, Section 3.2. 923 Note 7: CLR should include physical link errors with no queueing loss. 925 5.2 Encoding GS Using CBR 927 It is also possible to support GS using a CBR ``pipe.'' The 928 advantage of this is that CBR is probably supported; the disadvantage 929 is that data flows may not fill the pipe (utilization loss) and there 930 is no tagging option available. 932 AAL 933 Type 5 934 Forward CPCS-SDU Size parameter M of TSpec 935 Backward CPCS-SDU Size parameter M of TSpec 936 Mode 1 (Message mode) Note 1 937 SSCS Type 0 (Null SSCS) 939 Traffic Descriptor 940 Forward PCR 0+1 Note 6 941 Backward PCR 0+1 0 942 BE indicator NOT included 943 Forward Frame Discard bit 1 Note 2 944 Backward Frame Discard bit 1 Note 2 945 Tagging Forward bit 0 (No Tagging) Note 2 946 Tagging Backward bit 0 (No Tagging) Note 2 948 Broadband Bearer Capability 949 Bearer Class 16 (BCOB-X) Note 3 950 ATM Transfer Capability 7 Note 2 951 Traffic Type 001 (Constant Bit Rate) 952 Timing Requirements 01 (Timing Required) 953 Susceptible to Clipping 00 (Not susceptible) 954 User Plane Configuration 01 (For pt-to-mpt) 956 Broadband Low Layer Information 957 Layer 2 protocol 12 (ISO 8802/2) 958 Layer 3 protocol 204 (ISO/IEC TR 9577) 960 QoS Class 961 QoS Class Forward 1 Note 4 962 QoS Class Backward 1 Note 4 964 QoS Parameters 965 Transit Delay 100ms Notes 2,5 966 Forward CLR (CLP=0) 1.0e-9 Notes 2,5,7 967 Backward CLR (CLP=0) 1.0e-9 Notes 2,5,7 968 Forward CDV 30ms Notes 2,5 969 Backward CDV 30ms Notes 2,5 971 Note 1: Only included for UNI 3.0. 972 Note 2: Only included in TM/UNI 4.0. 973 Note 3: Value 1 (BCOB-A) can also be used. 974 Note 4: Optional in TM/UNI 4.0. Cf ITU I.365 (Oct 1996) for new definition. 975 Note 5: Values chosen to initiate discussion. May be network specific. 976 Note 6: See discussion on AdSpec, Section 3.2. 977 Note 7: CLR should include physical link errors with no queueing loss. 979 5.3 Encoding GS Using Non-Real-Time VBR 981 The remaining ATM service categories, including nrtVBR, do not 982 provide delay guarantees and cannot be recommended as the best fits. 983 However in some circumstances, the best fits may not be available. 985 If nrtVBR is used, no hard delay can be given. However by using a 986 variable rate service with low utilization, delay may be 987 `reasonable', but not controlled. The encoding of GS as nrtVBR is 988 the same as that for CLS using nrtVBR, except that the Forward PCR 989 would be derived from the Tspec peak rate. See Section 6.2 below. 991 5.4 Encoding GS Using ABR 993 The authors feel that this is a very unlikely combination. The 994 objective of the ABR service is to provide `low' loss rates which, 995 via flow control, can result in delays. The introduction of delays 996 is contrary to the point of GS. 998 5.5 Encoding GS Using UBR 1000 The UBR service is the default lowest common denominator of the 1001 services. It cannot provide delay or loss guarantees. However if it 1002 is used for GS, it will be encoded in the same way as Best Effort 1003 over UBR, with the exception that the PCR would be determined from 1004 the peak rate of the Tspec. See Section 5.1. 1006 5.6 Encoding GS Using UNI 3.0 and UNI 3.1. 1008 (Placeholder for text.) 1010 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 1012 This section describes how to create ATM VCs appropriately matched 1013 for Controlled Load. CLS traffic is partly delay tolerant and of 1014 variable rate. NrtVBR and ABR (for TM/UNI 4.0 only) are the possible 1015 choices in supporting CLS. 1017 Generally we prefer to use point-to-multipoint connections. However 1018 this is not yet available in ABR. Other than in ABR, the encodings 1019 assume a point-to-multipoint connection. For a unicast connection, 1020 the backward parameters would be equal to the forward parameters. 1022 6.1 Encoding CLS Using ABR 1024 AAL 1025 Type 5 1026 Forward CPCS-SDU Size parameter M of TSpec 1027 Backward CPCS-SDU Size parameter M of TSpec 1028 SSCS Type 0 (Null SSCS) 1030 Traffic Descriptor 1031 Forward PCR CLP=0+1 From line rate 1032 Backward PCR CLP=0+1 From line rate 1033 Forward MCR CLP 0+1 From TSpec token bucket rate 1034 Backward MCR CLP 0+1 From TSpec token bucket rate 1035 BE indicator NOT included 1036 Forward Frame Discard bit 1 1037 Backward Frame Discard bit 1 1038 Tagging Forward bit 0 (Tagging not requested) 1039 Tagging Backward bit 0 (Tagging not requested) 1041 Broadband Bearer Capability 1042 Bearer Class 16 (BCOB-X) Note 3 1043 ATM Transfer Capability 12 1044 Traffic Type 010 (Variable Bit Rate) 1045 Timing Requirements 10 (Timing Not Required) 1046 Susceptible to Clipping 00 (Not susceptible) 1047 User Plane Configuration 00 (For pt-to-pt) 1049 Broadband Low Layer Information 1050 Layer 2 protocol 12 (ISO 8802/2) 1051 Layer 3 protocol 204 (ISO/IEC TR 9577) 1053 QoS Class 1054 QoS Class Forward 3 Note 4 1055 QoS Class Backward 3 Note 4 1057 ABR Setup Parameters for further study (FFS) 1058 ABR Additional Parameters for further study (FFS) 1060 Note 3: Value 3 (BCOB-C) can also be used. 1061 Note 4: Optional in TM/UNI 4.0. Cf ITU I.365 (Oct 1996) for new definition. 1063 6.2 Encoding CLS Using Non-Real-Time VBR 1065 AAL 1066 Type 5 1067 Forward CPCS-SDU Size parameter M of TSpec 1068 Backward CPCS-SDU Size 0 1069 Mode 1 (Message mode) Note 1 1070 SSCS Type 0 (Null SSCS) 1072 Traffic Descriptor 1073 Forward PCR CLP=0+1 From line rate 1074 Backward PCR CLP=0+1 0 1075 Forward SCR CLP=0 From TSpec token bucket rate 1076 Backward SCR CLP=0 0 1077 Forward MBS (CLP=0) From TSpec bucket size param 1078 Backward MBS (CLP=0) 0 1079 BE indicator NOT included 1080 Forward Frame Discard bit 1 Note 2 1081 Backward Frame Discard bit 1 Note 2 1082 Tagging Forward bit 1 (Tagging requested) Note 2 1083 Tagging Backward bit 0 (No Tagging) Note 2 1085 Broadband Bearer Capability 1086 Bearer Class 16 (BCOB-X) Note 3 1087 ATM Transfer Capability Absent Note 2 1088 Traffic Type 010 (Variable Bit Rate) 1089 Timing Requirements 10 (Timing Not Required) 1090 Susceptible to Clipping 00 (Not susceptible) 1091 User Plane Configuration 01 (For pt-to-mpt) 1093 Broadband Low Layer Information 1094 Layer 2 protocol 12 (ISO 8802/2) 1095 Layer 3 protocol 204 (ISO/IEC TR 9577) 1097 QoS Class 1098 QoS Class Forward 3 Note 4 1099 QoS Class Backward 3 Note 4 1101 QoS Parameters 1102 Forward CLR (CLP=0) 1.0e-9 Notes 2,5,6 1103 Backward CLR (CLP=0) 1.0e-9 Notes 2,5,6 1105 Note 1: Only included for UNI 3.0. 1106 Note 2: Only included in TM/UNI 4.0. 1107 Note 3: Value 3 (BCOB-C) can also be used. 1108 Note 4: Optional in TM/UNI 4.0. Cf ITU I.365 (Oct 1996) for new definition. 1109 Note 5: Values chosen to initiate discussion. May be network specific. 1110 Note 6: CLR should include physical link errors with no queueing loss. 1112 6.3 Encoding CLS Using Real-Time VBR 1114 The encoding of CLS using rtVBR imposes a hard limit on the delay, 1115 which is specified as an end-to-end delay in the ATM network. This 1116 is more stringent than the CLS service specifies and may result in 1117 less utilization of the network. 1119 If rtVBR is used to encode CLS, then the encoding is essentially the 1120 same as that for GS. The exceptions are that the Forward PCR is 1121 derived from the line rate and probably a different value of the 1122 transit delay and CDV will be specified. See Section 3.1. 1124 6.4 Encoding CLS Using CBR 1126 The encoding of CLS using CBR is more stringent than using rtVBR 1127 since it does not take into account the variable rate of the data. 1128 Consequently there may be even lower utilization of the network. 1130 To use CBR for CLS, the same encoding as in Section 3.2 would be 1131 used. However a different set of values of the QoS parameters will 1132 likely be used. 1134 6.5 Encoding CLS Using UBR 1136 This encoding gives no QoS guarantees and would be done in the same 1137 way as for BE traffic. See Section 5.1. 1139 6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. 1141 (Placeholder for text.) 1143 7.0 Summary of ATM VC Setup Parameters for Best Effort Service 1145 This section describes how to create ATM VCs appropriately matched 1146 for Best Effort. The BE service does not need a reservation of 1147 resources. 1149 7.1 Encoding Best Effort Service Using UBR 1151 AAL 1152 Type 5 1153 Forward CPCS-SDU Size MTU of link 1154 Backward CPCS-SDU Size MTU of link 1155 Mode 1 (Message mode) Note 1 1156 SSCS Type 0 (Null SSCS) 1158 Traffic Descriptor 1159 Forward PCR CLP=0+1 From line rate 1160 Backward PCR CLP=0+1 0 1161 BE indicator included 1162 Forward Frame Discard bit 1 Note 2 1163 Backward Frame Discard bit 1 Note 2 1164 Tagging Forward bit 1 (Tagging requested) Note 2 1165 Tagging Backward bit 0 (no tagging) Note 2 1167 Broadband Bearer Capability 1168 Bearer Class 16 (BCOB-X) 1169 Traffic Type 010 (Variable Bit Rate) 1170 Timing Requirements 10 (Timing not required) 1171 Susceptible to Clipping 00 (Not susceptible) 1172 User Plane Configuration 01 (For pt-to-mpt) 1174 Broadband Low Layer Information 1175 Layer 2 protocol 12 (ISO 8802/2) 1176 Layer 3 protocol 204 (ISO/IEC TR 9577) 1178 QoS Class 1179 QoS Class Forward 0 1180 QoS Class Backward 0 1182 Note 1: Only included for UNI 3.0. 1183 Note 2: Only included in TM/UNI 4.0. 1185 7.2 Encoding Best Effort Service Using Other ATM Service Categories 1187 See the IETF ION working group draft on ATM signalling support for IP 1188 over ATM using UNI 4.0 [11]. 1190 8.0 Acknowledgements 1192 The authors would like to thank the members of the ISSLL working 1193 group for their input. In particular, thanks to Jon Bennett of Fore 1194 Systems, Roch Guerin of IBM and Susan Thomson of Bellcore. 1196 Appendix 1 Abbreviations 1198 AAL ATM Adaptation Layer 1199 ABR Available Bit Rate 1200 ATM Asynchronous Transfer Mode 1201 B-LLI Broadband Low Layer Information 1202 BCOB Broadband Connection-Oriented Bearer Capability 1203 BCOB-{A,C,X} Bearer Class A, C, or X 1204 BE Best Effort 1205 BT Burst Tolerance 1206 CBR Constant Bit Rate 1207 CDV Cell Delay Variation 1208 CDVT Cell Delay Variation Tolerance 1209 CLP Cell Loss Priority (bit) 1210 CLR Cell Loss Ratio 1211 CLS Controlled Load Service 1212 CPCS 1213 CTD Cell Transfer Delay 1214 EOM End of Message 1215 FFS For Further Study 1216 GCRA Generic Cell Rate Algorithm 1217 GS Guaranteed Service 1218 IE Information Element 1219 IETF Internet Engineering Task Force 1220 IP Internet Protocol 1221 IS Integrated Services 1222 ISSLL Integrated Services over Specific Link Layers 1223 ITU International Telecommunication Union 1224 IWF Interworking Function 1225 LIJ Leaf Initiated Join 1226 LLC Logical Link Control 1227 MBS Maximum Burst Size 1228 MCR Minimum Cell Rate 1229 MPL Minimum Path Latency 1230 MTU Maximum Transfer Unit 1231 nrtVBR Non-real-time VBR 1232 PCR Peak Cell Rate 1233 PDU Protocol Data Unit 1234 QoS Quality of Service 1235 RESV Reservation Message (of rsvp protocol) 1236 RFC Request for Comment 1237 RSVP Resource Reservation Protocol 1238 Rspec Reservation Specification 1239 rtVBR Real-time VBR 1240 SCR Sustained Cell Rate 1241 SDU Service Data Unit 1242 SIG ATM Signaling (ATM Forum document) 1243 SNAP Subnetwork Attachment Point 1244 SSCS 1245 Sw Switch 1246 TCP Transport Control Protocol 1247 TM Traffic Management 1248 TSpec Traffic Specification 1249 UBR Unspecified Bit Rate 1250 UNI User-Network Interface 1251 VBR Variable Bit Rate 1252 VC (ATM) Virtual Connection 1254 REFERENCES 1256 [1] R. Braden, D. Clark and S. Shenker, "Integrated Services in the 1257 Internet Architecture: an Overview", RFC 1633, June 1994. 1259 [2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 1260 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 1261 Specification", Internet Draft, May 1996, 1264 [3] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1265 sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. 1267 [4] The ATM Forum, "ATM User-Network Interface Specification, Ver- 1268 sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. 1270 [5] The ATM Forum, "ATM User-Network Interface (UNI) Signalling 1271 Specification, Version 4.0", Prentice Hall, Upper Saddle River 1272 NJ, specification finalized July 1996; expected publication, 1273 late 1996; available at ftp://ftp.atmforum.com/pub. 1275 [6] The ATM Forum, "ATM Traffic Management Specification, Version 1276 4.0", Prentice Hall, Upper Saddle River NJ; specification final- 1277 ized April 1996; expected publication, late 1996; available at 1278 ftp://ftp.atmforum.com/pub. 1280 [7] M. W. Garrett, "A Service Architecture for ATM: From Applica- 1281 tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6- 1282 14, May 1996. 1284 [8] S. Shenker, C. Partridge and R. Guerin, "Specification of 1285 Guaranteed Quality of Service", Internet Draft, August 1996, 1286 1288 [9] J. Wroclawski, "Specification of the Controlled-Load Network 1289 Element Service", Internet Draft, August 1996, draft-ietf- 1290 intserv-ctrl-load-svc-03.txt 1292 [10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. 1293 Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru- 1294 ary 1995. 1296 [11] M. Perez and A. Mankin, "ATM Signalling Support for IP over ATM 1297 - UNI 4.0 Update", Internet Draft, November 1996, 1300 [12] S. Berson, L. Berger, "IP Integrated Services with RSVP over 1301 ATM", Internet Draft, September 1996, 1304 [13] S. Shenker and J. Wroclawski, "Network Element Service Specifi- 1305 cation Template", Internet Draft, November 1995, 1308 [14] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 1309 Internet Draft, August 1996, 1311 [15] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of 1312 Real-time Services in an IP-ATM Network Architecture", "IP 1313 Authentication Header", RFC 1821, August 1995. 1315 [16] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 1316 Layer 5", RFC 1483, July 1993. 1318 AUTHORS' ADDRESSES 1320 Mark W. Garrett Marty Borden 1321 Bellcore New Oak, Inc. 1322 445 South Street 1323 Morristown, NJ 07960 1324 USA USA 1326 phone: +1 201 829-4439 phone: +1 508 1327 email: mwg@bellcore.com email: mborden@newoak.com