draft-ietf-issll-atm-mapping-05.txt   draft-ietf-issll-atm-mapping-06.txt 
INTERNET-DRAFT Mark W. Garrett, INTERNET-DRAFT Mark W. Garrett,
ISSLL WG Bellcore ISSLL WG Bellcore
Expires: 12 September 1998 Expires: 30 September 1998
Marty Borden, Marty Borden,
Bay Networks Bay Networks
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-05.txt> <draft-ietf-issll-atm-mapping-06.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
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract Abstract
This document provides guidelines for mapping service classes, and This document provides guidelines for mapping service classes, and
traffic management features and parameters between Internet and ATM traffic management features and parameters between Internet and ATM
technologies. The service mappings are useful for providing technologies. The service mappings are useful for providing
effective interoperation and end-to-end Quality of Service for IP effective interoperation and end-to-end Quality of Service for IP
Integrated Services networks containing ATM subnetworks. Integrated Services networks containing ATM subnetworks.
The discussion and specifications given here support the IP The discussion and specifications given here support the IP
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. (Note, in document are to be interpreted as described in RFC 2119 [1]. (Note,
many cases the use of "MUST" reflects our interpretation of the in many cases the use of "MUST" or "REQUIRED" reflects our
requirements of a related standard, e.g., ATM Forum UNI 4.0, rsvp, interpretation of the requirements of a related standard, e.g., ATM
etc.) Forum UNI 4.0, rsvp, etc.)
Table of Contents Table of Contents
1.0 Introduction ....................................................... 3 1.0 Introduction ....................................................... 3
1.1 General System Architecture .................................... 4 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 ............. 8
2.1 Service Category and Bearer Capability ......................... 8 2.1 Service Category and Bearer Capability ......................... 8
2.1.1 Service Categories for Guaranteed Service ................ 9 2.1.1 Service Categories for Guaranteed Service ................ 9
2.1.2 Service Categories for Controlled Load ................... 10 2.1.2 Service Categories for Controlled Load ................... 10
2.1.3 Service Categories for Best Effort ....................... 11 2.1.3 Service Categories for Best Effort ....................... 11
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.5.3 Translating Traffic Descriptors for Best Effort Service ....20 2.5.3 Translating Traffic Descriptors for Best Effort Service ....20
2.6 QoS Classes and Parameters ..................................... 20 2.6 QoS Classes and Parameters ..................................... 20
2.7 Additional Parameters -- Frame Discard Mode .................... 22 2.7 Additional Parameters -- Frame Discard Mode .................... 22
3.0 Additional IP-Integrated Services Protocol Features ................ 23 3.0 Additional IP-Integrated Services Protocol Features ................ 23
3.1 Path Characterization Parameters for IP Integrated Services .... 23 3.1 Path Characterization Parameters for IP Integrated Services .... 23
3.2 Handling of Excess Traffic ..................................... 24 3.2 Handling of Excess Traffic ..................................... 24
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 26 3.3 Use of Guaranteed Service Adspec Parameters and Slack Term ..... 26
4.0 Miscellaneous Items ................................................ 27 4.0 Miscellaneous Items ................................................ 27
4.1 Units Conversion ............................................... 27 4.1 Units Conversion ............................................... 27
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28 5.0 Summary of ATM VC Setup Parameters for Guaranteed Service .......... 28
5.1 Encoding GS Using Real-Time VBR ................................ 28 5.1 Encoding GS Using Real-Time VBR ................................ 29
5.2 Encoding GS Using CBR .......................................... 30 5.2 Encoding GS Using CBR .......................................... 30
5.3 Encoding GS Using Non-Real-Time VBR ............................ 31 5.3 Encoding GS Using Non-Real-Time VBR ............................ 32
5.4 Encoding GS Using ABR .......................................... 31 5.4 Encoding GS Using ABR .......................................... 32
5.5 Encoding GS Using UBR .......................................... 31 5.5 Encoding GS Using UBR .......................................... 32
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 31 5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ......................... 32
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 33 6.0 Summary of ATM VC Setup Parameters for Controlled Load Service ..... 34
6.1 Encoding CLS Using Non-Real-Time VBR ........................... 33 6.1 Encoding CLS Using Non-Real-Time VBR ........................... 34
6.2 Encoding CLS Using ABR ......................................... 34 6.2 Encoding CLS Using ABR ......................................... 35
6.3 Encoding CLS Using CBR ......................................... 36 6.3 Encoding CLS Using CBR ......................................... 37
6.4 Encoding CLS Using Real-Time VBR ............................... 36 6.4 Encoding CLS Using Real-Time VBR ............................... 37
6.5 Encoding CLS Using UBR ......................................... 36 6.5 Encoding CLS Using UBR ......................................... 37
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 36 6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ........................ 37
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 38 7.0 Summary of ATM VC Setup Parameters for Best Effort Service ......... 39
7.1 Encoding Best Effort Service Using UBR ......................... 38 7.1 Encoding Best Effort Service Using UBR ......................... 39
8.0 Security Considerations ............................................ 39 8.0 Security Considerations ............................................ 40
9.0 Acknowledgements ................................................... 40 9.0 Acknowledgements ................................................... 41
Appendix 1 Abbreviations .............................................. 40 Appendix 1 Abbreviations .............................................. 41
References ............................................................. 41 References ............................................................. 42
Authors' Addresses ..................................................... 43 Authors' Addresses ..................................................... 44
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 [2] with
an ATM subnetwork. This document is intended to be consistent with an ATM subnetwork. This document is intended to be consistent with
the rsvp protocol [2] for IP-level resource reservation, although it the rsvp protocol [3] for IP-level resource reservation, although it
applies also in the general case where GS and CLS services are applies also in the general case where GS and CLS services are
supported through other mechanisms. In the ATM network, we consider supported through other mechanisms. In the ATM network, we consider
ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [3, 4, 5]. The ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6]. The
latter uses the more complete service model of the ATM Forum's TM 4.0 latter uses the more complete service model of the ATM Forum's TM 4.0
specification [6, 7]. specification [7, 8].
This is a complex problem with many facets. In this document, we This is a complex problem with many facets. In this document, we
focus on the service types, parameters and signalling elements needed focus on the service types, parameters and signalling elements needed
for service interoperation. The resulting service mappings can be for service interoperation. The resulting service mappings can be
used to provide effective end-to-end Quality of Service (QoS) for IP used to provide effective end-to-end Quality of Service (QoS) for IP
traffic that traverses ATM networks. traffic that traverses ATM networks.
The IP services considered are Guaranteed Service (GS) [8] and The IP services considered are Guaranteed Service (GS) [9] and
Controlled Load Service (CLS) [9]. We also discuss the default Best Controlled Load Service (CLS) [10]. We also discuss the default Best
Effort Service (BE) in parallel with these. Our recommendations for Effort Service (BE) in parallel with these. Our recommendations for
BE are intended to be consistent with RFC 1755 [10], and [11], which BE are intended to be consistent with RFC 1755 [11], and [12], which
define how ATM VCs can be used in support of normal BE IP service. define how ATM VCs can be used in support of normal BE IP service.
The ATM services we consider are: The ATM services we consider are:
CBR Constant Bit Rate CBR Constant Bit Rate
rtVBR Real-time Variable Bit Rate rtVBR Real-time Variable Bit Rate
nrtVBR Non-real-time Variable Bit Rate nrtVBR Non-real-time Variable Bit Rate
UBR Unspecified Bit Rate UBR Unspecified Bit Rate
ABR Available Bit Rate ABR Available Bit Rate
In the case of UNI 3.x signalling, where these service are not all In the case of UNI 3.x signalling, where these service are not all
skipping to change at page 4, line 23 skipping to change at page 4, line 23
an ATM subnetwork. Section 4 addresses the conversion of traffic an ATM subnetwork. Section 4 addresses the conversion of traffic
descriptors to account for ATM-layer overheads. Section 5 gives the descriptors to account for ATM-layer overheads. Section 5 gives the
detailed VC setup parameters for Guaranteed Service, and considers detailed VC setup parameters for Guaranteed Service, and considers
the effect of using each of the ATM service categories. Section 6 the effect of using each of the ATM service categories. Section 6
provides a similar treatment for Controlled Load Service. Section 7 provides a similar treatment for Controlled Load Service. Section 7
considers Best Effort service. considers Best Effort service.
This document is only a part of the total solution to providing the This document is only a part of the total solution to providing the
interworking of IP integrated services with ATM subnetworks. The interworking of IP integrated services with ATM subnetworks. The
important issue of VC management, including flow aggregation, is important issue of VC management, including flow aggregation, is
considered in [12,13,14]. We do not consider how routing, QoS considered in [13,14,15]. We do not consider how routing, QoS
sensitive or not, interacts with the use of ATM VCs. We expect that sensitive or not, interacts with the use of ATM VCs. We expect that
a considerable degree of implementation latitude will exist, even a considerable degree of implementation latitude will exist, even
within the guidelines presented here. Many aspects of interworking within the guidelines presented here. Many aspects of interworking
between IP and ATM will depend on economic factors, and will not be between IP and ATM will depend on economic factors, and will not be
subject to standardization. subject to standardization.
1.1 General System Architecture 1.1 General System Architecture
We assume that the reader has a general working knowledge of IP, rsvp We assume that the reader has a general working knowledge of IP, rsvp
and ATM protocols. The network architecture we consider is and ATM protocols. The network architecture we consider is
skipping to change at page 5, line 39 skipping to change at page 5, line 39
A range of VC management policies are possible, which determine A range of VC management policies are possible, which determine
whether a flow initiates a new VC or joins an existing one. VCs are whether a flow initiates a new VC or joins an existing one. VCs are
managed according to a combination of standards and local policy managed according to a combination of standards and local policy
rules, which are specific to either the implementation (equipment) or rules, which are specific to either the implementation (equipment) or
the operator (network service provider). Point-to-multipoint the operator (network service provider). Point-to-multipoint
connections within the ATM cloud can be used to support general IP connections within the ATM cloud can be used to support general IP
multicast flows. In ATM, a point to multipoint connection can be multicast flows. In ATM, a point to multipoint connection can be
controlled by the source (or root) node, or a leaf initiated join controlled by the source (or root) node, or a leaf initiated join
(LIJ) feature in ATM may be used. The topic of VC management is (LIJ) feature in ATM may be used. The topic of VC management is
considered at length in other ISSLL documents [12,13,14]. considered at length in other ISSLL documents [13,14,15].
Figure 2 shows the functions of an edge device, summarizing the work Figure 2 shows the functions of an edge device, summarizing the work
not part of IP or ATM abstractly as an InterWorking Function (IWF), not part of IP or ATM abstractly as an InterWorking Function (IWF),
and segregating the control and data planes. and segregating the control and data planes.
IP ATM IP ATM
____________________ ____________________
| IWF | | IWF |
| | | |
admission and <--> | service mapping | <--> ATM admission and <--> | service mapping | <--> ATM
skipping to change at page 6, line 37 skipping to change at page 6, line 37
The service mapping and VC management functions can be highly The service mapping and VC management functions can be highly
interdependent. For example: (i) Multiple integrated-services flows interdependent. For example: (i) Multiple integrated-services flows
may be aggregated to use one point-to-multipoint VC. In this case, may be aggregated to use one point-to-multipoint VC. In this case,
we assume the IP flows are of the same service type and their we assume the IP flows are of the same service type and their
parameters have been merged appropriately. (ii) The VC management parameters have been merged appropriately. (ii) The VC management
function may choose to allocate extra resources in anticipation of function may choose to allocate extra resources in anticipation of
further reservations or based on an empiric of changing TSpecs. further reservations or based on an empiric of changing TSpecs.
(iii) There MUST exist a path for best effort flows and for sending (iii) There MUST exist a path for best effort flows and for sending
the rsvp control messages. How this interacts with the establishment the rsvp control messages. How this interacts with the establishment
of VCs for QoS traffic may alter the desired characteristics of those of VCs for QoS traffic may alter the desired characteristics of those
VCs. See [12,13,14] for further details on VC management. VCs. See [13,14,15] for further details on VC management.
Therefore, in discussing the service mapping problem, we will assume Therefore, in discussing the service mapping problem, we will assume
that the VC management function of the IWF can always express its that the VC management function of the IWF can always express its
result in terms of an IP-level service with some QoS and TSpec. The result in terms of an IP-level service with some QoS and TSpec. The
service mapping algorithm can then identify the appropriate VC service mapping algorithm can then identify the appropriate VC
parameters as if a new VC were to be created for this service. The parameters as if a new VC were to be created for this service. The
VC management function can then use this information consistent with VC management function can then use this information consistent with
its own policy, which determines whether the resulting action uses its own policy, which determines whether the resulting action uses
new or existing VCs. new or existing VCs.
1.2 Related Documents 1.2 Related Documents
Earlier ATM Forum documents combined signalling, traffic management Earlier ATM Forum documents combined signalling, traffic management
and other areas into a single document, e.g., UNI 3.0 [3] and UNI 3.1 and other areas into a single document, e.g., UNI 3.0 [4] and UNI 3.1
[4]. The 3.1 release was used to correct errors and fix alignment [5]. The 3.1 release was used to correct errors and fix alignment
with the ITU. While UNI 3.0 and 3.1 are incompatible in terms of with the ITU. While UNI 3.0 and 3.1 are incompatible in terms of
actual codepoints, the semantics are generally the same. Therefore, actual codepoints, the semantics are generally the same. Therefore,
we will often refer to UNI 3.x to mean either version of the ATM we will often refer to UNI 3.x to mean either version of the ATM
protocol. protocol.
After 3.1, the ATM Forum released documents separately for each After 3.1, the ATM Forum released documents separately for each
technical working group. The UNI Signalling 4.0 [5] and Traffic technical working group. The UNI Signalling 4.0 [6] and Traffic
Management 4.0 [6] documents represent a consistent overall ATM Management 4.0 [7] documents represent a consistent overall ATM
protocol, and we will sometime refer to the combination as TM/UNI protocol, and we will sometime refer to the combination as TM/UNI
4.0. 4.0.
Within the IETF, related material includes the work of the rsvp [2], Within the IETF, related material includes the work of the rsvp [3],
int-serv [1, 8, 9, 15, 16] and ion working groups [10, 11]. Rsvp int-serv [2, 9, 10, 16, 17] and ion working groups [11, 12]. 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 to the Traffic Management working particular services (analogous to the Traffic Management working
group in the ATM Forum). Ion defines interworking of IP and ATM for group in the ATM Forum). Ion defines interworking of IP and ATM for
traditional Best Effort service, and generally covers issues related traditional Best Effort service, and generally covers issues related
to IP/ATM 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 extend to IP frame-relay interworking, etc. These considerations extend to IP
skipping to change at page 10, line 13 skipping to change at page 10, line 13
TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may TM/UNI 4.0 either CBR or rtVBR is appropriate. The use of rtVBR may
encourage recovery of allocated bandwidth left unused by a source. encourage recovery of allocated bandwidth left unused by a source.
It also accommodates more bursty sources with a larger token bucket It also accommodates more bursty sources with a larger token bucket
burst parameter, and permits the use of tagging for excess traffic burst parameter, and permits the use of tagging for excess traffic
(see Section 2.2). (see Section 2.2).
Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good Neither the BCOB-C Bearer Class, nor nrtVBR, UBR, ABR are good
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 For BCOB-A or CBR, specification of a peak cell rate (PCR) is
rate (PCR). In these cases, PCR is the nominal clearing rate with a REQUIRED by ATM standards. In these cases, PCR is the nominal
nominal jitter toleration (bucket size), CDVT. clearing rate with a nominal jitter toleration (bucket size), CDVT.
Specification of rtVBR REQUIRES two rates, PCR and SCR. This models When rtVBR is specifed, two rates, PCR and SCR are REQUIRED (by ATM
bursty traffic with specified peak and sustainable rates. The standards). This models bursty traffic with specified peak and
corresponding ATM token bucket depth values are CDVT, and CDVT+BT, sustainable rates. The corresponding ATM token bucket depth values
respectively. are CDVT, and CDVT+BT, respectively.
2.1.2 Service Categories for Controlled Load 2.1.2 Service Categories for Controlled Load
There are three possible good mappings for CLS: There are three possible good mappings for CLS:
CBR (BCOB-A) CBR (BCOB-A)
nrtVBR (BCOB-C) nrtVBR (BCOB-C)
ABR ABR
Note that under UNI 3.x, there are equivalent services to CBR and Note that under UNI 3.x, there are equivalent services to CBR and
skipping to change at page 13, line 38 skipping to change at page 13, line 37
drop some of the cells of a packet while carrying others, which would drop some of the cells of a packet while carrying others, which would
then be dropped by the receiver. Therefore, the IWF, knowing the VC then be dropped by the receiver. Therefore, the IWF, knowing the VC
GCRA parameters, SHOULD always anticipate the cells which will be GCRA parameters, SHOULD always anticipate the cells which will be
tagged by the ATM UPC and tag all of the cells uniformly across each tagged by the ATM UPC and tag all of the cells uniformly across each
affected packet. See Section 3.2 for further discussion of excess affected packet. See Section 3.2 for further discussion of excess
traffic. traffic.
2.3 ATM Adaptation Layer 2.3 ATM Adaptation Layer
The AAL type 5 encoding SHOULD be used, as specified in RFC 1483 and The AAL type 5 encoding SHOULD be used, as specified in RFC 1483 and
RFC 1755. AAL-5 REQUIRES specification of the maximum SDU size in RFC 1755. For AAL-5, specification of the maximum SDU size in both
both the forward and reverse directions. Both GS and CLS specify a the forward and reverse directions is REQUIRED. Both GS and CLS
maximum packet size, M, as part of the TSpec and this value SHOULD be specify a maximum packet size, M, as part of the TSpec and this value
used (corrected for AAL headers) as the maximum SDU in each direction SHOULD be used (corrected for AAL headers) as the maximum SDU in each
for unicast connections, and for unidirectional point-to-multipoint direction for unicast connections, and for unidirectional point-to-
connections. When multiple flows are aggregated into a single VC, multipoint connections. When multiple flows are aggregated into a
the M parameters of the receiver TSpecs are merged according to rules single VC, the M parameters of the receiver TSpecs are merged
given in the GS and CLS specs. 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 LLC/SNAP encapsulation [18] SHOULD be supported as negotiation. The LLC/SNAP encapsulation [18] SHOULD be supported as
the default, but "null" or "VC encapsulation" MAY also be allowed. the default, but "null" or "VC encapsulation" MAY also be allowed.
Implementations SHOULD follow RFC 1577 [19] and RFC 1755 [10] for Implementations SHOULD follow RFC 1577 [19] and RFC 1755 [10] for
BLLI usage. BLLI usage.
skipping to change at page 20, line 50 skipping to change at page 20, line 50
Class value to 0 for UBR and ABR (as REQUIRED), 1 for CBR and rtVBR Class value to 0 for UBR and ABR (as REQUIRED), 1 for CBR and rtVBR
and 3 for nrtVBR. Note that the QoS Class follows the ATM service and 3 for nrtVBR. Note that the QoS Class follows the ATM service
category, and not the IP service, to avoid combination that are category, and not the IP service, to avoid combination that are
unlikely to be supported. For example, if only nrtVBR is available unlikely to be supported. For example, if only nrtVBR is available
for GS, then choosing QoS Class = 1 would probably result in for GS, then choosing QoS Class = 1 would probably result in
connection failure. The QoS Class MUST NOT be interpreted as a way connection failure. The QoS Class MUST NOT be interpreted as a way
to add real-time behavior to an inherently non-real-time service. to add real-time behavior to an inherently non-real-time service.
The ITU has included a standard set of parameter values for a (small) The ITU has included a standard set of parameter values for a (small)
number of QoS Classes in the latest version of Recommendation I.356 number of QoS Classes in the latest version of Recommendation I.356
[20]. Network providers may choose to define further network- [21]. Network providers may choose to define further network-
specific QoS Classes in addition to these. Note that the QoS class specific QoS Classes in addition to these. Note that the QoS class
definitions in the new I.356 version might not align with the model definitions in the new I.356 version might not align with the model
we follow from the ATM Forum UNI specs. Apart from these we follow from the ATM Forum UNI specs. Apart from these
definitions, there is no consistent agreement on QoS Class definitions, there is no consistent agreement on QoS Class
definitions among providers in practice. definitions among providers in practice.
The ATM QoS parameters have no explicitly signalled IP layer The ATM QoS parameters have no explicitly signalled IP layer
counterparts. The values that are signalled in the ATM network are counterparts. The values that are signalled in the ATM network are
determined by the IP service definitions and knowledge of the determined by the IP service definitions and knowledge of the
underlying ATM network characteristics, as explained below. underlying ATM network characteristics, as explained below.
skipping to change at page 21, line 38 skipping to change at page 21, line 38
minimized, so that the loss rate is approximately the same as for an minimized, so that the loss rate is approximately the same as for an
unloaded network. The characteristic loss behavior of the physical unloaded network. The characteristic loss behavior of the physical
medium not due to congestion (e.g., bit errors or fading on wireless medium not due to congestion (e.g., bit errors or fading on wireless
channels) determines the order of the permitted packet loss rate. channels) determines the order of the permitted packet loss rate.
The ingress edge device MUST choose a value of CLR that provides the The ingress edge device MUST choose a value of CLR that provides the
appropriate IP-level packet loss rate. The CLR value may be uniform appropriate IP-level packet loss rate. The CLR value may be uniform
over all egress points in the ATM network, or may differ, e.g., when over all egress points in the ATM network, or may differ, e.g., when
wireless or satellite ATM links are in some paths. The determination wireless or satellite ATM links are in some paths. The determination
of CLR MUST account for the effects of packet size distribution and of CLR MUST account for the effects of packet size distribution and
ATM Frame Discard mode (which can change the effective packet loss ATM Frame Discard mode (which can change the effective packet loss
rate by orders of magnitude [21]). rate by orders of magnitude [22]).
The ingress router will also tabulate values for the Minimum Path The ingress router will also tabulate values for the Minimum Path
Latency (MPL) and estimated queueing delays (D_ATM) for each egress Latency (MPL) and estimated queueing delays (D_ATM) for each egress
point. The latter will be used as part of the Adspec "D" parameter point. The latter will be used as part of the Adspec "D" parameter
for GS, but its use here applies to CLS as well (when the VC setup for GS, but its use here applies to CLS as well (when the VC setup
includes delay parameters). MPL represents all constant (non- includes delay parameters). MPL represents all constant (non-
congestion related) delays, including propagation delay. D_ATM congestion related) delays, including propagation delay. D_ATM
accounts for the variable component of delays in the ATM network. accounts for the variable component of delays in the ATM network.
(It may depend on non-signalled parameters such as CDVT.) Given (It may depend on non-signalled parameters such as CDVT.) Given
these quantities, a new VC can be set up with delay-related QoS these quantities, a new VC can be set up with delay-related QoS
skipping to change at page 22, line 15 skipping to change at page 22, line 15
CTD = D_ATM + MPL. CTD = D_ATM + MPL.
(CDV and CTD may be adjusted (increased) by the slack term in GS, see (CDV and CTD may be adjusted (increased) by the slack term in GS, see
Section 3.3 below.) Section 3.3 below.)
It is interesting (and perhaps unfortunate) to note that in a typical It is interesting (and perhaps unfortunate) to note that in a typical
GS/rtVBR service, the delay bound advertised can contain two GS/rtVBR service, the delay bound advertised can contain two
components of b/R instead of one. Consider the simple case where SCR components of b/R instead of one. Consider the simple case where SCR
= R is the rate allocated to the flow in both IP routers and ATM = R is the rate allocated to the flow in both IP routers and ATM
switches along the path, and the buffer allocation is MBS = b. switches along the path, and the buffer allocation is MBS = b.
Parekh's theory [22], which is the basis of the GS delay formula [8] Parekh's theory [23], which is the basis of the GS delay formula [8]
states that the b/R delay term occurs only once, because once a burst 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, the packets of size b has been served by a congested node at rate R, the packets
will not arrive at a subsequent node as a single burst. However, we will not arrive at a subsequent node as a single burst. However, we
can't tell a priori if this bottleneck will occur in the ATM network can't tell a priori if this bottleneck will occur in the ATM network
or elsewhere in the IP network, so the declaration of CDV SHOULD or elsewhere in the IP network, so the declaration of CDV SHOULD
account for it (i.e., CDV >= b/R). Once CDV is set, the ATM network account for it (i.e., CDV >= b/R). Once CDV is set, the ATM network
can impose this delay, whether or not the traffic arrives in a burst. can impose this delay, whether or not the traffic arrives in a burst.
Since the delay b/R can also occur elsewhere, it cannot be removed Since the delay b/R can also occur elsewhere, it cannot be removed
from the first term of the GS delay formula. The ATM b/R delay from the first term of the GS delay formula. The ATM b/R delay
component appears in the third term of the GS delay formula, D_tot. component appears in the third term of the GS delay formula, D_tot.
skipping to change at page 22, line 38 skipping to change at page 22, line 38
statistical resource allocation schemes. statistical resource allocation schemes.
2.7 Additional Parameters -- Frame Discard Mode 2.7 Additional Parameters -- Frame Discard Mode
TM/UNI 4.0 allows the user to choose a mode where the ATM network is TM/UNI 4.0 allows the user to choose a mode where the ATM network is
aware, for the purpose of congestion management, of PDUs larger than aware, for the purpose of congestion management, of PDUs larger than
an ATM cell (i.e., AAL PDUs that correspond in our context to IP an ATM cell (i.e., AAL PDUs that correspond in our context to IP
packets). This facilitates implementation of algorithms such as packets). This facilitates implementation of algorithms such as
partial packet discard, where a dropped cell causes subsequent cells partial packet discard, where a dropped cell causes subsequent cells
in the same AAL-5 PDU to be dropped as well. Several other in the same AAL-5 PDU to be dropped as well. Several other
applicable buffer management schemes have been proposed [21, 23]. applicable buffer management schemes have been proposed [22, 24].
Frame discard can improve the efficiency and performance of end-to- Frame discard can improve the efficiency and performance of end-to-
end protocols such as TCP, since the remaining cells of a damaged PDU end protocols such as TCP, since the remaining cells of a damaged PDU
are generally useless to the receiver. For IP over ATM, Frame are generally useless to the receiver. For IP over ATM, Frame
Discard MUST always be indicated, if available. Discard MUST always be indicated, if available.
3.0 Additional IP-Integrated Services Protocol Features 3.0 Additional IP-Integrated Services Protocol Features
3.1 Path Characterization Parameters for IP Integrated Services with ATM 3.1 Path Characterization Parameters for IP Integrated Services with ATM
This section discusses the setting of General Characterization This section discusses the setting of General Characterization
Parameters (GCPs) at an ATM egress edge router. GCPs are signalled Parameters (GCPs) at an ATM egress edge router. GCPs are signalled
from IP source to IP destination, and modified by intermediate nodes from IP source to IP destination, and modified by intermediate nodes
using the Adspec portion of PATH messages in rsvp. The GS-specific using the Adspec portion of PATH messages in rsvp. The GS-specific
Adspec parameters are discussed below in Section 3.3. These Adspec parameters are discussed below in Section 3.3. These
parameters are denoted as <x,y> where x is the service and y is the parameters are denoted as <x,y> where x is the service and y is the
parameter number. Service number 1 indicates default or general parameter number. Service number 1 indicates default or general
parameter values. Please refer to [24] for definitions and details. parameter values. Please refer to [25] for definitions and details.
The IS break bit <1,2> MUST, of course, be left alone by The IS break bit <1,2> MUST, of course, be left alone by
implementations following these guidelines (as they are presumably implementations following these guidelines (as they are presumably
IS-aware). Similarly, the router MUST always increment IS_HOPS IS-aware). Similarly, the router MUST always increment IS_HOPS
<1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2> <1,4>. The GS and CLS service-specific break bits, <2,2> and <5,2>
respectively, MUST be set if the support of the service is respectively, MUST be set if the support of the service is
inadequate. In general GS is adequately supported by CBR (BCOB-A) inadequate. In general GS is adequately supported by CBR (BCOB-A)
and rtVBR service categories, and not adequately supported by UBR, and rtVBR service categories, and not adequately supported by UBR,
ABR and nrtVBR because delays are not controlled. CLS may be ABR and nrtVBR because delays are not controlled. CLS may be
adequately supported by all service categories except UBR (or Best adequately supported by all service categories except UBR (or Best
skipping to change at page 24, line 44 skipping to change at page 24, line 44
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 (plus 8 bytes for the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for
the LLC/SNAP header) will generally not be an issue. In the PATH the LLC/SNAP header) will generally not be an issue. In the PATH
Adspec, however, the PATH_MTU parameter <x,10> for each service Adspec, however, the PATH_MTU parameter <x,10> for each service
SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19]. SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19].
3.2 Handling of Excess Traffic 3.2 Handling of Excess Traffic
CLS REQUIRES and GS RECOMMENDS that network elements transport For IP Integrated Services, network elements will transport traffic
traffic in excess of the TSpec parameters whenever physical resources in excess of the TSpec parameters whenever physical resources
(bandwidth, buffers and processing) are available. While excess (bandwidth, buffers and processing) are available. (In CLS a
traffic SHOULD be supported on a best effort basis, it MUST NOT "network element MUST attempt to forward the excess traffic on a
interfere with the QoS (delay and loss) of conforming CLS and GS best-effort basis" under certain conditions; and in GS a traffic
traffic, nor with normal service of non-reserved best effort traffic. policers "SHOULD relegate non-conforming datagrams to best effort".)
While excess traffic SHOULD be supported on a best effort basis, it
MUST NOT interfere with the QoS (delay and loss) of conforming CLS
and GS 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 necessitates careful design of the egress reordering of the flow, but necessitates careful design of the egress
router scheduler. To avoid reordering, the excess traffic can be router scheduler. To avoid reordering, the excess traffic can be
queued with conforming traffic. A threshold SHOULD be used to ensure queued with conforming traffic. A threshold SHOULD 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 in the queue ahead of conforming packets would have to be traffic in the queue ahead of conforming packets would have to be
skipping to change at page 29, line 45 skipping to change at page 29, line 50
Note 1: See discussion in Section 2.5.1. Note 1: See discussion in Section 2.5.1.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent. If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: The ATC value 19 is not used. The value 19 implies that the Note 3: The ATC value 19 is not used. The value 19 implies that the
CLR objective applies to the aggregate CLP=0+1 stream and CLR objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic. that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol 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 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6. Note 6: See discussion in Section 2.6.
5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0) 5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0)
A CBR VC MEETS the requirements of GS. The main advantage of this is A CBR VC MEETS the requirements of GS. The main advantage of this is
that CBR is widely supported; the disadvantage is that data flows that CBR is widely supported; the disadvantage is that data flows
might not fill the pipe (utilization loss) and there is no tagging might not fill the pipe (utilization loss) and there is no tagging
option available. Excess traffic MUST be handled using a separate option available. Excess traffic MUST be handled using a separate
VC. VC.
skipping to change at page 31, line 4 skipping to change at page 31, line 7
QoS Class QoS Class
QoS Class Forward 1 Note 5 QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5 QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6 Extended QoS Parameters Note 6
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
Note 1: See discussion in Section 2.5.1. Note 1: See discussion in Section 2.5.1.
Note 2: Value 1 (BCOB-A) can also be used. Note 2: Value 1 (BCOB-A) can also be used.
If Bearer Class A is chosen the ATC field MUST be absent. If Bearer Class A is chosen the ATC field MUST be absent.
Note 3: The ATC value 7 is not used. The value 7 implies CLR Note 3: The ATC value 7 is not used. The value 7 implies CLR
objective applies to the aggregate CLP=0+1 stream and objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic. that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol 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 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6. Note 6: See discussion in Section 2.6.
5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0) 5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for NrtVBR does not provide delay guarantees and is NOT RECOMMENDED for
GS. If GS/nrtVBR is used and network utilization is low, the delay GS. If GS/nrtVBR is used and network utilization is low, the delay
may be `reasonable', but will not be controlled. The encoding of GS may be `reasonable', but will not be controlled. The encoding of GS
with nrtVBR is the same as that for CLS using nrtVBR. See Section with nrtVBR is the same as that for CLS using nrtVBR. See Section
6.1 below. 6.1 below.
skipping to change at page 34, line 38 skipping to change at page 34, line 42
Note 1: See discussion in Section 2.5.2. Note 1: See discussion in Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is used, the ATC field MUST be absent. If Bearer Class C is used, the ATC field MUST be absent.
Note 3: The ATC value 11 is not used. The value 11 implies CLR Note 3: The ATC value 11 is not used. The value 11 implies CLR
objective applies to the aggregate CLP=0+1 stream and objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic. that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol 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 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6. Note 6: See discussion in Section 2.6.
6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0) 6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0)
ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec
rate. rate.
AAL AAL
Type 5 Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
skipping to change at page 35, line 46 skipping to change at page 36, line 4
QoS Class Forward 0 Note 4 QoS Class Forward 0 Note 4
QoS Class Backward 0 Note 4 QoS Class Backward 0 Note 4
Extended QoS Parameters Note 5 Extended QoS Parameters Note 5
Acceptable Forward CDV Acceptable Forward CDV
Acceptable Forward CLR Acceptable Forward CLR
Forward Max CTD Forward Max CTD
ABR Setup Parameters Note 6 ABR Setup Parameters Note 6
ABR Additional Parameters Note 6 ABR Additional Parameters Note 6
Note 1: See discussion in Section 2.5.2. Note 1: See discussion in Section 2.5.2.
Note 2: Value 3 (BCOB-C) can also be used. Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent. If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol 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 Rec. I.356 [20] for new QoS Class definitions. Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 5: See discussion in Section 2.6. Note 5: See discussion in Section 2.6.
Note 6: The ABR-specific parameters are beyond the scope of this document. Note 6: The ABR-specific parameters are beyond the scope of this document.
These generally depend on local implementation and not on values These generally depend on local implementation and not on values
mapped from IP level service parameters (except for MCR). mapped from IP level service parameters (except for MCR).
See [6, 11] for further information. See [6, 11] for further information.
6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0) 6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0)
Although CBR does not explicitly take into account the variable rate Although CBR does not explicitly take into account the variable rate
of source data, it may be convenient to use ATM connectivity between of source data, it may be convenient to use ATM connectivity between
skipping to change at page 37, line 48 skipping to change at page 38, line 6
QoS Class Forward 3 Note 5 QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5 QoS Class Backward 3 Note 5
Note 1: Only included for UNI 3.0. Note 1: Only included for UNI 3.0.
Note 2: See discussion in Section 2.5.2. Note 2: See discussion in Section 2.5.2.
Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic
Type and Timing Requirements fields are not included. Type and Timing Requirements fields are not included.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol 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 5: Cf ITU Rec. I.356 [20] for new QoS Class definitions. Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
QoS Parameters are implied by the QoS Class. QoS Parameters are implied by the QoS Class.
7.0 Summary of ATM VC Setup Parameters for Best Effort Service 7.0 Summary of ATM VC Setup Parameters for Best Effort Service
This section is provided for completeness only. The IETF ION working This section is provided for completeness only. The IETF ION working
group documents on ATM signalling support for IP over ATM [10, 11] group documents on ATM signalling support for IP over ATM [10, 11]
provide definitive specifications for Best Effort IP service over provide definitive specifications for Best Effort IP service over
ATM. ATM.
The best-matched ATM service category to IP Best Effort is UBR. We The best-matched ATM service category to IP Best Effort is UBR. We
skipping to change at page 39, line 49 skipping to change at page 40, line 8
Problems associated with translation of resource reservations at edge Problems associated with translation of resource reservations at edge
devices are probably more complex and susceptible to abuse when the devices are probably more complex and susceptible to abuse when the
IP-ATM edge is also an administrative boundary between service IP-ATM edge is also an administrative boundary between service
providers. Note also that administrative boundaries can exist within providers. Note also that administrative boundaries can exist within
the ATM cloud, i.e., the ingress and egress edge devices are operated the ATM cloud, i.e., the ingress and egress edge devices are operated
by different service providers. by different service providers.
Note, the ATM Forum Security Working Group is currently defining Note, the ATM Forum Security Working Group is currently defining
ATM-level security features such as data encryption and signalling ATM-level security features such as data encryption and signalling
authentication. See also the security issues raised in the rsvp authentication. See also the security issues raised in the rsvp
specification [2]. specification [3].
9.0 Acknowledgements 9.0 Acknowledgements
The authors received much useful input from the members of the ISSLL The authors received much useful input from the members of the ISSLL
working group. In particular, thanks to Drew Perkins and Jon Bennett working group. In particular, thanks to Drew Perkins and Jon Bennett
of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh of Fore Systems, Roch Guerin of IBM, Susan Thomson and Sudha Ramesh
of Bellcore. of Bellcore.
Appendix 1 Abbreviations Appendix 1 Abbreviations
skipping to change at page 41, line 29 skipping to change at page 41, line 34
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] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] 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, [3] 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", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[3] The ATM Forum, "ATM User-Network Interface Specification, Ver- [4] 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- [5] 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 [6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling
Specification, Version 4.0", July 1996. Available at Specification, Version 4.0", July 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps. ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.
[6] The ATM Forum, "ATM Traffic Management Specification, Version [7] The ATM Forum, "ATM Traffic Management Specification, Version
4.0", April 1996. Available at 4.0", April 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps. ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.
[7] M. W. Garrett, "A Service Architecture for ATM: From [8] M. W. Garrett, "A Service Architecture for ATM: From Applica-
Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3, tions to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6-
pp. 6-14, May 1996. 14, May 1996.
[8] S. Shenker, C. Partridge and R. Guerin, "Specification of [9] S. Shenker, C. Partridge and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997. Guaranteed Quality of Service", RFC 2212, September 1997.
[9] J. Wroclawski, "Specification of the Controlled-Load Network [10] J. Wroclawski, "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997. Element Service", RFC 2211, September 1997.
[10] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman and A. [11] 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 [12] M. Perez and A. Mankin, "ATM Signaling Support for IP over ATM
UNI 4.0 Update", Internet Draft, October 1997. <draft-ietf- UNI 4.0 Update", Internet Draft, October 1997. <draft-ietf-
ion-sig-uni4.0-05.txt> ion-sig-uni4.0-05.txt>
[12] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. [13] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J.
Krawczyk, "A Framework for Integrated Services and RSVP over Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", Internet Draft, July 1997. <draft-ietf-issll-atm- ATM", Internet Draft, July 1997. <draft-ietf-issll-atm-
framework-00.txt> framework-00.txt>
[13] L. Berger, "RSVP over ATM Implementation Requirements", Internet [14] L. Berger, "RSVP over ATM Implementation Requirements", Internet
Draft, January 1998. <draft-ietf-issll-atm-imp-req-02.txt> Draft, January 1998. <draft-ietf-issll-atm-imp-req-02.txt>
[14] L. Berger, "RSVP over ATM Implementation Guidelines", Internet [15] L. Berger, "RSVP over ATM Implementation Guidelines", Internet
Draft, January 1998. <draft-ietf-issll-imp-guide-03.txt> Draft, January 1998. <draft-ietf-issll-imp-guide-03.txt>
[15] S. Shenker and J. Wroclawski, "Network Element Service Specifi- [16] S. Shenker and J. Wroclawski, "Network Element Service Specifi-
cation Template", RFC 2216, September 1997. cation Template", RFC 2216, September 1997.
[16] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", [17] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997. RFC 2210, September 1997.
[17] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of [18] M. Borden, E. Crawley, B. Davie and S. Batsell, "Integration of
Real-time Services in an IP-ATM Network Architecture", RFC 1821, Real-time Services in an IP-ATM Network Architecture", RFC 1821,
August 1995. August 1995.
[18] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation [19] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993. Layer 5", RFC 1483, July 1993.
[19] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January [20] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, January
1994. 1994.
[20] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer per- [21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer per-
formance", International Telecommunication Union, Geneva, formance", International Telecommunication Union, Geneva,
October 1996. October 1996.
[21] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Net- [22] 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.
[22] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing [23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing
Approach to Flow Control in Integrated Services Networks: The Approach to Flow Control in Integrated Services Networks: The
Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2, Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2,
pp. 137-150, April 1994. pp. 137-150, April 1994.
[23] S. Floyd, V. Jacobson, "Link-sharing and Resource Management [24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management
Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3,
No. 4, August 1995. No. 4, August 1995.
[24] S. Shenker and J. Wroclawski, "General Characterization Parame- [25] S. Shenker and J. Wroclawski, "General Characterization Parame-
ters for Integrated Service Network Elements", RFC 2215, Sep- ters for Integrated Service Network Elements", RFC 2215, Sep-
tember 1997. tember 1997.
Authors' Addresses Authors' Addresses
Mark W. Garrett Marty Borden Mark W. Garrett Marty Borden
Bellcore Bay Networks Bellcore Bay Networks
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
 End of changes. 59 change blocks. 
106 lines changed or deleted 112 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/