idnits 2.17.1 draft-ietf-ion-sig-uni4.0-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-ion-sig-uni4.0-04', contains other characters than digits, lowercase letters and dash. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** 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.) ** There are 277 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([ISO8473], [RFC1626], [PER95], [ROM94], [SIG40], [LUC97], [LAUB93], [HEIN93], [UNI95], [LAUB94], [RSVP], [BRAD94], [BRAD89], [ABRS], [ILMI40], [ABRT], [TMGT40], [ISO9577]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '... o MUST, SHALL, or MANDATORY -- th...' RFC 2119 keyword, line 86: '... o SHOULD or RECOMMEND -- this ite...' RFC 2119 keyword, line 89: '... o MAY or OPTIONAL -- the item is ...' RFC 2119 keyword, line 128: '..._ party of a VCC MUST NOT use an inact...' RFC 2119 keyword, line 129: '...fault. A system MAY use an inactivity...' (17 more instances...) -- The abstract seems to indicate that this document updates RFC1755, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 368 has weird spacing: '...uration pt-...' == Unrecognized Status in 'Category: internet-draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1997) is 9842 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'SIG40' on line 737 looks like a reference -- Missing reference section? 'LAUB94' on line 30 looks like a reference -- Missing reference section? 'LUC97' on line 479 looks like a reference -- Missing reference section? 'UNI95' on line 482 looks like a reference -- Missing reference section? 'RSVP' on line 505 looks like a reference -- Missing reference section? 'PER95' on line 473 looks like a reference -- Missing reference section? 'RFC1626' on line 732 looks like a reference -- Missing reference section? 'TMGT40' on line 493 looks like a reference -- Missing reference section? 'ILMI40' on line 501 looks like a reference -- Missing reference section? 'ABRS' on line 489 looks like a reference -- Missing reference section? 'ROM94' on line 530 looks like a reference -- Missing reference section? 'LAUB93' on line 476 looks like a reference -- Missing reference section? 'ABRT' on line 497 looks like a reference -- Missing reference section? 'BRAD89' on line 510 looks like a reference -- Missing reference section? 'BRAD94' on line 514 looks like a reference -- Missing reference section? 'HEIN93' on line 518 looks like a reference -- Missing reference section? 'ISO8473' on line 521 looks like a reference -- Missing reference section? 'ISO9577' on line 525 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ION WG M. Maher 3 Category: internet-draft May 1997 4 draft-ietf-ion-sig-uni4.0-04.txt Expires: November 1, 1997 6 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This memo describes how to efficiently use the ATM call control 29 signalling procedures defined in UNI Signalling 4.0 [SIG40] to 30 support IP over ATM environments as described in RFC 1577 [LAUB94] 31 and in [LUC97]. Among the new features found in UNI Signalling 4.0 32 are Available Bit Rate signalling and traffic parameter negotiation. 33 This draft highlights the features of UNI Signalling 4.0 that provide 34 IP entities capabilities for requesting ATM service in sites with SVC 35 support, whether it is private ATM or publicly provisioned ATM, in 36 which case the SVC support is probably configured inside PVPs. 38 This document is only relevant to IP when used as the well known 39 "best effort" connectionless service. In particular, this means that 40 this document does not pertain to IP in the presence of implemented 41 IP Integrated Services. The topic of IP with Integrated Services 42 over ATM will be handled by a different specification or set of 43 specifications being worked on in the ISSLL WG. 45 This specification is follow-on to RFC 1755, "ATM Signaling Support 46 for IP over ATM", which is based on UNI 3.1 signalling [UNI95]. 47 Readers are assumed to be familiar with RFC 1755. 49 Table of Contents 51 1. Conventions ............................................... 2 52 2. Overview .................................................. 3 53 3. Use of Protocol Procedures ................................ 3 54 3.1 VC Teardown........................................... 3 55 4. Overview of Call Establishment Message Content ............ 3 56 5. Description of Information Elements ....................... 4 57 5.1 ATM Adaptation Layer Parameters ...................... 4 58 5.2 Broadband Low Layer Information ..................... 5 59 5.3 Traffic Management Issues and Related IEs............. 5 60 5.3.1 ATM Traffic Descriptor ........................ 7 61 5.3.1.1 Tagging vs. Dropping ................. 7 62 5.3.2 Traffic Parameter Negotiation .................. 8 63 5.3.3 Broadband Bearer Capability .................... 8 64 5.3.4 QoS Parameter .................................. 9 65 5.3.4.1 Signalling of Individual QoS Parameters 9 66 5.6 ATM Addressing Information ........................... 9 67 6. ABR Signalling In More Detail ............................ 9 68 7. Frame Discard Capability .................................. 10 69 8. Security Consideration .................................... 10 70 9. Open Issues ............................................... 10 71 10. Acknowledgements........................................... 11 72 11. References ................................................ 11 73 12. Authors ................................................... 12 74 Appendix A Sample Signalling Messages ........................ 13 75 Appendix B ABR and nrt-VBR Signalling Guidelines for IP Routers 15 76 Appendix C Combinations of Traffic Related Parameters ........ 18 78 1. Conventions 80 The following language conventions are used in the items of specifi- 81 cation in this document: 83 o MUST, SHALL, or MANDATORY -- the item is an absolute requirement 84 of the specification. 86 o SHOULD or RECOMMEND -- this item SHOULD generally be followed for 87 all but exceptional circumstances. 89 o MAY or OPTIONAL -- the item is truly optional and MAY be followed 90 or ignored according to the needs of the implementor. 92 2. Overview 94 UNI Signalling version 4.0 (SIG 4.0) is the ATM Forum follow-on 95 specification to UNI 3.1 signalling (UNI 3.1). Among the new features 96 in SIG 4.0, those of particular interest to IP over ATM environments 97 are: 99 o Available Bit Rate (ABR) Signalling for Point-to-Point Calls 100 o Traffic Parameter Negotiation 101 o Frame Discard Support 102 o Leaf Initiated Join (LIJ) Capability 103 o ATM Anycast Capability 104 o Switched Virtual Path (VP) Service 106 This draft highlights the first three capabilities listed above. The 107 last three capabilities are not discussed because models for their 108 use in IP over ATM environments have not yet been defined or IP 109 imposes no special requirements on them. 111 3. Use of Protocol Procedures 113 Section 3 in RFC 1755 introduces requirements of virtual circuit (VC) 114 management intended to prevent VC thrashing, excessive VC consump- 115 tion, and other related problems. This section updates RFC 1755's 116 requirements related to VC teardown. 118 3.1. VC Teardown 120 In environments running layer 3 (L3) signalling protocols, such as 121 RSVP [RSVP], over ATM, data VCs might correspond to L3 reserved flows 122 (even if the VC is a 'best effort' VC). In such environments it is 123 beneficial for VCs to be torn down only when the L3 reservation has 124 expired. In other words, it is more efficient for the sender of a L3 125 reserved flow to initiate VC tear-down when the receiver(s) has 126 ceased refreshing the reservation. To support such L3 behavior, sys- 127 tems implementing a Public ATM UNI interface and serving as the 128 _called_ party of a VCC MUST NOT use an inactivity timer on such a 129 VCC by default. A system MAY use an inactivity timer on such a VCC 130 if configured to do so. 132 4. Overview of Call Establishment Message Content 134 Signalling messages are structured to contain mandatory and optional 135 variable length information elements (IEs). A SETUP message which 136 establishes an ATM connection to be used for IP and multiprotocol 137 interconnection calls MUST contain the following IEs: 139 AAL Parameters 140 ATM Traffic Descriptor 141 Broadband Bearer Capability 142 Broadband Low Layer Information 143 QoS Parameter 144 Called Party Number 145 Calling Party Number 147 and MAY, under certain circumstance contain the following IEs : 149 Calling Party Subaddress 150 Called Party Subaddress 151 Transit Network Selection 153 (New in SIG 4.0:) 154 Minimum Acceptable ATM Traffic Descriptor 155 Alternative ATM Traffic Descriptor 156 ABR Setup Parameters 157 ABR Additional Parameters 158 Connection Scope Selection 159 Extended QoS Parameters 160 End-to-End Transit Delay 162 In SIG 4.0, like UNI 3.1, the AAL Parameters and the Broadband Low 163 Layer Information IEs are optional in a SETUP message. However, in 164 support of IP over ATM these two IEs MUST be included. Appendix A 165 shows a sample setup message. 167 5. Description of Information Elements 169 This section describes the coding of, and procedures surrounding, 170 information elements in SETUP and CONNECT messages. The first two IEs 171 described, ATM Adaptation Layer Parameters and Broadband Low Layer 172 Information, are categorized as having significance only to the end- 173 points of an ATM call supporting IP. That is, the network does not 174 process these IEs. 176 5.1. ATM Adaptation Layer (AAL) Parameters 178 The AAL Parameters IE carries information about the ATM adaptation 179 layer to be used on the connection. The parameters specified in this 180 IE are the same as specified in [PER95]. 182 Format and field values of AAL Parameters IE 184 ---------------------------------------------------------- 185 | aal_parameters | 186 ---------------------------------------------------------- 187 | aal_type 5 (AAL 5) | 188 | fwd_max_sdu_size_identifier 140 | 189 | fwd_max_sdu_size 65,535 (desired IP MTU) | 190 | bkw_max_sdu_size_identifier 129 | 191 | bkw_max_sdu_size 65,535 (desired IP MTU) | 192 | sscs_type identifier 132 | 193 | sscs_type 0 (null SSCS) | 194 ---------------------------------------------------------- 196 This shows maximum size MTUs. In practice, most sites have used 9180 197 IP MTUs for ATM [RFC1626]. 199 5.2. Broadband Low Layer Information 201 Selection of an encapsulation to support IP over an ATM VCC is done 202 using the Broadband Low Layer Information (B-LLI) IE, along with the 203 AAL Parameters IE, and the B-LLI negotiation procedure. B-LLI nego- 204 tiation is described in [PER95] in Appendix D. The procedures remain 205 the same for this SIG 4.0 based specification. 207 Format of B-LLI IE indicating LLC/SNAP encapsulation 209 ---------------------------------------------------------- 210 | bb_low_layer_information | 211 ---------------------------------------------------------- 212 | layer_2_id 2 | 213 | user_information_layer 12 (lan_llc - ISO 8802/2) | 214 ---------------------------------------------------------- 216 5.3. Traffic Management Issues and Related IEs 218 The ATM Forum Traffic Management Sub-working group has completed ver- 219 sion 4.0 of their specification [TMGT40]. This latest version focuses 220 primarily on the definition of the ABR service category. As opposed 221 to the Unspecified Bit Rate (UBR) traffic class, ABR uses a rate- 222 based flow control mechanism to assure certain traffic guarantees 223 (bandwidth and delay). There has been much debate on whether IP 224 benefits from ABR, and if so, how IP should use ABR. The IP 225 Integrated Services (IIS) and RSVP models in IP add complexity to 226 this issue because mapping IIS traffic classes to ATM traffic classes 227 is not straightforward. 229 This document attempts only to present the required IP to ATM signal- 230 ling interface for IP over ATM systems that do not support IIS as 231 yet. It is an attempt to cause IP over ATM vendors to support enough 232 options for signalling the traffic characteristics of VCs serving 233 non-IIS IP datagrams. This specification also aims to give guidance 234 to ATM system administrators so that they can configure their IP over 235 ATM entities to conform to the varied services that their ATM pro- 236 vider may have sold to them. By definition, IP without IIS cannot be 237 expected to provide a signalling interface that is flexible and 238 allows application specific traffic descriptors. The topic of IP over 239 ATM signalling for IP _with_ IIS is to be presented in other specifi- 240 cations being produced by the ISSLL WG of the IETF. 242 An IP over ATM interface may be configured to support all the defined 243 ATM Service Categories (ASC). They are: 245 - CBR 246 - CBR with CLR specified (loss-permitting CBR) 247 - ABR 248 - UBR 249 - real time VBR 250 - non-real time VBR 252 The ATM Traffic Descriptor IE, Broadband Bearer Capability IE, and 253 the QoS Parameter IE together define the signalling view of ATM 254 traffic management. Additionally, the Extended QoS parameters IE and 255 the End-to-end Transit Delay IE may be used to provide more specifics 256 about traffic requirements, however this note does not provide expli- 257 cit recommendations on their use. Annex 9 of [SIG40] describes a set 258 of allowable combinations of traffic and QoS related paramenters 259 defined for SIG 4.0. This set includes all forms of non-IIS IP sig- 260 nalling configurations that MUST be implemented in ATM endsystems to 261 accommodate varied sites' needs. The principle is that IP over ATM 262 service may be available in different sites by different types of 263 procured ATM service; for one site, a CBR PVP might be cost-effective 264 and then the SVCs that IP over ATM without IIS must establish must be 265 CBR. Similarly, VBR or ABR PVPs could be provisioned. The intent of 266 this document is to specify the use of the most sensible parameters 267 within this non-IIS configuration. For instance, for non-IIS VBR, 268 the SCR value may need to be hand-configured for IP users, or for 269 ABR, the PCR value may be link-rate with a 0 MCR. 271 For the reader's convenience, we have replicated the tables found in 272 Annex 9 of [SIG40] in Appendix C of this document. Ideally this docu- 273 ment could recommend specific values for the various table parameters 274 that would offer the most sensible IP over ATM service. Nevertheless, 275 it is not possible to mandate specific values given the varied 276 scenarios of procured ATM service. 278 5.3.1. ATM Traffic Descriptor 280 Even with the newly defined ABR ASC, the most convenient model for 281 supporting IP still corresponds to the best effort capability, the 282 UBR ASC. The rationale for this assertion stems from the fact that a 283 non-IIS IP service has no notion of the performance requirements of 284 the higher layers it supports. Therefore, if a a site's configuration 285 allows use of UBR, users SHOULD signal for it using the IE's and 286 parameters pertaining to the UBR ATC. See Appendix C for the list of 287 those IE's and parameters. 289 Although we consider the UBR ASC the most natural ASC for best-effort 290 IP, ATM vendors that implement VBR and ABR services could possibly 291 create hooks for convenient use of these services. If this is the 292 case, IP routers may perhaps have the most to gain from use of VBR or 293 ABR services because of the large aggregated traffic volume they are 294 required to forward. See Appendix B for detailed suggestions on VBR 295 and ABR signalling for IP routers. We simply note here that, in sup- 296 port of ABR service, two new subfields have been added in SIG 4.0 to 297 the Traffic Descriptor IE. These fields are the forward and backward 298 'Minimum Cell Rate' fields. 300 5.3.1.1. Tagging vs. Dropping 302 The Traffic Descriptor IE contains a 'tagging' subfield used for 303 indicating whether the network is allowed to tag the source's data 304 cells. Tagging in the network may occur during periods of congestion 305 or when the source's traffic has violated the traffic contract for 306 the connection. See Section 4 of [TMGT40] for an explanation of ATM 307 connection conformance and the Usage Parameter Control (UPC) func- 308 tion. 310 SIG 4.0 and TMGT 4.0 define two modes of UBR, UBR.1 which disables 311 tagging and UBR.2 which enables tagging (see Appendix C). In some 312 network environments there is no potential for UBR traffic sources to 313 violate the connection traffic contract because, either the user's 314 terminal equipment supports traffic shaping, or the network does not 315 enforce PCR. In such environments, the user SHOULD specify 'no tag- 316 ging' in the SETUP message (UBR.1). Specifying 'no tagging' indi- 317 cates to the network that cells should be dropped during periods of 318 congestion instead of being randomly marked/tagged as low priority. 319 Cells of packets that the source itself has marked as low priority 320 are dropped first, thereby preserving the source's characterization 321 of the traffic. 323 On the other hand, when the network applies PCR to the UPC function, 324 meaning it enforces PCR, and traffic shaping is not enabled at the 325 source, the source has the potential to violate the traffic contract 326 and SHOULD therefore signal for tagging (UBR.2). Tagging allows the 327 source's non-conforming cells to be tagged and forwarded instead of 328 dropped. 330 5.3.2. Traffic Parameter Negotiation 332 SIG 4.0 allows certain traffic parameters to be negotiated during the 333 call establishment phase Traffic parameters cannot be 'renegotiated' 334 after the call is active. Two new IEs make negotiation possible: 336 - the Minimum Acceptable ATM Traffic Descriptor IE allows 337 negotiation of PCR parameters 339 - the Alternative ATM Traffic Descriptor IE allows negotiation of 340 other traffic parameters 342 A SETUP or CONNECT message may include ONLY one of the above IEs. 343 That is, the calling party may only offer an 'alternative' or 344 'minimum' to the requested traffic parameters. (See Section 8 of 345 [SIG40].) IP over ATM entities SHOULD take advantage of this capabil- 346 ity whenever possible. In order to do so, IP over ATM entities SHOULD 347 specify PCR _equal_ to the link rate in the ATM Traffic Descriptor IE 348 of the SETUP message and a minimum of zero PCR in the Minimum Accept- 349 able ATM Traffic Descriptor IE. 351 5.3.3. Broadband Bearer Capability 353 A new field in UNI signalling 4.0 called, 'ATM Transfer Capability' 354 (ATC), has been defined in the Broadband Bearer Capability IE for the 355 purpose of explicitly specifying the desired ATM traffic category. 356 The figure below shows the allowable ATC values. 358 Format and field values of Broadband Bearer Capability IE 360 ------------------------------------------------------------- 361 | bb_bearer_capability | 362 ------------------------------------------------------------| 363 | spare 0 | 364 | bearer_class bcob-x,c,a or VP | 365 | transfer_capability cbr, rt-vbr, nrt-vbr, abr | 366 | susceptibility_to_clipping 0 (not suscept) | 367 | spare 0 | 368 | user_plane_configuration pt-to-pt, pt-to-mpt | 369 ------------------------------------------------------------- 371 5.3.4. QoS Parameter 373 Inclusion of the QoS Parameter IE is not mandatory in SIG 4.0. It 374 may be omitted from a SETUP message _if and only if_ the Extended QoS 375 Parameters IE is included (see next section). This specification 376 makes no explicit recommendation on the use of the QoS related IEs. 378 5.3.4.1. Two IEs for Signalling of Individual QoS Parameters 380 SIG 4.0 allows for signalling of individual QoS parameters for the 381 purpose of giving the the network and called party a more exact 382 description of the desired delay and cell loss characteristics. The 383 two individual QoS related IEs, Extended QoS Parameters IE and End- 384 to-End Transit Delay IE, can be used in the SETUP and CONNECT signal- 385 ling messages in place of the 'generic' QoS Parameter IE. Note that 386 inclusion of these two IEs depends on the type of ATM service 387 category requested (see Annex 9 in [SIG40]). 389 5.4. ATM Addressing Information 391 ATM addressing information is carried in the Called Party Number, 392 Calling Party Number, and, under certain circumstance, Called Party 393 Subaddress, and Calling Party Subaddress IE. The ATM Forum ILMI 394 Specification 4.0 [ILMI40] provides the procedure for an ATM endsys- 395 tem to learn its own ATM address from the ATM network, for use in 396 populating the Calling Party Number IE. 398 Format and field values of Called Party Number IE 400 ---------------------------------------------------------- 401 | called_party_number | 402 ---------------------------------------------------------- 403 | type_of_number (international number / unknown) | 404 | addr_plan_ident (ISDN / ATM Endsystem Address) | 405 | addr_number (E.164 / ATM Endsystem Address) | 406 ---------------------------------------------------------- 408 6. ABR Signalling In More Detail 410 The IEs and procedures pertaining to ABR signalling are briefly 411 described in this section. Nevertheless, this document makes no 412 specific recommendation on when to use the ABR service category for 413 IP VCCs or give suggestions on appropriate values for the various 414 parameters in the ABR related IEs. 416 Two new IEs have been defined for ABR signalling: 418 o ABR Setup Parameters 419 o ABR Additional Parameters 421 These IEs may be optionally included in a SETUP or CONNECT message. 422 The ABR Setup Parameters IE contains the following subfields: 424 - Forward/Backward ABR Initial Cell Rate 425 - Forward/Backward ABR Transient Buffer Exposure 426 - Cumulative RM Fixed Round Trip Time 427 - Forward/Backward Rate Increment Factor 428 - Forward/Backward Rate Decrease Factor 430 The ABR Additional Parameters IE contains one subfield: 432 - Forward/Backward Additional Parameters Record 434 The Additional Parameters Record value is a compressed encoding of a 435 set of ABR parameters (see [SIG40] and [ABRS]). 437 7. Frame Discard Capability 439 The frame discard capability in SIG 4.0 is primarily based on the 440 'Partial and Early Packet Discard' strategy [ROM94]. Its use is 441 defined for any of the ATM services, except for loss-less CBR. Frame 442 discard signalling MUST be supported by all IP over ATM entities and 443 it is RECOMMENDED that frame discard be signalled for all IP SVCs 444 because it has been proven to increase throughput under network 445 congestion. Signalling for frame discard is done by setting the frame 446 discard bit in the 'Traffic Management Options' subfield in the 447 Traffic Descriptor IE. It is possible that not all network entities 448 in the SVC path support frame discard, but it is required that they 449 all forward the signalling. 451 8. Security Considerations 453 The ATM Forum Security sub-working group is currently defining secu- 454 rity mechanisms in ATM. The group has yet to produce a specification, 455 therefore it is premature to begin defining IP over ATM signalling's 456 use of ATM security. IP Security (RFC1825) can be applied to IP 457 datagrams over any medium. 459 9. Open Issues 461 Description of Leaf Initiated Join (LIJ) signalling is not discussed 462 because the use of LIJ in IP over ATM environments have not yet been 463 defined. 465 10. Acknowledgements 467 The authors would like to thank the members of the ION working group 468 for their input. Special thanks to K.K. Ramakrishnan and Kerry Fen- 469 dick who contributed Appendix B of this document. 471 REFERENCES 473 [PER95] Perez*, M. et al, "ATM Signaling Support for IP over ATM", 474 RFC1755, February 1995 (* see author's information below) 476 [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, 477 Hewlett-Packard Laboratories, December 1993 479 [LUC97] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, 480 Piscitello, Cole, draft-ietf-rolc-nhrp-11.txt. work in progress. 482 [UNI95] ATM Forum, "ATM User-Network Interface Specification Version 483 3.1", Prentice Hall, Upper Saddle River, NJ, 1995 485 [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling 486 Specification Version 4.0", af-sig-0061.000, finalized July 1996; 487 available at ftp://ftp.atmforum.com/pub. 489 [ABRS] ATM Forum, "Addendum to UNI Signalling v4.0 for ABR Parameter 490 Negotiation", af-sig-0076.000; available at 491 ftp://ftp.atmforum.com/pub. 493 [TMGT40] ATM Forum, "Traffic Management Specification Version 4.0", 494 af-tm-0056.000, finalized April 1996; available at 495 ftp://ftp.atmforum.com/pub. 497 [ABRT] ATM Forum, "Addendum to Traffic Management v4.0 for ABR Param- 498 eter Negotiation", af-tm-0077.000; available at 499 ftp://ftp.atmforum.com/pub. 501 [ILMI40] ATM Forum, "Integrated Local Management Interface (ILMI) 502 Specification Version 4.0", af-ilmi-0065.000, finalized September 503 1996; available at ftp://ftp.atmforum.com/pub. 505 [RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 506 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 507 Specification", Internet Draft, May 1997, 510 [BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Com- 511 munication Layers", RFC 1122, USC/Information Science Institute, 512 October 1989. 514 [BRAD94] Braden, R., Clark, D, Shenker, S., "Integrated Service in 515 the Internet Architecture: An Overview", RFC 1633, 516 USC/Information Science Institute, June 1994. 518 [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta- 519 tion Layer 5", RFC 1483, Telecom Finland, July 1993. 521 [ISO8473] ISO/IEC 8473, Information processing systems - Data commun- 522 ications - Protocol for providing the connectionless-mode network 523 service, 1988. 525 [ISO9577] Information Technology - Telecommunication and information 526 exchange between systems - Protocol identification in the network 527 layer ISO/IEC TR9577 (International Standards Organization: 528 Geneva, 1990) 530 [ROM94] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM 531 Networks. IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. Abstract. 532 An earlier version appeared in SIGCOMM '94, August 1994, pp. 79- 533 88. 535 Author's Address 536 Maryann P. Maher (formerly Maryann Perez) 537 {maher@isi.edu} 538 USC/ISI 539 4350 N. Fairfax Drive, Suite 620 540 Arlington VA 22203 541 Appendix A. A Sample SIG 4.0 SETUP Message 543 +--------------------------------------------------------------------+ 544 SETUP 546 Information Elements/ 547 Fields Value/(Meaning) 548 -------------------- --------------- 550 aal_parameters 551 aal_type 5 (AAL 5) 552 fwd_max_sdu_size_ident 140 553 fwd_max_sdu_size (xmit IP MTU value) 554 bkw_max_sdu_size_ident 129 555 bkw_max_sdu_size (recv IP MTU, 0 for disallowing return traffic) 556 sscs_type identifier 132 557 sscs_type 0 (null SSCS) 559 traffic_descriptor 560 fwd_peak_cell_rate_0_1_ident 132 561 fwd_peak_cell_rate_0_1 (link rate) 562 bkw_peak_cell_rate_0_1_ident 133 563 bkw_peak_cell_rate_0_1 (link rate) 564 traff_mngt_options_ident 191 565 fwd_frame_discard 1 (on) 566 bkw_frame_discard 1 (on if return traffic indicated) 567 spare 0 568 tagging_bkw 1 (on) 569 tagging_fwd 1 (on if return traffic indicated) 570 best_effort_indication 190 (on) 572 minimum_acceptable_traffic_descriptor 573 fwd_peak_cell_rate_0_1_ident 132 574 fwd_peak_cell_rate_0_1 0 575 bkw_peak_cell_rate_0_1_ident 133 576 bkw_peak_cell_rate_0_1 0 578 bb_bearer_capability /* a coding for specifying UBR like service */ 579 spare 0 580 bearer_class 16 (BCOC-X) 581 spare 0 582 atm_transfer_capability 10 (nrt-vbr) 583 susceptibility_to_clipping 0 (not susceptible to clipping) 584 spare 0 585 user_plane_configuration 0 (point_to_point) 587 bb_low_layer_information 588 layer_2_id 2 589 user_information_layer 12 (lan_llc - ISO 8802/2) 591 qos_parameter 592 qos_class_fwd 0 (class 0) 593 qos_class_bkw 0 (class 0) 595 called_party_number 596 type_of_number (international number / unknown) 597 addr_plan_ident (ISDN / ATM Endsystem Address) 598 number (E.164 / ATM Endsystem Address) 600 calling_party_number 601 type_of_number (international number / unknown) 602 addr_plan_ident (ISDN / ATM Endsystem Address) 603 presentation_indic (presentation allowed) 604 spare 0 605 screening_indic (user_provided verified and passed) 606 number (E.164 / ATM Endsystem Address) 608 +--------------------------------------------------------------------+ 610 Figure 1. 611 Sample contents of SETUP message 613 Appendix B. ABR and VBR Signalling Guidelines for IP Routers 615 When ATM is used to interconnect routers that are supporting a best 616 effort service, the ATM connection typically carries an aggregation 617 of IP flows, e.g., all best effort IP traffic between a pair of 618 routers. With the efforts undertaken by ATM to be more "packet 619 friendly" (e.g., frame discard), it is useful to examine ways that a 620 VC can provide service comparable to or better than that of a dedi- 621 cated or leased "link" in terms of performance and packet loss. 623 For ATM connections used to interconnect routers, a non-zero 624 bandwidth reservation may be required to achieve consistently ade- 625 quate performance for the aggregate set of flows. The support of 626 bandwidth commitments for an ATM connection carrying IP traffic helps 627 to assure that a certain fraction of each link's capacity is reserved 628 for the total IP traffic between the routers. Reserving bandwidth 629 for the aggregation of best-effort traffic between a pair of routers 630 is analogous to provisioning a particular link bandwidth between the 631 routers. There are at least 3 service classes defined in the ATM 632 Traffic Management specification that provide varying degrees of 633 capability that are suitable for interconnecting IP routers: UBR, ABR 634 and VBR non-real-time. Although the use of best-effort service (UBR) 635 at the ATM layer is the most straightforward and uncomplicated, it 636 lacks the capability to enforce bandwidth commitments. 638 Note that we are talking of providing a "virtual link" between 639 routers, for the aggregate traffic. The provisioning is for the 640 aggregate. It is therefore distinct from the per-flow bandwidth 641 reservations that might be appropriate for Integrated Services. 643 Even best-effort IP flows, when supported on an aggregate basis, have 644 some broad service goals. The primary one is that of keeping packet 645 loss rate reasonably small. A service class that strives to achieve 646 this, keeping in mind the tradeoff between complexity and adequate 647 service, is desirable. It has been recommended in this draft that UBR 648 be the default service for this. UBR with (some form of) packet dis- 649 card has the desirable goal of being simple in function, and it 650 appears that vendors will be supporting it. However, when available, 651 it may be quite worthwhile to consider ABR and VBR non-real-time ser- 652 vice classes. 654 Because AAL5 frames with missing cells are discarded by the receiver, 655 ATM bandwidth commitments are most useful if supported in the form of 656 a committed rate of cell delivery in complete, non-errored AAL5 657 frames delivered to the receiver. In addition, it is desirable for 658 the ATM connection to deliver additional complete frames, beyond this 659 commitment, on a best-effort basis. 661 These characteristics can be achieved through the ABR service 662 category through the use of a Minimum Cell Rate, if the ABR service 663 is supported by the ATM endpoints and if efficient frame discard is 664 supported at the ABR source. The mechanisms put in place for the ABR 665 service strive to keep loss quite low within the ATM network. 667 The parameters that should be specified by the end system are (i) the 668 Peak Cell Rate (likely the link rate), (ii) the Minimum Cell Rate 669 (the committed rate), and (iii) the Cumulative RM Fixed Round-Trip 670 Time The remaining parameter values, if left unspecified by the cal- 671 ling party, are selected by the network or are chosen from the 672 default values specified in the ATM Forum Traffic Management specifi- 673 cation. 675 Parameters (i) and (ii) are contained in the mandatory Traffic 676 Descriptor IE, whereas parameter (iii) is contained in the mandatory 677 ABR Setup Parameters IE. Other paramenters in the ABR Setup Parame- 678 ters IE may be omitted. (Note that the third IE which pertains to ABR 679 signalling, the ABR Additional Parameters IE, is an optional IE and 680 therefore need not be included.) Parameter (iii) is dependent on the 681 hardware of the end system, so that the default value specified for 682 that hardware should be used. In the absense of such a default, a 683 value of zero MAY be specified by the end system. Entities using ABR 684 connections for IP over ATM SHOULD take advantage of parameter nego- 685 tiation by specifying Peak Cell Rate equal to the link rate in the 686 ATM Traffic Descriptor IE of the SETUP message. The value selected 687 for the Minimum Cell Rate is implementation specific. Note that the 688 MCR also MAY be negotiated if an MCR parameter is included by the end 689 system in the Minimum Acceptable ATM Traffic Descriptor IE. The use 690 of MCR negotiation by the end system is implementation specific. 691 Also, note that Frame Discard MAY be requested for ABR connections as 692 well as for UBR connections. Although the ABR service attempts to 693 minimize cell loss, the use of Frame Discard may improve throughput 694 when cell loss is not eliminated. 696 ATM recognizes in addition to the service class (UBR, ABR, etc.), a 697 notion of a QoS class. The QoS class specifies the type of guarantee 698 requested of the network when the call is setup. This is distinct 699 from the service class requested for the connection, and the specifi- 700 cation of the traffic parameters (which specify what the source's 701 traffic will look like). QoS class 0 is the "simplest", and is 702 called the Unspecified QoS class. In the context of ABR (and VBR 703 non-realtime below), we are only concerned with the QoS class provid- 704 ing an assurance of acceptable loss behavior for the connection. 706 The Unspecified QoS Class (QoS Class 0) MUST be requested for ABR 707 connections. In this context, QoS Class 0 corresponds to a network- 708 specific objective for the cell loss ratio. Networks in general are 709 expected to support a low Cell Loss Ratio for ABR sources that adjust 710 cell flow in response to control information. 712 The VBR-nrt service category provides an alternate means of achieving 713 these characteristics. These characteristics may be obtained with 714 VBR-nrt connections for which (i) the VBR.3 conformance definition is 715 used, (ii) a Sustainable Cell Rate (SCR) and Maximum Burst Size 716 (MBS), and Peak Cell Rate (PCR) are specified, and (iii) both tagging 717 and frame discard are requested. A request for tagging indicates 718 that best-effort delivery is desired for traffic offered in excess of 719 the SCR and MBS. A request for frame discard indicates to the net- 720 work that the user desires allocations of committed and excess 721 bandwidth to translate into corresponding throughputs at the frame 722 level. 724 As with UBR connections, entities using VBR-nrt connections for IP 725 over ATM should take advantage of parameter negotiation by specifying 726 PCR equal to the link rate in the ATM Traffic Descriptor IE of the 727 SETUP message and PCR equal to SCR in the Minimum Acceptable Traffic 728 descriptor. The selection of SCR, MBS, and CLR (cell loss ratio) 729 should be implementation specific. However, for IP over ATM, an MBS 730 value of N*(Maximum MTU) is RECOMMENDED, where N>=1 with a default of 731 2 and where Maximum MTU is equal to 192 cells (consistent with an IP 732 MTU size of 9180 bytes [RFC1626]). 734 Appendix C. Combinations of Traffic Related Parameters 736 This appendix contains a copy of the five tables found in Annex 9 of 737 [SIG40] which show the allowable combinations of traffic and QoS related 738 parameters in a SIG 4.0 SETUP message. 740 +--------------------------------------------------------------------+ 741 |ATM Service Category| CBR | 742 |--------------------|---------------|---------------|---------------| 743 | Conformance |CBR.1 (note 10)| (note 4) | (note 4) | 744 |--------------------|---------------|---------------|---------------| 745 | Bearer Capability | | | | 746 |--------------------|---------------|---------------|---------------| 747 | BB Bearer Class | A | X | VP | A | X | VP^| A | X | VP^| 748 |--------------------|---------------|----|-----|----|----|-----|----| 749 | ATM Transfer | | | 4,5,| | | 4,5,| | 750 | Capability (note 1)| 7 | abs| or 6| 5 | abs| or 6| 5 | 751 |--------------------|---------------|---------------|---------------| 752 | Traffic Descriptor | | | | 753 | for a given dir. | | | | 754 |--------------------|---------------|---------------|---------------| 755 | PCR (CLP=0) | | | S | 756 |--------------------|---------------|---------------|---------------| 757 | PCR (CLP=0+1) | S | S | S | 758 |--------------------|---------------|---------------|---------------| 759 | SCR, MBS (CLP=0) | | | | 760 |--------------------|---------------|---------------|---------------| 761 | SCR, MBS (CLP=0+1) | | | | 762 |--------------------|---------------|---------------|---------------| 763 | Best Effort | | | | 764 |--------------------|---------------|---------------|---------------| 765 | Tagging | N | N | Y/N | 766 |--------------------|---------------|---------------|---------------| 767 | Frame Discard | Y/N | Y/N | Y/N | 768 |--------------------|---------------|---------------|---------------| 769 | QoS Classes | * | * | * | 770 |--------------------|---------------|---------------|---------------| 771 | Transit Delay | O | O | O | 772 |--------------------|---------------|---------------|---------------| 773 | Peak-to-Peak CDV | O | O | O | 774 |--------------------|---------------|---------------|---------------| 775 | CLR (CLP=0)~ | | O | O | 776 |--------------------|---------------|---------------|---------------| 777 | CLR (CLP=0+1)~ | O | | | 778 +--------------------------------------------------------------------+ 779 +--------------------------------------------------------------------+ 780 |ATM Service Category| Real Time VBR | 781 |--------------------|---------------|---------------|---------------| 782 | Conformance |VBR.1 (note 10)| VBR.2 | VBR.3 | 783 |--------------------|---------------|---------------|---------------| 784 | Bearer Capability | | | | 785 |--------------------|---------------|---------------|---------------| 786 | BB Bearer Class | C | X | VP | C | X | VP | C | X | VP | 787 |--------------------|---------------|----|-----|----|----|-----|----| 788 | ATM Transfer | | | 1 | | | 1 | | 789 | Capability | 19 | 9 | or 9| 9 | 9 | or 9| 9 | 790 |--------------------|---------------|---------------|---------------| 791 | Traffic Descriptor | | | | 792 | for a given dir. | | | | 793 |--------------------|---------------|---------------|---------------| 794 | PCR (CLP=0) | | | | 795 |--------------------|---------------|---------------|---------------| 796 | PCR (CLP=0+1) | S | S | S | 797 |--------------------|---------------|---------------|---------------| 798 | SCR, MBS (CLP=0) | | S | S | 799 |--------------------|---------------|---------------|---------------| 800 | SCR, MBS (CLP=0+1) | S | | | 801 |--------------------|---------------|---------------|---------------| 802 | Best Effort | | | | 803 |--------------------|---------------|---------------|---------------| 804 | Tagging | N | N | Y/N | 805 |--------------------|---------------|---------------|---------------| 806 | Frame Discard | Y/N | Y/N | Y/N | 807 |--------------------|---------------|---------------|---------------| 808 | QoS Classes | * | * | * | 809 |--------------------|---------------|---------------|---------------| 810 | Transit Delay(nt.2)| O | O | O | 811 |--------------------|---------------|---------------|---------------| 812 | Peak-to-Peak CDV | O | O | O | 813 |--------------------|---------------|---------------|---------------| 814 | CLR (CLP=0)~ | | O | O | 815 |--------------------|---------------|---------------|---------------| 816 | CLR (CLP=0+1)~ | O | | | 817 +--------------------------------------------------------------------+ 818 +--------------------------------------------------------------------+ 819 |ATM Service Category| Real Time VBR | 820 |--------------------|---------------|---------------|---------------| 821 | Conformance | (note 4,7) | (note 4,8) | (note 4) | 822 |--------------------|---------------|---------------|---------------| 823 | Bearer Capability | | | | 824 |--------------------|---------------|---------------|---------------| 825 | BB Bearer Class | X | X | X | C or VP^| 826 |--------------------|---------------|---------------|-----|---------| 827 | ATM Transfer | | | | | 828 | Capability | 1 or 9 | 1 or 9 | 1or9| 9 | 829 |--------------------|---------------|---------------|---------------| 830 | Traffic Descriptor | | | | 831 | for a given dir. | | | | 832 |--------------------|---------------|---------------|---------------| 833 | PCR (CLP=0) | S | | | 834 |--------------------|---------------|---------------|---------------| 835 | PCR (CLP=0+1) | S | S | S | 836 |--------------------|---------------|---------------|---------------| 837 | SCR, MBS (CLP=0) | | | | 838 |--------------------|---------------|---------------|---------------| 839 | SCR, MBS (CLP=0+1) | | | S | 840 |--------------------|---------------|---------------|---------------| 841 | Best Effort | | | | 842 |--------------------|---------------|---------------|---------------| 843 | Tagging | Y/N | N | N | 844 |--------------------|---------------|---------------|---------------| 845 | Frame Discard | Y/N | Y/N | Y/N | 846 |--------------------|---------------|---------------|---------------| 847 | QoS Classes | * | * | * | 848 |--------------------|---------------|---------------|---------------| 849 | Transit Delay(nt.2)| O | O | O | 850 |--------------------|---------------|---------------|---------------| 851 | Peak-to-Peak CDV | O | O | O | 852 |--------------------|---------------|---------------|---------------| 853 | CLR (CLP=0)~ | O | O | O | 854 |--------------------|---------------|---------------|---------------| 855 | CLR (CLP=0+1)~ | | | | 856 +--------------------------------------------------------------------+ 857 +--------------------------------------------------------------------+ 858 |ATM Service Category| Non-Real Time VBR | 859 |--------------------|---------------|---------------|---------------| 860 | Conformance |VBR.1 (note 10)| VBR.2 | VBR.3 | 861 |--------------------|---------------|---------------|---------------| 862 | Bearer Capability | | | | 863 |--------------------|---------------|---------------|---------------| 864 | BB Bearer Class | C | X | VP |C | X | VP|C | X | VP| 865 |--------------------|---------------|--|--------|---|--|--------|---| 866 | ATM Transfer | | |abs,0,2,|abs| |abs,0,2,|abs| 867 | Capability | 11 |ab| 8,10 |10 |ab| 8,10 |10 | 868 |--------------------|---------------|---------------|---------------| 869 | Traffic Descriptor | | | | 870 | for a given dir. | | | | 871 |--------------------|---------------|---------------|---------------| 872 | PCR (CLP=0) | | | | 873 |--------------------|---------------|---------------|---------------| 874 | PCR (CLP=0+1) | S | S | S | 875 |--------------------|---------------|---------------|---------------| 876 | SCR, MBS (CLP=0) | | S | S | 877 |--------------------|---------------|---------------|---------------| 878 | SCR, MBS (CLP=0+1) | S | | | 879 |--------------------|---------------|---------------|---------------| 880 | Best Effort | | | | 881 |--------------------|---------------|---------------|---------------| 882 | Tagging | N | N | Y | 883 |--------------------|---------------|---------------|---------------| 884 | Frame Discard | Y/N | Y/N | Y/N | 885 |--------------------|---------------|---------------|---------------| 886 | QoS Classes | * | * | * | 887 |--------------------|---------------|---------------|---------------| 888 | Transit Delay(nt.2)| (note 3) | (note 3) | (note 3) | 889 |--------------------|---------------|---------------|---------------| 890 | Peak-to-Peak CDV | | | | 891 |--------------------|---------------|---------------|---------------| 892 | CLR (CLP=0)~ | | O | O | 893 |--------------------|---------------|---------------|---------------| 894 | CLR (CLP=0+1)~ | O | | | 895 +--------------------------------------------------------------------+ 896 +--------------------------------------------------------------------+ 897 |ATM Service Category| Non-Real Time VBR | 898 |--------------------|---------------|---------------|---------------| 899 | Conformance | (note 4,7) | (note 4,8) | (note 4) | 900 |--------------------|---------------|---------------|---------------| 901 | Bearer Capability | | | | 902 |--------------------|---------------|---------------|---------------| 903 | BB Bearer Class | C | X | C | X |C | X |VP^| 904 |--------------------|-------|-------|-------|-------|--|--------|---| 905 | ATM Transfer | |abs,0,2| |abs,0,2| |abs,0,2,|abs| 906 | Capability | abs |8 or 10| |8 or 10|ab| 8 or10 |10 | 907 |--------------------|---------------|---------------|---------------| 908 | Traffic Descriptor | | | | 909 | for a given dir. | | | | 910 |--------------------|---------------|---------------|---------------| 911 | PCR (CLP=0) | S | | | 912 |--------------------|---------------|---------------|---------------| 913 | PCR (CLP=0+1) | S | S | S | 914 |--------------------|---------------|---------------|---------------| 915 | SCR, MBS (CLP=0) | | | | 916 |--------------------|---------------|---------------|---------------| 917 | SCR, MBS (CLP=0+1) | | | S | 918 |--------------------|---------------|---------------|---------------| 919 | Best Effort | | | | 920 |--------------------|---------------|---------------|---------------| 921 | Tagging | Y/N | N | N | 922 |--------------------|---------------|---------------|---------------| 923 | Frame Discard | Y/N | Y/N | Y/N | 924 |--------------------|---------------|---------------|---------------| 925 | QoS Classes | * | * | * | 926 |--------------------|---------------|---------------|---------------| 927 | Transit Delay(nt.2)| (note 3) | (note 3) | (note 3) | 928 |--------------------|---------------|---------------|---------------| 929 | Peak-to-Peak CDV | | | | 930 |--------------------|---------------|---------------|---------------| 931 | CLR (CLP=0)~ | O | O | O | 932 |--------------------|---------------|---------------|---------------| 933 | CLR (CLP=0+1)~ | | | | 934 +--------------------------------------------------------------------+ 935 +--------------------------------------------------------------------+ 936 |ATM Service Category| ABR | UBR | 937 |--------------------|---------------|---------------|---------------| 938 | Conformance | ABR | UBR.1 | UBR.2 | 939 |--------------------|---------------|---------------|---------------| 940 | Bearer Capability | | | | 941 |--------------------|---------------|---------------|---------------| 942 | BB Bearer Class | C | X | VP |C | X | VP|C | X | VP| 943 |--------------------|---------------|--|--------|---|--|--------|---| 944 | ATM Transfer | | |abs,0,2,|abs| |abs,0,2,|abs| 945 | Capability | 12 |ab| 8,10 |10 |ab| 8,10 |10 | 946 |--------------------|---------------|---------------|---------------| 947 | Traffic Descriptor | | | | 948 | for a given dir. | | | | 949 |--------------------|---------------|---------------|---------------| 950 | PCR (CLP=0) | | | | 951 |--------------------|---------------|---------------|---------------| 952 | PCR (CLP=0+1) | S | S | S | 953 |--------------------|---------------|---------------|---------------| 954 | SCR, MBS (CLP=0) | | S | S | 955 |--------------------|---------------|---------------|---------------| 956 | SCR, MBS (CLP=0+1) | S | | | 957 |--------------------|---------------|---------------|---------------| 958 | ABR MCR | (note 6) | | | 959 |--------------------|---------------|---------------|---------------| 960 | Best Effort | | S (note 9) | S (note 9) | 961 |--------------------|---------------|---------------|---------------| 962 | Tagging | N | N | N | 963 |--------------------|---------------|---------------|---------------| 964 | Frame Discard | Y/N | Y/N | Y/N | 965 |--------------------|---------------|---------------|---------------| 966 | QoS Classes | 0 | 0 | 0 | 967 |--------------------|---------------|---------------|---------------| 968 | Transit Delay(nt.2)| | | | 969 |--------------------|---------------|---------------|---------------| 970 | Peak-to-Peak CDV | | | | 971 |--------------------|---------------|---------------|---------------| 972 | CLR (CLP=0)~ | | | | 973 |--------------------|---------------|---------------|---------------| 974 | CLR (CLP=0+1)~ | | | | 975 +--------------------------------------------------------------------+ 977 ab, abs = absent. 979 Y/N = either "Yes" or "No" is allowed. 981 O = Optional. May be specified using: 982 - an additional QoS parameter encoded i the Extended QoS parameters 983 information element or the end-to-end transit information 984 element; or, 985 - objectives implied from the QoS class 986 If an Extended QoS Parameters IE is not present in the message, 987 then any value of this parameter is acceptable. If neither the 988 parameter nor the Extended QoS Parameters IE is present, then the 989 objective for this parameter is determined from the QoS class 990 in the QoS Parameter IE. 992 S = Specified. 994 (blank) = Unspecified. 996 * = allowed QoS class values are a network option. Class 0 is always 997 for alignment with ITU-T. 999 ^ = (note 5). 1001 ~ = (note 11). 1003 Note 1 - Values 0,1,2,4,6, and 8 are not used on transmission but shall 1004 be understood on reception. 1005 Note 2 - Maximum end-2-end transit delay objectives may only be specified 1006 for the forward direction. 1007 Note 3 - Maximum end-2-end transit delay objectives may be specified for 1008 the ATM Service Category of Non-real Time VBR for reasons of 1009 backward compatibility with ITU-T Recommendations. 1010 Note 4 - Included for reasons of backward compatibility with UNI 3.1 and 1011 ITU-T Recommendations. With these conformance definitions, the 1012 CLR commitment is only for the CLP=0 traffic stream. 1013 Note 5 - Included to allow switched virtual paths to use the UNI 3.1 1014 conformance definitions. 1015 Note 6 - Optional in the user-to-network direction. Specified in the 1016 network-to-user direction. 1017 Note 7 - This combination should be treated as if the received PCR (CLP=0) 1018 parameter were a SCR (CLP=0) parameter and a MBS (CLP=0) parameter 1019 with a value of 1. 1020 Note 8 - This combination should be treated as if an additional SCR (CLP=0) 1021 parameter were received with the same value as a PCR (CLP=0+1) 1022 parameter and a MBS (CLP=0) parameter 1023 with a value of 1. 1024 Note 9 - The best effort parameter applies to both the forward and backward 1025 directions. 1026 Note 10 - This combination should only be used when the CLR commitment on 1027 CLP=0+1 is required versus CLR commitment on CLP=0 traffic, since 1028 these combinations are not supported by UNI 3.0/3.1 nor ITU-T 1029 Q.2931. 1030 Note 11 - In this table the CLR commitment is shown as two entries to 1031 indicated explicitly whether the CLR commitment is for the CLP=0 1032 or the CLP=0+1 cells.