draft-ietf-issll-atm-mapping-06.txt   rfc2381.txt 
INTERNET-DRAFT Mark W. Garrett, Network Working Group M. Garrett
ISSLL WG Bellcore Request for Comments: 2381 Bellcore
Expires: 30 September 1998 Category: Standards Track M. Borden
Marty Borden, Bay Networks
Bay Networks August 1998
31 March 1998
Interoperation of Controlled-Load Service and Guaranteed Service with ATM Interoperation of Controlled-Load Service
<draft-ietf-issll-atm-mapping-06.txt> and Guaranteed Service with ATM
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check Copyright (C) The Internet Society (1998). All Rights Reserved.
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract Abstract
This document provides guidelines for mapping service classes, and This document provides guidelines for mapping service classes, and
traffic management features and parameters between Internet and ATM traffic management features and parameters between Internet and ATM
technologies. The service mappings are useful for providing technologies. The service mappings are useful for providing
effective interoperation and end-to-end Quality of Service for IP effective interoperation and end-to-end Quality of Service for IP
Integrated Services networks containing ATM subnetworks. Integrated Services networks containing ATM subnetworks.
The discussion and specifications given here support the IP The discussion and specifications given here support the IP
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Controlled-Load Service (CLS) and the ATM Forum UNI specification, Controlled-Load Service (CLS) and the ATM Forum UNI specification,
versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service
over ATM is also included. over ATM is also included.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. (Note, document are to be interpreted as described in RFC 2119 [1]. (Note,
in many cases the use of "MUST" or "REQUIRED" reflects our in many cases the use of "MUST" or "REQUIRED" reflects our
interpretation of the requirements of a related standard, e.g., ATM interpretation of the requirements of a related standard, e.g., ATM
Forum UNI 4.0, rsvp, etc.) Forum UNI 4.0, rsvp, etc.)
Table of Contents
1.0 Introduction ....................................................... 3 Table of Contents
1.1 General System Architecture .................................... 4
1.2 Related Documents .............................................. 7
2.0 Major Protocol Features for Traffic Management and QoS ............. 8
2.1 Service Category and Bearer Capability ......................... 8
2.1.1 Service Categories for Guaranteed Service ................ 9
2.1.2 Service Categories for Controlled Load ................... 10
2.1.3 Service Categories for Best Effort ....................... 11
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions .... 12
2.3 ATM Adaptation Layer ........................................... 13
2.4 Broadband Low Layer Information ................................ 14
2.5 Traffic Descriptors ............................................ 14
2.5.1 Translating Traffic Descriptors for Guaranteed Service ... 15
2.5.2 Translating Traffic Descriptors for Controlled Load Service 19
2.5.3 Translating Traffic Descriptors for Best Effort Service ....20
2.6 QoS Classes and Parameters ..................................... 20
2.7 Additional Parameters -- Frame Discard Mode .................... 22
3.0 Additional IP-Integrated Services Protocol Features ................ 23
3.1 Path Characterization Parameters for IP Integrated Services .... 23
3.2 Handling of Excess Traffic ..................................... 24
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 26
4.0 Miscellaneous Items ................................................ 27
4.1 Units Conversion ............................................... 27
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28
5.1 Encoding GS Using Real-Time VBR ................................ 29
5.2 Encoding GS Using CBR .......................................... 30
5.3 Encoding GS Using Non-Real-Time VBR ............................ 32
5.4 Encoding GS Using ABR .......................................... 32
5.5 Encoding GS Using UBR .......................................... 32
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 32
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 34
6.1 Encoding CLS Using Non-Real-Time VBR ........................... 34
6.2 Encoding CLS Using ABR ......................................... 35
6.3 Encoding CLS Using CBR ......................................... 37
6.4 Encoding CLS Using Real-Time VBR ............................... 37
6.5 Encoding CLS Using UBR ......................................... 37
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 37
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 39
7.1 Encoding Best Effort Service Using UBR ......................... 39
8.0 Security Considerations ............................................ 40
9.0 Acknowledgements ................................................... 41
Appendix 1 Abbreviations .............................................. 41
References ............................................................. 42
Authors' Addresses ..................................................... 44
1.0 Introduction .................................................... 3
1.1 General System Architecture ................................. 4
1.2 Related Documents ........................................... 7
2.0 Major Protocol Features for Traffic Management and QoS .......... 8
2.1 Service Category and Bearer Capability ...................... 8
2.1.1 Service Categories for Guaranteed Service ............. 9
2.1.2 Service Categories for Controlled Load ................ 10
2.1.3 Service Categories for Best Effort .................... 11
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions . 11
2.3 ATM Adaptation Layer ........................................ 13
2.4 Broadband Low Layer Information ............................. 13
2.5 Traffic Descriptors ......................................... 13
2.5.1 Translating Traffic Descriptors for Guaranteed Service. 15
2.5.2 Translating Traffic Descriptors for Controlled Load
Service .............................................. 18
2.5.3 Translating Traffic Descriptors for Best Effort Service 19
2.6 QoS Classes and Parameters .................................. 19
2.7 Additional Parameters -- Frame Discard Mode ................. 22
3.0 Additional IP-Integrated Services Protocol Features ............. 22
3.1 Path Characterization Parameters for IP Integrated Services . 22
3.2 Handling of Excess Traffic .................................. 24
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term .. 25
4.0 Miscellaneous Items ............................................. 26
4.1 Units Conversion ............................................ 26
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service ....... 27
5.1 Encoding GS Using Real-Time VBR ............................. 28
5.2 Encoding GS Using CBR ....................................... 29
5.3 Encoding GS Using Non-Real-Time VBR ......................... 30
5.4 Encoding GS Using ABR ....................................... 30
5.5 Encoding GS Using UBR ....................................... 30
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ...................... 31
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service .. 32
6.1 Encoding CLS Using Non-Real-Time VBR ........................ 32
6.2 Encoding CLS Using ABR ...................................... 33
6.3 Encoding CLS Using CBR ...................................... 35
6.4 Encoding CLS Using Real-Time VBR ............................ 35
6.5 Encoding CLS Using UBR ...................................... 35
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ..................... 35
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ...... 36
7.1 Encoding Best Effort Service Using UBR ...................... 37
8.0 Security Considerations ......................................... 38
9.0 Acknowledgements ................................................ 38
Appendix 1 Abbreviations ........................................... 39
References .......................................................... 40
Authors' Addresses .................................................. 42
Full Copyright Statement ............................................ 43
1.0 Introduction 1.0 Introduction
We consider the problem of providing IP Integrated Services [2] with We consider the problem of providing IP Integrated Services [2] with
an ATM subnetwork. This document is intended to be consistent with an ATM subnetwork. This document is intended to be consistent with
the rsvp protocol [3] for IP-level resource reservation, although it the rsvp protocol [3] for IP-level resource reservation, although it
applies also in the general case where GS and CLS services are applies also in the general case where GS and CLS services are
supported through other mechanisms. In the ATM network, we consider supported through other mechanisms. In the ATM network, we consider
ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6]. The ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6]. The
latter uses the more complete service model of the ATM Forum's TM 4.0 latter uses the more complete service model of the ATM Forum's TM 4.0
specification [7, 8]. specification [7, 8].
skipping to change at page 3, line 29 skipping to change at page 3, line 28
used to provide effective end-to-end Quality of Service (QoS) for IP used to provide effective end-to-end Quality of Service (QoS) for IP
traffic that traverses ATM networks. traffic that traverses ATM networks.
The IP services considered are Guaranteed Service (GS) [9] and The IP services considered are Guaranteed Service (GS) [9] and
Controlled Load Service (CLS) [10]. We also discuss the default Best Controlled Load Service (CLS) [10]. We also discuss the default Best
Effort Service (BE) in parallel with these. Our recommendations for Effort Service (BE) in parallel with these. Our recommendations for
BE are intended to be consistent with RFC 1755 [11], and [12], which BE are intended to be consistent with RFC 1755 [11], and [12], which
define how ATM VCs can be used in support of normal BE IP service. define how ATM VCs can be used in support of normal BE IP service.
The ATM services we consider are: The ATM services we consider are:
CBR Constant Bit Rate CBR Constant Bit Rate
rtVBR Real-time Variable Bit Rate rtVBR Real-time Variable Bit Rate
nrtVBR Non-real-time Variable Bit Rate nrtVBR Non-real-time Variable Bit Rate
UBR Unspecified Bit Rate UBR Unspecified Bit Rate
ABR Available Bit Rate ABR Available Bit Rate
In the case of UNI 3.x signalling, where these service are not all In the case of UNI 3.x signalling, where these service are not all
clearly distinguishable, we identify the appropriate available clearly distinguishable, we identify the appropriate available
services. services.
We recommend the following service mappings, since they follow most We recommend the following service mappings, since they follow most
naturally from the service definitions: naturally from the service definitions:
Guaranteed Service -> CBR or rtVBR Guaranteed Service -> CBR or rtVBR
Controlled Load -> nrtVBR or ABR (with a minimum cell rate) Controlled Load -> nrtVBR or ABR (with a minimum
Best Effort -> UBR or ABR cell rate)
Best Effort -> UBR or ABR
For completeness, however, we provide detailed mappings for all For completeness, however, we provide detailed mappings for all
service combinations in Sections 5, 6, 7 and identify how each meets service combinations in Sections 5, 6, 7 and identify how each meets
or fails to meet the requirements of the higher level IP services. or fails to meet the requirements of the higher level IP services.
The reason for not restricting mappings to the most obvious or The reason for not restricting mappings to the most obvious or
natural ones is that we cannot predict how widely available all of natural ones is that we cannot predict how widely available all of
these services will be as ATM deployment evolves. A number of these services will be as ATM deployment evolves. A number of
differences in service definitions, such as the treatment of packets differences in service definitions, such as the treatment of packets
in excess of the flow traffic descriptor, make service mapping a in excess of the flow traffic descriptor, make service mapping a
relatively complicated subject. relatively complicated subject.
skipping to change at page 4, line 23 skipping to change at page 4, line 24
an ATM subnetwork. Section 4 addresses the conversion of traffic an ATM subnetwork. Section 4 addresses the conversion of traffic
descriptors to account for ATM-layer overheads. Section 5 gives the descriptors to account for ATM-layer overheads. Section 5 gives the
detailed VC setup parameters for Guaranteed Service, and considers detailed VC setup parameters for Guaranteed Service, and considers
the effect of using each of the ATM service categories. Section 6 the effect of using each of the ATM service categories. Section 6
provides a similar treatment for Controlled Load Service. Section 7 provides a similar treatment for Controlled Load Service. Section 7
considers Best Effort service. considers Best Effort service.
This document is only a part of the total solution to providing the This document is only a part of the total solution to providing the
interworking of IP integrated services with ATM subnetworks. The interworking of IP integrated services with ATM subnetworks. The
important issue of VC management, including flow aggregation, is important issue of VC management, including flow aggregation, is
considered in [13,14,15]. We do not consider how routing, QoS considered in [13, 14, 15]. We do not consider how routing, QoS
sensitive or not, interacts with the use of ATM VCs. We expect that sensitive or not, interacts with the use of ATM VCs. We expect that
a considerable degree of implementation latitude will exist, even a considerable degree of implementation latitude will exist, even
within the guidelines presented here. Many aspects of interworking within the guidelines presented here. Many aspects of interworking
between IP and ATM will depend on economic factors, and will not be between IP and ATM will depend on economic factors, and will not be
subject to standardization. subject to standardization.
1.1 General System Architecture 1.1 General System Architecture
We assume that the reader has a general working knowledge of IP, rsvp We assume that the reader has a general working knowledge of IP, rsvp
and ATM protocols. The network architecture we consider is and ATM protocols. The network architecture we consider is
skipping to change at page 5, line 13 skipping to change at page 5, line 13
UNI protocols, as well as translating between them. UNI protocols, as well as translating between them.
ATM Cloud ATM Cloud
----------------- -----------------
H ----\ ( ) /------- H H ----\ ( ) /------- H
H ---- R -- R -- E-( X -- X -- X )-E -- R -- R -- H H ---- R -- R -- E-( X -- X -- X )-E -- R -- R -- H
H ----/ | ( ) \ H ----/ | ( ) \
| ----------------- \------ H | ----------------- \------ H
H ----------R H ----------R
Figure 1: Network Architecture with Hosts (H), Figure 1: Network Architecture with Hosts (H),
Routers (R), Edge Devices (E) and ATM Routers (R), Edge Devices (E) and ATM
Switches (X). Switches (X).
When considering the edge devices with respect to traffic flowing When considering the edge devices with respect to traffic flowing
from source to destination, the upstream edge device is called the from source to destination, the upstream edge device is called the
"ingress" point and the downstream device the "egress" point. The "ingress" point and the downstream device the "egress" point. The
edge devices may be considered part of the IP internet or part of the edge devices may be considered part of the IP internet or part of the
ATM cloud, or both. They process RSVP messages, reserve resources, ATM cloud, or both. They process RSVP messages, reserve resources,
and maintain soft state (in the control path), and classify and and maintain soft state (in the control path), and classify and
schedule packets (in the data path). They also initiate ATM schedule packets (in the data path). They also initiate ATM
connections by signalling, and accept or refuse connections signalled connections by signalling, and accept or refuse connections signalled
to them. They police and schedule cells going into the ATM cloud. to them. They police and schedule cells going into the ATM cloud.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
A range of VC management policies are possible, which determine A range of VC management policies are possible, which determine
whether a flow initiates a new VC or joins an existing one. VCs are whether a flow initiates a new VC or joins an existing one. VCs are
managed according to a combination of standards and local policy managed according to a combination of standards and local policy
rules, which are specific to either the implementation (equipment) or rules, which are specific to either the implementation (equipment) or
the operator (network service provider). Point-to-multipoint the operator (network service provider). Point-to-multipoint
connections within the ATM cloud can be used to support general IP connections within the ATM cloud can be used to support general IP
multicast flows. In ATM, a point to multipoint connection can be multicast flows. In ATM, a point to multipoint connection can be
controlled by the source (or root) node, or a leaf initiated join controlled by the source (or root) node, or a leaf initiated join
(LIJ) feature in ATM may be used. The topic of VC management is (LIJ) feature in ATM may be used. The topic of VC management is
considered at length in other ISSLL documents [13,14,15]. considered at length in other ISSLL documents [13, 14, 15].
Figure 2 shows the functions of an edge device, summarizing the work Figure 2 shows the functions of an edge device, summarizing the work
not part of IP or ATM abstractly as an InterWorking Function (IWF), not part of IP or ATM abstractly as an InterWorking Function (IWF),
and segregating the control and data planes. and segregating the control and data planes.
IP ATM IP ATM
____________________ ____________________
| IWF | | IWF |
| | | |
admission and <--> | service mapping | <--> ATM admission and <--> | service mapping | <--> ATM
policy control | VC management | signalling & policy control | VC management | signalling &
| address resolution | admission | address resolution | admission
|....................| control |....................| control
| | | |
classification, |ATM Adaptation Layer| cell classification, |ATM Adaptation Layer| cell
policing & <--> | Segmentation and | <--> scheduling/ policing & <--> | Segmentation and | <--> scheduling/
scheduling | Reassembly | shaping scheduling | Reassembly | shaping
| Buffering | | Buffering |
____________________ ____________________
Figure 2: Edge Device Functions showing the IWF Figure 2: Edge Device Functions showing the IWF
In the logical view of Figure 2, some functions, such as scheduling, In the logical view of Figure 2, some functions, such as scheduling,
are shown separately, since these functions are present on both the are shown separately, since these functions are present on both the
IP and ATM sides. However it may be possible in an integrated IP and ATM sides. However it may be possible in an integrated
implementation to combine such functions. implementation to combine such functions.
The service mapping and VC management functions can be highly The service mapping and VC management functions can be highly
interdependent. For example: (i) Multiple integrated-services flows interdependent. For example: (i) Multiple integrated-services flows
may be aggregated to use one point-to-multipoint VC. In this case, may be aggregated to use one point-to-multipoint VC. In this case,
we assume the IP flows are of the same service type and their we assume the IP flows are of the same service type and their
parameters have been merged appropriately. (ii) The VC management parameters have been merged appropriately. (ii) The VC management
function may choose to allocate extra resources in anticipation of function may choose to allocate extra resources in anticipation of
further reservations or based on an empiric of changing TSpecs. further reservations or based on an empiric of changing TSpecs.
(iii) There MUST exist a path for best effort flows and for sending (iii) There MUST exist a path for best effort flows and for sending
the rsvp control messages. How this interacts with the establishment the rsvp control messages. How this interacts with the establishment
of VCs for QoS traffic may alter the desired characteristics of those of VCs for QoS traffic may alter the desired characteristics of those
VCs. See [13,14,15] for further details on VC management. VCs. See [13, 14, 15] for further details on VC management.
Therefore, in discussing the service mapping problem, we will assume Therefore, in discussing the service mapping problem, we will assume
that the VC management function of the IWF can always express its that the VC management function of the IWF can always express its
result in terms of an IP-level service with some QoS and TSpec. The result in terms of an IP-level service with some QoS and TSpec. The
service mapping algorithm can then identify the appropriate VC service mapping algorithm can then identify the appropriate VC
parameters as if a new VC were to be created for this service. The parameters as if a new VC were to be created for this service. The
VC management function can then use this information consistent with VC management function can then use this information consistent with
its own policy, which determines whether the resulting action uses its own policy, which determines whether the resulting action uses
new or existing VCs. new or existing VCs.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
Another related document is RFC 1821 [17], which represents an early Another related document is RFC 1821 [17], which represents an early
discussion of issues involved with interoperating IP and ATM discussion of issues involved with interoperating IP and ATM
protocols for integrated services and QoS. protocols for integrated services and QoS.
2.0 Major Protocol Features for Traffic Management and QoS 2.0 Major Protocol Features for Traffic Management and QoS
The ATM Call Setup is sent by the ingress edge device to the ATM The ATM Call Setup is sent by the ingress edge device to the ATM
network to establish end-to-end (ATM) service. This setup contains network to establish end-to-end (ATM) service. This setup contains
the following information. the following information.
Service Category/Broadband Bearer Capability Service Category/Broadband Bearer Capability
AAL Parameters AAL Parameters
Broadband Low Layer Information Broadband Low Layer Information
Calling and Called Party Addressing Information Calling and Called Party Addressing Information
Traffic Descriptors Traffic Descriptors
QoS Class and/or Parameters QoS Class and/or Parameters
Additional Parameters of TM/UNI 4.0 Additional Parameters of TM/UNI 4.0
In this section, we discuss each of these items as they relate to In this section, we discuss each of these items as they relate to
creating ATM VCs suitable for GS, CLS and BE services. We do not creating ATM VCs suitable for GS, CLS and BE services. We do not
discuss routing and addressing at all, since they are (at least discuss routing and addressing at all, since they are (at least
presently) independent of QoS. Following the section on service presently) independent of QoS. Following the section on service
categories, we discuss tagging and conformance definitions for IP and categories, we discuss tagging and conformance definitions for IP and
ATM. These do not appear explicitly as set-up parameters in the ATM. These do not appear explicitly as set-up parameters in the
above list, since they are implied by the policing method used. above list, since they are implied by the policing method used.
2.1 Service Category and Bearer Capability 2.1 Service Category and Bearer Capability
skipping to change at page 8, line 43 skipping to change at page 8, line 43
These elements indicate the general properties of a VC: whether there These elements indicate the general properties of a VC: whether there
is a real-time delay constraint, whether the traffic is constant or is a real-time delay constraint, whether the traffic is constant or
variable rate, the applicable traffic and QoS description parameters variable rate, the applicable traffic and QoS description parameters
and (implicitly) the complexity of some supporting switch mechanisms and (implicitly) the complexity of some supporting switch mechanisms
(e.g., ABR). (e.g., ABR).
For UNI 3.0 and UNI 3.1, there are only two distinct options for For UNI 3.0 and UNI 3.1, there are only two distinct options for
bearer capabilities (in our context): bearer capabilities (in our context):
BCOB-A: constant rate, timing required, unicast/multipoint; BCOB-A: constant rate, timing required, unicast/multipoint;
BCOB-C: variable rate, timing not required, unicast/multipoint. BCOB-C: variable rate, timing not required, unicast/multipoint.
A third capability, BCOB-X, can be used as a substitute for the above A third capability, BCOB-X, can be used as a substitute for the above
two capabilities, with its dependent parameters (traffic type and two capabilities, with its dependent parameters (traffic type and
timing requirement) set appropriately. The distinction between the timing requirement) set appropriately. The distinction between the
BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and
BCOB-C constructs is whether the ATM network is to provide pure cell BCOB-C constructs is whether the ATM network is to provide pure cell
relay service or interwork with other technologies (with relay service or interwork with other technologies (with
interoperable signalling), such as narrowband ISDN. Where this interoperable signalling), such as narrowband ISDN. Where this
distinction is applicable, the appropriate code SHOULD be used (see distinction is applicable, the appropriate code SHOULD be used (see
[5] and related ITU specs, e.g., I.371). [5] and related ITU specs, e.g., I.371).
In TM/UNI 4.0 the service categories are: In TM/UNI 4.0 the service categories are:
Constant Bit Rate (CBR) Constant Bit Rate (CBR)
Real-time Variable Bit Rate (rtVBR) Real-time Variable Bit Rate (rtVBR)
Non-real-time Variable Bit Rate (nrtVBR) Non-real-time Variable Bit Rate (nrtVBR)
Unspecified Bit Rate (UBR) Unspecified Bit Rate (UBR)
Available Bit Rate (ABR) Available Bit Rate (ABR)
The first two of these are real-time services, so that rtVBR is new The first two of these are real-time services, so that rtVBR is new
to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR to TM/UNI 4.0. The ABR service is also new to TM/UNI 4.0. UBR
exists in all specifications, although it is called "best effort" in exists in all specifications, although it is called "best effort" in
UNI 3.x. In either case it is indicated by the "best effort" UNI 3.x. In either case it is indicated by the "best effort"
indication flag (and the QoS Class set to 0). indication flag (and the QoS Class set to 0).
The Service Category in TM/UNI 4.0 is encoded into the same signalled The Service Category in TM/UNI 4.0 is encoded into the same signalled
Information Element (IE) as the Bearer Capability in UNI 3.x, for the Information Element (IE) as the Bearer Capability in UNI 3.x, for the
purpose of backward compatibilty. Thus, we use the convention of purpose of backward compatibilty. Thus, we use the convention of
skipping to change at page 9, line 38 skipping to change at page 9, line 35
TM/UNI 4.0 (where the bearer capability is implicit). When we refer TM/UNI 4.0 (where the bearer capability is implicit). When we refer
to the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we are to the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we are
describing a UNI 3.x signalling message. describing a UNI 3.x signalling message.
In principle, it is possible to support any service through the use In principle, it is possible to support any service through the use
of BCOB-A/CBR. This is because the CBR service is equivalent to of BCOB-A/CBR. This is because the CBR service is equivalent to
having a "pipe" of a specified bandwidth. However, it may be having a "pipe" of a specified bandwidth. However, it may be
significantly more efficient to use the other ATM services where significantly more efficient to use the other ATM services where
applicable and available [17]. applicable and available [17].
2.1.1 Service Categories for Guaranteed Service 2.1.1 Service Categories for Guaranteed Service
There are two possible mappings for GS: There are two possible mappings for GS:
CBR (BCOB-A) CBR (BCOB-A)
rtVBR rtVBR
Real-time support is REQUIRED for GS. Thus in UNI 3.x, the Bearer Real-time support is REQUIRED for GS. Thus in UNI 3.x, the Bearer
Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used. In Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used. In
TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may
encourage recovery of allocated bandwidth left unused by a source. encourage recovery of allocated bandwidth left unused by a source.
It also accommodates more bursty sources with a larger token bucket It also accommodates more bursty sources with a larger token bucket
burst parameter, and permits the use of tagging for excess traffic burst parameter, and permits the use of tagging for excess traffic
(see Section 2.2). (see Section 2.2).
Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good
skipping to change at page 10, line 22 skipping to change at page 10, line 18
For BCOB-A or CBR, specification of a peak cell rate (PCR) is For BCOB-A or CBR, specification of a peak cell rate (PCR) is
REQUIRED by ATM standards. In these cases, PCR is the nominal REQUIRED by ATM standards. In these cases, PCR is the nominal
clearing rate with a nominal jitter toleration (bucket size), CDVT. clearing rate with a nominal jitter toleration (bucket size), CDVT.
When rtVBR is specifed, two rates, PCR and SCR are REQUIRED (by ATM When rtVBR is specifed, two rates, PCR and SCR are REQUIRED (by ATM
standards). This models bursty traffic with specified peak and standards). This models bursty traffic with specified peak and
sustainable rates. The corresponding ATM token bucket depth values sustainable rates. The corresponding ATM token bucket depth values
are CDVT, and CDVT+BT, respectively. are CDVT, and CDVT+BT, respectively.
2.1.2 Service Categories for Controlled Load 2.1.2 Service Categories for Controlled Load
There are three possible good mappings for CLS: There are three possible good mappings for CLS:
CBR (BCOB-A) CBR (BCOB-A)
nrtVBR (BCOB-C) nrtVBR (BCOB-C)
ABR ABR
Note that under UNI 3.x, there are equivalent services to CBR and Note that under UNI 3.x, there are equivalent services to CBR and
nrtVBR, but not ABR. The first, with a CBR/BCOB-A connection, nrtVBR, but not ABR. The first, with a CBR/BCOB-A connection,
provides a higher level of QoS than is necessary, but it may be provides a higher level of QoS than is necessary, but it may be
convenient to simply allocate a fixed-rate "pipe", which we expect to convenient to simply allocate a fixed-rate "pipe", which we expect to
be ubiquitously supported in ATM networks. However unless this is be ubiquitously supported in ATM networks. However unless this is
the only choice available, it would probably be wasteful of network the only choice available, it would probably be wasteful of network
resources. resources.
The nrtVBR/BCOB-C category is perhaps the best match, since it The nrtVBR/BCOB-C category is perhaps the best match, since it
skipping to change at page 11, line 15 skipping to change at page 11, line 10
The rtVBR category can be used, although the edge device MUST then The rtVBR category can be used, although the edge device MUST then
determine values for CTD and CDV. Since there are no corresponding determine values for CTD and CDV. Since there are no corresponding
IP-level parameters, their values are set as a matter of local IP-level parameters, their values are set as a matter of local
policy. policy.
The UBR category does not provide enough capability for Controlled The UBR category does not provide enough capability for Controlled
Load. The point of CLS is to allow an allocation of resources. This Load. The point of CLS is to allow an allocation of resources. This
is facilitated by the token bucket traffic descriptor, which is is facilitated by the token bucket traffic descriptor, which is
unavailable with UBR. unavailable with UBR.
2.1.3 Service Categories for Best Effort 2.1.3 Service Categories for Best Effort
All of the service categories have the capability to carry Best All of the service categories have the capability to carry Best
Effort service, but the natural service category is UBR (or, in UNI Effort service, but the natural service category is UBR (or, in UNI
3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or 3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or
rtVBR clearly could be used, and since the service is not real-time, rtVBR clearly could be used, and since the service is not real-time,
a nrtVBR connection could also be used. In these cases the rate a nrtVBR connection could also be used. In these cases the rate
parameter used reflects a bandwidth allocation in support of the parameter used reflects a bandwidth allocation in support of the
ingress edge device's best effort connectivity to the egress edge ingress edge device's best effort connectivity to the egress edge
router. It would be normal for traffic from many source/destination router. It would be normal for traffic from many source/destination
pairs to be aggregated on this connection; indeed, since Best Effort pairs to be aggregated on this connection; indeed, since Best Effort
skipping to change at page 15, line 19 skipping to change at page 15, line 5
parameters and ensure a higher likelihood of call admission. In parameters and ensure a higher likelihood of call admission. In
general, our discussion of connection parameters assumes the values general, our discussion of connection parameters assumes the values
resulting from successful connection setup. resulting from successful connection setup.
The Best Effort indicator (used only with UBR) and Tagging indicators The Best Effort indicator (used only with UBR) and Tagging indicators
(see Section 2.2) are also part of the signalled information element (see Section 2.2) are also part of the signalled information element
(IE) containing the traffic descriptor. In the UNI 4.0 traffic (IE) containing the traffic descriptor. In the UNI 4.0 traffic
descriptor IE there is an additional parameter, the Frame Discard descriptor IE there is an additional parameter, the Frame Discard
indicator, which is discussed below in Section 2.7. indicator, which is discussed below in Section 2.7.
2.5.1 Translating Traffic Descriptors for Guaranteed Service 2.5.1 Translating Traffic Descriptors for Guaranteed Service
For Guaranteed Service the source TSpec contains peak rate, rate and For Guaranteed Service the source TSpec contains peak rate, rate and
and bucket depth parameters, p_s, r_s, b_s. The receiver TSpec and bucket depth parameters, p_s, r_s, b_s. The receiver TSpec
contains corresponding parameters p_r, r_r, b_r. The (receiver) contains corresponding parameters p_r, r_r, b_r. The (receiver)
RSpec also has a rate, R. The two different TSpec rates are intended RSpec also has a rate, R. The two different TSpec rates are intended
to support receiver heterogeneity, in the sense that receivers can to support receiver heterogeneity, in the sense that receivers can
accept different rates representing different subsets of the sender's accept different rates representing different subsets of the sender's
traffic. Whenever rates from different receivers differ, the values traffic. Whenever rates from different receivers differ, the values
MUST always be merged appropriately before being mapping into ATM MUST always be merged appropriately before being mapping into ATM
parameters. parameters.
skipping to change at page 15, line 48 skipping to change at page 15, line 34
The receiver TSpec rate describes the traffic for which resources are The receiver TSpec rate describes the traffic for which resources are
to be reserved, and may be used for policing, while the RSpec rate to be reserved, and may be used for policing, while the RSpec rate
(which cannot be smaller) is used (perhaps in an implementation (which cannot be smaller) is used (perhaps in an implementation
specific way) to modify the allocated service bandwidth in order to specific way) to modify the allocated service bandwidth in order to
reduce the delay. reduce the delay.
When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic When mapping Guaranteed Service onto a rtVBR VC, the ATM traffic
descriptor parameters (PCR, SCR, MBS) can be set cannonically as: descriptor parameters (PCR, SCR, MBS) can be set cannonically as:
PCR = p_r PCR = p_r
SCR = R SCR = R
MBS = b_r. MBS = b_r.
There are a number of conditions that may lead to different choices. There are a number of conditions that may lead to different choices.
The following discussion is not intended to set hard requirements, The following discussion is not intended to set hard requirements,
but to provide some interpretation and guidance on the bounds of but to provide some interpretation and guidance on the bounds of
possible parameter mappings. The ingress edge device generally possible parameter mappings. The ingress edge device generally
includes a buffer preceding the ATM network interface. This buffer includes a buffer preceding the ATM network interface. This buffer
can be used to absorb bursts that fall within the IP-level TSpec, but can be used to absorb bursts that fall within the IP-level TSpec, but
not within the ATM traffic descriptor. The minimal REQUIREMENT for not within the ATM traffic descriptor. The minimal REQUIREMENT for
guaranteed service is that the delay in this buffer MUST NOT exceed guaranteed service is that the delay in this buffer MUST NOT exceed
b/R, and the delays within the ATM network MUST be accurately b/R, and the delays within the ATM network MUST be accurately
accounted for in the values of Adspec parameters C and D advertised accounted for in the values of Adspec parameters C and D advertised
by the ingress router (see Section 3.3 below). by the ingress router (see Section 3.3 below).
If either an edge device buffer of size b_r exists or the ATM maximum If either an edge device buffer of size b_r exists or the ATM maximum
burst size (MBS) parameter is at least b_r, then the various rate burst size (MBS) parameter is at least b_r, then the various rate
parameters will generally exhibit the following relationship: parameters will generally exhibit the following relationship:
r_r <= SCR <= R <= PCR <= APB <= line rate r_r <= SCR <= R <= PCR <= APB <= line rate
r_r <= p_r <= APB r_r <= p_r <= APB
APB refers to the General Characterization Parameter, APB refers to the General Characterization Parameter,
AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion AVAILABLE_PATH_BANDWIDTH, which is negotiated in the Adspec portion
of the PATH message. APB reflects the narrowest bottleneck rate of the PATH message. APB reflects the narrowest bottleneck rate
along the path, and so is always no larger than the local line rate. along the path, and so is always no larger than the local line rate.
The receiver SHOULD choose a peak rate no greater than APB for the The receiver SHOULD choose a peak rate no greater than APB for the
reservation to be accepted, although the source peak rate, p_s, could reservation to be accepted, although the source peak rate, p_s, could
be higher, as the source does not know the value of APB. There is no be higher, as the source does not know the value of APB. There is no
advantage to allocating any rate above APB of course, so it is an advantage to allocating any rate above APB of course, so it is an
upper bound for all the other parameters. upper bound for all the other parameters.
skipping to change at page 19, line 5 skipping to change at page 18, line 29
for the flow. for the flow.
For GS over CBR, the value of PCR may be mapped to the RSpec rate R, For GS over CBR, the value of PCR may be mapped to the RSpec rate R,
if the edge device has a buffer of size b_r + C_sum + R D_sum. With if the edge device has a buffer of size b_r + C_sum + R D_sum. With
little or no burst buffering, the requirements resemble the zero- little or no burst buffering, the requirements resemble the zero-
buffer case above, and we have PCR = max (R, p_r). Additional buffer case above, and we have PCR = max (R, p_r). Additional
buffers sufficient to absorb network jitter, given by C_sum, D_sum, buffers sufficient to absorb network jitter, given by C_sum, D_sum,
MUST always be provided in the edge router, or in the ATM network via MUST always be provided in the edge router, or in the ATM network via
MBS. MBS.
2.5.2 Translating Traffic Descriptors for Controlled Load Service 2.5.2 Translating Traffic Descriptors for Controlled Load Service
The Controlled Load service TSpec has a peak rate, p, a "token The Controlled Load service TSpec has a peak rate, p, a "token
bucket" rate, r, and a corresponding token bucket depth parameter, b. bucket" rate, r, and a corresponding token bucket depth parameter, b.
The receiver TSpec values are used to determine resource allocation, The receiver TSpec values are used to determine resource allocation,
and a simple mapping for the nrtVBR service category is given by, and a simple mapping for the nrtVBR service category is given by,
PCR = p_r PCR = p_r
SCR = r_r SCR = r_r
MBS = b_r. MBS = b_r.
The discussions in the preceding section on using edge device buffers The discussions in the preceding section on using edge device buffers
to reduce PCR and/or MBS apply generally to the CLS over nrtVBR case to reduce PCR and/or MBS apply generally to the CLS over nrtVBR case
as well. Extra buffers to accommodate jitter accumulated (beyond the as well. Extra buffers to accommodate jitter accumulated (beyond the
b_r burst size allowed at the source) MUST be provided. For CLS, b_r burst size allowed at the source) MUST be provided. For CLS,
there are no Adspec parameters C and D, so the dimensioning of such there are no Adspec parameters C and D, so the dimensioning of such
buffers is an implementation design issue. buffers is an implementation design issue.
For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate For ABR VCs, the TSpec rate r_r is used to set the minimum cell rate
(MCR) parameter. Since there is no corresponding signalled bucket (MCR) parameter. Since there is no corresponding signalled bucket
skipping to change at page 20, line 5 skipping to change at page 19, line 23
last byte of a burst of size b_r sees a delay approximately b_r/r_r. last byte of a burst of size b_r sees a delay approximately b_r/r_r.
For example, a network element with no cross-traffic, a work For example, a network element with no cross-traffic, a work
conserving scheduler and an output link rate of r_L, might provide conserving scheduler and an output link rate of r_L, might provide
delays in the range from M/r_L to b_r/r_L, that are much lower than delays in the range from M/r_L to b_r/r_L, that are much lower than
b_r/r_r. While the access to the full link bandwidth (r_L), as b_r/r_r. While the access to the full link bandwidth (r_L), as
reflected in this example, is a more literal interpretation of delay reflected in this example, is a more literal interpretation of delay
"under unloaded conditions" for a shared link, an ATM VC may only "under unloaded conditions" for a shared link, an ATM VC may only
have access to bandwidth equal to its nominal allocation (some have access to bandwidth equal to its nominal allocation (some
implementation specific function of SCR and PCR). implementation specific function of SCR and PCR).
2.5.3 Translating Traffic Descriptors for Best Effort Service 2.5.3 Translating Traffic Descriptors for Best Effort Service
For Best Effort service, there is no traffic description. The UBR For Best Effort service, there is no traffic description. The UBR
service category allows negotiation of PCR simply to allow the source service category allows negotiation of PCR simply to allow the source
to discover the smallest physical bottleneck along the path. The to discover the smallest physical bottleneck along the path. The
ingress edge router may set PCR to the ATM line rate, and then when ingress edge router may set PCR to the ATM line rate, and then when
the VC setup is complete, the returned value indicates an upper bound the VC setup is complete, the returned value indicates an upper bound
on throughput. For UBR service, resources may be allocated for the on throughput. For UBR service, resources may be allocated for the
overall service (i.e., not per-VC) using the (implementation overall service (i.e., not per-VC) using the (implementation
specific) admission control features of the ATM switches. specific) admission control features of the ATM switches.
Often a service provider will statically configure large VCs with a Often a service provider will statically configure large VCs with a
certain bandwidth allocation to handle all best effort traffic certain bandwidth allocation to handle all best effort traffic
between two edge routers. ABR, CBR or nrtVBR VCs are appropriate for between two edge routers. ABR, CBR or nrtVBR VCs are appropriate for
this design, with traffic parameters set to comfortably accommodate this design, with traffic parameters set to comfortably accommodate
the expected traffic load. See IETF ION specifications for IP over the expected traffic load. See IETF ION specifications for IP over
ATM signalling [10,11]. ATM signalling [10, 11].
2.6 QoS Classes and Parameters 2.6 QoS Classes and Parameters
In UNI 3.x the quality of service is indicated by a single parameter In UNI 3.x the quality of service is indicated by a single parameter
called "QoS Class," which is essentially an index to a network called "QoS Class," which is essentially an index to a network
specific table of values for the actual QoS parameters. In TM/UNI specific table of values for the actual QoS parameters. In TM/UNI
4.0 three QoS parameters may be individually signalled, and the 4.0 three QoS parameters may be individually signalled, and the
signalled values override those implied by the QoS Class, which is signalled values override those implied by the QoS Class, which is
still present. These parameters are the Cell Loss Ratio (CLR), Cell still present. These parameters are the Cell Loss Ratio (CLR), Cell
Transfer Delay (CTD), and Cell Delay Variation (CDV) [6]. Transfer Delay (CTD), and Cell Delay Variation (CDV) [6].
skipping to change at page 22, line 4 skipping to change at page 21, line 20
The ingress router will also tabulate values for the Minimum Path The ingress router will also tabulate values for the Minimum Path
Latency (MPL) and estimated queueing delays (D_ATM) for each egress Latency (MPL) and estimated queueing delays (D_ATM) for each egress
point. The latter will be used as part of the Adspec "D" parameter point. The latter will be used as part of the Adspec "D" parameter
for GS, but its use here applies to CLS as well (when the VC setup for GS, but its use here applies to CLS as well (when the VC setup
includes delay parameters). MPL represents all constant (non- includes delay parameters). MPL represents all constant (non-
congestion related) delays, including propagation delay. D_ATM congestion related) delays, including propagation delay. D_ATM
accounts for the variable component of delays in the ATM network. accounts for the variable component of delays in the ATM network.
(It may depend on non-signalled parameters such as CDVT.) Given (It may depend on non-signalled parameters such as CDVT.) Given
these quantities, a new VC can be set up with delay-related QoS these quantities, a new VC can be set up with delay-related QoS
parameters given by parameters given by
CDV = D_ATM
CTD = D_ATM + MPL. CDV = D_ATM
CTD = D_ATM + MPL.
(CDV and CTD may be adjusted (increased) by the slack term in GS, see (CDV and CTD may be adjusted (increased) by the slack term in GS, see
Section 3.3 below.) Section 3.3 below.)
It is interesting (and perhaps unfortunate) to note that in a typical It is interesting (and perhaps unfortunate) to note that in a typical
GS/rtVBR service, the delay bound advertised can contain two GS/rtVBR service, the delay bound advertised can contain two
components of b/R instead of one. Consider the simple case where SCR components of b/R instead of one. Consider the simple case where SCR
= R is the rate allocated to the flow in both IP routers and ATM = R is the rate allocated to the flow in both IP routers and ATM
switches along the path, and the buffer allocation is MBS = b. switches along the path, and the buffer allocation is MBS = b.
Parekh's theory [23], which is the basis of the GS delay formula [8] Parekh's theory [23], which is the basis of the GS delay formula [8]
skipping to change at page 26, line 25 skipping to change at page 25, line 38
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term
The Adspec is used by the Guaranteed Service to allow a receiver to The Adspec is used by the Guaranteed Service to allow a receiver to
calculate the worst-case delay associated with a GS flow. Three calculate the worst-case delay associated with a GS flow. Three
quantities, C, D, and MPL, are accumulated (by simple addition of quantities, C, D, and MPL, are accumulated (by simple addition of
components corresponding to each network element) in the PATH message components corresponding to each network element) in the PATH message
from source to receiver. The resulting delay values can be different from source to receiver. The resulting delay values can be different
for each unique receiver. The maximum delay is computed as for each unique receiver. The maximum delay is computed as
delay <= b_r/R + C_TOT/R + D_TOT + MPL delay <= b_r/R + C_TOT/R + D_TOT + MPL
The Minimum Path Latency (MPL) includes propagation delay, while The Minimum Path Latency (MPL) includes propagation delay, while
b_r/R accounts for bursts due to the source and C and D include other b_r/R accounts for bursts due to the source and C and D include other
queueing, scheduling and serialization delays. (We neglect the queueing, scheduling and serialization delays. (We neglect the
effect of maximum packet size and peak rate here; see the GS effect of maximum packet size and peak rate here; see the GS
specification [8] for a more detailed equation.) The service rate specification [8] for a more detailed equation.) The service rate
requested by the receiver, R, can be greater than the TSpec rate, requested by the receiver, R, can be greater than the TSpec rate,
r_r, resulting in lower delay. The burst size, b_r, is the leaky r_r, resulting in lower delay. The burst size, b_r, is the leaky
bucket parameter from the receiver TSpec. bucket parameter from the receiver TSpec.
skipping to change at page 27, line 20 skipping to change at page 26, line 30
with. The value of D_ATM contributes to the D parameter advertised with. The value of D_ATM contributes to the D parameter advertised
by the edge router, and SHOULD accurately reflect the CDV that the by the edge router, and SHOULD accurately reflect the CDV that the
router will get in a VC when it is set up. Factors that affect CDV, router will get in a VC when it is set up. Factors that affect CDV,
such as statistical multiplexing in the ATM network, SHOULD be taken such as statistical multiplexing in the ATM network, SHOULD be taken
into account when compiling data for the router's table. In case of into account when compiling data for the router's table. In case of
uncertainty, D_ATM can be set to an upper bound. When an RESV uncertainty, D_ATM can be set to an upper bound. When an RESV
message arrives, causing a VC to be set up, the requested values for message arrives, causing a VC to be set up, the requested values for
CTD and CDV can be relaxed using the slack term in the receiver CTD and CDV can be relaxed using the slack term in the receiver
RSpec: RSpec:
CTD = D_ATM + MPL + S_ATM CTD = D_ATM + MPL + S_ATM
CDV = D_ATM + S_ATM. CDV = D_ATM + S_ATM.
The term S_ATM is the portion of the slack term applied to the ATM The term S_ATM is the portion of the slack term applied to the ATM
portion of the path. Recall that the slack term [8] is positive when portion of the path. Recall that the slack term [8] is positive when
the receiver can afford more delay than that computed from the the receiver can afford more delay than that computed from the
Adspec. The ATM edge device may take part (or all) of the slack Adspec. The ATM edge device may take part (or all) of the slack
term, S. The distribution of delay slack among the nodes and subnets term, S. The distribution of delay slack among the nodes and subnets
is network specific. is network specific.
Note that with multipoint VCs the egress edge router may need to Note that with multipoint VCs the egress edge router may need to
correct advertised values of C and D. See discussion in Section 3.1. correct advertised values of C and D. See discussion in Section 3.1.
skipping to change at page 28, line 4 skipping to change at page 27, line 12
IP layer, token bucket depths and rates are measured in bytes and IP layer, token bucket depths and rates are measured in bytes and
bytes/sec, respectively, whereas for ATM, they are measured in cells bytes/sec, respectively, whereas for ATM, they are measured in cells
and cells/sec. and cells/sec.
Each IP Packet is wrapped into an AAL-5 PDU, having a number of Each IP Packet is wrapped into an AAL-5 PDU, having a number of
additional header bytes (8 for LLC/SNAP and perhaps others, e.g. 12 additional header bytes (8 for LLC/SNAP and perhaps others, e.g. 12
for MPOA, etc.), and an 8-byte AAL-5 trailer. The AAL-5 PDU is then for MPOA, etc.), and an 8-byte AAL-5 trailer. The AAL-5 PDU is then
segmented into multiple ATM cells, each having a 5-byte cell header segmented into multiple ATM cells, each having a 5-byte cell header
followed by a 48-byte cell payload. The number of cells used to followed by a 48-byte cell payload. The number of cells used to
carry an IP packet with carry an IP packet with
B = number of IP-packet Bytes,
H = number of AAL-5 header bytes (LLC/SNAP etc.) B = number of IP-packet Bytes,
C = number of cells, H = number of AAL-5 header bytes (LLC/SNAP etc.)
C = number of cells,
is roughly is roughly
C = B/48, C = B/48,
and more precisely and more precisely
C = floor[(H + B + 8 + 47)/48] C = floor[(H + B + 8 + 47)/48]
where floor[] is rounds down to the nearest integer. The '8' where floor[] is rounds down to the nearest integer. The '8'
accounts for the AAL-5 trailer and the '47' accounts for the last accounts for the AAL-5 trailer and the '47' accounts for the last
cell which may be only partially filled. cell which may be only partially filled.
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service
This section describes how to create ATM VCs appropriately matched This section describes how to create ATM VCs appropriately matched
for Guaranteed Service. The key points are that real-time timing is for Guaranteed Service. The key points are that real-time timing is
REQUIRED, that the data flow may have a variable rate, and that REQUIRED, that the data flow may have a variable rate, and that
skipping to change at page 29, line 30 skipping to change at page 28, line 40
Bearer Class 16 (BCOB-X) Note 2 Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 9 (Real time VBR) Note 3 ATM Transfer Capability 9 (Real time VBR) Note 3
Susceptible to Clipping 00 (Not Susceptible) Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint) User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information Broadband Low Layer Information
User Information Layer 2 User Information Layer 2
Protocol 12 (ISO 8802/2) Protocol 12 (ISO 8802/2)
User Information Layer 3 User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4 Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204 ISO/IEC TR 9577 IPI 204
QoS Class QoS Class
QoS Class Forward 1 Note 5 QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5 QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6 Extended QoS Parameters Note 6
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
skipping to change at page 29, line 42 skipping to change at page 29, line 4
QoS Class QoS Class
QoS Class Forward 1 Note 5 QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5 QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6 Extended QoS Parameters Note 6
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
Note 1: See discussion in Section 2.5.1. Note 1: See discussion in Section 2.5.1.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent. If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: The ATC value 19 is not used. The value 19 implies that the Note 3: The ATC value 19 is not used. The value 19 implies that the
CLR objective applies to the aggregate CLP=0+1 stream and CLR objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic. that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
be specified. For BE VCs, it can be left unspecified, allowing SHOULD be specified. For BE VCs, it can be left
the VC to be shared by multiple protocols, following RFC 1755. unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6. Note 6: See discussion in Section 2.6.
5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0) 5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0)
A CBR VC MEETS the requirements of GS. The main advantage of this is A CBR VC MEETS the requirements of GS. The main advantage of this is
that CBR is widely supported; the disadvantage is that data flows that CBR is widely supported; the disadvantage is that data flows
might not fill the pipe (utilization loss) and there is no tagging might not fill the pipe (utilization loss) and there is no tagging
option available. Excess traffic MUST be handled using a separate option available. Excess traffic MUST be handled using a separate
VC. VC.
skipping to change at page 31, line 10 skipping to change at page 30, line 18
Extended QoS Parameters Note 6 Extended QoS Parameters Note 6
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
Note 1: See discussion in Section 2.5.1. Note 1: See discussion in Section 2.5.1.
Note 2: Value 1 (BCOB-A) can also be used. Note 2: Value 1 (BCOB-A) can also be used.
If Bearer Class A is chosen the ATC field MUST be absent. If Bearer Class A is chosen the ATC field MUST be absent.
Note 3: The ATC value 7 is not used. The value 7 implies CLR Note 3: The ATC value 7 is not used. The value 7 implies CLR
objective applies to the aggregate CLP=0+1 stream and objective applies to the aggregate CLP=0+1 stream and that
that does not give desirable treatment of excess traffic. does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
be specified. For BE VCs, it can be left unspecified, allowing SHOULD be specified. For BE VCs, it can be left
the VC to be shared by multiple protocols, following RFC 1755. unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6. Note 6: See discussion in Section 2.6.
5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for
GS. If GS/nrtVBR is used and network utilization is low, the delay GS. If GS/nrtVBR is used and network utilization is low, the delay
may be `reasonable', but will not be controlled. The encoding of GS may be `reasonable', but will not be controlled. The encoding of GS
with nrtVBR is the same as that for CLS using nrtVBR. See Section with nrtVBR is the same as that for CLS using nrtVBR. See Section
6.1 below. 6.1 below.
skipping to change at page 32, line 46 skipping to change at page 31, line 51
Protocol 12 (ISO 8802/2) Protocol 12 (ISO 8802/2)
User Information Layer 3 User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4 Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204 ISO/IEC TR 9577 IPI 204
QoS Class Note 5 QoS Class Note 5
QoS Class Forward 1 QoS Class Forward 1
QoS Class Backward 1 QoS Class Backward 1
Note 1: Only included for UNI 3.0. Note 1: Only included for UNI 3.0.
Note 2: See discussion in Section 2.5.1. PCR CLP=0 SHOULD be set identical Note 2: See discussion in Section 2.5.1. PCR CLP=0 SHOULD be set
to PCR CLP=0+1. Although this could potentially allow a CBR VC identical to PCR CLP=0+1. Although this could potentially
to carry excess traffic as tagged cells, it is not recommended allow a CBR VC to carry excess traffic as tagged cells, it
since it is not supported in UNI 4.0 is not recommended since it is not supported in UNI 4.0
Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used Traffic
Type and Timing Requirements fields are not included. Type and Timing Requirements fields are not included.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
be specified. For BE VCs, it can be left unspecified, allowing SHOULD be specified. For BE VCs, it can be left
the VC to be shared by multiple protocols, following RFC 1755. unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 5: QoS Parameters are implied by the QoS Class. Note 5: QoS Parameters are implied by the QoS Class.
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service
This section describes how to create ATM VCs appropriately matched This section describes how to create ATM VCs appropriately matched
for Controlled Load Service. CLS traffic is partly delay tolerant for Controlled Load Service. CLS traffic is partly delay tolerant
and has variable rate. NrtVBR and ABR (TM/UNI 4.0 only) are the best and has variable rate. NrtVBR and ABR (TM/UNI 4.0 only) are the best
choices for supporting CLS. choices for supporting CLS.
Note, these encodings assume point to multipoint connections where Note, these encodings assume point to multipoint connections where
skipping to change at page 36, line 4 skipping to change at page 34, line 41
QoS Class Forward 0 Note 4 QoS Class Forward 0 Note 4
QoS Class Backward 0 Note 4 QoS Class Backward 0 Note 4
Extended QoS Parameters Note 5 Extended QoS Parameters Note 5
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
ABR Setup Parameters Note 6 ABR Setup Parameters Note 6
ABR Additional Parameters Note 6 ABR Additional Parameters Note 6
Note 1: See discussion in Section 2.5.2. Note 1: See discussion in Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent. If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol
be specified. For BE VCs, it can be left unspecified, allowing SHOULD be specified. For BE VCs, it can be left
the VC to be shared by multiple protocols, following RFC 1755. unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions. Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 5: See discussion in Section 2.6. Note 5: See discussion in Section 2.6.
Note 6: The ABR-specific parameters are beyond the scope of this document.
These generally depend on local implementation and not on values Note 6: The ABR-specific parameters are beyond the scope of this
mapped from IP level service parameters (except for MCR). document. These generally depend on local implementation
See [6, 11] for further information. and not on values mapped from IP level service parameters
(except for MCR). See [6, 11] for further information.
6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0) 6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0)
Although CBR does not explicitly take into account the variable rate Although CBR does not explicitly take into account the variable rate
of source data, it may be convenient to use ATM connectivity between of source data, it may be convenient to use ATM connectivity between
edge routers to provide a simple "pipe" service, as a leased line edge routers to provide a simple "pipe" service, as a leased line
replacement. Since no tagging option is available with CBR, excess replacement. Since no tagging option is available with CBR, excess
traffic MUST be handled using a separate VC. Under this condition, traffic MUST be handled using a separate VC. Under this condition,
CBR MEETS the requirements of CLS. CBR MEETS the requirements of CLS.
skipping to change at page 37, line 50 skipping to change at page 36, line 38
ISO/IEC TR 9577 IPI 204 ISO/IEC TR 9577 IPI 204
QoS Class QoS Class
QoS Class Forward 3 Note 5 QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5 QoS Class Backward 3 Note 5
Note 1: Only included for UNI 3.0. Note 1: Only included for UNI 3.0.
Note 2: See discussion in Section 2.5.2. Note 2: See discussion in Section 2.5.2.
Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic
Type and Timing Requirements fields are not included. Type and Timing Requirements fields are not included.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
be specified. For BE VCs, it can be left unspecified, allowing SHOULD be specified. For BE VCs, it can be left
the VC to be shared by multiple protocols, following RFC 1755. unspecified, allowing the VC to be shared by multiple
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. protocols, following RFC 1755.
QoS Parameters are implied by the QoS Class. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. QoS
Parameters are implied by the QoS Class.
7.0 Summary of ATM VC Setup Parameters for Best Effort Service 7.0 Summary of ATM VC Setup Parameters for Best Effort Service
This section is provided for completeness only. The IETF ION working This section is provided for completeness only. The IETF ION working
group documents on ATM signalling support for IP over ATM [10, 11] group documents on ATM signalling support for IP over ATM [10, 11]
provide definitive specifications for Best Effort IP service over provide definitive specifications for Best Effort IP service over
ATM. ATM.
The best-matched ATM service category to IP Best Effort is UBR. We The best-matched ATM service category to IP Best Effort is UBR. We
provide the setup details for this case below. The BE service does provide the setup details for this case below. The BE service does
skipping to change at page 40, line 19 skipping to change at page 39, line 7
9.0 Acknowledgements 9.0 Acknowledgements
The authors received much useful input from the members of the ISSLL The authors received much useful input from the members of the ISSLL
working group. In particular, thanks to Drew Perkins and Jon Bennett working group. In particular, thanks to Drew Perkins and Jon Bennett
of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh
of Bellcore. of Bellcore.
Appendix 1 Abbreviations Appendix 1 Abbreviations
AAL ATM Adaptation Layer AAL ATM Adaptation Layer
ABR Available Bit Rate ABR Available Bit Rate
APB Available Path Bandwidth (int-serv GCP) APB Available Path Bandwidth (int-serv GCP)
ATC ATM Transfer Capability ATC ATM Transfer Capability
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
B-LLI Broadband Low Layer Information B-LLI Broadband Low Layer Information
BCOB Broadband Connection-Oriented Bearer Capability BCOB Broadband Connection-Oriented Bearer Capability
BCOB-{A,C,X} Bearer Class A, C, or X BCOB-{A,C,X} Bearer Class A, C, or X
BE Best Effort BE Best Effort
BT Burst Tolerance BT Burst Tolerance
CBR Constant Bit Rate CBR Constant Bit Rate
CDV Cell Delay Variation CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance CDVT Cell Delay Variation Tolerance
CLP Cell Loss Priority (bit) CLP Cell Loss Priority (bit)
CLR Cell Loss Ratio CLR Cell Loss Ratio
CLS Controlled Load Service CLS Controlled Load Service
CPCS Common Part Convergence Sublayer CPCS Common Part Convergence Sublayer
CTD Cell Transfer Delay CTD Cell Transfer Delay
EOM End of Message EOM End of Message
GCP General Characterization Parameter GCP General Characterization Parameter
GCRA Generic Cell Rate Algorithm GCRA Generic Cell Rate Algorithm
GS Guaranteed Service GS Guaranteed Service
IE Information Element IE Information Element
IETF Internet Engineering Task Force IETF Internet Engineering Task Force
ION IP Over Non-broadcast multiple access networks ION IP Over Non-broadcast multiple access networks
IP Internet Protocol IP Internet Protocol
IPI Initial Protocol Identifier IPI Initial Protocol Identifier
IS Integrated Services IS Integrated Services
ISSLL Integrated Services over Specific Link Layers ISSLL Integrated Services over Specific Link Layers
ITU International Telecommunication Union ITU International Telecommunication Union
IWF Interworking Function IWF Interworking Function
LIJ Leaf Initiated Join LIJ Leaf Initiated Join
LLC Logical Link Control LLC Logical Link Control
MBS Maximum Burst Size MBS Maximum Burst Size
MCR Minimum Cell Rate MCR Minimum Cell Rate
MPL Minimum Path Latency MPL Minimum Path Latency
MTU Maximum Transfer Unit MTU Maximum Transfer Unit
nrtVBR Non-real-time VBR nrtVBR Non-real-time VBR
PCR Peak Cell Rate PCR Peak Cell Rate
PDU Protocol Data Unit PDU Protocol Data Unit
PVC Permanent Virtual Connection PVC Permanent Virtual Connection
QoS Quality of Service QoS Quality of Service
RESV Reservation Message (of rsvp protocol) RESV Reservation Message (of rsvp protocol)
RFC Request for Comments RFC Request for Comments
RSVP Resource Reservation Protocol RSVP Resource Reservation Protocol
RSpec Reservation Specification RSpec Reservation Specification
rtVBR Real-time VBR rtVBR Real-time VBR
SCR Sustainable Cell Rate SCR Sustainable Cell Rate
SDU Service Data Unit SDU Service Data Unit
SNAP Subnetwork Attachment Point SNAP Subnetwork Attachment Point
SSCS Service-Specific Convergence Sub-layer SSCS Service-Specific Convergence Sub-layer
SVC Switched Virtual Connection SVC Switched Virtual Connection
TCP Transport Control Protocol TCP Transport Control Protocol
TM Traffic Management TM Traffic Management
TSpec Traffic Specification TSpec Traffic Specification
UBR Unspecified Bit Rate UBR Unspecified Bit Rate
UNI User-Network Interface UNI User-Network Interface
UPC Usage Parameter Control (ATM traffic policing function) UPC Usage Parameter Control (ATM traffic policing function)
VBR Variable Bit Rate VBR Variable Bit Rate
VC (ATM) Virtual Connection VC (ATM) Virtual Connection
REFERENCES REFERENCES
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] R. Braden, D. Clark and S. Shenker, "Integrated Services in the [2] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
Internet Architecture: an Overview", RFC 1633, June 1994. the Internet Architecture: an Overview", RFC 1633, June 1994.
[3] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, [3] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[4] The ATM Forum, "ATM User-Network Interface Specification, Ver- [4] The ATM Forum, "ATM User-Network Interface Specification,
sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.
[5] The ATM Forum, "ATM User-Network Interface Specification, Ver- [5] The ATM Forum, "ATM User-Network Interface Specification,
sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.
[6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling [6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling
Specification, Version 4.0", July 1996. Available at Specification, Version 4.0", July 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps. ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.
[7] The ATM Forum, "ATM Traffic Management Specification, Version [7] The ATM Forum, "ATM Traffic Management Specification, Version
4.0", April 1996. Available at 4.0", April 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps. ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.
[8] M. W. Garrett, "A Service Architecture for ATM: From Applica- [8] M. W. Garrett, "A Service Architecture for ATM: From
tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6- Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3,
14, May 1996. pp. 6-14, May 1996.
[9] S. Shenker, C. Partridge and R. Guerin, "Specification of [9] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997. Guaranteed Quality of Service", RFC 2212, September 1997.
[10] J. Wroclawski, "Specification of the Controlled-Load Network [10] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997. Element Service", RFC 2211, September 1997.
[11] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. [11] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru- A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
ary 1995. February 1995.
[12] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM [12] Maher, M., "ATM Signalling Support for IP over ATM - UNI
UNI 4.0 Update", Internet Draft, October 1997. <draft-ietf- Signalling 4.0 Update", RFC 2331, April 1998.
ion-sig-uni4.0-05.txt>
[13] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. [13] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
Krawczyk, "A Framework for Integrated Services and RSVP over J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", Internet Draft, July 1997. <draft-ietf-issll-atm- ATM", RFC 2382, August 1998.
framework-00.txt>
[14] L. Berger, "RSVP over ATM Implementation Requirements", Internet [14] Berger, L., "RSVP over ATM Implementation Requirements", RFC
Draft, January 1998. <draft-ietf-issll-atm-imp-req-02.txt> 2380, August 1998.
[15] L. Berger, "RSVP over ATM Implementation Guidelines", Internet [15] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24,
Draft, January 1998. <draft-ietf-issll-imp-guide-03.txt> RFC 2379, August 1998.
[16] S. Shenker and J. Wroclawski, "Network Element Service Specifi- [16] Shenker, S., and J. Wroclawski, "Network Element Service
cation Template", RFC 2216, September 1997. Specification Template", RFC 2216, September 1997.
[17] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", [17] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997. RFC 2210, September 1997.
[18] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of [18] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
Real-time Services in an IP-ATM Network Architecture", RFC 1821, of Real-time Services in an IP-ATM Network Architecture", RFC
August 1995. 1821, August 1995.
[19] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation [19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993. Layer 5", RFC 1483, July 1993.
[20] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January [20] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January
1994. 1994.
[21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer per- [21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer
formance", International Telecommunication Union, Geneva, performance", International Telecommunication Union, Geneva,
October 1996. October 1996.
[22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net- [22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM
works", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633- Networks", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp.
41, May 1995. 633-41, May 1995.
[23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing [23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing
Approach to Flow Control in Integrated Services Networks: The Approach to Flow Control in Integrated Services Networks: The
Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2, Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2,
pp. 137-150, April 1994. pp. 137-150, April 1994.
[24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management [24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management
Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3,
No. 4, August 1995. No. 4, August 1995.
[25] S. Shenker and J. Wroclawski, "General Characterization Parame- [25] S. Shenker and J. Wroclawski, "General Characterization
ters for Integrated Service Network Elements", RFC 2215, Sep- Parameters for Integrated Service Network Elements", RFC 2215,
tember 1997. September 1997.
Authors' Addresses Authors' Addresses
Mark W. Garrett Marty Borden Mark W. Garrett
Bellcore Bay Networks Bellcore
445 South Street 42 Nagog Park 445 South Street
Morristown, NJ 07960 Acton MA, 01720 Morristown, NJ 07960
USA USA USA
phone: +1 201 829-4439 phone: +1 508 266-1011 Phone: +1 201 829-4439
email: mwg@bellcore.com email: mborden@baynetworks.com EMail: mwg@bellcore.com
Marty Borden
Bay Networks
42 Nagog Park
Acton MA, 01720
USA
Phone: +1 508 266-1011
EMail: mborden@baynetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 72 change blocks. 
278 lines changed or deleted 280 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/