< draft-ietf-ion-sig-uni4.0-03.txt   draft-ietf-ion-sig-uni4.0-04.txt >
ION WG M. Maher ION WG M. Maher
Category: internet-draft May 1997 Category: internet-draft May 1997
draft-ietf-ion-sig-uni4.0-03.txt Expires: November 1, 1997 draft-ietf-ion-sig-uni4.0-04.txt Expires: November 1, 1997
ATM Signalling Support for IP over ATM - UNI 4.0 Update ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update
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 1, line 30 skipping to change at page 1, line 30
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This memo describes how to efficiently use the ATM call control This memo describes how to efficiently use the ATM call control
signalling procedures defined in UNI 4.0 [UNI96] to support IP over signalling procedures defined in UNI Signalling 4.0 [SIG40] to
ATM environments as described in RFC 1577 [LAUB94] and in [LUC97]. support IP over ATM environments as described in RFC 1577 [LAUB94]
Among the new features found in UNI 4.0 signalling are Available Bit and in [LUC97]. Among the new features found in UNI Signalling 4.0
Rate (ABR) signalling and traffic parameter negotiation. This draft are Available Bit Rate signalling and traffic parameter negotiation.
highlights the features of UNI 4.0 signalling that provide IP This draft highlights the features of UNI Signalling 4.0 that provide
entities capabilities for requesting ATM service in sites with SVC IP entities capabilities for requesting ATM service in sites with SVC
support, whether it is private ATM or publicly provisioned ATM, in support, whether it is private ATM or publicly provisioned ATM, in
which case the SVC support is probably configured inside PVPs. which case the SVC support is probably configured inside PVPs.
This document is only relevant to IP when used as the well known This document is only relevant to IP when used as the well known
"best effort" connectionless service. In particular, this means that "best effort" connectionless service. In particular, this means that
this document does not pertain to IP in the presence of implemented this document does not pertain to IP in the presence of implemented
IP Integrated Services (ISS). The topic of IP with ISS over ATM will IP Integrated Services. The topic of IP with Integrated Services
be handled by a different specification or set of specifications over ATM will be handled by a different specification or set of
being worked on in the ISSLL WG. specifications being worked on in the ISSLL WG.
This specification is follow-on to RFC 1755, "ATM Signaling Support This specification is follow-on to RFC 1755, "ATM Signaling Support
for IP over ATM", which is based on UNI signalling 3.1. Readers are for IP over ATM", which is based on UNI 3.1 signalling [UNI95].
assumed to be familiar with RFC 1755. Readers are assumed to be familiar with RFC 1755.
Table of Contents Table of Contents
1. Conventions ............................................... 2 1. Conventions ............................................... 2
2. Overview .................................................. 3 2. Overview .................................................. 3
3. Use of Protocol Procedures ................................ 3 3. Use of Protocol Procedures ................................ 3
3.1 VC Teardown........................................... 3 3.1 VC Teardown........................................... 3
4. Overview of Call Establishment Message Content ............ 3 4. Overview of Call Establishment Message Content ............ 3
5. Description of Information Elements ....................... 4 5. Description of Information Elements ....................... 4
5.1 ATM Adaptation Layer Parameters ...................... 4 5.1 ATM Adaptation Layer Parameters ...................... 4
skipping to change at page 3, line 7 skipping to change at page 3, line 7
of the specification. of the specification.
o SHOULD or RECOMMEND -- this item SHOULD generally be followed for o SHOULD or RECOMMEND -- this item SHOULD generally be followed for
all but exceptional circumstances. all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and MAY be followed o MAY or OPTIONAL -- the item is truly optional and MAY be followed
or ignored according to the needs of the implementor. or ignored according to the needs of the implementor.
2. Overview 2. Overview
UNI Signalling version 4.0 is the ATM Forum follow-on specification UNI Signalling version 4.0 (SIG 4.0) is the ATM Forum follow-on
to UNI Signalling 3.1. Among the new features in UNI 4.0, those of specification to UNI 3.1 signalling (UNI 3.1). Among the new features
particular interest to IP over ATM environments are: in SIG 4.0, those of particular interest to IP over ATM environments
are:
o ABR Signalling for Point-to-Point Calls o Available Bit Rate (ABR) Signalling for Point-to-Point Calls
o Traffic Parameter Negotiation o Traffic Parameter Negotiation
o Frame Discard Support o Frame Discard Support
o Leaf Initiated Join (LIJ) Capability o Leaf Initiated Join (LIJ) Capability
o ATM Anycast Capability o ATM Anycast Capability
o Switched Virtual Path (VP) Service o Switched Virtual Path (VP) Service
This draft highlights the first three capabilities listed above. The This draft highlights the first three capabilities listed above. The
last three capabilities are not discussed because models for their last three capabilities are not discussed because models for their
use in IP over ATM environments have not yet been defined or IP use in IP over ATM environments have not yet been defined or IP
imposes no special requirements on them. imposes no special requirements on them.
skipping to change at page 3, line 40 skipping to change at page 3, line 41
3.1. VC Teardown 3.1. VC Teardown
In environments running layer 3 (L3) signalling protocols, such as In environments running layer 3 (L3) signalling protocols, such as
RSVP [RSVP], over ATM, data VCs might correspond to L3 reserved flows RSVP [RSVP], over ATM, data VCs might correspond to L3 reserved flows
(even if the VC is a 'best effort' VC). In such environments it is (even if the VC is a 'best effort' VC). In such environments it is
beneficial for VCs to be torn down only when the L3 reservation has beneficial for VCs to be torn down only when the L3 reservation has
expired. In other words, it is more efficient for the sender of a L3 expired. In other words, it is more efficient for the sender of a L3
reserved flow to initiate VC tear-down when the receiver(s) has reserved flow to initiate VC tear-down when the receiver(s) has
ceased refreshing the reservation. To support such L3 behavior, sys- ceased refreshing the reservation. To support such L3 behavior, sys-
tems implementing a Public ATM UNI interface and serving as the tems implementing a Public ATM UNI interface and serving as the
_called_ party of a VC, MUST NOT use an inactivity timer to clear _called_ party of a VCC MUST NOT use an inactivity timer on such a
connections that are idle for some period of time. VCC by default. A system MAY use an inactivity timer on such a VCC
if configured to do so.
4. Overview of Call Establishment Message Content 4. Overview of Call Establishment Message Content
Signalling messages are structured to contain mandatory and optional Signalling messages are structured to contain mandatory and optional
variable length information elements (IEs). A SETUP message which variable length information elements (IEs). A SETUP message which
establishes an ATM connection to be used for IP and multiprotocol establishes an ATM connection to be used for IP and multiprotocol
interconnection calls MUST contain the following IEs: interconnection calls MUST contain the following IEs:
AAL Parameters AAL Parameters
ATM Traffic Descriptor ATM Traffic Descriptor
skipping to change at page 4, line 19 skipping to change at page 4, line 20
QoS Parameter QoS Parameter
Called Party Number Called Party Number
Calling Party Number Calling Party Number
and MAY, under certain circumstance contain the following IEs : and MAY, under certain circumstance contain the following IEs :
Calling Party Subaddress Calling Party Subaddress
Called Party Subaddress Called Party Subaddress
Transit Network Selection Transit Network Selection
(New in UNI 4.0:) (New in SIG 4.0:)
Minimum Acceptable ATM Traffic Descriptor Minimum Acceptable ATM Traffic Descriptor
Alternative ATM Traffic Descriptor Alternative ATM Traffic Descriptor
ABR Setup Parameters ABR Setup Parameters
ABR Additional Parameters ABR Additional Parameters
Connection Scope Selection Connection Scope Selection
Extended QoS Parameters Extended QoS Parameters
End-to-End Transit Delay End-to-End Transit Delay
In UNI 4.0, like UNI 3.1, the AAL Parameters and the Broadband Low In SIG 4.0, like UNI 3.1, the AAL Parameters and the Broadband Low
Layer Information IEs are optional in a SETUP message. However, in Layer Information IEs are optional in a SETUP message. However, in
support of IP over ATM these two IEs MUST be included. Appendix A support of IP over ATM these two IEs MUST be included. Appendix A
shows a sample setup message. shows a sample setup message.
5. Description of Information Elements 5. Description of Information Elements
This section describes the coding of, and procedures surrounding, This section describes the coding of, and procedures surrounding,
information elements in SETUP and CONNECT messages. The first two IEs information elements in SETUP and CONNECT messages. The first two IEs
described, ATM Adaptation Layer Parameters and Broadband Low Layer described, ATM Adaptation Layer Parameters and Broadband Low Layer
Information, are categorized as having significance only to the end- Information, are categorized as having significance only to the end-
skipping to change at page 5, line 28 skipping to change at page 5, line 28
This shows maximum size MTUs. In practice, most sites have used 9180 This shows maximum size MTUs. In practice, most sites have used 9180
IP MTUs for ATM [RFC1626]. IP MTUs for ATM [RFC1626].
5.2. Broadband Low Layer Information 5.2. Broadband Low Layer Information
Selection of an encapsulation to support IP over an ATM VCC is done Selection of an encapsulation to support IP over an ATM VCC is done
using the Broadband Low Layer Information (B-LLI) IE, along with the using the Broadband Low Layer Information (B-LLI) IE, along with the
AAL Parameters IE, and the B-LLI negotiation procedure. B-LLI nego- AAL Parameters IE, and the B-LLI negotiation procedure. B-LLI nego-
tiation is described in [PER95] in Appendix D. The procedures remain tiation is described in [PER95] in Appendix D. The procedures remain
the same for this UNI 4.0 based specification. the same for this SIG 4.0 based specification.
Format of B-LLI IE indicating LLC/SNAP encapsulation Format of B-LLI IE indicating LLC/SNAP encapsulation
---------------------------------------------------------- ----------------------------------------------------------
| bb_low_layer_information | | bb_low_layer_information |
---------------------------------------------------------- ----------------------------------------------------------
| layer_2_id 2 | | layer_2_id 2 |
| user_information_layer 12 (lan_llc - ISO 8802/2) | | user_information_layer 12 (lan_llc - ISO 8802/2) |
---------------------------------------------------------- ----------------------------------------------------------
5.3. Traffic Management Issues and Related IEs 5.3. Traffic Management Issues and Related IEs
The ATM Forum Traffic Management Sub-working group has completed ver- The ATM Forum Traffic Management Sub-working group has completed ver-
sion 4.0 of their specification [TMGT96]. This latest version focuses sion 4.0 of their specification [TMGT40]. This latest version focuses
primarily on the definition of the ABR service category. As opposed primarily on the definition of the ABR service category. As opposed
to the Unspecified Bit Rate (UBR) traffic class, ABR uses a rate- to the Unspecified Bit Rate (UBR) traffic class, ABR uses a rate-
based flow control mechanism to assure certain traffic guarantees based flow control mechanism to assure certain traffic guarantees
(bandwidth and delay). There has been much debate on whether IP (bandwidth and delay). There has been much debate on whether IP
benefits from ABR, and if so, how IP should use ABR. The Integrated benefits from ABR, and if so, how IP should use ABR. The IP
Internet Services (IIS) and RSVP models in IP add complexity to this Integrated Services (IIS) and RSVP models in IP add complexity to
issue because mapping IIS traffic classes to ATM traffic classes is this issue because mapping IIS traffic classes to ATM traffic classes
not straightforward. is not straightforward.
This document attempts only to present the required IP to ATM signal- This document attempts only to present the required IP to ATM signal-
ling interface for IP over ATM systems that do not support IIS as ling interface for IP over ATM systems that do not support IIS as
yet. It is an attempt to cause IP over ATM vendors to support enough yet. It is an attempt to cause IP over ATM vendors to support enough
options for signalling the traffic characteristics of VCs serving options for signalling the traffic characteristics of VCs serving
non-IIS IP datagrams. This specification also aims to give guidance non-IIS IP datagrams. This specification also aims to give guidance
to ATM system administrators so that they can configure their IP over to ATM system administrators so that they can configure their IP over
ATM entities to conform to the varied services that their ATM pro- ATM entities to conform to the varied services that their ATM pro-
vider may have sold to them. By definition, IP without IIS cannot be vider may have sold to them. By definition, IP without IIS cannot be
expected to provide a signalling interface that is flexible and expected to provide a signalling interface that is flexible and
allows application specific traffic descriptors. The topic of IP over allows application specific traffic descriptors. The topic of IP over
ATM signalling for IP _with_ IIS is to presented other specifications ATM signalling for IP _with_ IIS is to be presented in other specifi-
produced by the ISSLL WG of the IETF. cations being produced by the ISSLL WG of the IETF.
An IP over ATM interface may be configured to support all the defined An IP over ATM interface may be configured to support all the defined
ATM Service Categories (ASC). They are: ATM Service Categories (ASC). They are:
- CBR - CBR
- CBR with CLR specified (loss-permitting CBR) - CBR with CLR specified (loss-permitting CBR)
- ABR - ABR
- UBR - UBR
- real time VBR - real time VBR
- non-real time VBR - non-real time VBR
The ATM Traffic Descriptor IE, Broadband Bearer Capability IE, and The ATM Traffic Descriptor IE, Broadband Bearer Capability IE, and
the QoS Parameter IE together define the signalling view of ATM the QoS Parameter IE together define the signalling view of ATM
traffic management. Additionally, the Extended QoS parameters IE and traffic management. Additionally, the Extended QoS parameters IE and
the End-to-end Transit Delay IE may be used to provide more specifics the End-to-end Transit Delay IE may be used to provide more specifics
about traffic requirements, however this note does not provide expli- about traffic requirements, however this note does not provide expli-
cit recommendations on their use. Annex 9 of [TMGT96] describes a cit recommendations on their use. Annex 9 of [SIG40] describes a set
set of allowable combinations of traffic and QoS related paramenters of allowable combinations of traffic and QoS related paramenters
defined for UNI 4.0 signalling. This set includes all forms of non- defined for SIG 4.0. This set includes all forms of non-IIS IP sig-
IIS IP signalling configurations that MUST be implemented in ATM nalling configurations that MUST be implemented in ATM endsystems to
endsystems to accommodate varied sites' needs. The principle is that accommodate varied sites' needs. The principle is that IP over ATM
IP over ATM service may be available in different sites by different service may be available in different sites by different types of
types of procured ATM service; for one site, a CBR PVP might be procured ATM service; for one site, a CBR PVP might be cost-effective
cost-effective and then the SVCs that IP over ATM without IIS must and then the SVCs that IP over ATM without IIS must establish must be
establish must be CBR. Similarly, VBR or ABR PVPs could be pro- CBR. Similarly, VBR or ABR PVPs could be provisioned. The intent of
visioned. The intent of this document is to specify the use of the this document is to specify the use of the most sensible parameters
most sensible parameters within this non-IIS configuration. For within this non-IIS configuration. For instance, for non-IIS VBR,
instance, for non-IIS VBR, the SCR value may need to be hand- the SCR value may need to be hand-configured for IP users, or for
configured for IP users, or for ABR, the PCR value may be link-rate ABR, the PCR value may be link-rate with a 0 MCR.
with a 0 MCR.
For the reader's convenience, we have replicated the tables found in For the reader's convenience, we have replicated the tables found in
Annex 9 of [TMGT96] in Appendix C of this document. Ideally this Annex 9 of [SIG40] in Appendix C of this document. Ideally this docu-
document could recommend specific values for the various table param- ment could recommend specific values for the various table parameters
eters that would offer the most sensible IP over ATM service. that would offer the most sensible IP over ATM service. Nevertheless,
Nevertheless, it is not possible to mandate specific values given the it is not possible to mandate specific values given the varied
varied scenarios of procured ATM service. scenarios of procured ATM service.
5.3.1. ATM Traffic Descriptor 5.3.1. ATM Traffic Descriptor
Even with the newly defined ABR ASC, the most convenient model of IP Even with the newly defined ABR ASC, the most convenient model for
behavior still corresponds to the best effort capability. If a a supporting IP still corresponds to the best effort capability, the
site's configuration allows this capability, a user MAY signal for it UBR ASC. The rationale for this assertion stems from the fact that a
using the IE's and parameters pertaining to the UBR ATM service non-IIS IP service has no notion of the performance requirements of
category. See Appendix C for the list of IE's and parameters. the higher layers it supports. Therefore, if a a site's configuration
allows use of UBR, users SHOULD signal for it using the IE's and
parameters pertaining to the UBR ATC. See Appendix C for the list of
those IE's and parameters.
Although we consider the UBR ASC the most natural ASC for best-effort Although we consider the UBR ASC the most natural ASC for best-effort
IP, ATM vendors that implement VBR and ABR services could possibly IP, ATM vendors that implement VBR and ABR services could possibly
create hooks for convenient use of these services. If this is the create hooks for convenient use of these services. If this is the
case, IP routers may perhaps have the most to gain from use of VBR or case, IP routers may perhaps have the most to gain from use of VBR or
ABR services because of the large aggregated traffic volume they are ABR services because of the large aggregated traffic volume they are
required to forward. See appendix XX for detailed suggestions on VBR required to forward. See Appendix B for detailed suggestions on VBR
and ABR signalling for IP routers. We simply note here that, in sup- and ABR signalling for IP routers. We simply note here that, in sup-
port of ABR service, two new subfields have been added in UNI 4.0 to port of ABR service, two new subfields have been added in SIG 4.0 to
the Traffic Descriptor IE. These fields are the forward and backward the Traffic Descriptor IE. These fields are the forward and backward
'Minimum Cell Rate' fields. 'Minimum Cell Rate' fields.
5.3.1.1. Tagging vs. Dropping 5.3.1.1. Tagging vs. Dropping
The Traffic Descriptor IE contains a 'tagging' subfield used for The Traffic Descriptor IE contains a 'tagging' subfield used for
indicating whether the network is allowed to tag the source's data indicating whether the network is allowed to tag the source's data
cells. Tagging in the network may occur during periods of congestion cells. Tagging in the network may occur during periods of congestion
or when the source's traffic has violated the traffic contract for or when the source's traffic has violated the traffic contract for
the connection. See Section 4 of [TMGT96] for an explanation of ATM the connection. See Section 4 of [TMGT40] for an explanation of ATM
connection conformance and the Usage Parameter Control (UPC) func- connection conformance and the Usage Parameter Control (UPC) func-
tion. tion.
UNI 4.0 and TMGT 4.0 define two modes of UBR, UBR.1 which disables SIG 4.0 and TMGT 4.0 define two modes of UBR, UBR.1 which disables
tagging and UBR.2 which enables tagging (see Appendix C). In some tagging and UBR.2 which enables tagging (see Appendix C). In some
network environments there is no potential for UBR traffic sources to network environments there is no potential for UBR traffic sources to
violate the connection traffic contract because, either the user's violate the connection traffic contract because, either the user's
terminal equipment supports traffic shaping, or the network does not terminal equipment supports traffic shaping, or the network does not
enforce PCR. In such environments, the user SHOULD specify 'no tag- enforce PCR. In such environments, the user SHOULD specify 'no tag-
ging' in the SETUP message (UBR.1). Specifying 'no tagging' indi- ging' in the SETUP message (UBR.1). Specifying 'no tagging' indi-
cates to the network that cells should be dropped during periods of cates to the network that cells should be dropped during periods of
congestion instead of being randomly marked/tagged as low priority. congestion instead of being randomly marked/tagged as low priority.
Cells of packets that the source itself has marked as low priority Cells of packets that the source itself has marked as low priority
are dropped first, thereby preserving the source's characterization are dropped first, thereby preserving the source's characterization
skipping to change at page 8, line 14 skipping to change at page 8, line 16
On the other hand, when the network applies PCR to the UPC function, On the other hand, when the network applies PCR to the UPC function,
meaning it enforces PCR, and traffic shaping is not enabled at the meaning it enforces PCR, and traffic shaping is not enabled at the
source, the source has the potential to violate the traffic contract source, the source has the potential to violate the traffic contract
and SHOULD therefore signal for tagging (UBR.2). Tagging allows the and SHOULD therefore signal for tagging (UBR.2). Tagging allows the
source's non-conforming cells to be tagged and forwarded instead of source's non-conforming cells to be tagged and forwarded instead of
dropped. dropped.
5.3.2. Traffic Parameter Negotiation 5.3.2. Traffic Parameter Negotiation
UNI 4.0 allows certain traffic parameters to be negotiated during the SIG 4.0 allows certain traffic parameters to be negotiated during the
call establishment phase Traffic parameters cannot be 'renegotiated' call establishment phase Traffic parameters cannot be 'renegotiated'
after the call is active. Two new IEs make negotiation possible: after the call is active. Two new IEs make negotiation possible:
- the Minimum Acceptable ATM Traffic Descriptor IE allows - the Minimum Acceptable ATM Traffic Descriptor IE allows
negotiation of PCR parameters negotiation of PCR parameters
- the Alternative ATM Traffic Descriptor IE allows negotiation of - the Alternative ATM Traffic Descriptor IE allows negotiation of
other traffic parameters other traffic parameters
A SETUP or CONNECT message may include ONLY one of the above IEs. A SETUP or CONNECT message may include ONLY one of the above IEs.
That is, the calling party may only offer an 'alternative' or That is, the calling party may only offer an 'alternative' or
'minimum' to the requested traffic parameters. (See Section 8 of 'minimum' to the requested traffic parameters. (See Section 8 of
[UNI96].) IP over ATM entities SHOULD take advantage of this capabil- [SIG40].) IP over ATM entities SHOULD take advantage of this capabil-
ity whenever possible. In order to do so, IP over ATM entities SHOULD ity whenever possible. In order to do so, IP over ATM entities SHOULD
specify PCR _equal_ to the link rate in the ATM Traffic Descriptor IE specify PCR _equal_ to the link rate in the ATM Traffic Descriptor IE
of the SETUP message and a minimum of zero PCR in the Minimum Accept- of the SETUP message and a minimum of zero PCR in the Minimum Accept-
able ATM Traffic Descriptor IE. able ATM Traffic Descriptor IE.
5.3.3. Broadband Bearer Capability 5.3.3. Broadband Bearer Capability
A new field in UNI signalling 4.0 called, 'ATM Transfer Capability' A new field in UNI signalling 4.0 called, 'ATM Transfer Capability'
(ATC), has been defined in the Broadband Bearer Capability IE for the (ATC), has been defined in the Broadband Bearer Capability IE for the
purpose of explicitly specifying the desired ATM traffic category. purpose of explicitly specifying the desired ATM traffic category.
The figure below shows the allowable ATC values. The figure below shows the allowable ATC values.
Format and field values of Broadband Bearer Capability IE Format and field values of Broadband Bearer Capability IE
------------------------------------------------------------- -------------------------------------------------------------
| bb_bearer_capability | | bb_bearer_capability |
------------------------------------------------------------| ------------------------------------------------------------|
| spare 0 | | spare 0 |
| bearer_class 16 (bcob-x,c,a or VP) | | bearer_class bcob-x,c,a or VP |
| transfer_capability cbr, rt-vbr, nrt-vbr, abr | | transfer_capability cbr, rt-vbr, nrt-vbr, abr |
| susceptibility_to_clipping 0 (not suscept) | | susceptibility_to_clipping 0 (not suscept) |
| spare 0 | | spare 0 |
| user_plane_configuration pt-to-pt, pt-to-mpt | | user_plane_configuration pt-to-pt, pt-to-mpt |
------------------------------------------------------------- -------------------------------------------------------------
5.3.4. QoS Parameter 5.3.4. QoS Parameter
Inclusion of the QoS Parameter IE is optional in UNI 4.0 signalling. Inclusion of the QoS Parameter IE is not mandatory in SIG 4.0. It
It may be omitted from a SETUP message when the Extended QoS Parame- may be omitted from a SETUP message _if and only if_ the Extended QoS
ters IE, discussed in the next section, is included. This specifica- Parameters IE is included (see next section). This specification
tion makes no explicit recommendation on the use of the QoS related makes no explicit recommendation on the use of the QoS related IEs.
IEs.
5.3.4.1. Two IEs for Signalling of Individual QoS Parameters 5.3.4.1. Two IEs for Signalling of Individual QoS Parameters
UNI 4.0 allows for signalling of individual QoS parameters for the SIG 4.0 allows for signalling of individual QoS parameters for the
purpose of giving the the network and called party a more exact purpose of giving the the network and called party a more exact
description of the desired delay and cell loss characteristics. The description of the desired delay and cell loss characteristics. The
two individual QoS related IEs, Extended QoS Parameters IE and End- two individual QoS related IEs, Extended QoS Parameters IE and End-
to-End Transit Delay IE, can be used in the SETUP and CONNECT signal- to-End Transit Delay IE, can be used in the SETUP and CONNECT signal-
ling messages in place of the 'generic' QoS Parameter IE. Note that ling messages in place of the 'generic' QoS Parameter IE. Note that
inclusion of these two IEs depends on the type of ATM service inclusion of these two IEs depends on the type of ATM service
category requested (see Annex 9 in [TMGT96]). category requested (see Annex 9 in [SIG40]).
5.4. ATM Addressing Information 5.4. ATM Addressing Information
ATM addressing information is carried in the Called Party Number, ATM addressing information is carried in the Called Party Number,
Calling Party Number, and, under certain circumstance, Called Party Calling Party Number, and, under certain circumstance, Called Party
Subaddress, and Calling Party Subaddress IE. The ATM Forum ILMI Subaddress, and Calling Party Subaddress IE. The ATM Forum ILMI
Specification 4.0 provides the procedure for an ATM endsystem to Specification 4.0 [ILMI40] provides the procedure for an ATM endsys-
learn its own ATM address from the ATM network, for use in populating tem to learn its own ATM address from the ATM network, for use in
the Calling Party Number IE. populating the Calling Party Number IE.
Format and field values of Called Party Number IE Format and field values of Called Party Number IE
---------------------------------------------------------- ----------------------------------------------------------
| called_party_number | | called_party_number |
---------------------------------------------------------- ----------------------------------------------------------
| type_of_number (international number / unknown) | | type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) | | addr_plan_ident (ISDN / ATM Endsystem Address) |
| addr_number (E.164 / ATM Endsystem Address) | | addr_number (E.164 / ATM Endsystem Address) |
---------------------------------------------------------- ----------------------------------------------------------
6. ABR Signalling In More Detail 6. ABR Signalling In More Detail
skipping to change at page 10, line 27 skipping to change at page 10, line 42
- Forward/Backward ABR Transient Buffer Exposure - Forward/Backward ABR Transient Buffer Exposure
- Cumulative RM Fixed Round Trip Time - Cumulative RM Fixed Round Trip Time
- Forward/Backward Rate Increment Factor - Forward/Backward Rate Increment Factor
- Forward/Backward Rate Decrease Factor - Forward/Backward Rate Decrease Factor
The ABR Additional Parameters IE contains one subfield: The ABR Additional Parameters IE contains one subfield:
- Forward/Backward Additional Parameters Record - Forward/Backward Additional Parameters Record
The Additional Parameters Record value is a compressed encoding of a The Additional Parameters Record value is a compressed encoding of a
set of ABR parameters (see TMGT96). set of ABR parameters (see [SIG40] and [ABRS]).
7. Frame Discard Capability 7. Frame Discard Capability
The frame discard capability in UNI 4.0 is primarily based on the The frame discard capability in SIG 4.0 is primarily based on the
'Partial and Early Packet Discard' strategy [ROM94]. Its use is 'Partial and Early Packet Discard' strategy [ROM94]. Its use is
defined for any of the ATM services, except for loss-less CBR. Frame defined for any of the ATM services, except for loss-less CBR. Frame
discard signalling MUST be supported by all IP over ATM entities and discard signalling MUST be supported by all IP over ATM entities and
it is RECOMMENDED that frame discard be signalled for all IP SVCs it is RECOMMENDED that frame discard be signalled for all IP SVCs
because it has been proven to increase throughput under network because it has been proven to increase throughput under network
congestion. Signalling for frame discard is done by setting the frame congestion. Signalling for frame discard is done by setting the frame
discard bit in the 'Traffic Management Options' subfield in the discard bit in the 'Traffic Management Options' subfield in the
Traffic Descriptor IE. It is possible that not all network entities Traffic Descriptor IE. It is possible that not all network entities
in the SVC path support frame discard, but it is required that they in the SVC path support frame discard, but it is required that they
all forward the signalling. all forward the signalling.
8. Security Considerations 8. Security Considerations
The ATM Forum has established an ATM Security sub-working group for The ATM Forum Security sub-working group is currently defining secu-
the purpose of defining security mechanisms in ATM. It is therefore rity mechanisms in ATM. The group has yet to produce a specification,
premature to begin defining IP over ATM signalling's use of ATM secu- therefore it is premature to begin defining IP over ATM signalling's
rity. IP Security (RFC1825) can be applied to IP datagrams over any use of ATM security. IP Security (RFC1825) can be applied to IP
medium. datagrams over any medium.
9. Open Issues 9. Open Issues
Description of Leaf Initiated Join (LIJ) signalling is not discussed Description of Leaf Initiated Join (LIJ) signalling is not discussed
because the use of LIJ in IP over ATM has not been defined. because the use of LIJ in IP over ATM environments have not yet been
defined.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank the members of the ION working group The authors would like to thank the members of the ION working group
for their input. for their input. Special thanks to K.K. Ramakrishnan and Kerry Fen-
dick who contributed Appendix B of this document.
REFERENCES REFERENCES
[PER95] Perez*, M. et al, ""ATM Signaling Support for IP over ATM", [PER95] Perez*, M. et al, "ATM Signaling Support for IP over ATM",
RFC1755, February 1995 (* see author's information below) RFC1755, February 1995 (* see author's information below)
[LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577,
Hewlett-Packard Laboratories, December 1993 Hewlett-Packard Laboratories, December 1993
[UNI96] ATM Forum, "ATM User-Network Interface Specification Version [LUC97] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz,
4.0", Prentice Hall, Upper Saddle River, NJ, specification final- Piscitello, Cole, draft-ietf-rolc-nhrp-11.txt. work in progress.
ized July 1996; expected publication, late 1996; available at
ftp://ftp.atmforum.com/pub.
[UNI94] ATM Forum, "ATM User-Network Interface Specification Version [UNI95] ATM Forum, "ATM User-Network Interface Specification Version
3.1", Prentice Hall, Upper Saddle River, NJ, 1995 3.1", Prentice Hall, Upper Saddle River, NJ, 1995
[TMGT96] ATM Forum, "ATM Forum Traffic Management Specification Ver- [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling
sion 4.0", Prentice Hall, Upper Saddle River NJ; specification Specification Version 4.0", af-sig-0061.000, finalized July 1996;
finalized April 1996; expected publication, late 1996; available available at ftp://ftp.atmforum.com/pub.
at ftp://ftp.atmforum.com/pub.
[ABRS] ATM Forum, "Addendum to UNI Signalling v4.0 for ABR Parameter
Negotiation", af-sig-0076.000; available at
ftp://ftp.atmforum.com/pub.
[TMGT40] ATM Forum, "Traffic Management Specification Version 4.0",
af-tm-0056.000, finalized April 1996; available at
ftp://ftp.atmforum.com/pub.
[ABRT] ATM Forum, "Addendum to Traffic Management v4.0 for ABR Param-
eter Negotiation", af-tm-0077.000; available at
ftp://ftp.atmforum.com/pub.
[ILMI40] ATM Forum, "Integrated Local Management Interface (ILMI)
Specification Version 4.0", af-ilmi-0065.000, finalized September
1996; available at ftp://ftp.atmforum.com/pub.
[RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, [RSVP] 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-spec- Specification", Internet Draft, May 1997, <draft-ietf-rsvp-spec-
14.txt> 15.txt>
[LUC97] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz,
Piscitello, Cole, draft-ietf-rolc-nhrp-11.txt. work in progress.
[BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Com- [BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Com-
munication Layers", RFC 1122, USC/Information Science Institute, munication Layers", RFC 1122, USC/Information Science Institute,
October 1989. October 1989.
[BRAD94] Braden, R., Clark, D, Shenker, S., "Integrated Service in [BRAD94] Braden, R., Clark, D, Shenker, S., "Integrated Service in
the Internet Architecture: An Overview", RFC 1633, the Internet Architecture: An Overview", RFC 1633,
USC/Information Science Institute, June 1994. USC/Information Science Institute, June 1994.
[HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta- [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta-
skipping to change at page 12, line 27 skipping to change at page 13, line 4
exchange between systems - Protocol identification in the network exchange between systems - Protocol identification in the network
layer ISO/IEC TR9577 (International Standards Organization: layer ISO/IEC TR9577 (International Standards Organization:
Geneva, 1990) Geneva, 1990)
[ROM94] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM [ROM94] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM
Networks. IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. Abstract. Networks. IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. Abstract.
An earlier version appeared in SIGCOMM '94, August 1994, pp. 79- An earlier version appeared in SIGCOMM '94, August 1994, pp. 79-
88. 88.
Author's Address Author's Address
Maryann P. Maher (formerly Maryann Perez) Maryann P. Maher (formerly Maryann Perez)
{maher@isi.edu}
USC/ISI USC/ISI
4350 N. Fairfax Drive, Suite 620 4350 N. Fairfax Drive, Suite 620
Arlington VA 22203 Arlington VA 22203
Appendix A. A Sample UNI 4.0 SETUP Message Appendix A. A Sample SIG 4.0 SETUP Message
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
SETUP SETUP
Information Elements/ Information Elements/
Fields Value/(Meaning) Fields Value/(Meaning)
-------------------- --------------- -------------------- ---------------
aal_parameters aal_parameters
aal_type 5 (AAL 5) aal_type 5 (AAL 5)
skipping to change at page 13, line 46 skipping to change at page 14, line 46
fwd_peak_cell_rate_0_1_ident 132 fwd_peak_cell_rate_0_1_ident 132
fwd_peak_cell_rate_0_1 0 fwd_peak_cell_rate_0_1 0
bkw_peak_cell_rate_0_1_ident 133 bkw_peak_cell_rate_0_1_ident 133
bkw_peak_cell_rate_0_1 0 bkw_peak_cell_rate_0_1 0
bb_bearer_capability /* a coding for specifying UBR like service */ bb_bearer_capability /* a coding for specifying UBR like service */
spare 0 spare 0
bearer_class 16 (BCOC-X) bearer_class 16 (BCOC-X)
spare 0 spare 0
atm_transfer_capability 10 (nrt-vbr) atm_transfer_capability 10 (nrt-vbr)
timing_requirements 10 (timing not required)
susceptibility_to_clipping 0 (not susceptible to clipping) susceptibility_to_clipping 0 (not susceptible to clipping)
spare 0 spare 0
user_plane_configuration 0 (point_to_point) user_plane_configuration 0 (point_to_point)
bb_low_layer_information bb_low_layer_information
layer_2_id 2 layer_2_id 2
user_information_layer 12 (lan_llc - ISO 8802/2) user_information_layer 12 (lan_llc - ISO 8802/2)
qos_parameter qos_parameter
qos_class_fwd 0 (class 0) qos_class_fwd 0 (class 0)
skipping to change at page 15, line 25 skipping to change at page 16, line 25
For ATM connections used to interconnect routers, a non-zero For ATM connections used to interconnect routers, a non-zero
bandwidth reservation may be required to achieve consistently ade- bandwidth reservation may be required to achieve consistently ade-
quate performance for the aggregate set of flows. The support of quate performance for the aggregate set of flows. The support of
bandwidth commitments for an ATM connection carrying IP traffic helps bandwidth commitments for an ATM connection carrying IP traffic helps
to assure that a certain fraction of each link's capacity is reserved to assure that a certain fraction of each link's capacity is reserved
for the total IP traffic between the routers. Reserving bandwidth for the total IP traffic between the routers. Reserving bandwidth
for the aggregation of best-effort traffic between a pair of routers for the aggregation of best-effort traffic between a pair of routers
is analogous to provisioning a particular link bandwidth between the is analogous to provisioning a particular link bandwidth between the
routers. There are at least 3 service classes defined in the ATM routers. There are at least 3 service classes defined in the ATM
Traffic Management specification that provide varying degrees of Traffic Management specification that provide varying degrees of
capabilty that are suitable for interconnecting IP routers: UBR, ABR capability that are suitable for interconnecting IP routers: UBR, ABR
and VBR non-real-time. Although the use of best-effort service (UBR) and VBR non-real-time. Although the use of best-effort service (UBR)
at the ATM layer is the most straightforward and uncomplicated, it at the ATM layer is the most straightforward and uncomplicated, it
lacks the capability to enforce bandwidth commitments. lacks the capability to enforce bandwidth commitments.
Note that we are talking of providing a "virtual link" between Note that we are talking of providing a "virtual link" between
routers, for the aggregate traffic. The provisioning is for the routers, for the aggregate traffic. The provisioning is for the
aggregate. It is therefore distinct from the per-flow bandwidth aggregate. It is therefore distinct from the per-flow bandwidth
reservations that might be appropriate for Integrated Services. reservations that might be appropriate for Integrated Services.
Even best-effort IP flows, when supported on an aggregate basis, have Even best-effort IP flows, when supported on an aggregate basis, have
skipping to change at page 16, line 22 skipping to change at page 17, line 22
Peak Cell Rate (likely the link rate), (ii) the Minimum Cell Rate Peak Cell Rate (likely the link rate), (ii) the Minimum Cell Rate
(the committed rate), and (iii) the Cumulative RM Fixed Round-Trip (the committed rate), and (iii) the Cumulative RM Fixed Round-Trip
Time The remaining parameter values, if left unspecified by the cal- Time The remaining parameter values, if left unspecified by the cal-
ling party, are selected by the network or are chosen from the ling party, are selected by the network or are chosen from the
default values specified in the ATM Forum Traffic Management specifi- default values specified in the ATM Forum Traffic Management specifi-
cation. cation.
Parameters (i) and (ii) are contained in the mandatory Traffic Parameters (i) and (ii) are contained in the mandatory Traffic
Descriptor IE, whereas parameter (iii) is contained in the mandatory Descriptor IE, whereas parameter (iii) is contained in the mandatory
ABR Setup Parameters IE. Other paramenters in the ABR Setup Parame- ABR Setup Parameters IE. Other paramenters in the ABR Setup Parame-
ters IE may be ommitted. (Note that the third IE which pertains to ters IE may be omitted. (Note that the third IE which pertains to ABR
ABR signalling, the ABR Additional Parameters IE, is an optional IE signalling, the ABR Additional Parameters IE, is an optional IE and
and therefore need not be include.) Parameter (iii) is dependent on therefore need not be included.) Parameter (iii) is dependent on the
the hardware of the end system, so that the default value specified hardware of the end system, so that the default value specified for
for that hardware should be used. In the absense of such a default, a that hardware should be used. In the absense of such a default, a
value of zero MAY be specified by the end system. Entities using ABR value of zero MAY be specified by the end system. Entities using ABR
connections for IP over ATM SHOULD take advantage of parameter nego- connections for IP over ATM SHOULD take advantage of parameter nego-
tiation by specifying Peak Cell Rate equal to the link rate in the tiation by specifying Peak Cell Rate equal to the link rate in the
ATM Traffic Descriptor IE of the SETUP message. The value selected ATM Traffic Descriptor IE of the SETUP message. The value selected
for the Minimum Cell Rate is implementation specific. Note that the for the Minimum Cell Rate is implementation specific. Note that the
MCR also MAY be negotiated if an MCR parameter is included by the end MCR also MAY be negotiated if an MCR parameter is included by the end
system in the Minimum Acceptable ATM Traffic Descriptor IE. The use system in the Minimum Acceptable ATM Traffic Descriptor IE. The use
of MCR negotiation by the end system is implementation specific. of MCR negotiation by the end system is implementation specific.
Also, note that Frame Discard MAY be requested for ABR connections as Also, note that Frame Discard MAY be requested for ABR connections as
for UBR connections. Although the ABR service attempts to minimize well as for UBR connections. Although the ABR service attempts to
cell loss, the use of Frame Discard may improve throughput when cell minimize cell loss, the use of Frame Discard may improve throughput
loss is not eliminated. when cell loss is not eliminated.
ATM recognizes in addition to the service class (UBR, ABR, etc.), a
notion of a QoS class. The QoS class specifies the type of guarantee
requested of the network when the call is setup. This is distinct
from the service class requested for the connection, and the specifi-
cation of the traffic parameters (which specify what the source's
traffic will look like). QoS class 0 is the "simplest", and is
called the Unspecified QoS class. In the context of ABR (and VBR
non-realtime below), we are only concerned with the QoS class provid-
ing an assurance of acceptable loss behavior for the connection.
The Unspecified QoS Class (QoS Class 0) MUST be requested for ABR
connections. In this context, QoS Class 0 corresponds to a network-
specific objective for the cell loss ratio. Networks in general are
expected to support a low Cell Loss Ratio for ABR sources that adjust
cell flow in response to control information.
The VBR-nrt service category provides an alternate means of achieving The VBR-nrt service category provides an alternate means of achieving
better throughput and delay. This better performance may be obtained these characteristics. These characteristics may be obtained with
with VBR-nrt connections for which (i) the VBR.3 conformance defini- VBR-nrt connections for which (i) the VBR.3 conformance definition is
tion is used, (ii) a Sustainable Cell Rate (SCR) and Maximum Burst used, (ii) a Sustainable Cell Rate (SCR) and Maximum Burst Size
Size (MBS), and Peak Cell Rate (PCR) are specified, and (iii) both (MBS), and Peak Cell Rate (PCR) are specified, and (iii) both tagging
tagging and frame discard are requested. A request for tagging indi- and frame discard are requested. A request for tagging indicates
cates that best-effort delivery is desired for traffic offered in that best-effort delivery is desired for traffic offered in excess of
excess of the SCR and MBS. A request for frame discard indicates to the SCR and MBS. A request for frame discard indicates to the net-
the network that the user desires allocations of committed and excess work that the user desires allocations of committed and excess
bandwidth to translate into corresponding throughputs at the frame bandwidth to translate into corresponding throughputs at the frame
level. level.
As with UBR connections, entities using VBR-nrt connections for IP As with UBR connections, entities using VBR-nrt connections for IP
over ATM should take advantage of parameter negotiation by specifying over ATM should take advantage of parameter negotiation by specifying
PCR equal to the link rate in the ATM Traffic Descriptor IE of the PCR equal to the link rate in the ATM Traffic Descriptor IE of the
SETUP message and PCR equal to SCR in the Minimum Acceptable Traffic SETUP message and PCR equal to SCR in the Minimum Acceptable Traffic
descriptor. The selection of SCR, MBS, and CLR (cell loss ratio) descriptor. The selection of SCR, MBS, and CLR (cell loss ratio)
should be implementation specific. However, for IP over ATM, an MBS should be implementation specific. However, for IP over ATM, an MBS
value of N*(Maximum MTU) is RECOMMENDED, where N>=1 with a default of value of N*(Maximum MTU) is RECOMMENDED, where N>=1 with a default of
2 and where Maximum MTU is equal to 192 cells (consistent with an IP 2 and where Maximum MTU is equal to 192 cells (consistent with an IP
MTU size of 9180 bytes [RFC1626]). MTU size of 9180 bytes [RFC1626]).
Appendix C. Combinations of Traffic Related Parameters Appendix C. Combinations of Traffic Related Parameters
This appendix contains a copy of the five tables found in Annex 9 of This appendix contains a copy of the five tables found in Annex 9 of
[UNI96] which show the allowable combinations of traffic and QoS related [SIG40] which show the allowable combinations of traffic and QoS related
parameters in a UNI 4.0 SETUP message. parameters in a SIG 4.0 SETUP message.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|ATM Service Category| CBR | |ATM Service Category| CBR |
|--------------------|---------------|---------------|---------------| |--------------------|---------------|---------------|---------------|
| Conformance |CBR.1 (note 10)| (note 4) | (note 4) | | Conformance |CBR.1 (note 10)| (note 4) | (note 4) |
|--------------------|---------------|---------------|---------------| |--------------------|---------------|---------------|---------------|
| Bearer Capability | | | | | Bearer Capability | | | |
|--------------------|---------------|---------------|---------------| |--------------------|---------------|---------------|---------------|
| BB Bearer Class | A | X | VP | A | X | VP^| A | X | VP^| | BB Bearer Class | A | X | VP | A | X | VP^| A | X | VP^|
|--------------------|---------------|----|-----|----|----|-----|----| |--------------------|---------------|----|-----|----|----|-----|----|
 End of changes. 48 change blocks. 
116 lines changed or deleted 147 lines changed or added

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