idnits 2.17.1 draft-ietf-issll-atm-mapping-00.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-19) 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 665 has weird spacing: '...tes are measu...' == Line 695 has weird spacing: '...mber of usefu...' == Line 1106 has weird spacing: '...rks.com emai...' -- 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) == Missing Reference: 'RSVP' is mentioned on line 52, but not defined == Missing Reference: 'TM40' is mentioned on line 55, but not defined == Missing Reference: 'CLS' is mentioned on line 64, but not defined == Missing Reference: 'ATM' is mentioned on line 277, but not defined == Unused Reference: 'IPATM' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC1821' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'USE-RSVP-IS' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'TEMPLATE' is defined on line 1064, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 -- Possible downref: Non-RFC (?) normative reference: ref. 'IPATM' ** Downref: Normative reference to an Informational RFC: RFC 1821 -- Possible downref: Non-RFC (?) normative reference: ref. 'GS' -- Possible downref: Non-RFC (?) normative reference: ref. 'USE-RSVP-IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMPLATE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMsvc' Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Marty Borden, 2 Bay Networks, 3 Mark W. Garrett, 4 Bellcore. 5 September, 1996. 7 Interoperation of Controlled-Load and Guaranteed-Service with ATM 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Service mappings are an important aspect of effective interoperation 31 between Internet Integrated Services and ATM networks. Both Internet 32 and ATM technologies have well-defined service architectures. In 33 each, a small number of services are identified, with behavioral 34 descriptions and related parameters to quantify network traffic and 35 Quality of Service (QoS). 37 This draft provides mappings between the services of each technology, 38 in order to facilitate effective end-to-end Quality of Service in the 39 case where ATM subnetwork technology occurs in the path between 40 Internet end systems. Specifically, it identifies the types of ATM 41 Virtual Circuits (VCs) which can be utilized for each of the two 42 currently defined IP services. A detailed discussion is given of the 43 accompanying parameters and options, and the interactions between the 44 two models. Some of the text may be considered preliminary 45 discussion and is expected to be refined as this draft evolves into a 46 proper specification. 48 1.0 Introduction 50 We consider the problem of providing IP Integrated Services [RFC1633] 51 with an ATM subnetwork. We assume the use of the rsvp protocol 52 [RSVP] for IP-level resource reservation. In the ATM network, we 53 consider ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [UNI3.0, 54 UNI3.1, UNI4.0]. The latter uses the more complete service model of 55 The ATM Forum's TM 4.0 specification [TM40, ATMsvc]. 57 This is a complex problem with many facets. In this draft, we focus 58 on the service types, parameters and signalling elements needed for 59 service interoperation. The resulting service mappings can be used 60 to provide effective end-to-end Quality of Service (QoS) for IP 61 traffic that traverses ATM networks. 63 The IP services considered are Guaranteed Service [GS] and Controlled 64 Load Service [CLS]. We also treat the default Best Effort Service 65 (BE) in parallel with these. Our recommendations for BE are intended 66 to be consistent with RFC 1755 [RFC1755], which defines how ATM VCs 67 can be used in support of normal BE IP service. The ATM services we 68 consider are: 70 CBR Constant Bit Rate 71 rtVBR Real-time Variable Bit Rate 72 nrtVBR Non-real-time Variable Bit Rate 73 UBR Unspecified Bit Rate 74 ABR Available Bit Rate 76 In the case of UNI 3.0 and 3.1 signaling, where these service are not 77 all clearly distinguishable, we identify equivalent services where 78 possible. 80 The service mappings which follow most naturally from their 81 definitions are as follows: 83 Guaranteed Service -> CBR or rtVBR 84 Controlled Load -> nrtVBR or ABR (with a minimum cell rate) 85 Best Effort -> UBR or ABR 87 However, for completeness we provide detailed mappings for all 88 service combinations and identify how each meets or fails to meet the 89 requirements of the higher level IP services. A number of details, 90 such as treatment of packets in excess of the flow traffic 91 descriptor, make service mapping a complicated subject, which cannot 92 be expressed briefly and accurately at the same time. 94 The remainder of this introduction provides a general discussion of 95 the system configuration and other assumptions. Section 2 considers 96 the relevant ATM protocol elements and their effects as related to 97 Guaranteed, Controlled Load and Best Effort services (the latter 98 being the default "service"). Section 3 discusses a number of 99 important features of the IP services and how they can be handled on 100 an ATM subnetwork. Section 4 gives detailed VC setup parameters for 101 Guaranteed Service, and considers the effect of using each of the ATM 102 service categories. Section 5 provides a similar treatment for 103 Controlled Load Service. Section 6 considers Best Effort service. 105 This document is only a part of the total solution to providing the 106 interworking of IP integrated services with ATM subnetworks. We do 107 not consider the important issues of when ATM VCs should be created 108 or destroyed, how they should be used or coordinated, or of how 109 routing -- QoS sensitive or not -- interacts with the use of VCs, 110 especially in the case of multicast (or point-to-multipoint) flows. 112 1.1 General System Architecture 114 The network architecture we consider is illustrated in Figure 1, 115 below. An IP-attached host may send unicast datagrams to another 116 host, or may use an IP multicast address to send packets to all of 117 the hosts which have "joined" the multicast "tree". In either case, 118 any destination host may use RSVP to establish resource reservation 119 in routers along the internet path for the data flow. 121 An ATM network lies in the path (chosen by the IP routing), and 122 consists of one or many ATM switches. It uses VCs to provide both 123 resources and QoS within the ATM cloud. These connections are set 124 up, added to (in the case of multipoint trees), torn down, and 125 controlled by the edge devices, which act as both IP routers and ATM 126 interfaces, capable of initiating and managing VCs across the ATM 127 user-to-network (UNI) interface. The edge devices are assumed to be 128 fully functional in both the IP int-serv/RSVP protocols and the ATM 129 UNI protocols, as well as translating between them. 131 ATM Cloud 132 ------------------ 133 H ---\ ( ) /------- H 134 H ---- R -- R -- E --( ATM SW -- ATM SW ) -- E -- R -- R -- H 135 H ---/ | ( ) \ 136 | ------------------ ------- H 137 H ----------R 139 Figure 1: Network Architecture with hosts (H), 140 Routers (R) and Edge Devices (E). 142 The edge devices may be considered part of the IP internet or part of 143 the ATM cloud, or both. This is not an issue since they must provide 144 capabilities of both environments. The edge devices have normal RSVP 145 capability to process RSVP messages, reserve resources, and maintain 146 soft state (in the control path), and to classify and schedule 147 packets (in the data path). They also have the normal ATM 148 capabilities to initiate connections by signaling, and to accept or 149 refuse connections signaled to them. They police and schedule cells 150 going into the ATM cloud. An IP-level reservation (RESV message) 151 triggers the edge device to translate the RSVP service requirements 152 into ATM VC (UNI) semantics. 154 A range of VC management policies are possible, which determine 155 whether a flow should initiate a new VC or join an existing one. VCs 156 are managed according to a combination of standards and local policy 157 rules, which are specific to either the implementation (equipment) or 158 the operator (network service provider). Point-to-multipoint 159 connections within the ATM cloud can be used to support general IP 160 multicast flows. In ATM, a point to multipoint connection can be 161 controlled by the source (or root) node, or a leaf initiated join 162 (LIJ) feature in ATM may be used. (Note, a longer section on VC 163 management will be written, either in as part of this draft or 164 another one from the issll working group at some point. 166 Figure 2 shows the functions of an edge device, summarizing the work 167 not part of IP or ATM abstractly as an InterWorking Function (IWF), 168 and segregating the control and data planes. (Note: for expositional 169 convenience, policy control and other control functions are included 170 as part of the admission control in the diagram.) 171 IP ATM 172 ____________________ 173 | IWF | 174 | | 175 admission <--> | service mapping | <--> ATM 176 control | VC management | signalling & 177 | address resolution | admission 178 |....................| control 179 | | 180 classification/ | ATM Adaption Layer | cell 181 policing & <--> | Segmentation and | <--> scheduling/ 182 scheduling | Reassembly | shaping 183 | Buffering | 184 ____________________ 186 Figure 2: Edge Device Functions showing the IWF 188 In the logical view of Figure 2, some functions, such as scheduling, 189 are shown separately, since these functions are required of both the 190 IP and ATM sides. However it may be possible in an integrated 191 implementation to combine such functions. 193 It is not possible to completely separate the service mapping and VC 194 management functions. Several illustrative examples come to mind: 195 (i) Multiple integrated-services flows may be aggregated to use one 196 point-to-multipoint VC. In this case, we assume the IP flows are of 197 the same service type and their parameters have been merged 198 appropriately. (ii) The VC management function may choose to 199 allocate extra resources in anticipation of further reservations or 200 based on an empiric of changing TSpecs. In this case we can assume 201 that the additional resources are still specifiable in the form of a 202 TSpec, which can be mapped using the same algorithm. (iii) There 203 must exist a path for best effort flows and for sending the rsvp 204 control messages. How this interacts with the establishment of VCs 205 for QoS traffic may alter the characteristics required of those VCs. 207 Therefore, in discussing the service-mapping problem, we will assume 208 that the VC management function of the IWF can always express its 209 result in terms of an IP-level service with some QoS and TSpec. The 210 service mapping algorithm, which is the subject of this draft, can 211 then identify the appropriate VC parameters, whether the resulting 212 action is initiation of a new VC, the addition/deletion of a leaf to 213 an existing multipoint tree, or the modification of an existing VC to 214 one of another description. 216 1.2 Related documents 218 Earlier ATM Forum documents were called UNI 3.0 and UNI 3.1. The 3.1 219 release was used to correct errors and fix alignment with the ITU. 220 Unfortunately UNI 3.0 and 3.1 are incompatible. However this is in 221 terms of actual codepoints, not semantics. Therefore, descriptions 222 of parameter values can generally be used for both. 224 After 3.1, the ATM Forum decided to release documents separately for 225 each technical subcommittee. The Traffic Management and Signalling 226 4.0 documents are available publically at ftp.atmforum.com/pub. We 227 refer to the combination of traffic management and signalling as 228 TM/UNI 4.0, although specific references may be made to the TM 4.0 229 specification or the UNI SIG 4.0 specification. 231 Within the IETF area, related material includes: 233 RSVP functional specification, 234 Guaranteed Service specification, 235 Controlled Load service specification, 236 Int-serv data encoding specification, 237 RFC 1577, 238 RFC 1755, 239 RFC 1821, 240 draft-crawley-rsvp-over-atm, 241 draft-birman-ipatm-rsvpatm, 242 draft-onvural-srinivasan-rsvp-atm. 244 1.3 Abbreviations 246 ABR Available Bit Rate 247 BCOB Broadband Connection-Oriented Bearer Capability 248 BCOB-{A,C,X} Bearer Class A, C, or X 249 BE Best Effort 250 BT Burst Tolerance 251 CBR Constant Bit Rate 252 CDV Cell Delay Variation 253 CDVT Cell Delay Variation Tolerance 254 CLS Controlled Load Service 255 CLP Cell Loss Priority (bit) 256 CLR Cell Loss Ratio 257 CTD Cell Transfer Delay 258 GS Guaranteed Service 259 IWF Interworking Function 260 MBS Maximum Burst Size 261 MCR Minimum Cell Rate 262 PCR Peak Cell Rate 263 SCR Sustained Cell Rate 264 UBR Unspecified Bit Rate 265 VBR Variable Bit Rate 266 nrtVBR Non-real-time VBR 267 rtVBR Real-time VBR 269 2.0 Discussion of Relevant ATM Protocol Features 271 In this section, we discuss each of the items that must be specified 272 in the setup of an ATM VC. For each of these we discuss which 273 specified items and values may be most appropriate for each of the 274 integrated services. 276 The ATM Call Setup is sent by the edge device to the ATM network to 277 establish end-to-end [ATM] service. This setup contains the 278 following information. 280 Service Category/Broadband Bearer Capability 281 AAL Parameters 282 Broadband Low Layer Information 283 Calling and Called Party Addressing Information 284 Traffic Descriptors 285 QoS Parameters 286 Additional Parameters of TM/UNI 4.0 288 We will discuss each of these, except addressing information, as they 289 relate to the translation of GS and CLS to ATM services. Following 290 the discussion of the service categories, we discuss the tagging and 291 conformance definitions for IP and ATM, since the policing method is 292 implicit in the call setup. We then continue with mappings of the 293 other parameters and information elements. 295 2.1 Service Category and Bearer Capability 297 The highest level of abstraction distinguishing features of ATM VCs 298 is in the service category or bearer capability. Service categories 299 were introduced in TM/UNI 4.0; previously the bearer capability was 300 used to discriminate at this level. 302 In each version of the ATM specifications, these indicate the general 303 properties required of a VC: whether there is a real-time delay 304 constraint, whether the traffic is constant or variable rate, the 305 applicable traffic and QoS description parameters and (implicitly) 306 the complexity of some supporting switch mechanisms. 308 For UNI 3.0 and UNI 3.1, there are only two distinct options for 309 bearer capabilities (in our context): 311 BCOB-A: constant rate, timing required, unicast/multipoint; 312 BCOB-C: variable rate, timing not required, unicast/multipoint. 314 There is a third capability, BCOB-X, but in the case of AAL5 (which 315 we require -- see below) it can be used interchangeably and 316 consistently with the above two capabilities. 318 In TM/UNI 4.0 the service categories are: 320 Constant Bit Rate (CBR) 321 Real-time Variable Bit Rate (rtVBR) 322 Non-real-time Variable Bit Rate (nrtVBR) 323 Unspecified Bit Rate (UBR) 324 Available Bit Rate (ABR) 326 The first two of these are real-time services, so that rtVBR is new 327 to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR 328 exists in all specifications, except perhaps in name, through the 329 ``best effort'' indication flag and/or the QoS Class 0. 331 The encoding used in 4.0 is consistent with the earlier versions. 332 For example, the Service Category is indicated solely by the 333 combination of the Bearer Capabilty and the Best Effort indication 334 flag. 336 In principle, it is possible to support any forseeable service 337 through the use of BCOB-A/CBR. This is because the CBR service is 338 equivalent to having a ``pipe'' with specified bandwidth/timing. 339 However, it may be desirable to make better use of the ATM network's 340 resources by using other, less demanding, services when available. 341 (See RFC 1821 for a discussion of this.) 343 2.1.1 Service Categories for Guaranteed Service 345 There are two possible mappings for GS: 347 CBR (BCOB-A) 348 rtVBR 350 GS requires real-time support, that is, timing is required. Thus in 351 UNI 3.x, the bearer class BCOB-A (or an equivalent BCOB-X 352 formulation) must be used. In TM/UNI 4.0 either of CBR or rtVBR is 353 appropriate, the latter allowing the network to possibly take 354 advantage of the statistical multiplexing gain of variable rate flows 355 and to use tagging (see section 2.2). 357 Neither the BCOB-C bearer class, nor nrtVBR, UBR, ABR are matches for 358 the GS service. These provide no delay estimates and one cannot 359 expect low, predictable, or consistent delays. 361 Specification of BCOB-A or CBR requires specification of a PCR. The 362 PCR should be specified as the the token bucket rate parameter, with 363 appropriate conversion from bytes to cells (accounting for overhead), 364 of the GS TSpec. For both of these, the network provides a nominal 365 clearing rate of PCR with jitter toleration (bucket size) CDVT, 366 specified in a network specific manner (see below). 368 Specification of rtVBR requires the specification of two rates, SCR 369 and PCR. This models bursty traffic with specified peak and average 370 rates. With rtVBR, it is appropriate to map the PCR to the line rate 371 of incoming traffic and the SCR to the GS TSpec bucket rate. The ATM 372 bucket sizes are CDVT, in a network specific manner, and CDVT+BT, 373 respectively for the PCR and SCR parameters (see below). 375 2.1.2 Service Categories for Controlled Load 377 There are three possible mappings for CLS: 379 CBR (BCOB-A) 380 ABR 381 nrtVBR (BCOB-C) 383 Note that under UNI 3.x, only the first and third choices are 384 applicable. The first, with a CBR/BCOB-A connection, provides a 385 higher level of QoS than is necessary, but it may be convenient to 386 simply allocate a fixed-rate ``pipe'', which should be ubiquitously 387 supported in ATM networks. However unless this is the only choice 388 available, this will probably be wasteful of network resources. 390 The ABR category with a positive MCR aligns with the CLS idea of 391 ``best effort with floor.'' The ATM network agrees to forward cells 392 with a rate of at least MCR, which should be directly converted from 393 the token bucket rate of the TSpec. The bucket size parameter 394 measures approximately the amount of buffer required at the IWF. 396 The nrtVBR/BCOB-C category can also be used. It does introduce some 397 unaligned complexity in the conformance definition (see section 2.2) 398 by the use of two leaky buckets. The CLS rate parameter would 399 correspond to the SCR, while the PCR should be set to the line rate, 400 as for Guaranteed Service. 402 The remaining service categories are inappropriate for CLS. The 403 rtVBR category adds complexity without providing useful features: 404 there is no need for tightly constrained delays, and the double-rate 405 traffic description is not needed. The UBR category does not provide 406 enough capability for Controlled Load. The point of CLS is to allow 407 an allocation of resources, which is facilitated by the token bucket 408 traffic descriptor, and is unavailable in UBR. 410 2.1.3 Service Categories for Best Effort 412 Any of the service categories has the capability to carry Best Effort 413 service, but the natural service category is UBR (or, in UNI 3.x, 414 BCOB-C or BCOB-X, with the best effort indicator flag). A CBR or 415 rtVBR clearly could be used, and since the service is not real-time, 416 a nrtVBR connection could also be used. In these cases the rate 417 parameter used reflects a bandwidth allocation in support of the edge 418 device's best effort connectivity to the far edge router. It would 419 be normal for many flows to be aggregated on this connection; indeed, 420 since Best Effort is the default IP behavior, the individual flows 421 are not necessarily identified or accounted for. CBR may be a 422 preferred solution in the case where best effort traffic is 423 sufficiently highly aggregated that a simple fixed-rate pipe is 424 efficient. An ABR connection could similarly be used to support Best 425 Effort traffic. This is the purpose for which ABR was specifically 426 designed. It is conceivable that a separate ABR connection would be 427 made for different IP flows, although the normal case would probably 428 have all IP Best Effort traffic with a common exit router sharing a 429 single ABR connection. 431 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions 433 An ATM header carries the Cell Loss Priority (CLP) bit. Cells with 434 bit CLP=1 are said to have been tagged and have lower priority. This 435 tagging may have been done by the source or an upstream switch. 436 Options involving the use of tagging are decided at call setup time. 438 A Conformance Definition is a rule that determines whether a cell is 439 conforming to the traffic descriptor of the VC. The conformance 440 definition is given in terms of a Generic Cell Rate Algorithm (GCRA), 441 also known as a "leaky bucket" algorithm, for CBR and VBR services. 442 (UBR and ABR have network-specific conformance definitions. Note, 443 the term "compliance" in ATM is used to describe the behavior of a 444 connection.) 446 The network may tag cells which are non-conforming, rather than 447 dropping them only if the VC is set up to request tagging and the 448 network supports the tagging option. When congestion occurs, a 449 switch must attempt to discard tagged cells in preference to the 450 discarding of CLP=0 cells. However, the mechanism for doing this is 451 completely implementation specific. Tagged cells are treated with a 452 behavior which is Best Effort in the sense that they are transported 453 when bandwidth is available, queued when buffers are available, and 454 dropped when the resources are overcommitted. 456 Since GS and CLS services require excess traffic to be treated as 457 Best Effort, the tagging option should always be chosen (if 458 supported) in the VC setup as a means of ``downgrading'' 459 nonconformant cells. However, we wish to point out that the term 460 ``best effort'' seems to be used with two distinguishable meanings in 461 the int-serv specs. The first interpretation is that of a service 462 class that, in some typical scheduler implementations, would 463 correspond to a separate queue. Placing excess traffic in best 464 effort in this sense would be giving it lower delay priority. The 465 other sense is more generic, meaning that the network would make a 466 best effort to transport the traffic. A reasonable expectation is 467 that a network with no contending traffic would transport the packet, 468 while a very congested network would drop the packet. A packet that 469 could be tagged with lower loss priority (such as the ATM CLP bit) 470 would be more likely to be dropped, but would not normally be 471 transported out of order with respect to the conforming portion of 472 the flow. Such a mechanism would agree with the latter definition of 473 best effort, but not the former. 475 In TM/UNI 4.0 tagging does not apply to the CBR or ABR services. 476 However, there are three conformance definitions of VBR service (for 477 both rtVBR and nrtVBR) to consider. In VBR, only the conformance 478 definition VBR.3 supports tagging and applies the GCRA with PCR to 479 the aggregate CLP=0+1 cells, and another GCRA with SCR to the CLP=0 480 cells. Thus this conformance definition should always be used in 481 support of IP integrated services. For UBR service, conformance 482 definition UBR.2 supports the use of tagging, but a CLP=1 cell does 483 not imply non-conformance; it may be a hint of network congestion. 485 Once an ATM connection is established, the use of the conformance 486 definition and resulting policing action is mandatory. Since the 487 conformance algorithm operates on cells, when mapping rates and 488 bucket sizes from IP services to corresponding ATM parameters, a 489 correction needs to be made (at call setup time) for the ATM 490 segmentation overhead. Unfortunately this overhead, as a ratio, 491 depends on packet length, with the overhead largest for small 492 packets. Thus the appropriate correction could be based on minimum 493 packet size, expected packet size, or otherwise in a network specific 494 manner, determined at the edge device IWF. 496 2.3 ATM Adaptation Layer 498 The AAL type 5 encoding must be used, as specified in RFC 1483 and 499 RFC 1755. AAL5 requires specification of the maximum SDU size in both 500 the forward and reverse directions. Both GS and CLS specify a maximum 501 packet size as part of the TSpec and this value shall be used as the 502 maximum SDU in each direction for unicast connections, but only in 503 one direction for point-to-multipoint connections, which are 504 unidirectional. When more than one flow aggregated into a single VC, 505 the TSpecs are merged to yield the largest packet size. In no case 506 can this exceed 65535 (or, of course, the MTU of the link). 508 2.4 Broadband Low Layer Information 510 The B-LLI Information Element is transferred transparently by the ATM 511 network between the edge devices and is used to specify the 512 encapsulation method. Multiple B-LLI IEs may be sent as part of 513 negotiation. The default encapsulation LLC/SNAP must be supported as 514 specified in RFC 1577 and RFC 1755. Additional encapsulations are 515 discussed in RFC 1755 and we refer to the discussion there. 517 2.5 Traffic Descriptor 519 The ATM traffic descriptor always contains specification of a peak 520 cell rate (PCR) (in each direction). For variable rate services it 521 also contains specification of a sustainable cell rate (SCR) and 522 maximum burst size (MBS). 524 The Best Effort indicators and Tagging indicators are also part of 525 the traffic descriptors in the signalling sense. In UNI SIG 4.0 526 there is an additional parameter, the Frame Discard indicator in the 527 traffic descriptor. The latter is used to indicate the request that 528 if a cell is to be dropped, then all subsequent cells of a frame be 529 dropped up to the End of Message (EOM) cell (AAL 5); see section 2.7. 531 In ATM UNI SIG 4.0 there are also the notions of Alternative Traffic 532 Descriptors and Minimal Traffic Descriptors. Alternative Traffic 533 Descriptors enumerate other acceptable choices for traffic 534 descriptors and do not seem to be relevant here. Minimal Traffic 535 Descriptors are used in ``negotiation,'' a term which when 536 interpreted colloquially will lead to confusion. Very roughly it 537 works like this, e.g., for PCR. A minimal PCR and a requested PCR are 538 signalled, the requested PCR being the usual item signalled, and the 539 minimal PCR being the absolute minimum that the source edge device 540 will accept. When sensing the existence of both minimal and requested 541 parameters, intermediate switches along the path may reduce the 542 requested PCR to a comfortable level. If at any point the requested 543 PCR falls below the minimal PCR then the call is cleared. This is a 544 very rough sketch, but we do see potential to make use of Minimal 545 Traffic Descriptors in future versions of this draft in order to 546 present an acceptable range for parameters and have higher liklihood 547 of call admission. Minimal Traffic Descriptors are not explored 548 further in this version of the draft. 550 The Traffic Management viewpoint, which we examine next, is more 551 concerned with the value of the PCR, SCR and MBS parameters after 552 call setup. 554 PCR and CDVT are used in the CBR and VBR conformance definitions as 555 parameters for a leaky bucket. However CDVT is not signalled and is 556 determined by the network operator as a measure of the ``clumping'' 557 done by the network. This makes it difficult to map any leaky bucket 558 description of a TSpec to the PCR-CDVT leaky bucket. Additional 559 buffering will be needed at the IWF to account for the depth of the 560 bucket. 562 The SCR and MBS are used with the VBR services. They are used in an 563 implementation specific manner to allocate resources. The Burst 564 Tolerance (BT) is derived from MBS (see TM 4.0) to be used in a 565 second SCR-BT leaky bucket. Since both parameters are available to 566 be signalled, this leaky bucket has the potential to be used in the 567 same way as the integrated services bucket. Note that the 568 segmentation overhead and minimum policed unit need to be taken into 569 account when translating the bucket parameters. 571 For Guaranteed Service there is a bucket rate, r and a service rate, 572 R. The bucket rate describes the traffic, and can be used for 573 policing, while the service rate (which cannot be smaller) is the 574 allocated service rate. When mapping Guaranteed Service onto a rtVBR 575 VC, the mapping is straightforward. The bucket rate maps to the SCR 576 and the peak rate maps to PCR. The bucket depth parameter maps to 577 MBS. The minimum policed unit may need to be taken into account when 578 translating the leaky bucket parameters. Note that due to cell 579 segmentation, the ATM traffic parameters will increase due to the 580 additional headers. The minimum packet size can be used to identify 581 the worst case situation. 583 For GS over CBR, the bucket rate can be mapped to the PCR parameter. 584 As noted above, the edge device may need to ensure that adequate 585 buffering exists at the ATM network ingress to accommodate the TSpec 586 bucket depth. If the available buffering is not sufficient, then a 587 VC may have to be set up using the IP peak rate parameter mapping to 588 PCR. It is probably inadvisable to try to set the PCR to a value 589 between the bucket rate and the peak rate, since such a value would 590 depend on assumptions about the statistical properties of the source. 592 Controlled Load service has a single bucket rate and corresponding 593 depth parameter. The minimum policed unit and maximum packet size 594 play the same roles in mapping parameters as for Guaranteed Service. 595 When using nrtVBR, the bucket rate and depth map to SCR and MBS, 596 while the PCR parameter can be set to the line rate as a worst case 597 value. For ABR VCs, the bucket rate would be used to set the minimum 598 cell rate (MCR) parameter. The bucket depth parameter does not map 599 directly to a signalled ATM parameter, but the edge device should 600 check that the buffering at the ATM ingress is sufficient to account 601 for the size of bursts allowed by that parameter. Finally for CBR, 602 the bucket rate sets the PCR, and again, the available buffering in 603 the edge device must be adequate to accommodate possible bursts. 605 For Best Effort service, there is no traffic description. The UBR 606 service category allows negotiation of PCR, simply to identify to the 607 source the smallest physical bottleneck along the path. 609 2.6 QoS Classes and Parameters 611 In TM/UNI 4.0 the three QoS parameters may be individually signalled. 612 These parameters are the Cell Loss Ratio (CLR), Cell Transfer Delay 613 (CTD), and Cell Delay Variation (CDV). In UNI 3.x the setup message 614 includes only the QoS Class, which is essentially an index to a 615 network specific table of values for these three parameters. A 616 network provider may choose to associate other parameters, such as 617 Severely Errored Cell Block Ratio, but these are less well understood 618 and accepted compared to the basic loss, delay and jitter parameters 619 mentioned here. The ITU may include a standard set of parameter 620 values for a number (probably four) of QoS classes. In that case, 621 the network provider could define further network-specific QoS 622 classes in addition. The problem of agreement between network 623 providers as to the definition of QoS classes is completely 624 unaddressed to date. We will adopt a convention expressed in UNI 625 3.x, that assumes that QoS class 1 is appropriate for low-delay, 626 low-loss CBR connections, and QoS class 3 is appropriate for variable 627 rate connections with loss and delay roughly appropriate for non- 628 real-time data applications. 630 Since no IP layer counterparts to these ATM QoS parameters exist in 631 any of the IP services, they must be set by policy of the edge 632 device. The QoS classes can be chosen relatively easily. QoS class 633 1 should be used with Guaranteed Service and QoS class 3 should be 634 used with Controlled Load Service. Best Effort Service always gets 635 QoS class 0, which is unspecified QoS by definition. There are two 636 issues which amount to the same thing: First, the choice of 637 individually signalled parameter values (under TM/UNI 4.0) for GS and 638 CLS is the edge device policy. The second issue is choosing 639 parameter values for the two QoS classes, which is the ATM network 640 policy. If the same network operator controls both, then these 641 problems are identical; if not, an agreement to make the values 642 identical would be extremely desirable. 644 Note that we have mapped QoS class 1 and 3 onto Guaranteed and 645 Controlled Load service respectively. This is regardless of what 646 service category is used. So when running CLS over a CBR pipe, it 647 would not be inappropriate to use QoS class 3. This leaves the delay 648 unspecified (or much looser than with QoS 1). These comments should 649 be taken as preliminary, as these issues are far from clear, and 650 industry consensus should be sought. 652 2.7 Additional Parameters -- Frame Discard Mode 654 In TM/UNI 4.0 ATM allows the user to choose a mode where a dropped 655 cell causes all cells up to the last remaining in the AAL5 PDU to be 656 also dropped. This improves efficiency and the behavior of end-to- 657 end protocols such as TCP, since the remaining cells of a damaged PDU 658 are useless to the receiver. For IP over ATM, Frame Discard should 659 always be used in both directions, if available, for all services. 661 3.0 Discussion of Miscellaneous Items 663 3.1 Units Conversion 665 In the integrated services domain, buckets and rates are measured in 666 bytes and bytes/sec, respectively, whereas for ATM, they are measured 667 in cells and cells/sec. 669 Packets are segmented into 53 byte cells of which the first 5 bytes 670 are header information. For 671 B = number of Bytes, 672 C = number of cells, 673 a rough approximation between the token bucket parameters (rate and 674 bucket depth) is 675 C = B/48. 677 This is actually a lower bound on C and does not take into account 678 the extra padding at the end of a partially filled cell, or the 8 679 byte trailer in the last cell of an AAL5 encoding. The actual 680 relationship between the number of cells and bytes of one packet is 681 C = 1 + int(B/48) + x, 683 where x = 1 if B mod 48 > 41 684 0 otherwise. 685 where int() is the rounding down operation. The third term is 0 or 686 1 and is 1 only when the remainder of B/48 is 41 or more. (An 687 additional cell is needed because the 41 bytes plus 8 byte trailer 688 will not fit in a cell.) 690 The above formula is not particularly amenable to engineering 691 considerations. By equating the number of bytes before and after 692 segmentation we have 693 48 C = B + 8 + A, 694 where A is the additional padding used in the last 2 cells and has 695 the range 0 <= A <= 47. From this we obtain a number of useful 696 observations. 698 For example, if one believes that the packet lengths are uniformly 699 distributed mod 48, then on average, 48 C = B + 8 + 47/2, or C = B/48 700 + .65625. 702 We can also make use of the upper bound on A to state that 48 C <= B 703 + 55. This is true for any one packet. Considering the number of 704 bytes in a stream of P packets, we have 705 48 C <= B + 55 P. 706 The number of packets P may not be a readily available quantity. 707 However, in terms of the minimum policed unit m, we know that P * m 708 <= B. Hence P <= B/m and 48 C <= B ( 1 + 55/m). That is, 709 C <= B/48 * (1 + 55/m). 711 4.0 Guaranteed Service over ATM 713 This section describes how to create ATM VCs appropriately matched 714 for Guaranteed Service. The key points differentiating among ATM 715 choices are that real-time timing is required, that the data flow may 716 have a variable rate, and that demotion of non-conforming traffic to 717 best effort is desired. For this reason, we prefer a rtVBR service 718 in which tagging is supported. Another good match is to use CBR with 719 special handling of any non-conforming traffic. 721 The encodings assume a point-to-multipoint connection. For a unicast 722 connection, the backward parameters would be equal to the forward 723 parameters. 725 4.1 Encoding GS as a real-time variable bit rate service 727 AAL 728 Type 5 729 Forward CPCS-SDU Size parameter M of TSpec 730 Backward CPCS-SDU Size 0 731 Mode 1 (Message mode) Note 1 732 SSCS Type 0 (Null SSCS) 734 Traffic Descriptor 735 Forward PCR CLP=0+1 From TSpec peak rate 736 Backward PCR CLP=0+1 0 737 Forward SCR CLP=0 From TSpec token bucket rate 738 Backward SCR CLP=0 0 739 Forward MBS (CLP=0) From TSpec bucket size param 740 Backward MBS (CLP=0) 0 741 BE indicator NOT included 742 Forward Frame Discard bit 1 Note 2 743 Backward Frame Discard bit 1 Note 2 744 Tagging Forward bit 1 (Tagging requested) Note 2 745 Tagging Backward bit 0 (No Tagging) Note 2 747 Broadband Bearer Capability 748 Bearer Class 16 (BCOB-X) Note 3 749 ATM Transfer Capability 9 Note 2 750 Traffic Type 010 (Variable Bit Rate) 751 Timing Requirements 01 (Timing Required) 752 Susceptible to Clipping 00 (Not susceptible) 753 User Plane Configuration 01 (For pt-to-mpt) 755 Broadband Low Layer Information 756 Layer 2 protocol 12 (ISO 8802/2) 757 Layer 3 protocol 204 (ISO/IEC TR 9577) 759 QoS Class 760 QoS Class Forward 1 Note 4 761 QoS Class Backward 1 Note 4 763 QoS Parameters 764 Transit Delay 100ms Notes 2,5 765 Forward CLR (CLP=0) 1.0e-6 Notes 2,5 766 Backward CLR (CLP=0) 1.0e-6 Notes 2,5 767 Forward CDV 30ms Notes 2,5 768 Backward CDV 30ms Notes 2,5 770 Note 1: Only included for UNI 3.0. 772 Note 2: Only included in TM/UNI 4.0. 773 Note 3: Value 1 (BCOB-A) can also be used. 774 Note 4: Optional in TM/UNI 4.0. 775 Note 5: Values chosen to initiate discussion. 777 4.2 Encoding GS as a constant bit rate service 779 It is also possible to support GS using a CBR ``pipe.'' The 780 advantage of this is that CBR is probably supported; the disadvantage 781 is that data flows may not fill the pipe (utilization loss) and there 782 is no tagging option available. 784 AAL 785 Type 5 786 Forward CPCS-SDU Size parameter M of TSpec 787 Backward CPCS-SDU Size parameter M of TSpec 788 Mode 1 (Message mode) Note 1 789 SSCS Type 0 (Null SSCS) 791 Traffic Descriptor 792 Forward PCR 0+1 From TSpec token bucket rate 793 Backward PCR 0+1 0 794 BE indicator NOT included 795 Forward Frame Discard bit 1 Note 2 796 Backward Frame Discard bit 1 Note 2 797 Tagging Forward bit 0 (No Tagging) Note 2 798 Tagging Backward bit 0 (No Tagging) Note 2 800 Broadband Bearer Capability 801 Bearer Class 16 (BCOB-X) Note 3 802 ATM Transfer Capability 7 Note 2 803 Traffic Type 001 (Constant Bit Rate) 804 Timing Requirements 01 (Timing Required) 805 Susceptible to Clipping 00 (Not susceptible) 806 User Plane Configuration 01 (For pt-to-mpt) 808 Broadband Low Layer Information 809 Layer 2 protocol 12 (ISO 8802/2) 810 Layer 3 protocol 204 (ISO/IEC TR 9577) 812 QoS Class 813 QoS Class Forward 1 Note 4 814 QoS Class Backward 1 Note 4 816 QoS Parameters 817 Transit Delay 100ms Notes 2,5 818 Forward CLR (CLP=0) 1.0e-6 Notes 2,5 819 Backward CLR (CLP=0) 1.0e-6 Notes 2,5 820 Forward CDV 30ms Notes 2,5 821 Backward CDV 30ms Notes 2,5 823 Note 1: Only included for UNI 3.0. 824 Note 2: Only included in TM/UNI 4.0. 825 Note 3: Value 1 (BCOB-A) can also be used. 826 Note 4: Optional in TM/UNI 4.0. 827 Note 5: Values chosen to initiate discussion. 829 4.3 Encoding GS as a non-real-time variable bit rate service 831 The remaining ATM service categories, including nrtVBR, do not 832 provide delay guarantees and cannot be recommended as the best fits. 833 However in some circumstances, the best fits may not be available. 835 If nrtVBR is used, no hard delay can be given. However by using a 836 variable rate service with low utilization, delay may be 837 `reasonable', but not controlled. The encoding of GS as nrtVBR is 838 the same as that for CL using nrtVBR, except that the Forward PCR 839 would be derived from the Tspec peak rate. See section 5.2 below. 841 4.4 Encoding GS as an ABR service 843 The authors feel that this is a very unlikely combination. The 844 objective of the ABR service is to provide `low' loss rates which, 845 via flow control, can result in delays. The introduction of delays 846 is contrary to the point of GS. 848 4.5 Encoding GS as an UBR service 850 The UBR service is the default lowest common denominator of the 851 services. It cannot provide delay or loss guarantees. However if it 852 is used for GS, it will be encoded in the same way as Best Effort 853 over UBR, with the exception that the PCR would be determined from 854 the peak rate of the Tspec. See section 5.1. 856 5.0 Controlled Load Service over ATM 858 This section describes how to create ATM VCs appropriately matched 859 for Controlled Load. CL traffic is partly delay tolerant and of 860 variable rate. We see nrtVBR and ABR (for TM/UNI 4.0 only) as 861 possible choices in supporting CL. 863 Generally we prefer to use point-to-multipoint connections. However 864 this is not yet available in ABR. Other than in ABR, the encodings 865 assume a point-to-multipoint connection. For a unicast connection, 866 the backward parameters would be equal to the forward parameters. 868 5.1 Encoding CL using an ABR service 870 AAL 871 Type 5 872 Forward CPCS-SDU Size parameter M of TSpec 873 Backward CPCS-SDU Size parameter M of TSpec 874 SSCS Type 0 (Null SSCS) 876 Traffic Descriptor 877 Forward PCR CLP=0+1 From line rate 878 Backward PCR CLP=0+1 From line rate 879 Forward MCR CLP 0+1 From TSpec token bucket rate 880 Backward MCR CLP 0+1 From TSpec token bucket rate 881 BE indicator NOT included 882 Forward Frame Discard bit 1 883 Backward Frame Discard bit 1 884 Tagging Forward bit 0 (Tagging not requested) 885 Tagging Backward bit 0 (Tagging not requested) 887 Broadband Bearer Capability 888 Bearer Class 16 (BCOB-X) Note 3 889 ATM Transfer Capability 12 890 Traffic Type 010 (Variable Bit Rate) 891 Timing Requirements 10 (Timing Not Required) 892 Susceptible to Clipping 00 (Not susceptible) 893 User Plane Configuration 00 (For pt-to-pt) 895 Broadband Low Layer Information 896 Layer 2 protocol 12 (ISO 8802/2) 897 Layer 3 protocol 204 (ISO/IEC TR 9577) 899 QoS Class 900 QoS Class Forward 3 Note 4 901 QoS Class Backward 3 Note 4 903 ABR Setup Parameters For Further Study 904 ABR Additional Parameters For Further Study 906 Note 3: Value 3 (BCOB-C) can also be used. 907 Note 4: Optional in TM/UNI 4.0. 909 5.2 Encoding CL using a non-real-time variable bit rate service 911 AAL 912 Type 5 913 Forward CPCS-SDU Size parameter M of TSpec 914 Backward CPCS-SDU Size 0 915 Mode 1 (Message mode) Note 1 916 SSCS Type 0 (Null SSCS) 918 Traffic Descriptor 919 Forward PCR CLP=0+1 From line rate 920 Backward PCR CLP=0+1 0 921 Forward SCR CLP=0 From TSpec token bucket rate 922 Backward SCR CLP=0 0 923 Forward MBS (CLP=0) From TSpec bucket size param 924 Backward MBS (CLP=0) 0 925 BE indicator NOT included 926 Forward Frame Discard bit 1 Note 2 927 Backward Frame Discard bit 1 Note 2 928 Tagging Forward bit 1 (Tagging requested) Note 2 929 Tagging Backward bit 0 (No Tagging) Note 2 931 Broadband Bearer Capability 932 Bearer Class 16 (BCOB-X) Note 3 933 ATM Transfer Capability Absent Note 2 934 Traffic Type 010 (Variable Bit Rate) 935 Timing Requirements 10 (Timing Not Required) 936 Susceptible to Clipping 00 (Not susceptible) 937 User Plane Configuration 01 (For pt-to-mpt) 939 Broadband Low Layer Information 940 Layer 2 protocol 12 (ISO 8802/2) 941 Layer 3 protocol 204 (ISO/IEC TR 9577) 943 QoS Class 944 QoS Class Forward 3 Note 4 945 QoS Class Backward 3 Note 4 947 QoS Parameters 948 Forward CLR (CLP=0) 1.0e-6 Notes 2,5 949 Backward CLR (CLP=0) 1.0e-6 Notes 2,5 951 Note 1: Only included for UNI 3.0. 952 Note 2: Only included in TM/UNI 4.0. 953 Note 3: Value 3 (BCOB-C) can also be used. 954 Note 4: Optional in TM/UNI 4.0. 955 Note 5: Values chosen to initiate discussion. 957 5.3 Encoding CL using a real-time variable bit rate service 959 The encoding of CL using rtVBR imposes a hard limit on the delay, 960 which is specified as an end-to-end delay in the ATM network. This 961 is more stringent than the CL service specifies and may result in 962 less utilization of the network. 964 If rtVBR is used to encode CL, then the encoding is essentially the 965 same as that for GS. The exceptions are that the Forward PCR is 966 derived from the line rate and probably a different value of the 967 transit delay and CDV will be specified. See section 3.1. 969 5.4 Encoding CL using a constant bit rate service 971 The encoding of CL using CBR is more stringent than using rtVBR since 972 it does not take into account the variable rate of the data. 973 Consequently there may be even lower utilization of the network. 975 To use CBR for CL, the same encoding as in section 3.2 would be used. 976 However a different set of values of the QoS parameters will likely 977 be used. 979 5.5 Encoding CL using a UBR service 981 This encoding gives no QoS guarantees and would be done in the same 982 way as for BE traffic. See section 5.1. 984 6.0 Best Effort Service over ATM 986 This section describes how to create ATM VCs appropriately matched 987 for Best Effort. The BE service does not need a reservation of 988 resources. 990 5.1 Best Effort Service using UBR 992 AAL 993 Type 5 994 Forward CPCS-SDU Size MTU of link 995 Backward CPCS-SDU Size MTU of link 996 Mode 1 (Message mode) Note 1 997 SSCS Type 0 (Null SSCS) 999 Traffic Descriptor 1000 Forward PCR CLP=0+1 From line rate 1001 Backward PCR CLP=0+1 0 1002 BE indicator included 1003 Forward Frame Discard bit 1 Note 2 1004 Backward Frame Discard bit 1 Note 2 1005 Tagging Forward bit 1 (Tagging requested) Note 2 1006 Tagging Backward bit 0 (no tagging) Note 2 1008 Broadband Bearer Capability 1009 Bearer Class 16 (BCOB-X) 1010 Traffic Type 010 (Variable Bit Rate) 1011 Timing Requirements 10 (Timing not required) 1012 Susceptible to Clipping 00 (Not susceptible) 1013 User Plane Configuration 01 (For pt-to-mpt) 1015 Broadband Low Layer Information 1016 Layer 2 protocol 12 (ISO 8802/2) 1017 Layer 3 protocol 204 (ISO/IEC TR 9577) 1019 QoS Class 1020 QoS Class Forward 0 1021 QoS Class Backward 0 1023 Note 1: Only included for UNI 3.0. 1024 Note 2: Only included in TM/UNI 4.0. 1026 1. REFERENCES 1028 [RFC1633] 1029 R. Braden, D. Clark and S. Shenker, "Integrated Services in the 1030 Internet Architecture: an Overview", RFC 1633, June 1994. 1032 [RFC1755] 1033 M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. 1034 Malis, "ATM Signlaing Support for IP over ATM", RFC 1755, Febru- 1035 ary 1995. 1037 [IPATM] 1038 M. Perez and A. Mankin, "ATM Signalling Support for IP over ATM 1039 - UNI 4.0 Update", Internet Draft, June 1996, 1042 [RFC1821] 1043 M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of 1044 Real-time Sevices in an IP-ATM Network Architecture", "IP 1045 Authentication Header", RFC 1821, August 1995. 1047 [RSVP]R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 1048 "Resource ReSevVation Protocol (RSVP) - Version 1 Functional 1049 Specification", Internet Draft, May 1996, 1052 [GS] S. Shenker, C. Partridge and R. Guerin, "Specification of 1053 Guaranteed Quality of Service", Internet Draft, August 1996, 1054 1056 [CLS]J. Wroclawski, "Specification of the Controlled-Load Network 1057 Element Service", Internet Draft, August 1996, draft-ietf- 1058 intserv-ctrl-load-svc-03.txt 1060 [USE-RSVP-IS] 1061 J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 1062 Internet Draft, August 1996, 1064 [TEMPLATE] 1065 S. Shenker and J. Wroclawski, "Network Element Service Specifi- 1066 cation Template", Internet Draft, November 1995, 1069 [UNI3.0] 1070 The ATM Forum, "ATM User-Network Interface Specification, Ver- 1071 sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. 1073 [UNI3.1] 1074 The ATM Forum, "ATM User-Network Interface Specification, Ver- 1075 sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. 1077 [UNI4.0] 1078 The ATM Forum, "ATM User-Network Interface (UNI) Signalling 1079 Specification, Version 4.0", Prentice Hall, Upper Saddle River 1080 NJ, specification finalized July 1996; expected publication, 1081 late 1996; available at ftp://ftp.atmforum.com/pub. The ATM 1082 Forum, "ATM Traffic Management Specification, Version 4.0", 1083 Prentice Hall, Upper Saddle River NJ; specification finalized 1084 April 1996; expected publication, late 1996; available at 1085 ftp://ftp.atmforum.com/pub. 1087 [ATMsvc] 1088 M. W. Garrett, "A Service Architecture for ATM: From Applica- 1089 tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6- 1090 14, May 1996. 1092 Acknowledgements 1094 The authors would like to thank the members of the ISSLL working group 1095 for their input. In particular, thanks to Jon Bennett of Fore Systems. 1097 AUTHORS' ADDRESSES 1099 Marty Borden Mark W. Garrett 1100 Bay Networks Bellcore 1101 3 Federal Street 445 South Street 1102 Billerica, MA 01821 Morristown, NJ 07960 1103 USA USA 1105 phone: +1 508 436-3903 phone: +1 201 829-4439 1106 email: mborden@baynetworks.com email: mwg@bellcore.com