draft-ietf-issll-atm-mapping-03.txt   draft-ietf-issll-atm-mapping-04.txt 
INTERNET-DRAFT Mark W. Garrett, INTERNET-DRAFT Mark W. Garrett,
ISSLL WG Bellcore ISSLL WG Bellcore
Expires: 25 January 1998
Marty Borden, Marty Borden,
New Oak Communications New Oak Communications
21 November 1997
Interoperation of Controlled-Load Service and Guaranteed Service with ATM Interoperation of Controlled-Load Service and Guaranteed Service with ATM
<draft-ietf-issll-atm-mapping-03.txt> <draft-ietf-issll-atm-mapping-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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
integrated services protocols for Guaranteed Service (GS), integrated services protocols for Guaranteed Service (GS),
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.
Table of Contents Table of Contents
0.0 What's New in This Version ......................................... 3
1.0 Introduction ....................................................... 3 1.0 Introduction ....................................................... 3
1.1 General System Architecture .................................... 5 1.1 General System Architecture .................................... 4
1.2 Related Documents .............................................. 7 1.2 Related Documents .............................................. 7
2.0 Major Protocol Features for Traffic Management and QoS ............. 8 2.0 Major Protocol Features for Traffic Management and QoS ............. 7
2.1 Service Category and Bearer Capability ......................... 8 2.1 Service Category and Bearer Capability ......................... 8
2.1.1 Service Categories for Guaranteed Service ................ 8 2.1.1 Service Categories for Guaranteed Service ................ 9
2.1.2 Service Categories for Controlled Load ................... 9 2.1.2 Service Categories for Controlled Load ................... 10
2.1.3 Service Categories for Best Effort ....................... 10 2.1.3 Service Categories for Best Effort ....................... 11
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions .... 12 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions .... 11
2.3 ATM Adaptation Layer ........................................... 13 2.3 ATM Adaptation Layer ........................................... 13
2.4 Broadband Low Layer Information ................................ 13 2.4 Broadband Low Layer Information ................................ 13
2.5 Traffic Descriptors ............................................ 13 2.5 Traffic Descriptors ............................................ 14
2.5.1 Translating Traffic Descriptors for Guaranteed Service ... 14 2.5.1 Translating Traffic Descriptors for Guaranteed Service ... 15
2.5.2 Translating Traffic Descriptors for Controlled Load Service 17 2.5.2 Translating Traffic Descriptors for Controlled Load Service 18
2.5.3 Translating Traffic Descriptors for Best Effort Service ....19 2.5.3 Translating Traffic Descriptors for Best Effort Service ....19
2.6 QoS Classes and Parameters ..................................... 20 2.6 QoS Classes and Parameters ..................................... 19
2.7 Additional Parameters -- Frame Discard Mode .................... 22 2.7 Additional Parameters -- Frame Discard Mode .................... 22
3.0 Additional IP-Integrated Services Protocol Features ................ 22 3.0 Additional IP-Integrated Services Protocol Features ................ 22
3.1 Path Characterization Parameters for IP Integrated Services .... 22 3.1 Path Characterization Parameters for IP Integrated Services .... 22
3.2 Handling of Excess Traffic ..................................... 23 3.2 Handling of Excess Traffic ..................................... 24
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 24 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 25
4.0 Miscellaneous Items ................................................ x
4.1 Units Conversion ............................................... x
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... x
5.1 Encoding GS Using Real-Time VBR ................................ x
5.2 Encoding GS Using CBR .......................................... x
5.3 Encoding GS Using Non-Real-Time VBR ............................ x
5.4 Encoding GS Using ABR .......................................... x
5.5 Encoding GS Using UBR .......................................... x
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... x
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... x
6.1 Encoding CLS Using ABR ......................................... x
6.2 Encoding CLS Using Non-Real-Time VBR ........................... x
6.3 Encoding CLS Using Real-Time VBR ............................... x
6.4 Encoding CLS Using CBR ......................................... x
6.5 Encoding CLS Using UBR ......................................... x
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ x
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... x 4.0 Miscellaneous Items ................................................ 26
7.1 Encoding Best Effort Service Using UBR ......................... x 4.1 Units Conversion ............................................... 26
8.0 Acknowledgements ................................................... x 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28
5.1 Encoding GS Using Real-Time VBR ................................ 28
5.2 Encoding GS Using CBR .......................................... 30
5.3 Encoding GS Using Non-Real-Time VBR ............................ 31
5.4 Encoding GS Using ABR .......................................... 31
5.5 Encoding GS Using UBR .......................................... 31
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 32
Appendix 1 Abbreviations .............................................. x 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 33
References ............................................................. x 6.1 Encoding CLS Using ABR ......................................... 34
Authors' Addresses ..................................................... x 6.2 Encoding CLS Using Non-Real-Time VBR ........................... 35
6.3 Encoding CLS Using Real-Time VBR ............................... 36
6.4 Encoding CLS Using CBR ......................................... 37
6.5 Encoding CLS Using UBR ......................................... 37
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 37
0.0 What's New in This Version 7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 38
7.1 Encoding Best Effort Service Using UBR ......................... 39
8.0 Security ........................................................... 39
9.0 Acknowledgements ................................................... 39
New sections on path characterization parameters (Section 3.1), and Appendix 1 Abbreviations .............................................. 40
on handling of excess traffic (Section 3.2) have been added. The References ............................................................. 41
sections on translating traffic descriptors (Section 2.5) and QoS Authors' Addresses ..................................................... 43
paremeters (Section 2.6) have been substantially revised. Minor
improvements were made in the mapping tables in Sections 5, 6, 7.
1.0 Introduction 1.0 Introduction
We consider the problem of providing IP Integrated Services [1] with We consider the problem of providing IP Integrated Services [1] 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 [2] for IP-level resource reservation, although it the rsvp protocol [2] for IP-level resource reservation, although it
is, strictly speaking, independent of rsvp, since GS and CLS services applies also in the general case where GS and CLS services are
can be supported through other mechanisms. In the ATM network, we supported through other mechanisms. In the ATM network, we consider
consider ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, 5]. The
5]. The latter uses the more complete service model of the ATM latter uses the more complete service model of the ATM Forum's TM 4.0
Forum's TM 4.0 specification [6, 7]. specification [6, 7].
This is a complex problem. In this document, we focus on the service This is a complex problem. In this document, we focus on the service
types, parameters and signalling elements needed for service types, parameters and signalling elements needed for service
interoperation. The resulting service mappings can be used to interoperation. The resulting service mappings can be used to
provide effective end-to-end Quality of Service (QoS) for IP traffic provide effective end-to-end Quality of Service (QoS) for IP traffic
that traverses ATM networks. that traverses ATM networks.
The IP services considered are Guaranteed Service (GS) [8] and The IP services considered are Guaranteed Service (GS) [8] and
Controlled Load Service (CLS) [9]. We also treat the default Best Controlled Load Service (CLS) [9]. 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 [10], and its revision BE are intended to be consistent with RFC 1755 [10], and its revision
(in progress) [11], which defines how ATM VCs can be used in support [11], which define how ATM VCs can be used in support of normal BE IP
of normal BE IP service. The ATM services we consider are: service. 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.0 and 3.1 signalling, where these service are
not all clearly distinguishable, we identify the appropriate
available services.
The service mappings which follow most naturally from the service In the case of UNI 3.x signalling, where these service are not all
definitions are as follows: clearly distinguishable, we identify the appropriate available
services.
We recommend the following service mappings, since they follow most
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 cell rate)
Best Effort -> UBR or ABR Best Effort -> UBR or ABR
For completeness, however, we provide detailed mappings for all
For completeness we provide detailed mappings for all service service combinations in Sections 5, 6, 7 and identify how each meets
combinations in Sections 5, 6, 7) and identify how each meets or or fails to meet the requirements of the higher level IP services.
fails to meet the requirements of the higher level IP services. The The reason for not restricting mappings to the most obvious or
reason for not restricting mappings to the most obvious or natural natural ones is that we cannot predict how widely available all of
ones is that we cannot predict how widely available all of these these services will be as ATM deployment evolves. A number of
services will be as ATM deployment evolves. A number of details, differences in service definitions, such as the treatment of packets
such as the difference in service definitions and the treatment of in excess of the flow traffic descriptor, make service mapping a
packets in excess of the flow traffic descriptor, make service relatively complicated subject.
mapping a relatively complicated subject.
The remainder of this introduction provides a general discussion of The remainder of this introduction provides a general discussion of
the system configuration and other assumptions. Section 2 considers the system configuration and other assumptions. Section 2 considers
the relevant ATM protocol elements and their effects as related to the relevant ATM protocol elements and the corresponding features of
Guaranteed, Controlled Load and Best Effort services (the latter Guaranteed, Controlled Load and Best Effort services (the latter
being the default "service"). This section discusses features of the being the default "service"). Section 3 discusses a number of
IP services as well; we chose to organize the main discussion by ATM remaining features of the IP services and how they can be handled on
features only because ATM is more complex in structure. Section 3 an ATM subnetwork. Section 4 addresses the conversion of traffic
discusses a number of remaining features of the IP services and how descriptors to account for ATM-layer overheads. Section 5 gives the
they can be handled on an ATM subnetwork. Section 4 addresses an detailed VC setup parameters for Guaranteed Service, and considers
issue (units conversion) that is neither distinctly IP nor ATM. the effect of using each of the ATM service categories. Section 6
Section 5 gives the detailed VC setup parameters for Guaranteed provides a similar treatment for Controlled Load Service. Section 7
Service, and considers the effect of using each of the ATM service considers Best Effort service.
categories. Section 6 provides a similar treatment for Controlled
Load Service. Section 7 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 [12,18,19]. We do not consider how routing, QoS considered in [12,13,14]. We do not consider how routing, QoS
sensitive or not, interacts with the use of VCs. We expect that a sensitive or not, interacts with the use of ATM VCs. We expect that
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
illustrated in Figure 1. An IP-attached host may send unicast illustrated in Figure 1. An IP-attached host may send unicast
datagrams to another host, or may use an IP multicast address to send datagrams to another host, or may use an IP multicast address to send
skipping to change at page 5, line 44 skipping to change at page 5, line 28
Figure 1: Network Architecture with Hosts (H), Figure 1: Network Architecture with Hosts (H),
Routers (R) and Edge Devices (E). Routers (R) and Edge Devices (E).
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 signaled 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.
The service mapping function occurs when an IP-level reservation The service mapping function occurs when an IP-level reservation
(RESV message) triggers the edge device to translate the RSVP service (RESV message) triggers the edge device to translate the RSVP service
requirements into ATM VC (UNI) semantics. requirements into ATM VC (UNI) semantics.
A range of VC management policies are possible, which determine A range of VC management policies are possible, which determine
whether a flow should initiate a new VC or join an existing one. VCs whether a flow should initiate a new VC or join an existing one. VCs
are managed according to a combination of standards and local policy are 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. Note, the topic of VC management (LIJ) feature in ATM may be used. The topic of VC management is
and mapping of flows onto VCs is considered at length in other issll considered at length in other ISSLL working group drafts [12,13,14].
working group drafts [12,18,19].
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. (Note: for expositional and segregating the control and data planes.
convenience, policy control and other control functions are included
as part of the admission control in the diagram.)
IP ATM IP ATM
____________________ ____________________
| IWF | | IWF |
| | | |
admission <--> | service mapping | <--> ATM admission and <--> | service mapping | <--> ATM
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 required of both the are shown separately, since these functions are required of 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.
It is not possible to completely separate the service mapping and VC The service mapping and VC management functions can be highly
management functions. Several illustrative examples come to mind: interdependent. For example: (i) Multiple integrated-services flows
(i) Multiple integrated-services flows may be aggregated to use one may be aggregated to use one point-to-multipoint VC. In this case,
point-to-multipoint VC. In this case, we assume the IP flows are of we assume the IP flows are of the same service type and their
the same service type and their parameters have been merged parameters have been merged appropriately. (ii) The VC management
appropriately. (ii) The VC management function may choose to function may choose to allocate extra resources in anticipation of
allocate extra resources in anticipation of further reservations or further reservations or based on an empiric of changing TSpecs.
based on an empiric of changing TSpecs. (iii) There must exist a (iii) There must exist a path for best effort flows and for sending
path for best effort flows and for sending the rsvp control messages. the rsvp control messages. How this interacts with the establishment
How this interacts with the establishment of VCs for QoS traffic may of VCs for QoS traffic may alter the characteristics required of
alter the characteristics required of those VCs. See [12,18,19] for those VCs. See [12,13,14] for further details on VC management.
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, whether the resulting action uses new or existing VCs. parameters as if a new VC were to be created for this service. The
VC management function can then use this information consistent with
its own policy, which determines whether the resulting action uses
new or existing VCs.
1.2 Related Documents 1.2 Related Documents
Earlier ATM Forum documents were called UNI 3.0 and UNI 3.1. The 3.1 Earlier ATM Forum documents combined signaling, traffic management
release was used to correct errors and fix alignment with the ITU. and other areas into a single document, e.g., UNI 3.0 [3] and UNI 3.1
Unfortunately UNI 3.0 and 3.1 are incompatible. However this is in [4]. The 3.1 release was used to correct errors and fix alignment
terms of actual codepoints, not semantics. Therefore, descriptions with the ITU. While UNI 3.0 and 3.1 are incompatible in terms of
of parameter values can generally be used for both. actual codepoints, the semantics are generally the same. Therefore,
we will often refer to UNI 3.x to mean either version of the ATM
protocol.
After 3.1, the ATM Forum began to release documents separately for After 3.1, the ATM Forum released documents separately for each
each technical working group. The Traffic Management and Signalling technical working group. The UNI Signalling 4.0 [5] and Traffic
4.0 documents are available publically at ftp.atmforum.com/pub. We Management 4.0 [6] documents represent a consistent overall ATM
refer to the combination of traffic management and signalling as protocol, and we will sometime refer to the combination as TM/UNI
TM/UNI 4.0, although specific references may be made to the TM 4.0 4.0.
specification or the UNI Signalling 4.0 specification.
Within the IETF, related material includes the work of the rsvp [2], Within the IETF, related material includes the work of the rsvp [2],
int-serv [1, 8, 9, 13, 14] and ion working groups [10, 11]. Rsvp int-serv [1, 8, 9, 15, 16] and ion working groups [10, 11]. Rsvp
defines the resource reservation protocol (which is analogous to defines the resource reservation protocol (which is analogous to
signalling in ATM). Int-serv defines the behavior and semantics of signalling in ATM). Int-serv defines the behavior and semantics of
particular services (analogous e.g., to the Traffic Management particular services (analogous to the Traffic Management working
working group in the ATM Forum). Ion defines interworking of IP and group in the ATM Forum). Ion defines interworking of IP and ATM for
ATM for traditional Best Effort service, and covers issues related to traditional Best Effort service, and generally covers issues related
routing and addressing. to IP/ATM routing and addressing.
A large number of ATM signalling details are covered in RFC 1755 A large number of ATM signalling details are covered in RFC 1755
[10], e.g., differences between UNI 3.0 and UNI 3.1, encapsulation, [10]; e.g., differences between UNI 3.0 and UNI 3.1, encapsulation,
frame-relay interworking, etc. These considerations generally extend frame-relay interworking, etc. These considerations extend to IP
to IP over ATM with QoS as well. Any description given in this over ATM with QoS as well. The description given in this document of
document of IP Best Effort service (i.e. the default behavior) over IP Best Effort service (i.e. the default behavior) over ATM is
ATM is intended to be consistent with RFC 1755 and it's extension for intended to be consistent with RFC 1755 and it's extension for UNI
UNI 4.0 [11], and those documents are to be considered definitive. 4.0 [11], and those documents are to be considered definitive. For
In some instances with non-best-effort services, certain IP/ATM non-best-effort services, certain IP/ATM features will diverge from
features will diverge from the following RFC 1755. The authors have the following RFC 1755. We have attempted to note such differences
attempted to note such differences explicitly. (For example, best explicitly. (For example, best effort VCs may be taken down on
effort VCs are taken down on timeout by either edge device, while QoS timeout by either edge device, while QoS VCs are only removed by the
VCs are only removed by the upstream edge device when the upstream edge device when the corresponding rsvp reservation is
corresponding rsvp reservation is deleted.) deleted.)
RFC 1821 [15], represents an early discussion of issues involved with Another related document is RFC 1821 [17], which represents an early
interoperating IP and ATM protocols for integrated services and QoS. discussion of issues involved with interoperating IP and ATM
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
In this section, we discuss each of the items that must be specified
in the setup of an ATM VC. For each of these we discuss which
specified items and values may be most appropriate for each of the
three integrated services.
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
We discuss each of these as they relate to the translation of GS and In this section, we discuss each of these items as they relate to
CLS to ATM services. We do not discuss addressing at all, since it creating ATM VCs suitable for GS, CLS and BE services. We do not
is (at least presently) independent of QoS. Following the section on discuss routing and addressing at all, since they are (at least
service categories, we discuss tagging and conformance definitions presently) independent of QoS. Following the section on service
for IP and ATM. These do not appear explicitly as set-up parameters categories, we discuss tagging and conformance definitions for IP and
since the policing method used is implicit in the call setup. ATM. These do not appear explicitly as set-up parameters in the
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
The highest level of abstraction distinguishing features of ATM VCs The highest level of abstraction distinguishing features of ATM VCs
is in the service category or bearer capability. Service categories is in the service category or bearer capability. Service categories
were introduced in TM/UNI 4.0; previously the bearer capability was were introduced in TM/UNI 4.0; previously the bearer capability was
used to discriminate at this level. used to discriminate at this level.
These parameters indicate the general properties required of a VC: These elements indicate the general properties required of a VC:
whether there is a real-time delay constraint, whether the traffic is whether there is a real-time delay constraint, whether the traffic is
constant or variable rate, the applicable traffic and QoS description constant or variable rate, the applicable traffic and QoS description
parameters and (implicitly) the complexity of some supporting switch parameters and (implicitly) the complexity of some supporting switch
mechanisms. mechanisms (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
skipping to change at page 9, line 32 skipping to change at page 9, line 17
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, except perhaps in name, through the exists in all specifications, although it is called "best effort" in
"best effort" indication flag and/or the use of QoS Class 0. UNI 3.x. In either case it is indicated by the "best effort"
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
referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for
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" with specified bandwidth/timing. However, it may be having a "pipe" of a specified bandwidth. However, it may be
desirable to make better use of the ATM network's resources by using significantly more efficient to use the other ATM services where
other, less demanding, services when available. (See RFC 1821 for a applicable and available [17].
discussion of this [15].)
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
GS requires real-time support. Thus in UNI 3.x, the bearer class GS requires real-time support. Thus in UNI 3.x, the bearer class
BCOB-A (or an equivalent BCOB-X formulation) must be used. In TM/UNI 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 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
skipping to change at page 10, line 22 skipping to change at page 10, line 11
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
matches for the GS service. These provide no delay estimates and matches for the GS service. These provide no delay estimates and
cannot guarantee consistently low delay for every packet. cannot guarantee consistently low delay for every packet.
Specification of BCOB-A or CBR requires specification of a peak cell Specification of BCOB-A or CBR requires specification of a peak cell
rate (PCR). In these cases, PCR is the nominal clearing rate with rate (PCR). In these cases, PCR is the nominal clearing rate with a
jitter toleration (bucket size) CDVT, which is generally small. nominal jitter toleration (bucket size), CDVT.
Specification of rtVBR requires two rates, PCR and SCR. This models Specification of rtVBR requires two rates, PCR and SCR. This models
bursty traffic with specified peak and sustainable rates. The bursty traffic with specified peak and sustainable rates. The
corresponding ATM token bucket depth values are CDVT, and CDVT+BT, corresponding ATM token bucket depth values are CDVT, and CDVT+BT,
respectively. 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)
ABR ABR
nrtVBR (BCOB-C) nrtVBR (BCOB-C)
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, this will 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
provides for allocation of bandwidth and buffers with an additional provides for allocation of bandwidth and buffers with an additional
peak rate indication, similar to the CLS TSpec. peak rate indication, similar to the CLS TSpec.
The ABR category with a positive MCR aligns with the CLS idea of The ABR category with a positive MCR aligns with the CLS idea of
"best effort with a floor." The ATM network agrees to forward cells "best effort with a floor." The ATM network agrees to forward cells
with a rate of at least MCR, which should be directly converted from with a rate of at least MCR, which should be directly converted from
the token bucket rate of the receiver TSpec. The bucket size the token bucket rate of the receiver TSpec. The bucket size
parameter measures approximately the amount of buffer required at the parameter measures approximately the amount of buffer required at the
IWF. This buffer serves to absorb the bursts allowed by the token IWF. This buffer serves to absorb the bursts allowed by the token
bucket, since they cannot be passed directly into a ABR VC. bucket, since they cannot be passed directly into an ABR VC.
The rtVBR category can be used, although the edge device must The rtVBR category can be used, although the edge device must
determine a value 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, which Load. The point of CLS is to allow an allocation of resources. This
is facilitated by the token bucket traffic descriptor, and 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). A CBR 3.x, BCOB-C or BCOB-X, with the best effort indication set). CBR or
or rtVBR clearly could be used, and since the service is not real- rtVBR clearly could be used, and since the service is not real-time,
time, a nrtVBR connection could also be used. In these cases the a nrtVBR connection could also be used. In these cases the rate
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
is the default IP behavior, the individual flows are not necessarily is the default IP behavior, the individual flows are not normally
identified or accounted for. CBR may be a preferred solution in the identified or accounted for. CBR may be a preferred solution in the
case where best effort traffic is sufficiently highly aggregated that case where best effort traffic is sufficiently highly aggregated that
a simple fixed-rate pipe is efficient. Both CBR and nrt-VBR provide a simple fixed-rate pipe is efficient. Both CBR and nrt-VBR provide
bandwidth allocation which may be useful for billing purposes. explicit bandwidth allocation which may be useful for billing
purposes.
An ABR connection could similarly be used to support Best Effort An ABR connection could similarly be used to support Best Effort
traffic. Indeed, the support of data communications protocols such traffic. Indeed, the support of data communications protocols such
as TCP/IP is the explicit purpose for which ABR was designed. It is as TCP/IP is the explicit purpose for which ABR was designed. It is
conceivable that a separate ABR connection would be made for conceivable that a separate ABR connection would be made for each IP
different IP flows, although the normal case would probably have all flow, although the normal case would probably have all IP Best Effort
IP Best Effort traffic with a common egress router sharing a single traffic with a common egress router sharing a single ABR connection.
ABR connection.
The rt-VBR service category may be considered less suitable, simply The rt-VBR service category may be considered less suitable, simply
because both the real-time delay constraint and the use of SCR/BT add because both the real-time delay constraint and the use of SCR/BT add
unnecessary complexity. unnecessary complexity.
See specifications from the IETF ion working group [10, 11] for See specifications from the IETF ion working group [10, 11] for
related work on support of Best Effort service with ATM. related work on support of Best Effort service with ATM.
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions 2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions
skipping to change at page 12, line 43 skipping to change at page 12, line 31
treated as "best effort" in the sense that they are transported when treated as "best effort" in the sense that they are transported when
bandwidth is available, queued when buffers are available, and bandwidth is available, queued when buffers are available, and
dropped when resources are overcommitted. ATM standards, however, do dropped when resources are overcommitted. ATM standards, however, do
not explicitly specify treatment of tagged traffic. Providers of GS not explicitly specify treatment of tagged traffic. Providers of GS
and CLS service with ATM subnetworks should ascertain the actual and CLS service with ATM subnetworks should ascertain the actual
behavior of ATM implementation with respect to tagged cells. behavior of ATM implementation with respect to tagged cells.
Since GS and CLS services require excess traffic to be treated as Since GS and CLS services require excess traffic to be treated as
best effort, the tagging option should always be chosen (if best effort, the tagging option should always be chosen (if
supported) in the VC setup as a means of "downgrading" the cells supported) in the VC setup as a means of "downgrading" the cells
comprising non-conformant packets. However, the term "best effort" comprising non-conformant packets. The term "best effort" can be
can be interpreted in two distinct ways. The first is as a service interpreted in two ways. The first is as a service class that, for
class that, in some typical scheduler implementations, would example, may be implemented as a separate queue. The other sense is
correspond to a separate queue. Placing excess traffic in best more generic, meaning that the network makes a best effort to
effort in this sense would be giving it lower delay priority. The transport the traffic. A reasonable interpretation of this is that a
other sense is more generic, meaning that the network would make a network with no contending traffic would transport the packet, while
best effort to transport the traffic. A reasonable expectation is a very congested network would drop the packet. A mechanism that
that a network with no contending traffic would transport the packet, tags best effort packets with lower loss priority (such as with the
while a very congested network would drop the packet. A packet that ATM CLP bit) would drop some of these packets, but would not reorder
could be tagged with lower loss priority (such as with the ATM CLP the remaining ones with respect to the conforming portion of the
bit) would be more likely to be dropped, but would not be reordered flow. The "best effort" mechanism for excess traffic does not
with respect to the conforming portion of the flow. Such a mechanism necessarily have to be the same as that for best effort "service", as
would agree with the latter definition of best effort, but not the long as it fits this generic sense of best effort.
former. This interpretation is left to the implementation.
There are three conformance definitions of VBR service (for both There are three conformance definitions of VBR service (for both
rtVBR and nrtVBR) to consider. In VBR, only the conformance rtVBR and nrtVBR) to consider. In VBR, only the conformance
definition VBR.3 supports tagging and applies the GCRA with rate PCR definition VBR.3 supports tagging and applies the GCRA with rate PCR
to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the
CLP=0 cells. This conformance definition should always be used with CLP=0 cells. This conformance definition should always be used with
a VBR service supporting IP integrated services. For UBR service, a VBR service supporting IP integrated services. For UBR service,
conformance definition UBR.2 supports the use of tagging, but a CLP=1 conformance definition UBR.2 supports the use of tagging, but a CLP=1
cell does not imply non-conformance; rather, it may be used to cell does not imply non-conformance; rather, it may be used to
indicate network congestion. indicate network congestion.
skipping to change at page 14, line 10 skipping to change at page 13, line 41
maximum SDU in each direction for unicast connections, and for maximum SDU in each direction for unicast connections, and for
unidirectional point-to-multipoint connections. When multiple flows unidirectional point-to-multipoint connections. When multiple flows
are aggregated into a single VC, the M parameters of the receiver are aggregated into a single VC, the M parameters of the receiver
TSpecs are merged according to rules given in the GS and CLS specs. TSpecs are merged according to rules given in the GS and CLS specs.
2.4 Broadband Low Layer Information 2.4 Broadband Low Layer Information
The B-LLI Information Element is transferred transparently by the ATM The B-LLI Information Element is transferred transparently by the ATM
network between the edge devices and is used to specify the network between the edge devices and is used to specify the
encapsulation method. Multiple B-LLI IEs may be sent as part of encapsulation method. Multiple B-LLI IEs may be sent as part of
negotiation. The default encapsulation LLC/SNAP [16] must be negotiation. The default encapsulation LLC/SNAP [18] must be
supported as specified in RFC 1577 [17] and RFC 1755 [10]. See RFC supported as specified in RFC 1577 [19] and RFC 1755 [10]. See RFC
1755 for information on additional encapsulations. 1755 for information on additional encapsulations.
2.5 Traffic Descriptors 2.5 Traffic Descriptors
The ATM traffic descriptor always contains a peak cell rate (PCR) The ATM traffic descriptor always contains a peak cell rate (PCR)
(for each direction). For variable rate services it also contains a (for each direction). For variable rate services it also contains a
sustainable cell rate (SCR) and maximum burst size (MBS). The SCR sustainable cell rate (SCR) and maximum burst size (MBS). The SCR
and MBS form a leaky bucket pair (rate, depth), while the bucket and MBS form a leaky bucket pair (rate, depth), while the bucket
depth parameter for PCR is CDVT. Note that CDVT is not signaled depth parameter for PCR is CDVT. Note that CDVT is not signalled
explicitly, but is determined by the network operator, and serves as explicitly, but is determined by the network operator, and serves as
a measure of the jitter imposed by the network. a measure of the jitter imposed by the network.
Since CDVT is generally presumed to be small (equivalent to a few Since CDVT is generally presumed to be small (equivalent to a few
cells of token bucket depth), and cannot be set independently for cells of token bucket depth), and cannot be set independently for
each connection, it cannot be used to account for the burstiness each connection, it cannot be used to account for the burstiness
permitted by b of the IP-layer TSpec. Additional buffering is needed permitted by b of the IP-layer TSpec. Additional buffering is needed
at the IWF to account for the depth of the token bucket. at the IWF to account for the depth of the token bucket.
The ATM Burst Tolerance (BT) is equivalent to MBS (see TM 4.0 [6] for The ATM Burst Tolerance (BT) is equivalent to MBS (see TM 4.0 [6] for
skipping to change at page 15, line 14 skipping to change at page 14, line 51
the intermediate switches along the path may reduce the requested PCR the intermediate switches along the path may reduce the requested PCR
to a "comfortable" level. This choice is part of admission control, to a "comfortable" level. This choice is part of admission control,
and is therefore implementation dependent. If at any point the and is therefore implementation dependent. If at any point the
requested PCR falls below the minimal PCR then the call is cleared. requested PCR falls below the minimal PCR then the call is cleared.
Minimal Traffic Descriptors can be used to present an acceptable Minimal Traffic Descriptors can be used to present an acceptable
range for parameters and ensure a higher likelihood of call range for parameters and ensure a higher likelihood of call
admission. In general, our discussion of connection parameters admission. In general, our discussion of connection parameters
assumes the values resulting from successful connection setup. assumes the values 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
are also part of the signaled information element (IE) containing the are also part of the signalled information element (IE) containing
traffic descriptor. In the UNI 4.0 traffic descriptor IE there is an the traffic descriptor. In the UNI 4.0 traffic descriptor IE there
additional parameter, the Frame Discard indicator, which is discussed is an additional parameter, the Frame Discard indicator, which is
below in Section 2.7. 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
will always be merged appropriately before being mapping into ATM will always be merged appropriately before being mapping into ATM
parameters. parameters.
Note that when the sender and receiver TSpec rates r_s, r_r differ, Note that when the sender and receiver TSpec rates r_s, r_r differ,
there is no mechanism specified (in either rsvp or the int-serv there is no mechanism specified (in either rsvp or the int-serv
specs) for indicating which subset of the traffic is to be specs) for indicating which subset of the traffic is to be
transported. Implementation of this feature is therefore completely transported. Implementation of this feature is therefore completely
network specific. Hence the ambiguity in how policing and scheduling network specific. Hence the ambiguity in how policing and scheduling
use the two rates is an inherent and currently unresolved issue in use the two rates is an inherent and currently unresolved issue in
IP-IS technology. IP-IS technology.
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 the allocated service bandwidth (or (which cannot be smaller) is the allocated service bandwidth (or
strictly speaking, a lower bound on this). A receiver increases R strictly speaking, a lower bound on this). A receiver increases R
over r_r to reduce the delay. over r_r to 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 often be set cannonically descriptor parameters (PCR, SCR, MBS) can often be set cannonically
as: 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 so much to set hard The following discussion is not intended so much to set hard
requirements, but to provide some interpretation and guidance on the requirements, but to provide some interpretation and guidance on the
bounds of possible parameter mappings. The ingress edge device bounds of possible parameter mappings. The ingress edge device
generally includes a buffer preceeding the ATM network interface. generally includes a buffer preceding the ATM network interface.
This buffer can be used to absorb bursts that fall within the IP- This buffer can be used to absorb bursts that fall within the IP-
level TSpec, but not within the ATM traffic descriptor. The minimal level TSpec, but not within the ATM traffic descriptor. The minimal
requirement for guaranteed service is that the delay in this buffer requirement for guaranteed service is that the delay in this buffer
may not exceed b/R, and the delays within the ATM network must be may not exceed b/R, and the delays within the ATM network must be
accurately accounted for in the values of Adspec parameters C and D accurately accounted for in the values of Adspec parameters C and D
advertised by the ingress router (see Section 3.3 below). advertised by the ingress router (see Section 3.3 below).
In general, if either an edge device buffer of size b_r exists or the In general, 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 ATM maximum burst size (MBS) parameter is at least b_r, then the
various rate parameters will generally exhibit the following various rate parameters will generally exhibit the following
skipping to change at page 17, line 30 skipping to change at page 17, line 18
+ D_TOT. To effectively allocate bandwidth R to the flow, we set SCR + D_TOT. To effectively allocate bandwidth R to the flow, we set SCR
to match R. (Note it is unnecessary in any case to set SCR above R, to match R. (Note it is unnecessary in any case to set SCR above R,
so the relation, SCR <= R, is still true.) It is possible to set SCR so the relation, SCR <= R, is still true.) It is possible to set SCR
to a value as low as r_r, without violating the delay bounds or to a value as low as r_r, without violating the delay bounds or
overflowing the edge device buffer. With PCR = R, a burst of size b overflowing the edge device buffer. With PCR = R, a burst of size b
will be buffered and sent into the ATM network at rate R, so the last will be buffered and sent into the ATM network at rate R, so the last
byte suffers delay only b/R. Any further traffic will be limited to byte suffers delay only b/R. Any further traffic will be limited to
rate r_r, which is SCR, so with the arriving and departing rates rate r_r, which is SCR, so with the arriving and departing rates
matched, its delay will also be no more than b/R. matched, its delay will also be no more than b/R.
While this scenerio meets the GS service requirements, the penalty While this scenario meets the GS service requirements, the penalty
for allocating SCR = r_r rather than R is that the delay in the ATM for allocating SCR = r_r rather than R is that the delay in the ATM
network will have a component of MBS/SCR, which will be b/r rather network will have a component of MBS/SCR, which will be b/r rather
than b/R, contained in the D term advertised for the ATM sub-network than b/R, contained in the D term advertised for the ATM sub-network
(see further discussion in Section 3.3 below). It is also true that (see further discussion in Section 3.3 below). It is also true that
allocating r instead of R in a portion of the path is rather against allocating r instead of R in a portion of the path is rather against
the spirit of GS. As mentioned above, this mapping may however be the spirit of GS. As mentioned above, this mapping may however be
useful in practice in the case where pricing in the ATM network leads useful in practice in the case where pricing in the ATM network leads
to different incentives in the tradeoff between delay and bandwidth to different incentives in the tradeoff between delay and bandwidth
than those of the user who buys IP integrated services. than those of the user who buys IP integrated services.
Another point of view on parameter mapping suggests that SCR should Another point of view on parameter mapping suggests that SCR should
merely reflect the traffic description, hence SCR = r_r, while the merely reflect the traffic description, hence SCR = r_r, while the
service requirement is expressed in the QoS parameter as CDV = b/R. service requirement is expressed in the QoS parameter as CDV = b/R.
Thus the ATM network may internally allocate bandwidth R, but it is Thus the ATM network may internally allocate bandwidth R, but it is
free to use other methods as well to achieve the delay constraint. free to use other methods as well to achieve the delay constraint.
Mechanisms such as statistical flow/connection aggregation may be Mechanisms such as statistical flow/connection aggregation may be
implemented in the ATM network and hidden from the user (or parameter implemented in the ATM network and hidden from the user (or parameter
mapping module in the edge router) which sees only the interface mapping module in the edge router) which sees only the interface
implemented in the signaled parameters. implemented in the signalled parameters.
Note that this discussion considers an edge device buffer size of Note that this discussion considers an edge device buffer size of
b_r. In practice, it may be necessary for the AAL/segmentation b_r. In practice, it may be necessary for the AAL/segmentation
module to buffer M bytes in converting packets to cells. Also an module to buffer M bytes in converting packets to cells. Also an
additional amount of buffer equal to C_sum + R D_sum is generally additional amount of buffer equal to C_sum + R D_sum is generally
necessary to absorb jitter imposed by the upstream network [8]. necessary to absorb jitter imposed by the upstream network [8].
With ATM, it is possible to have little or no buffer in the edge With ATM, it is possible to have little or no buffer in the edge
router, because the ATM VC can be set to accept bursts at peak rate. router, because the ATM VC can be set to accept bursts at peak rate.
This may be unusual, since the edge router normally has enough buffer This may be unusual, since the edge router normally has enough buffer
skipping to change at page 18, line 35 skipping to change at page 18, line 24
their buffering designs that IP-level users typically specify much their buffering designs that IP-level users typically specify much
larger burst parameters than can be handled in the ATM subnet. larger burst parameters than can be handled in the ATM subnet.
Peak-rate bandwidth allocation provides a means to work around this Peak-rate bandwidth allocation provides a means to work around this
problem. It is also true that intermediate tradeoffs can be problem. It is also true that intermediate tradeoffs can be
formulated, where the burst-absorbing buffer is less than b bytes, formulated, where the burst-absorbing buffer is less than b bytes,
and SCR is set above R and below p_r. Note that jitter-absorbing and SCR is set above R and below p_r. Note that jitter-absorbing
buffers (C_sum + R D_sum) can not be avoided, generally, by buffers (C_sum + R D_sum) can not be avoided, generally, by
increasing ATM rates, unless SCR is set to exceed the physical line increasing ATM rates, unless SCR is set to exceed the physical line
rate(s) into the edge device for the flow. rate(s) into the edge device 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. With little or no burst if the edge device has a buffer of size b_r. With little or no burst
buffering, the requirements resemble the zero-buffer case above, and buffering, the requirements resemble the zero-buffer case above, and
we have PCR = max (R, p_r). Additional buffers sufficient to absorb we have PCR = max (R, p_r). Additional buffers sufficient to absorb
network jitter, given by C_sum, D_sum, must always be provided in the network jitter, given by C_sum, D_sum, must always be provided in the
edge router, or in the ATM network via MBS. edge router, or in the ATM network via 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 preceeding section on using edge device The discussions in the preceding section on using edge device buffers
buffers to reduce PCR, increasing buffers to reduce PCR and trading to reduce PCR, increasing buffers to reduce PCR and trading off
off between such buffers and MBS, apply generally to the CLS over between such buffers and MBS, apply generally to the CLS over nrtVBR
nrtVBR case as well. Extra buffers to accommodate jitter accumulated case as well. Extra buffers to accommodate jitter accumulated
(beyond the b_r burst size allowed at the source) must be provided. (beyond the b_r burst size allowed at the source) must be provided.
For CLS, there are no Adspec parameters C and D, so the estimation of For CLS, there are no Adspec parameters C and D, so the estimation of
such buffers is an implementation design issue. such 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
depth parameter, the edge device must have a buffer of at least b_r depth parameter, the edge device must have a buffer of at least b_r
bytes. Since the actual transfer rate can vary substantially with bytes. Since the actual transfer rate can vary substantially with
ABR, the buffering should not be made so large that the, in an ABR, the buffering should not be made so large that the, in an
attempt to avoid loss, that delays exceed higher-layer timeouts, attempt to avoid loss, that delays exceed higher-layer timeouts,
skipping to change at page 21, line 42 skipping to change at page 21, line 30
set up, the delay-related QoS parameters are given by set up, the delay-related QoS parameters are given by
CDV = D_ATM CDV = D_ATM
CTD = D_ATM + MPL. CTD = D_ATM + MPL.
(CDV and CTD may be increased by the slack term in GS, see Section (CDV and CTD may be increased by the slack term in GS, see Section
3.3 below.) For rtVBR, the value of CDV will generally have a 3.3 below.) For rtVBR, the value of CDV will generally have a
component of MBS/SCR analogous to the b/R term in the delay of GS component of MBS/SCR analogous to the b/R term in the delay of GS
service. It may have other components that depend on the ATM switch service. It may have other components that depend on the ATM switch
implementation. In cases where the ATM network uses statistical implementation. In cases where the ATM network uses statistical
resouce allocation methods, it may be possible to establish VCs with resource allocation methods, it may be possible to establish VCs with
CDV less than MBS/SCR. This capability should be reflected in the CDV less than MBS/SCR. This capability should be reflected in the
D_ATM values advertised in GS and used to determine CDV in for VCs D_ATM values advertised in GS and used to determine CDV in for VCs
supporting both GS and CLS. supporting both GS and CLS.
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 case where SCR = R components of b/R instead of one. Consider the case where SCR = R
and MBS = b. Parekh's theory, which is the basis of the GS delay and MBS = b. Parekh's theory, which is the basis of the GS delay
formula [8] states that the b/R delay term occurs only once, because formula [8] states that the b/R delay term occurs only once, because
once a burst of size b has been served by a congested node at rate R, once a burst of size b has been served by a congested node at rate R,
skipping to change at page 23, line 38 skipping to change at page 23, line 25
policy limitation on the value of PCR, below the physical link policy limitation on the value of PCR, below the physical link
bottleneck. In this case, the advertised value of APB (in general bottleneck. In this case, the advertised value of APB (in general
and for each service if different) should reflect this limit, since and for each service if different) should reflect this limit, since
excess traffic beyond this rate will be dropped. (Note that there is excess traffic beyond this rate will be dropped. (Note that there is
no tagging of traffic in excess of PCR for TM/UNI 4.0.) These values no tagging of traffic in excess of PCR for TM/UNI 4.0.) These values
should generally be cached by the ingress router for the set of should generally be cached by the ingress router for the set of
egress routers that it typically needs to establish VCs to. The egress routers that it typically needs to establish VCs to. The
Adspec parameters <x,6> are only adjusted down, to reflect the Adspec parameters <x,6> are only adjusted down, to reflect the
minimum as the composed value. minimum as the composed value.
In the case of a multipoint VC, the value of several parameters can In the case of a multipoint VC, several parameters can be different
be different for each egress point. In this case, the IWF at the for each egress point. In this case, the IWF at the egress routers
egress routers must correct these values in PATH messages as they must correct these values in PATH messages as they exit the ATM
exit the ATM network. This is the only case where the egress router network. This is the only case where the egress router needs to
needs to operate on rsvp control messages. (A similar correction operate on rsvp control messages. (A similar correction must be
must be implemented for any non-rsvp set-up mechanism). The implemented for any non-rsvp set-up mechanism). The parameters that
parameters that require such correction are specifically the require such correction are specifically the Available Path Bandwidth
Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the (APB), the Minimum Path Latency (MPL), the Path MTU (although for
Path MTU (although for ATM/AAL5 this may typically be constant), and ATM/AAL5 this may typically be constant), and the ATM-specific
the ATM-specific components of the GS Adspec parameters C_ATM and components of the GS Adspec parameters C_ATM and D_ATM.
D_ATM.
The ingress router table must store values for the ATM-network MPL The ingress router table must store values for the ATM-network MPL
<x,7> for the various egress points. The composed values <x,8> are <x,7> for the various egress points. The composed values <x,8> are
formed by addition and forwarded along the path. In the cases where formed by addition and forwarded along the path. In the cases where
ATM routing chooses different paths for VCs to a given egress point, ATM routing chooses different paths for VCs to a given egress point,
depending on the service category, the table will generally reflect depending on the service category, the table will generally reflect
different values for each service. If the ATM network is very large different values for each service. If the ATM network is very large
and complex, it may become difficult to predict the routes that VCs and complex, it may become difficult to predict the routes that VCs
will take once they are set up. This could be a significant source will take once they are set up. This could be a significant source
of misconfiguration, resulting in discrepencies between GS delay of misconfiguration, resulting in discrepancies between GS delay
advertisements and actual results. The RSpec Slack term may be advertisements and actual results. The RSpec Slack term may be
useful in mitigating this problem. useful in mitigating this problem.
AAL 5 will support any message size up to 65,535 bytes, so setting AAL 5 will support any message size up to 65,535 bytes, so setting
the AAL SDU to the receiver TSpec M parameter value should generally the AAL SDU to the receiver TSpec M parameter value should generally
not be a issue. In the PATH Adspec, however, the PATH_MTU parameter not be a issue. In the PATH Adspec, however, the PATH_MTU parameter
<x,10> for each service should be set to 9180 bytes, which is the <x,10> for each service should be set to 9180 bytes, which is the
default MTU for AAL 5. default MTU for AAL 5.
3.2 Handling of Excess Traffic 3.2 Handling of Excess Traffic
skipping to change at page 24, line 34 skipping to change at page 24, line 19
(bandwidth, buffers and processing) are available. While excess (bandwidth, buffers and processing) are available. While excess
traffic should be supported on a best effort basis, it should not traffic should be supported on a best effort basis, it should not
interfere with the QoS (delay and loss) of conforming CLS and GS interfere with the QoS (delay and loss) of conforming CLS and GS
traffic, nor with normal service of non-reserved best effort traffic. traffic, nor with normal service of non-reserved best effort traffic.
There are several solutions with ATM: the most attractive is to use a There are several solutions with ATM: the most attractive is to use a
VBR service category (with an appropriate conformance definition) and VBR service category (with an appropriate conformance definition) and
tag excess traffic as low priority using the CLP bit. This avoids tag excess traffic as low priority using the CLP bit. This avoids
reordering of the flow, but requires care in the design of the egress reordering of the flow, but requires care in the design of the egress
router scheduler. To avoid reordering, the excess traffic would be router scheduler. To avoid reordering, the excess traffic would be
queued with confoming traffic. A threshold must be used to ensure queued with conforming traffic. A threshold must be used to ensure
that conforming traffic is not unnecessarily delayed by the excess. that conforming traffic is not unnecessarily delayed by the excess.
Also, for GS, the extra delay that would be incurred due to excess Also, for GS, the extra delay that would be incurred due to excess
traffic below the threshold would have to be accurately reflected in traffic below the threshold would have to be accurately reflected in
the delay advertisement. Note that the egress router should the delay advertisement. Note that the egress router should
uniformly tag all the cells of each non-conforming packet, rather uniformly tag all the cells of each non-conforming packet, rather
than letting the ATM network apply tagging due to ATM-level non- than letting the ATM network apply tagging due to ATM-level non-
conformance. conformance.
There is no requirement in ATM standards that tagged cells, marked There is no requirement in ATM standards that tagged cells, marked
either by the user or by policing, must be transported if possible. either by the user or by policing, must be transported if possible.
skipping to change at page 28, line 33 skipping to change at page 28, line 20
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 differentiating among ATM for Guaranteed Service. The key points differentiating among ATM
choices are that real-time timing is required, that the data flow may choices are that real-time timing is required, that the data flow may
have a variable rate, and that demotion of non-conforming traffic to have a variable rate, and that demotion of non-conforming traffic to
best effort is required to be in agreement with the definition of GS. best effort is required to be in agreement with the definition of GS.
For this reason, we prefer an rtVBR service in which tagging is For this reason, we prefer an rtVBR service in which tagging is
supported. Another good match is to use CBR with special handling of supported. Another good match is to use CBR with special handling of
any non-conforming traffic, usually through another VC, since a CBR any non-conforming traffic, e.g., through another VC, since a CBR VC
VC will not accommodate traffic in excess of PCR. will not accommodate traffic in excess of PCR.
Note, these encodings assume point to multipoint connections, where Note, these encodings assume point to multipoint connections, where
the backward channel is not used. If the IP session is unicast only, the backward channel is not used. If the IP session is unicast only,
then a point-to-point VC may be used and the IWF may make use of the then a point-to-point VC may be used and the IWF may make use of the
backward channel, provided that the QoS parameters are mapped backward channel, provided that the QoS parameters are mapped
consistently for the service provided. consistently for the service provided.
5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0) 5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
AAL AAL
skipping to change at page 33, line 20 skipping to change at page 32, line 50
QoS Class QoS Class
QoS Class Forward 1 QoS Class Forward 1
QoS Class Backward 1 QoS Class Backward 1
QoS Parameters QoS Parameters
Parameters are implied by the QOS Class Parameters are implied by the QOS Class
Note 1: Only included for UNI 3.0. Note 1: Only included for UNI 3.0.
Note 2: See discussion, Section 2.5.1. PCR CLP=0 should be set identical Note 2: See discussion, Section 2.5.1. PCR CLP=0 should be set identical
to PCR CLP=0+1. Although this culd potentially allow a CBR VC to PCR CLP=0+1. Although this could potentially allow a CBR VC
to carry excess traffic as tagged cells, it is not recommended to carry excess traffic as tagged cells, it is not recommended
since it is not supported in UNI 4.0 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 should
be specified. For BE VCs, it can be left unspecified, allowing be specified. For BE VCs, it can be left unspecified, allowing
the VC to be shared by multiple protocols, following RFC 1755. the VC to be shared by multiple protocols, following RFC 1755.
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service
skipping to change at page 35, line 4 skipping to change at page 34, line 33
QoS Parameters Note 5 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, Section 2.5.2. Note 1: See discussion, Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
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 should
be specified. For BE VCs, it can be left unspecified, allowing be specified. For BE VCs, it can be left unspecified, allowing
the VC to be shared by multiple protocols, following RFC 1755. the VC to be shared by multiple protocols, following RFC 1755.
Note 4: Cf ITU I.365 (Oct 1996) for new QoS Class definitions. Note 4: Cf ITU I.365 (Oct 1996) for new QoS Class definitions.
Note 5: See Section 2.6 for the values to be used. Note 5: See Section 2.6 for the values to be used.
Note 6: Discussion of ABR-specific parameters is beyond the scope of Note 6: The ABR-specific parameters are beyond the scope of this document.
this document. These generally depend on local implementation and These generally depend on local implementation and not on values
not on values mapped from IP level service parameters (with the mapped from IP level service parameters (with the exception of MCR).
exception of MCR). See [6, 11] for further information.
6.2 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 6.2 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
AAL AAL
Type 5 Type 5
Forward CPCS-SDU Size parameter M of receiver TSpec Forward CPCS-SDU Size parameter M of receiver TSpec
Backward CPCS-SDU Size parameter M of receiver TSpec Backward CPCS-SDU Size parameter M of receiver TSpec
SSCS Type 0 (Null SSCS) SSCS Type 0 (Null SSCS)
Traffic Descriptor Traffic Descriptor
Forward PCR CLP=0+1 Note 1 Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0 Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 1 Forward SCR CLP=0 Note 1
skipping to change at page 39, line 27 skipping to change at page 39, line 10
Tagging Backward bit 1 (Tagging requested) Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2 Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 10 (Non-real time VBR) Note 3 ATM Transfer Capability 10 (Non-real time VBR) Note 3
Susceptible to Clipping 00 (bit encoding for Not susceptible) Susceptible to Clipping 00 (bit encoding for Not susceptible)
User Plane Configuration 01 (bit encoding for pt-to-mpt) User Plane Configuration 01 (bit encoding for pt-to-mpt)
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) Note 4
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class QoS Class
QoS Class Forward 0 QoS Class Forward 0
QoS Class Backward 0 QoS Class Backward 0
Note 1: See discussion, Section 2.5.3. Note 1: See discussion, Section 2.5.3.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
Note 3: If bearer class C is used, the ATC field must be absent Note 3: If bearer class C is used, the ATC field must be absent
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 should
be specified. For BE VCs, it can be left unspecified, allowing be specified. For BE VCs, it can be left unspecified, allowing
skipping to change at page 41, line 14 skipping to change at page 40, line 51
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 Comment RFC Request for Comment
RSVP Resource Reservation Protocol RSVP Resource Reservation Protocol
Rspec Reservation Specification RSpec Reservation Specification
rtVBR Real-time VBR rtVBR Real-time VBR
SCR Sustained Cell Rate SCR Sustained 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
Sw Switch Sw Switch
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] R. Braden, D. Clark and S. Shenker, "Integrated Services in the [1] R. Braden, D. Clark and S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994. Internet Architecture: an Overview", RFC 1633, June 1994.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, [2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
"Resource ReSerVation Protocol (RSVP) - Version 1 Functional "Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification", Internet Draft, May 1996, <draft-ietf-rsvp- Specification", RFC 2205, September 1997.
spec-12.txt>
[3] The ATM Forum, "ATM User-Network Interface Specification, Ver- [3] The ATM Forum, "ATM User-Network Interface Specification, Ver-
sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993. sion 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.
[4] The ATM Forum, "ATM User-Network Interface Specification, Ver- [4] The ATM Forum, "ATM User-Network Interface Specification, Ver-
sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995. sion 3.1", Prentice Hall, Upper Saddle River NJ, 1995.
[5] The ATM Forum, "ATM User-Network Interface (UNI) Signalling [5] The ATM Forum, "ATM User-Network Interface (UNI) Signalling
Specification, Version 4.0", Prentice Hall, Upper Saddle River Specification, Version 4.0", July 1996. Publication by Prentice
NJ, specification finalized July 1996; expected publication, Hall pending; available at ftp://ftp.atmforum.com/pub/approved-
late 1996; available at ftp://ftp.atmforum.com/pub/approved-
specs/af-sig-0061.000.ps. specs/af-sig-0061.000.ps.
[6] The ATM Forum, "ATM Traffic Management Specification, Version [6] The ATM Forum, "ATM Traffic Management Specification, Version
4.0", Prentice Hall, Upper Saddle River NJ; specification final- 4.0", April 1996. Publication by Prentice Hall pending, avail-
ized April 1996; expected publication, late 1996; available at able at ftp://ftp.atmforum.com/pub/approved-specs/af-tm-
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps. 0056.000.ps.
[7] M. W. Garrett, "A Service Architecture for ATM: From Applica- [7] M. W. Garrett, "A Service Architecture for ATM: From Applica-
tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6- tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6-
14, May 1996. 14, May 1996.
[8] S. Shenker, C. Partridge and R. Guerin, "Specification of [8] S. Shenker, C. Partridge and R. Guerin, "Specification of
Guaranteed Quality of Service", Internet Draft, July 1997, Guaranteed Quality of Service", RFC 2212, September 1997.
<draft-ietf-intserv-guaranteed-svc-08.txt>
[9] J. Wroclawski, "Specification of the Controlled-Load Network [9] J. Wroclawski, "Specification of the Controlled-Load Network
Element Service", Internet Draft, November 1996, <draft-ietf- Element Service", RFC 2211, September 1997.
intserv-ctrl-load-svc-04.txt>
[10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. [10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A.
Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru- Malis, "ATM Signaling Support for IP over ATM", RFC 1755, Febru-
ary 1995. ary 1995.
[11] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM - [11] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM
UNI 4.0 Update", Internet Draft, May 1997, <draft-ietf-ion-sig- UNI 4.0 Update", Internet Draft, October 1997. <draft-ietf-
uni4.0-04.txt> ion-sig-uni4.0-05.txt>
[12] S. Berson, L. Berger, "IP Integrated Services with RSVP over [12] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J.
ATM", Internet Draft, September 1996, <draft-ietf-issll-atm- Krawczyk, "A Framework for Integrated Services and RSVP over
support-01.txt> ATM", Internet Draft, July 1997. <draft-ietf-issll-atm-
framework-00.txt>
[13] S. Shenker and J. Wroclawski, "Network Element Service Specifi- [13] L. Berger, "RSVP over ATM Implementation Requirements", Internet
cation Template", Internet Draft, November 1995, <draft-ietf- Draft, July 1997. <draft-ietf-issll-atm-imp-req-00.txt>
intserv-svc-template-02.txt>
[14] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", [14] L. Berger, "RSVP over ATM Implementation Guidelines", Internet
Internet Draft, August 1996, <draft-ietf-intserv-use-00.txt> Draft, July 1997. <draft-ietf-issll-imp-guide-01.txt>
[15] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of [15] S. Shenker and J. Wroclawski, "Network Element Service Specifi-
Real-time Services in an IP-ATM Network Architecture", "IP cation Template", RFC 2216, September 1997.
Authentication Header", RFC 1821, August 1995.
[16] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation [16] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
Layer 5", RFC 1483, July 1993. RFC 2210, September 1997.
[17] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January [17] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of
1994. Real-time Services in an IP-ATM Network Architecture", RFC 1821,
August 1995.
[18] L. Berger, "RSVP over ATM Implementation Requirements", Internet [18] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
Draft, July 1997, <draft-ietf-issll-atm-imp-req-00.txt> Layer 5", RFC 1483, July 1993.
[19] L. Berger, "RSVP over ATM Implementation Guidelines", Internet [19] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January
Draft, July 1997, <draft-ietf-issll-imp-guide-01.txt> 1994.
[20] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net- [20] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net-
works", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633- works", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633-
-41, May 1995, -41, May 1995,
[21] S. Floyd, V. Jacobson, "Link-sharing and Resource Management [21] 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.
[22] S. Shenker and J. Wroclawski, "General Characterization Parame- [22] S. Shenker and J. Wroclawski, "General Characterization Parame-
ters for Integrated Service Network Elements", Internet Draft, ters for Integrated Service Network Elements", RFC 2215, Sep-
July 1997, <draft-ietf-intserv-charac-03.txt> tember 1997.
Authors' Addresses Authors' Addresses
Mark W. Garrett Marty Borden Mark W. Garrett Marty Borden
Bellcore New Oak Communications, Inc. Bellcore New Oak Communications, Inc.
445 South Street 42 Nagog Park 445 South Street 42 Nagog Park
Morristown, NJ 07960 Acton MA, 01720 Morristown, NJ 07960 Acton MA, 01720
USA USA USA USA
phone: +1 201 829-4439 phone: +1 508 266-1011 phone: +1 201 829-4439 phone: +1 508 266-1011
 End of changes. 92 change blocks. 
270 lines changed or deleted 246 lines changed or added

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