RFC 2331
ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update
RFC 2331: ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update 🎀
Title block, the facts first 📋
- Series: Network Working Group
- RFC number: 2331
- Author: M. Maher, USC/ISI
- Category: Standards Track
- Date: April 1998
- Obsoletes / Updates: The header has no Obsoletes line, but the text says this is a follow-on to RFC 1755, and Section 3.1 updates RFC 1755's VC teardown requirements. 🔁
Status of This Memo 📜
Okay so this document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice ⚖️
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract 🦋
Bestie, this memo explains how to use the ATM call control signalling procedures from UNI Signalling 4.0 [SIG40] efficiently, so IP over ATM environments work well. The IP over ATM setups it's talking about are described in RFC 2225 [LAUB98] and RFC 2332 [LUC98] 🌸 UNI Signalling 4.0 is giving us new stuff like Available Bit Rate signalling and traffic parameter negotiation, and the memo highlights the features that let IP entities request ATM service at sites with SVC support. That covers private ATM, and publicly provisioned ATM too, where the SVC support is probably configured inside PVPs ✨
This document is only relevant to IP when it's used as the well known "best effort" connectionless service. So it does NOT cover IP when IP Integrated Services are implemented 🙅♀️ IP with Integrated Services over ATM will be handled by a different specification (or set of specifications) that the ISSLL WG is working on.
This specification is a follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI 3.1 signalling [UNI95]. Readers are assumed to be familiar with RFC 1755, so go read that first 📚🧚
Table of Contents 🗂️
1. Conventions ............................................... 2
2. Overview .................................................. 2
3. Use of Protocol Procedures ................................ 3
3.1 VC Teardown........................................... 3
4. Overview of Call Establishment Message Content ............ 3
5. Description of Information Elements ....................... 4
5.1 ATM Adaptation Layer Parameters ...................... 4
5.2 Broadband Low Layer Information ..................... 5
5.3 Traffic Management Issues and Related IEs............. 5
5.3.1 ATM Traffic Descriptor ........................ 6
5.3.1.1 Tagging vs. Dropping ................. 7
5.3.2 Traffic Parameter Negotiation .................. 7
5.3.3 Broadband Bearer Capability .................... 8
5.3.4 QoS Parameter .................................. 8
5.3.4.1 Signalling of Individual QoS Parameters 8
5.4 ATM Addressing Information ........................... 9
6. ABR Signalling In More Detail ............................ 9
7. Frame Discard Capability .................................. 10
8. Security Considerations ................................... 10
9. Acknowledgements........................................... 10
10. References ................................................ 10
11. Author's Address .......................................... 12
Appendix A Sample Signalling Messages ........................ 13
Appendix B ABR and nrt-VBR Signalling Guidelines for IP Routers 15
Appendix C Combinations of Traffic Related Parameters ........ 18
Full Copyright Statement ...................................... 261. Conventions ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97]. These are the BCP 14 key words, so pay attention to them 👑
2. Overview 🌈
Okay so UNI Signalling version 4.0 (SIG 4.0) is the ATM Forum's follow-on spec to UNI 3.1 signalling (UNI 3.1) 💖 Among the new features in SIG 4.0, these are the ones that matter most for IP over ATM environments:
- Available Bit Rate (ABR) Signalling for Point-to-Point Calls
- Traffic Parameter Negotiation
- Frame Discard Support
- Leaf Initiated Join (LIJ) Capability
- ATM Anycast Capability
- Switched Virtual Path (VP) Service
This memo highlights the first three capabilities on that list. The last three are not discussed because models for using them in IP over ATM environments have not been defined yet 🙈 The ION WG is looking at whether LIJ and Group Addressing apply to the RFC2022 problem space. Anycast addressing is also being explored as a technique for supporting server discovery in ATM networks 🔍
3. Use of Protocol Procedures 🛠️
Section 3 in RFC 1755 introduces requirements for virtual circuit (VC) management, which are meant to prevent VC thrashing, excessive VC consumption, and other related problems. This section updates RFC 1755's requirements related to VC teardown 🦋
3.1. VC Teardown 💀
In environments running layer 3 (L3) signalling protocols, like RSVP [RSVP], over ATM, data VCs might correspond to L3 reserved flows (even if the VC is a 'best effort' VC). In those environments it's beneficial for VCs to be torn down only when the L3 reservation has expired. Put another way, it's more efficient for the sender of an L3 reserved flow to start VC tear-down once the receiver(s) stop refreshing the reservation 🧚
To support that L3 behavior, systems implementing a Public ATM UNI interface and serving as the _called_ party of a VCC MUST NOT use an inactivity timer on such a VCC by default. A system MAY use an inactivity timer on such a VCC if it's configured to do so ⏱️
Read that MUST NOT carefully. The default is no inactivity timer, and only configuration turns one on.
4. Overview of Call Establishment Message Content 📨
Signalling messages are structured to contain mandatory and optional variable length information elements (IEs) 🧩 A SETUP message that establishes an ATM connection for IP and multiprotocol interconnection calls MUST contain the following IEs:
AAL Parameters
ATM Traffic Descriptor
Broadband Bearer Capability
Broadband Low Layer Information
QoS Parameter
Called Party Number
Calling Party NumberIt MAY, under certain circumstance, contain the following IEs:
Calling Party Subaddress
Called Party Subaddress
Transit Network Selection
(New in SIG 4.0:)
Minimum Acceptable ATM Traffic Descriptor
Alternative ATM Traffic Descriptor
ABR Setup Parameters
ABR Additional Parameters
Connection Scope Selection
Extended QoS Parameters
End-to-End Transit DelayIn SIG 4.0, like UNI 3.1, the AAL Parameters and the Broadband Low Layer Information IEs are optional in a SETUP message. BUT, in support of IP over ATM, these two IEs MUST be included 😤 Appendix A shows a sample setup message, so peek at that when you need an example 👀
5. Description of Information Elements 🎀
This section covers how information elements in SETUP and CONNECT messages are coded, plus the procedures around them. The first two IEs, ATM Adaptation Layer Parameters and Broadband Low Layer Information, only matter to the endpoints of an ATM call that supports IP. The network does not process these IEs, so it's basically hands off 🙌
5.1. ATM Adaptation Layer (AAL) Parameters 🧃
The AAL Parameters IE carries info about the ATM adaptation layer to be used on the connection. The parameters in this IE are the same as the ones specified in [PER95].
Format and field values of AAL Parameters IE:
----------------------------------------------------------
| aal_parameters |
----------------------------------------------------------
| aal_type 5 (AAL 5) |
| fwd_max_sdu_size_identifier 140 |
| fwd_max_sdu_size 65,535 (desired IP MTU) |
| bkw_max_sdu_size_identifier 129 |
| bkw_max_sdu_size 65,535 (desired IP MTU) |
| sscs_type identifier 132 |
| sscs_type 0 (null SSCS) |
----------------------------------------------------------This shows maximum size MTUs. In practice, most sites have used 9180 IP MTUs for ATM [RFC1626] 📏
5.2. Broadband Low Layer Information 🌸
Picking an encapsulation to support IP over an ATM VCC is done using the Broadband Low Layer Information (B-LLI) IE, together with the AAL Parameters IE and the B-LLI negotiation procedure. B-LLI negotiation is described in [PER95] in Appendix D, and the procedures stay the same for this SIG 4.0 based specification 💖
Format of B-LLI IE indicating LLC/SNAP encapsulation:
----------------------------------------------------------
| bb_low_layer_information |
----------------------------------------------------------
| layer_2_id 2 |
| user_information_layer 12 (lan_llc - ISO 8802/2) |
----------------------------------------------------------5.3. Traffic Management Issues and Related IEs ✨
Okay bestie, the ATM Forum Traffic Management Sub-working group finished version 4.0 of their spec [TMGT40] 📚 This version is mostly about the ABR service category. Unlike UBR, ABR uses rate-based flow control to promise certain traffic guarantees, like bandwidth and delay 🦋 People have argued a LOT about whether IP even benefits from ABR and, if so, how IP should use it 🙈 It gets messy with IP Integrated Services (IIS) and RSVP because mapping IIS traffic classes onto ATM traffic classes is not straightforward at all 💀
This document only covers the required IP to ATM signalling interface for IP over ATM systems that don't support IIS yet 🌸 The goal is to get IP over ATM vendors to support enough options for signalling the traffic characteristics of VCs that carry non-IIS IP datagrams 💖 It's also meant to help ATM system administrators configure their IP over ATM entities so they match whatever services their ATM provider sold them 🎀 By definition, IP without IIS can't be expected to offer a flexible signalling interface that allows application-specific traffic descriptors, so no, it can't do that 🙃 IP over ATM signalling for IP with IIS is being handled in other specs from the ISSLL WG of the IETF 🫶
An IP over ATM interface may be configured to support all the defined ATM Service Categories (ASC) ✨ They are:
- CBR
- CBR with CLR specified (loss-permitting CBR)
- ABR
- UBR
- real time VBR
- non-real time VBR
The ATM Traffic Descriptor IE, the Broadband Bearer Capability IE and the QoS Parameter IE together define the signalling view of ATM traffic management 🧚 The Extended QoS Parameters IE and the End-to-end Transit Delay IE can also be used to give more detail about traffic requirements, but this note doesn't make any explicit recommendations about using them 🤷♀️ Annex 9 of [SIG40] lists allowable combinations of traffic and QoS related parameters defined for SIG 4.0 👑 That set includes every form of non-IIS IP signalling configuration that MUST be implemented in ATM endsystems so they can handle all kinds of sites' needs 😭 The main idea is that IP over ATM service might be available at different sites through different types of procured ATM service 🌈 For example, one site might find a CBR PVP cost-effective, which means the SVCs that IP over ATM without IIS sets up have to be CBR too 💅 VBR or ABR PVPs can be provisioned in the same way 💜 This document's goal is to specify the most sensible parameters within this non-IIS configuration 🍓 For instance, for non-IIS VBR, the SCR value might need to be hand-configured for IP users, or for ABR, the PCR value could be the link rate with a 0 MCR 🔥
For your convenience, we copied the tables from Annex 9 of [SIG40] into Appendix C of this document 📋 Ideally this document could recommend specific values for the various table parameters that would give the most sensible IP over ATM service 🥹 But it's not possible to mandate specific values, because the procured ATM service scenarios vary so much 😔
5.3.1. ATM Traffic Descriptor 🦋
Even with the new ABR ASC, the most convenient model for supporting IP still matches the best effort capability, which is the UBR ASC 💖 The reason is that a non-IIS IP service has no idea what performance requirements the higher layers it supports actually have 🙈 So if a site's configuration allows UBR, users SHOULD signal for it using the IEs and parameters that belong to the UBR ATC 🫶 See Appendix C for the list of those IEs and parameters 📚
We think UBR is the most natural ASC for best-effort IP, but ATM vendors that implement VBR and ABR services might create hooks that make those easier to use 🌟 If they do, IP routers may have the most to gain from VBR or ABR services, because they have to forward a huge amount of aggregated traffic 🚀 See Appendix B for detailed suggestions on VBR and ABR signalling for IP routers 🧠 Just so you know, SIG 4.0 added two new subfields to the Traffic Descriptor IE to support ABR service: the forward and backward 'Minimum Cell Rate' fields 💅
5.3.1.1. Tagging vs. Dropping 🏷️
The Traffic Descriptor IE has a 'tagging' subfield that says whether the network is allowed to tag the source's data cells ✨ Tagging can happen in the network during congestion, or when the source's traffic has broken the traffic contract for the connection 😬 See Section 4 of [TMGT40] for an explanation of ATM connection conformance and the Usage Parameter Control (UPC) function 📖
SIG 4.0 and TMGT 4.0 define two modes of UBR: UBR.1, which disables tagging, and UBR.2, which enables it (see Appendix C) 💜 In some network environments, UBR traffic sources have no way to violate the connection traffic contract, either because the user's terminal equipment supports traffic shaping or because the network doesn't enforce PCR 🥳 In those environments, the user SHOULD specify 'no tagging' in the SETUP message (UBR.1) 🙌 Specifying 'no tagging' tells the network to drop cells during congestion instead of randomly marking/tagging them as low priority 🗑️ The cells of packets that the source has already marked as low priority get dropped first, which keeps the source's characterization of the traffic intact 🦋
On the other hand, when the network applies PCR to the UPC function (meaning it enforces PCR) and traffic shaping isn't enabled at the source, the source could violate the traffic contract 😰 So it SHOULD therefore signal for tagging (UBR.2) 🫣 Tagging lets the source's non-conforming cells be tagged and forwarded instead of dropped 🌈
5.3.2. Traffic Parameter Negotiation 🤝
SIG 4.0 lets certain traffic parameters be negotiated during the call establishment phase 🎀 Traffic parameters can't be 'renegotiated' once the call is active, so this is your one shot 😭 Two new IEs make negotiation possible:
- the Minimum Acceptable ATM Traffic Descriptor IE allows negotiation of PCR parameters
- the Alternative ATM Traffic Descriptor IE allows negotiation of other traffic parameters
A SETUP or CONNECT message may include ONLY one of the above IEs 🙅♀️ So the calling party can only offer an 'alternative' or a 'minimum' to the requested traffic parameters, not both (See Section 8 of [SIG40].) 📖 IP over ATM entities SHOULD take advantage of this whenever possible 🫶 To do that, they SHOULD 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 Acceptable ATM Traffic Descriptor IE 🔥
5.3.3. Broadband Bearer Capability 🧚
UNI signalling 4.0 has a new field called 'ATM Transfer Capability' (ATC) 💅 It's defined in the Broadband Bearer Capability IE so you can explicitly specify the ATM traffic category you want 🎯 The figure below shows the allowable ATC values 👀
Format and field values of Broadband Bearer Capability IE
-------------------------------------------------------------
| bb_bearer_capability |
------------------------------------------------------------|
| spare 0 |
| bearer_class bcob-x,c,a or VP |
| transfer_capability cbr, rt-vbr, nrt-vbr, abr |
| susceptibility_to_clipping 0 (not suscept) |
| spare 0 |
| user_plane_configuration pt-to-pt, pt-to-mpt |
-------------------------------------------------------------5.3.4. QoS Parameter 📊
Including the QoS Parameter IE is not mandatory in SIG 4.0 🙂 It can be left out of a SETUP message if and only if the Extended QoS Parameters IE is included (see next section) 🫶 This specification doesn't make any explicit recommendation about using the QoS related IEs 🤷♀️
5.3.4.1. Two IEs for Signalling of Individual QoS Parameters 🎯
SIG 4.0 lets you signal individual QoS parameters, so the network and called party get a more exact description of the delay and cell loss characteristics you want 🥹 The two individual QoS related IEs, the Extended QoS Parameters IE and the End-to-End Transit Delay IE, can be used in the SETUP and CONNECT signalling messages in place of the 'generic' QoS Parameter IE ✨ Whether you can include these two IEs depends on the type of ATM service category requested (see Annex 9 in [SIG40]) 💅
5.4. ATM Addressing Information 📮
ATM addressing information is carried in the Called Party Number IE, the Calling Party Number IE and, in certain circumstances, the Called Party Subaddress and Calling Party Subaddress IEs 🧚 The ATM Forum ILMI Specification 4.0 [ILMI40] describes how an ATM endsystem can learn its own ATM address from the ATM network, so it can fill in the Calling Party Number IE 🌸
Format and field values of Called Party Number IE
----------------------------------------------------------
| called_party_number |
----------------------------------------------------------
| type_of_number (international number / unknown) |
| addr_plan_ident (ISDN / ATM Endsystem Address) |
| addr_number (E.164 / ATM Endsystem Address) |
----------------------------------------------------------6. ABR Signaling In More Detail 🔥
The IEs and procedures for ABR signalling are briefly described in this section 📝 Even so, this document makes no specific recommendation on when to use the ABR service category for IP VCCs, and it doesn't suggest values for the various parameters in the ABR related IEs 🙈
Two new IEs have been defined for ABR signalling:
- ABR Setup Parameters
- ABR Additional Parameters
These IEs may optionally be included in a SETUP or CONNECT message 🎀 The ABR Setup Parameters IE contains the following subfields:
- Forward/Backward ABR Initial Cell Rate
- Forward/Backward ABR Transient Buffer Exposure
- Cumulative RM Fixed Round Trip Time
- Forward/Backward Rate Increment Factor
- Forward/Backward Rate Decrease Factor
The ABR Additional Parameters IE contains one subfield:
- Forward/Backward Additional Parameters Record
The Additional Parameters Record value is a compressed encoding of a set of ABR parameters (see [SIG40] and [ABRS]) 🦋
7. Frame Discard Capability 🗑️✨
okay so frame discard in SIG 4.0 is basically built on the 'Partial and Early Packet Discard' strategy [ROM94] 💅. It works for any of the ATM services, except loss-less CBR (sorry CBR, not this time 🙈).
Frame discard signaling MUST be supported by all IP over ATM entities. It's also RECOMMENDED that you signal frame discard for all IP SVCs, bc it has been proven to increase throughput when the network is congested 🔥. To signal it, you set the frame discard bit in the 'Traffic Management Options' subfield of the Traffic Descriptor IE.
Not every network entity on the SVC path has to support frame discard, but they are required to forward the signaling anyway 🫶.
8. Security Considerations 🚨
Okay, this part is serious bestie 😭. The ATM Forum Security sub-working group is still defining security mechanisms for ATM, and they haven't produced a specification yet. That means it's premature to start defining how IP over ATM signalling uses ATM security 🙅♀️.
The ATM Forum is working on authentication mechanisms for signalling, and on mechanisms for data integrity and confidentiality (e.g encryption). Until those exist, there's no way to authenticate who sent a signalling message, like a connection setup request or a connection teardown request. Anyone could send one and it would look legit 💀.
IP Security (RFC1825) can be applied to IP datagrams over ATM VCs to make up for the lack of security at the ATM layer. So if you're worried about this, go look at that one 🔐.
9. Acknowledgements 🎀
The authors want to thank the members of the ION working group for their input 🥹. Special shoutout to K.K. Ramakrishnan and Kerry Fendick, who contributed Appendix B of this document 👑.
REFERENCES 📚
- [ABRS] ATM Forum, "Addendum to UNI Signalling v4.0 for ABR Parameter Negotiation", af-sig-0076.000; available at ftp://ftp.atmforum.com/pub.
- [ABRT] ATM Forum, "Addendum to Traffic Management v4.0 for ABR Parameter Negotiation", af-tm-0077.000; available at ftp://ftp.atmforum.com/pub.
- [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
- [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Service in the Internet Architecture: An Overview", RFC 1633, June 1994.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
- [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.
- [ISO8473] ISO/IEC 8473, Information processing systems - Data communications - Protocol for providing the connectionless-mode network service, 1988.
- [ISO9577] Information Technology - Telecommunication and information exchange between systems - Protocol identification in the network layer ISO/IEC TR9577 (International Standards Organization: Geneva, 1990)
- [LAUB98] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
- [LUC98] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
- [RFC1755] Perez*, M., et. al., "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. (* see author's information below)
- [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. An earlier version appeared in SIGCOMM '94, August 1994, pp. 79-88.
- [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
- [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification Version 4.0", af-sig-0061.000, finalized July 1996; 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.
- [UNI95] ATM Forum, "ATM User-Network Interface Specification Version 3.1", Prentice Hall, Upper Saddle River, NJ, 1995.
Author's Address 🖋️
Maryann P. Maher (formerly Maryann Perez)
USC/ISI
4350 N. Fairfax Drive, Suite 620
Arlington VA 22203
EMail: maher@isi.eduAppendix A. A Sample SIG 4.0 SETUP Message 🧚
+--------------------------------------------------------------------+
SETUP
Information Elements/
Fields Value/(Meaning)
-------------------- ---------------
aal_parameters
aal_type 5 (AAL 5)
fwd_max_sdu_size_ident 140
fwd_max_sdu_size (xmit IP MTU value)
bkw_max_sdu_size_ident 129
bkw_max_sdu_size (recv IP MTU, 0 for disallowing return traffic)
sscs_type identifier 132
sscs_type 0 (null SSCS)
traffic_descriptor
fwd_peak_cell_rate_0_1_ident 132
fwd_peak_cell_rate_0_1 (link rate)
bkw_peak_cell_rate_0_1_ident 133
bkw_peak_cell_rate_0_1 (link rate)
traff_mngt_options_ident 191
fwd_frame_discard 1 (on)
bkw_frame_discard 1 (on if return traffic indicated)
spare 0
tagging_bkw 1 (on)
tagging_fwd 1 (on if return traffic indicated)
best_effort_indication 190 (on)
minimum_acceptable_traffic_descriptor
fwd_peak_cell_rate_0_1_ident 132
fwd_peak_cell_rate_0_1 0
bkw_peak_cell_rate_0_1_ident 133
bkw_peak_cell_rate_0_1 0
bb_bearer_capability /* a coding for specifying UBR like service */
spare 0
bearer_class 16 (BCOC-X)
spare 0
atm_transfer_capability 10 (nrt-vbr)
susceptibility_to_clipping 0 (not susceptible to clipping)
spare 0
user_plane_configuration 0 (point_to_point)
bb_low_layer_information
layer_2_id 2
user_information_layer 12 (lan_llc - ISO 8802/2)
qos_parameter
qos_class_fwd 0 (class 0)
qos_class_bkw 0 (class 0)
called_party_number
type_of_number (international number / unknown)
addr_plan_ident (ISDN / ATM Endsystem Address)
number (E.164 / ATM Endsystem Address)
calling_party_number
type_of_number (international number / unknown)
addr_plan_ident (ISDN / ATM Endsystem Address)
presentation_indic (presentation allowed)
spare 0
screening_indic (user_provided verified and passed)
number (E.164 / ATM Endsystem Address)
+--------------------------------------------------------------------+
Figure 1.
Sample contents of SETUP messageAppendix B. ABR and VBR Signaling Guidelines for IP Routers 🌸
okay bestie, when ATM is used to connect routers that are doing best effort service 💅, the ATM connection usually carries an aggregate of IP flows, like all the best effort IP traffic between a pair of routers. ATM is getting more "packet friendly" (frame discard is a big one 🎀), so it's worth looking at how a VC can give service that's as good as or better than a dedicated or leased "link" when it comes to performance and packet loss ✨.
For ATM connections used to interconnect routers, a non-zero bandwidth reservation may be required to get consistently adequate performance for the aggregate set of flows 🫶. Supporting bandwidth commitments for an ATM connection that carries IP traffic helps make sure a certain fraction of each link's capacity is reserved for all the IP traffic between the routers. Reserving bandwidth for the aggregate of best-effort traffic between two routers is basically like provisioning a particular link bandwidth between them 🦋. There are at least 3 service classes in the ATM Traffic Management specification that are good for interconnecting IP routers: UBR, ABR and VBR non-real-time 🌈. Best-effort service (UBR) at the ATM layer is the most straightforward and uncomplicated option, but it can't enforce bandwidth commitments 💀.
Note that we're talking about a "virtual link" between routers, for the aggregate traffic. The provisioning is for the aggregate, so it's totally distinct from the per-flow bandwidth reservations that might fit Integrated Services 🧚.
Even best-effort IP flows, when they're supported on an aggregate basis, have some broad service goals 🍓. The primary one is keeping the packet loss rate reasonably small. A service class that strives for this, while balancing complexity against adequate service, is desirable. This memo recommended that UBR be the default service for this. UBR with (some form of) packet discard has the desirable goal of being simple in function, and it looks like vendors will be supporting it. However, when they're available, it can be really worth considering the ABR and VBR non-real-time service classes ✨.
Because AAL5 frames with missing cells get discarded by the receiver, ATM bandwidth commitments are most useful when they're supported as a committed rate of cell delivery in complete, non-errored AAL5 frames delivered to the receiver 💜. On top of that, it's desirable for the ATM connection to deliver additional complete frames, beyond that commitment, on a best-effort basis 🌸.
These characteristics can be achieved through the ABR service category using a Minimum Cell Rate, as long as the ABR service is supported by the ATM endpoints and efficient frame discard is supported at the ABR source 🔥. The mechanisms put in place for the ABR service strive to keep loss quite low within the ATM network 🫶.
The parameters that should be specified by the end system are (i) the Peak Cell Rate (likely the link rate), (ii) the Minimum Cell Rate (the committed rate), and (iii) the Cumulative RM Fixed Round-Trip Time. Any remaining parameter values that the calling party leaves unspecified are selected by the network or chosen from the default values in the ATM Forum Traffic Management specification 📋.
Parameters (i) and (ii) are contained in the mandatory Traffic Descriptor IE, while parameter (iii) is contained in the mandatory ABR Setup Parameters IE. Other parameters in the ABR Setup Parameters IE can be omitted. (Note that the third IE for ABR signalling, the ABR Additional Parameters IE, is an optional IE, so it doesn't have to be included 🙈.) Parameter (iii) depends on the hardware of the end system, so the default value specified for that hardware should be used. In the absence of such a default, a value of zero MAY be specified by the end system 🍓. Entities using ABR connections for IP over ATM SHOULD take advantage of parameter negotiation by specifying Peak Cell Rate equal to the link rate in the ATM Traffic Descriptor IE of the SETUP message. The value selected 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 system in the Minimum Acceptable ATM Traffic Descriptor IE. How the end system uses MCR negotiation is implementation specific. Also, Frame Discard MAY be requested for ABR connections as well as for UBR connections. Although the ABR service attempts to minimize cell loss, Frame Discard may improve throughput when cell loss isn't 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 set up. It's distinct from the service class requested for the connection, and from the specification of the traffic parameters (which describe 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-real-time below), we only care about the QoS class that provides 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 these characteristics 🧁. They may be obtained with VBR-nrt connections for which (i) the VBR.3 conformance definition is used, (ii) a Sustainable Cell Rate (SCR), a Maximum Burst Size (MBS), and a Peak Cell Rate (PCR) are specified, and (iii) both tagging and frame discard are requested. A request for tagging indicates that best-effort delivery is desired for traffic offered in excess of the SCR and MBS. A request for frame discard tells the network that the user wants allocations of committed and excess bandwidth to translate into corresponding throughputs at the frame level.
As with UBR connections, entities using VBR-nrt connections for IP over ATM should take advantage of parameter negotiation by specifying 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 descriptor. The selection of SCR, MBS, and CLR (cell loss ratio) 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 2, and where Maximum MTU is equal to 192 cells (consistent with an IP MTU size of 9180 bytes [RFC1626]).
Appendix C. Combinations of Traffic Related Parameters 🎀
This appendix contains a copy of the five tables found in Annex 9 of [SIG40], which show the allowable combinations of traffic and QoS related parameters in a SIG 4.0 SETUP message 💜.
+--------------------------------------------------------------------+
|ATM Service Category| CBR |
|--------------------|---------------|---------------|---------------|
| Conformance |CBR.1 (note 10)| (note 4) | (note 4) |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | A | X | VP | A | X | VP^| A | X | VP^|
|--------------------|---------------|----|-----|----|----|-----|----|
| ATM Transfer | | | 4,5,| | | 4,5,| |
| Capability (note 1)| 7 | abs| or 6| 5 | abs| or 6| 5 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | | | S |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | | | |
|--------------------|---------------|---------------|---------------|
| Best Effort | | | |
|--------------------|---------------|---------------|---------------|
| Tagging | N | N | Y/N |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | * | * | * |
|--------------------|---------------|---------------|---------------|
| Transit Delay | O | O | O |
|--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | O | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | O | | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
|ATM Service Category| Real Time VBR |
|--------------------|---------------|---------------|---------------|
| Conformance |VBR.1 (note 10)| VBR.2 | VBR.3 |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | C | X | VP | C | X | VP | C | X | VP |
|--------------------|---------------|----|-----|----|----|-----|----|
| ATM Transfer | | | 1 | | | 1 | |
| Capability | 19 | 9 | or 9| 9 | 9 | or 9| 9 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | S | | |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | S | | |okay bestie, we're picking up right where we left off, and this is the table stuff 💅🎀 every row matters, so I'm keeping each one exactly as it is 🫶
|--------------------|---------------|---------------|---------------|
| Best Effort | | | |
|--------------------|---------------|---------------|---------------|
| Tagging | N | N | Y/N |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | * | * | * |
|--------------------|---------------|---------------|---------------|
| Transit Delay(nt.2)| O | O | O |
|--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | O | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | O | | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
|ATM Service Category| Real Time VBR |
|--------------------|---------------|---------------|---------------|
| Conformance | (note 4,7) | (note 4,8) | (note 4) |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | X | X | X | C or VP^|
|--------------------|---------------|---------------|-----|---------|
| ATM Transfer | | | | |
| Capability | 1 or 9 | 1 or 9 | 1or9| 9 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | S | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | | | S |
|--------------------|---------------|---------------|---------------|
| Best Effort | | | |
|--------------------|---------------|---------------|---------------|
| Tagging | Y/N | N | N |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | * | * | * |
|--------------------|---------------|---------------|---------------|
| Transit Delay(nt.2)| O | O | O |
|--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | O | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | O | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | | | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
|ATM Service Category| Non-Real Time VBR |
|--------------------|---------------|---------------|---------------|
| Conformance |VBR.1 (note 10)| VBR.2 | VBR.3 |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | C | X | VP |C | X | VP|C | X | VP|
|--------------------|---------------|--|--------|---|--|--------|---|
| ATM Transfer | | |abs,0,2,|abs| |abs,0,2,|abs|
| Capability | 11 |ab| 8,10 |10 |ab| 8,10 |10 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | S | | |
|--------------------|---------------|---------------|---------------|
| Best Effort | | | |
|--------------------|---------------|---------------|---------------|
| Tagging | N | N | Y |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | * | * | * |
|--------------------|---------------|---------------|---------------|
| Transit Delay(nt.2)| (note 3) | (note 3) | (note 3) |
|--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | | | |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | O | | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
|ATM Service Category| Non-Real Time VBR |
|--------------------|---------------|---------------|---------------|
| Conformance | (note 4,7) | (note 4,8) | (note 4) |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | C | X | C | X |C | X |VP^|
|--------------------|-------|-------|-------|-------|--|--------|---|
| ATM Transfer | |abs,0,2| |abs,0,2| |abs,0,2,|abs|
| Capability | abs |8 or 10| |8 or 10|ab| 8 or10 |10 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | S | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | | | S |
|--------------------|---------------|---------------|---------------|
| Best Effort | | | |
|--------------------|---------------|---------------|---------------|
| Tagging | Y/N | N | N |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | * | * | * |
|--------------------|---------------|---------------|---------------|
| Transit Delay(nt.2)| (note 3) | (note 3) | (note 3) |
|--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | | | |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | O | O | O |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | | | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
|ATM Service Category| ABR | UBR |
|--------------------|---------------|---------------|---------------|
| Conformance | ABR | UBR.1 | UBR.2 |
|--------------------|---------------|---------------|---------------|
| Bearer Capability | | | |
|--------------------|---------------|---------------|---------------|
| BB Bearer Class | C | X | VP |C | X | VP|C | X | VP|
|--------------------|---------------|--|--------|---|--|--------|---|
| ATM Transfer | | |abs,0,2,|abs| |abs,0,2,|abs|
| Capability | 12 |ab| 8,10 |10 |ab| 8,10 |10 |
|--------------------|---------------|---------------|---------------|
| Traffic Descriptor | | | |
| for a given dir. | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0) | | | |
|--------------------|---------------|---------------|---------------|
| PCR (CLP=0+1) | S | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0) | | S | S |
|--------------------|---------------|---------------|---------------|
| SCR, MBS (CLP=0+1) | S | | |
|--------------------|---------------|---------------|---------------|
| ABR MCR | (note 6) | | |
|--------------------|---------------|---------------|---------------|
| Best Effort | | S (note 9) | S (note 9) |
|--------------------|---------------|---------------|---------------|
| Tagging | N | N | N |
|--------------------|---------------|---------------|---------------|
| Frame Discard | Y/N | Y/N | Y/N |
|--------------------|---------------|---------------|---------------|
| QoS Classes | 0 | 0 | 0 |
|--------------------|---------------|---------------|---------------|
| Transit Delay(nt.2)| | | ||--------------------|---------------|---------------|---------------|
| Peak-to-Peak CDV | | | |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0)~ | | | |
|--------------------|---------------|---------------|---------------|
| CLR (CLP=0+1)~ | | | |
+--------------------------------------------------------------------+Okay, so the table is done, but the legend is where the real tea is 🫖💅 Here's how to read it, bestie:
ab, abs= absent 🫥Y/N= you can put either "Yes" or "No" 🙆♀️O= Optional 🌸 It can be specified in one of two ways. First, with an extra QoS parameter encoded in the Extended QoS parameters information element or the end-to-end transit information element. Second, through objectives implied by the QoS class. If there's no Extended QoS Parameters IE in the message, then any value for this parameter is acceptable. If there's neither the parameter nor the Extended QoS Parameters IE, the objective comes from the QoS class in the QoS Parameter IE. Main character energy, honestly 👑S= Specified ✨- (blank) = Unspecified 🫧
*= the allowed QoS class values are a network option, but Class 0 is always there for alignment with ITU-T 🧚^= see note 5 📝~= see note 11 📝
Now the notes, which are so detailed and I'm obsessed 🤓🎀
- Note 1 💜 Values 0, 1, 2, 4, 6, and 8 are not used on transmission, but they shall be understood on reception. Receive them, don't send them 🙈
- Note 2 🦋 Maximum end-2-end transit delay objectives may only be specified for the forward direction. Backward is not it 💀
- Note 3 🍓 Maximum end-2-end transit delay objectives may be specified for the ATM Service Category of Non-real Time VBR, for reasons of backward compatibility with ITU-T Recommendations. Old-school vibes, respect 🫶
- Note 4 🌈 This is included for backward compatibility with UNI 3.1 and ITU-T Recommendations. With these conformance definitions, the CLR commitment is only for the CLP=0 traffic stream. So CLP=0 gets the guarantee, not CLP=0+1 🥹
- Note 5 🧚 This is included so switched virtual paths can use the UNI 3.1 conformance definitions ✨
- Note 6 🌸 It's optional in the user-to-network direction, and specified in the network-to-user direction 🫶
- Note 7 💅 This combination should be treated as if the received PCR (CLP=0) parameter were an SCR (CLP=0) parameter, plus an MBS (CLP=0) parameter with a value of 1. Plot twist 😭
- Note 8 🔥 This combination should be treated as if an additional SCR (CLP=0) parameter were received, with the same value as a PCR (CLP=0+1) parameter, and an MBS (CLP=0) parameter with a value of 1. Two parameters, one vibe 💖
- Note 9 🌷 The best effort parameter applies to both the forward and backward directions. Bidirectional, no notes 🦋
- Note 10 💀 This combination should only be used when a CLR commitment on CLP=0+1 is required, versus a CLR commitment on CLP=0 traffic. These combinations aren't supported by UNI 3.0/3.1 or ITU-T Q.2931, so proceed with care 🙈
- Note 11 🌈 In this table, the CLR commitment is shown as two entries, so it's explicit whether the CLR commitment is for the CLP=0 or the CLP=0+1 cells. Clarity is iconic 👑
Full Copyright Statement 💖
Copyright (C) The Internet Society (1998). All Rights Reserved. 🌸
Okay, legal stuff, but it's actually sweet. You can copy and share this document, and translations of it are fine too. You can also make derivative works that comment on or explain it, or that help with implementing it. Those can be prepared, copied, published, and distributed, in whole or in part, with no restriction of any kind. The one condition is that the above copyright notice and this paragraph stay on every copy and derivative work 🫶
The document itself can't be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🌍
These limited permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them 💜
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
📦 where this page comes from
- ietf: rfc2331 1998-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms