RFC 2381
Interoperation of Controlled-Load Service and Guaranteed Service with ATM
RFC 2381: Interoperation of Controlled-Load Service and Guaranteed Service with ATM 💖
- Network Working Group 🌸
- Request for Comments: 2381 📜
- Authors: M. Garrett (Bellcore) and M. Borden (Bay Networks) 🧚
- Category: Standards Track 🔥
- Date: August 1998 🗓️
- Obsoletes / Updates: This header doesn't list anything it obsoletes or updates 🦋
Status of this Memo ✨
Okay so this one is an Internet standards track protocol for the whole Internet community 🌈, and it's literally asking everyone for discussion and suggestions for improvements 💬. If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🫶.
Copyright Notice 💅
Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀
Abstract 🦋
This doc gives you guidelines for mapping service classes, plus traffic management features and parameters, between Internet and ATM technologies 🧚. These service mappings are super useful for smooth interoperation and end-to-end Quality of Service for IP Integrated Services networks that contain ATM subnetworks 🔥.
The specs here back up the IP integrated services protocols for Guaranteed Service (GS), Controlled-Load Service (CLS), and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0 💜. There's also some talk about IP best effort service over ATM 🍓.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [1]. (Note, in lots of cases the use of "MUST" or "REQUIRED" is the authors' take on the requirements of a related standard, like ATM Forum UNI 4.0, rsvp, etc. 🙈)
Table of Contents 🌈
1.0 Introduction .................................................... 3
1.1 General System Architecture ................................. 4
1.2 Related Documents ........................................... 7
2.0 Major Protocol Features for Traffic Management and QoS .......... 8
2.1 Service Category and Bearer Capability ...................... 8
2.1.1 Service Categories for Guaranteed Service ............. 9
2.1.2 Service Categories for Controlled Load ................ 10
2.1.3 Service Categories for Best Effort .................... 11
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions . 11
2.3 ATM Adaptation Layer ........................................ 13
2.4 Broadband Low Layer Information ............................. 13
2.5 Traffic Descriptors ......................................... 13
2.5.1 Translating Traffic Descriptors for Guaranteed Service. 15
2.5.2 Translating Traffic Descriptors for Controlled Load
Service .............................................. 18
2.5.3 Translating Traffic Descriptors for Best Effort Service 19
2.6 QoS Classes and Parameters .................................. 19
2.7 Additional Parameters -- Frame Discard Mode ................. 22
3.0 Additional IP-Integrated Services Protocol Features ............. 22
3.1 Path Characterization Parameters for IP Integrated Services . 22
3.2 Handling of Excess Traffic .................................. 24
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term .. 25
4.0 Miscellaneous Items ............................................. 26
4.1 Units Conversion ............................................ 26
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service ....... 27
5.1 Encoding GS Using Real-Time VBR ............................. 28
5.2 Encoding GS Using CBR ....................................... 29
5.3 Encoding GS Using Non-Real-Time VBR ......................... 30
5.4 Encoding GS Using ABR ....................................... 30
5.5 Encoding GS Using UBR ....................................... 30
5.6 Encoding GS Using UNI 3.0 and UNI 3.1. ...................... 31
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service .. 32
6.1 Encoding CLS Using Non-Real-Time VBR ........................ 32
6.2 Encoding CLS Using ABR ...................................... 33
6.3 Encoding CLS Using CBR ...................................... 35
6.4 Encoding CLS Using Real-Time VBR ............................ 35
6.5 Encoding CLS Using UBR ...................................... 35
6.6 Encoding CLS Using UNI 3.0 and UNI 3.1. ..................... 35
7.0 Summary of ATM VC Setup Parameters for Best Effort Service ...... 36
7.1 Encoding Best Effort Service Using UBR ...................... 37
8.0 Security Considerations ......................................... 38
9.0 Acknowledgements ................................................ 38
Appendix 1 Abbreviations ........................................... 39
References .......................................................... 40
Authors' Addresses .................................................. 42
Full Copyright Statement ............................................ 431.0 Introduction ✨
Here's the problem we're tackling: giving IP Integrated Services [2] an ATM subnetwork to run on 🫶. This doc is meant to line up with the rsvp protocol [3] for IP-level resource reservation, but it also works in the general case where GS and CLS are supported through other mechanisms 🌸. On the ATM side, we're looking at ATM Forum UNI Signaling, versions 3.0, 3.1 and 4.0 [4, 5, 6]. The latter uses the fuller service model from the ATM Forum's TM 4.0 specification [7, 8] 💅.
This is a complicated problem with a lot of facets 🧩. Here we focus on the service types, parameters and signalling elements you need for service interoperation 🎀. The resulting service mappings can be used to give IP traffic that crosses ATM networks effective end-to-end Quality of Service (QoS) 👑.
The IP services we're covering are Guaranteed Service (GS) [9] and Controlled Load Service (CLS) [10]. We also discuss the default Best Effort Service (BE) alongside them 🍓. Our recommendations for BE are meant to be consistent with RFC 1755 [11], and [12], which explain how ATM VCs can support normal BE IP service 🧚. The ATM services we look at are:
CBR Constant Bit Rate
rtVBR Real-time Variable Bit Rate
nrtVBR Non-real-time Variable Bit Rate
UBR Unspecified Bit Rate
ABR Available Bit RateWith UNI 3.x signalling, these services aren't all clearly distinguishable, so we pick out the appropriate available services 🙈.
We recommend these service mappings, since they follow most naturally from the service definitions 💖:
Guaranteed Service -> CBR or rtVBR
Controlled Load -> nrtVBR or ABR (with a minimum
cell rate)
Best Effort -> UBR or ABRFor completeness, we also give detailed mappings for every service combination in Sections 5, 6, 7, and we show how each one meets or fails to meet the requirements of the higher level IP services 🔥. We don't restrict mappings to the most obvious or natural ones because we can't predict how widely available all of these services will be as ATM deployment evolves 🌈. Lots of differences in service definitions, like how packets over the flow traffic descriptor are treated, make service mapping a pretty complicated subject 💀.
The rest of this intro gives a general overview of the system configuration and other assumptions ✨. Section 2 covers the relevant ATM protocol elements and the matching features of Guaranteed, Controlled Load and Best Effort services (BE being the default "service") 💜. Section 3 goes through a bunch of the remaining features of the IP services and how they can be handled on an ATM subnetwork 🦋. Section 4 covers converting traffic descriptors to account for ATM-layer overheads 🍓. Section 5 gives the detailed VC setup parameters for Guaranteed Service and looks at what happens with each ATM service category 👑. Section 6 gives a similar treatment for Controlled Load Service 🧚. Section 7 covers Best Effort service 🫶.
Real talk, this doc is only part of the whole solution for interworking IP integrated services with ATM subnetworks 🎀. The big issue of VC management, including flow aggregation, is covered in [13, 14, 15] 💅. We don't look at how routing, QoS sensitive or not, interacts with ATM VCs 😭. We expect there to be a lot of implementation latitude, even within the guidelines here 🌸. Plenty of the interworking between IP and ATM will depend on economic factors and won't be subject to standardization 💖.
1.1 General System Architecture ✨
okay so we're assuming you already know your IP, RSVP, and ATM basics, bestie 🫶 The network setup looks like Figure 1. An IP-attached host can send unicast datagrams to another host, or hit an IP multicast address to reach every host that has "joined" the multicast "tree" 🌳 Either way, the destination host can then use RSVP to reserve resources in the routers along the internet path for that data flow. main character energy 👑
An ATM network sits in the path (picked by IP routing) and is made of one or more ATM switches. It uses SVCs to provide both resources and QoS inside the ATM cloud ☁️ The edge devices set these connections up, add to them (for multipoint trees), tear them down, and control them. They act as both IP routers and ATM interfaces, and they can start and manage VCs across the ATM user-to-network (UNI) interface. We're assuming the edge devices are fully functional in both the IP int-serv/RSVP protocols and the ATM UNI protocols, and that they translate between the two 💖
ATM Cloud
-----------------
H ----\ ( ) /------- H
H ---- R -- R -- E-( X -- X -- X )-E -- R -- R -- H
H ----/ | ( ) \
| ----------------- \------ H
H ----------R
Figure 1: Network Architecture with Hosts (H),
Routers (R), Edge Devices (E) and ATM
Switches (X).When we look at traffic flowing from source to destination, the upstream edge device is the "ingress" point and the downstream one is the "egress" point 🦋 Edge devices can count as part of the IP internet, part of the ATM cloud, or both. They process RSVP messages, reserve resources, and keep soft state (in the control path), and they classify and schedule packets (in the data path) 🧚 They also start ATM connections by signalling, and they accept or refuse connections that get signalled to them. They police and schedule cells going into the ATM cloud 💅 The service mapping function kicks in when an IP-level reservation (RESV message) makes the edge device translate the RSVP service requirements into ATM VC (UNI) semantics. iconic behaviour ✨
A bunch of VC management policies are possible, and they decide whether a flow starts a brand new VC or joins one that already exists 🌸 VCs get managed through a mix of standards and local policy rules, and those rules are specific to either the implementation (the equipment) or the operator (the network service provider). Point-to-multipoint connections inside the ATM cloud can carry general IP multicast flows. In ATM, a point-to-multipoint connection can be controlled by the source (root) node, or a leaf initiated join (LIJ) feature in ATM can be used. VC management gets covered at length in other ISSLL documents [13, 14, 15] 📚
Figure 2 shows what an edge device does. It summarises the work that isn't part of IP or ATM as an InterWorking Function (IWF), and it separates the control and data planes 🎀
IP ATM
____________________
| IWF |
| |
admission and <--> | service mapping | <--> ATM
policy control | VC management | signalling &
| address resolution | admission
|....................| control
| |
classification, |ATM Adaptation Layer| cell
policing & <--> | Segmentation and | <--> scheduling/
scheduling | Reassembly | shaping
| Buffering |
____________________
Figure 2: Edge Device Functions showing the IWFIn the logical view of Figure 2, some functions (scheduling, for example) get drawn separately because they exist on both the IP and ATM sides. An integrated implementation might be able to combine functions like that, though 🫧
The service mapping and VC management functions can be really interdependent 🔥 For example: (i) multiple integrated-services flows can be aggregated to share one point-to-multipoint VC. In that case we assume the IP flows are the same service type and their parameters have been merged appropriately. (ii) The VC management function might allocate extra resources in anticipation of more reservations, or based on an empiric of changing TSpecs. (iii) There MUST exist a path for best effort flows and for sending the RSVP control messages. How that interacts with setting up VCs for QoS traffic may change the characteristics those VCs need. See [13, 14, 15] for more on VC management 🦋
So when we talk about the service mapping problem, we're going to assume the VC management function of the IWF can always express its result as an IP-level service with some QoS and TSpec 💖 The service mapping algorithm can then figure out the right VC parameters as if a new VC were being created for that service. The VC management function can use that info however its policy says, which decides whether the result uses new VCs or existing ones. ✨
1.2 Related Documents 📚
Earlier ATM Forum documents mashed signalling, traffic management, and other areas into one single document, like UNI 3.0 [4] and UNI 3.1 [5]. The 3.1 release was used to fix errors and line things up with the ITU. UNI 3.0 and 3.1 are incompatible in terms of actual codepoints, but the semantics are generally the same, so we'll often say UNI 3.x to mean either version of the ATM protocol 🌈
After 3.1, the ATM Forum split its documents up, with one per technical working group. The UNI Signalling 4.0 [6] and Traffic Management 4.0 [7] documents make up a consistent overall ATM protocol, and sometimes we'll refer to the combo as TM/UNI 4.0 🍓
Inside the IETF, related stuff comes from the rsvp [3], int-serv [2, 9, 10, 16, 17], and ion working groups [11, 12] 💜 RSVP defines the resource reservation protocol (kind of like signalling in ATM). Int-serv defines the behaviour and semantics of particular services (kind of like the Traffic Management working group in the ATM Forum). Ion defines interworking of IP and ATM for traditional Best Effort service, and it generally covers IP/ATM routing and addressing issues 🧚
A ton of ATM signalling details live in RFC 1755 [10]. Things like the differences between UNI 3.0 and UNI 3.1, encapsulation, frame-relay interworking, and so on. Those considerations stretch over to IP over ATM with QoS too 🫶 The way this document describes IP Best Effort service (aka the default behaviour) over ATM is meant to match RFC 1755 and its extension for UNI 4.0 [11], and those documents are the ones to trust. For non-best-effort services, some IP/ATM features are going to diverge from RFC 1755, and we've tried to point out those differences explicitly. (For example, best effort VCs may be taken down on timeout by either edge device, while QoS VCs only get removed by the upstream edge device when the matching RSVP reservation is deleted 🙈)
One more related doc is RFC 1821 [17], an early discussion of the issues with making IP and ATM protocols work together for integrated services and QoS 🌸
2.0 Major Protocol Features for Traffic Management and QoS 💅
The ATM Call Setup gets sent by the ingress edge device to the ATM network to set up end-to-end (ATM) service 🚀 That setup carries this info:
Service Category/Broadband Bearer Capability
AAL Parameters
Broadband Low Layer Information
Calling and Called Party Addressing Information
Traffic Descriptors
QoS Class and/or Parameters
Additional Parameters of TM/UNI 4.0We're going to talk through each of these as they relate to making ATM VCs that work for GS, CLS, and BE services 🎀 We aren't discussing routing and addressing at all, since they're (at least for now) independent of QoS. After the service categories section, we'll go over tagging and conformance definitions for IP and ATM. Those don't show up explicitly as set-up parameters in the list above, because they're implied by the policing method being used 👑
2.1 Service Category and Bearer Capability 🦋
The highest-level, most abstract thing that tells ATM VCs apart is the service category or bearer capability. Service categories were introduced in TM/UNI 4.0. Before that, the bearer capability did that job 💖
These elements show the general properties of a VC: whether there's a real-time delay constraint, whether the traffic is constant or variable rate, the applicable traffic and QoS description parameters, and (implicitly) how complex some supporting switch mechanisms are (ABR, for example) ✨
For UNI 3.0 and UNI 3.1, there are only two distinct bearer capability options (in our context) 🌈
BCOB-A: constant rate, timing required, unicast/multipoint;
BCOB-C: variable rate, timing not required, unicast/multipoint.A third capability, BCOB-X, can stand in for the above two, with its dependent parameters (traffic type and timing requirement) set appropriately. The difference between the BCOB-X formulation and the "equivalent" (for our purposes) BCOB-A and BCOB-C constructs is whether the ATM network is supposed to provide pure cell relay service or interwork with other technologies (with interoperable signalling), like narrowband ISDN 🧚 Where that difference matters, the appropriate code SHOULD be used (see [5] and related ITU specs, e.g., I.371) 🍓
In TM/UNI 4.0, the service categories are:
Constant Bit Rate (CBR)
Real-time Variable Bit Rate (rtVBR)
Non-real-time Variable Bit Rate (nrtVBR)
Unspecified Bit Rate (UBR)
Available Bit Rate (ABR)The first two of these are real-time services, so rtVBR is new to TM/UNI 4.0. ABR is also new to TM/UNI 4.0. UBR exists in all the specifications, although it's called "best effort" in UNI 3.x. Either way, it's indicated by the "best effort" indication flag (and the QoS Class set to 0) 💜
The Service Category in TM/UNI 4.0 gets encoded into the same signalled Information Element (IE) as the Bearer Capability in UNI 3.x, for backwards compatibilty. So we use the convention of referring to Service Category (CBR, rtVBR, nrtVBR, UBR, ABR) for TM/UNI 4.0 (where the bearer capability is implicit). When we mention the Bearer Capability explicitly (BCOB-A, BCOB-C, BCOB-X), we're describing a UNI 3.x signalling message 🌸
In principle, you can support any service by using BCOB-A/CBR, because CBR is basically equivalent to having a "pipe" of a specified bandwidth. But it may be a lot more efficient to use the other ATM services where they apply and are available [17] 🫶
2.1.1 Service Categories for Guaranteed Service ✨
Okay so GS only has two possible mappings, bestie 🎀
- CBR (BCOB-A)
- rtVBR
Real-time support is REQUIRED for GS 😭 So in UNI 3.x, the Bearer Class BCOB-A (or an equivalent BCOB-X formulation) MUST be used 💅. In TM/UNI 4.0, either CBR or rtVBR is appropriate ✨. rtVBR may encourage recovery of allocated bandwidth that a source leaves unused 🦋. It also accommodates burstier sources with a bigger token bucket burst parameter, and it lets you use tagging for excess traffic (see Section 2.2) 🌈.
Neither the BCOB-C Bearer Class nor nrtVBR, UBR, or ABR are good matches for GS 💀. They don't give delay estimates and can't guarantee consistently low delay for every packet 🙈.
For BCOB-A or CBR, specifying a peak cell rate (PCR) is REQUIRED by ATM standards 📏. In these cases, PCR is the nominal clearing rate, with a nominal jitter toleration (bucket size) called CDVT 🧚.
When rtVBR is specified, two rates, PCR and SCR, are REQUIRED (by ATM standards) 🍓. This models bursty traffic with specified peak and sustainable rates. The matching ATM token bucket depth values are CDVT and CDVT+BT, respectively 💜.
2.1.2 Service Categories for Controlled Load
Okay, CLS has three possible good mappings 🫶
- CBR (BCOB-A)
- nrtVBR (BCOB-C)
- ABR
Note that under UNI 3.x there are equivalent services to CBR and nrtVBR, but not ABR 🙃. The first one, a CBR/BCOB-A connection, gives you a higher level of QoS than you actually need. Still, it can be convenient to just allocate a fixed-rate "pipe," which we expect to be ubiquitously supported in ATM networks 🌸. Unless it's the only choice available, though, it would probably be wasteful of network resources 💅.
The nrtVBR/BCOB-C category is probably the best match, since it lets you allocate bandwidth and buffers with an extra peak rate indication, kind of like the CLS TSpec ✨. Excess traffic can be handled by CLP bit tagging with VBR 🎀.
The ABR category with a positive MCR matches the CLS idea of "best effort with a floor" 👑. The ATM network agrees to forward cells at a rate of at least MCR, which MUST be directly converted from the token bucket rate of the receiver TSpec 🔥. The bucket size parameter roughly measures how much buffer the IWF needs. This buffer absorbs the bursts allowed by the token bucket, since those bursts can't be passed straight into an ABR VC 🫠.
The rtVBR category can be used, but then the edge device MUST determine values for CTD and CDV 🙈. Since there are no matching IP-level parameters, their values are set as a matter of local policy 🧁.
The UBR category just doesn't have enough capability for Controlled Load 😤. The whole point of CLS is to allow an allocation of resources. That's made possible by the token bucket traffic descriptor, which UBR doesn't have 💀.
2.1.3 Service Categories for Best Effort
Every service category can carry Best Effort service, but the natural one is UBR (or, in UNI 3.x, BCOB-C or BCOB-X with the best effort indication set) 🌈. CBR or rtVBR could also be used, and since this service isn't real-time, an nrtVBR connection works too 💖. In these cases, the rate parameter reflects a bandwidth allocation for the ingress edge device's best effort connectivity to the egress edge router 🦋.
Traffic from lots of source/destination pairs is usually aggregated onto this connection. Honestly, since Best Effort is the default IP behavior, individual flows usually don't get identified or accounted for 🧚. CBR might be the preferred option when best effort traffic is aggregated so heavily that a simple fixed-rate pipe is efficient ✨. Both CBR and nrt-VBR give explicit bandwidth allocation, which can be useful for billing purposes 🍓. With UBR, the network operator SHOULD allocate bandwidth for the overall service through the admission control function, even though that allocation isn't done explicitly per VC 📊.
An ABR connection could also support Best Effort traffic 🙌. Honestly, supporting data protocols like TCP/IP is exactly why ABR was designed 💅. It's conceivable that a separate ABR connection could be made for each IP flow, but the normal case would probably be all IP Best Effort traffic heading to a common egress router sharing one ABR connection 🫶.
The rt-VBR service category may be less suitable, simply because both the real-time delay constraint and the use of SCR/BT add unnecessary complexity 🙄.
For related work on supporting Best Effort service with ATM, check out the specs from the IETF ion working group [10, 11] 📚✨.
2.2 Cell Loss Priority Bit, Tagging and Conformance Definitions
Okay, every ATM cell header has a Cell Loss Priority (CLP) bit 🎀. Cells with CLP=1 are called "tagged" or "marked," and they have lower priority 🫠. Tagging can be done by the source to show relative priority within the VC, or by a switch to show traffic that breaks the policing parameters 👀. The options for using tagging are decided at call setup time 📞.
A Conformance Definition is a rule that decides whether a cell conforms to the traffic descriptor of the VC 📏. It's written in terms of a Generic Cell Rate Algorithm (GCRA), also known as a "leaky bucket" algorithm, for CBR and VBR services 🪣. The conformance definition also spells out rules for tagging traffic that goes over the {SCR, MBS} GCRA traffic descriptor 💅. (Quick note: in ATM, "compliance" describes how a connection behaves, while "conformance" applies to a single cell, so don't mix them up 🤓.)
The network may tag non-conforming cells instead of dropping them, but only if the VC setup requests tagging and the network supports the tagging option 🦋. When tagging is used and congestion happens, a switch MUST attempt to discard tagged cells before discarding CLP=0 cells 🔥. The mechanism for doing that is totally implementation specific, though 🙃. The behavior that best meets the requirements of IP Integrated Services is when tagged cells are treated as "best effort." That means they get transported when bandwidth is available, queued when buffers are available, and dropped when resources are overcommitted 🌈. ATM standards don't explicitly specify how tagged traffic gets treated, though 😤. Providers of GS and CLS service over ATM subnetworks SHOULD ascertain how the actual ATM implementation handles tagged cells 🔍.
GS and CLS services REQUIRE excess traffic to be treated as best effort, so the tagging option SHOULD always be chosen (if supported) in the VC setup 🫶. That's how you "downgrade" the cells that make up non-conformant packets 📉. The term "best effort" can be read two ways. The first is as a service class that might be implemented as a separate queue 🧁. The second is more generic: the network makes a best effort to transport the traffic. A reasonable reading is that a network with no contending traffic would transport the packet, while a very congested network would drop it 🌸. A mechanism that tags best effort packets with lower loss priority (like the ATM CLP bit) would drop some of those packets, but it wouldn't reorder the remaining ones relative to the conforming part of the flow ✨. The "best effort" mechanism for excess traffic doesn't have to be the same as the one for best effort "service," as long as it fits that generic sense of best effort 💖.
There are three conformance definitions of VBR service (for both rtVBR and nrtVBR) to think about 🧠. In VBR, only VBR.3 supports tagging. It applies the GCRA with rate PCR to the aggregate CLP=0+1 cells, and another GCRA with rate SCR to the CLP=0 cells 🌟. This conformance definition SHOULD always be used with a VBR service that supports IP integrated services 💅. For UBR service, UBR.2 supports tagging, but a CLP=1 cell doesn't automatically mean non-conformance. Instead, the network may use it to signal congestion 🚨.
In TM/UNI 4.0, tagging isn't a feature of the conformance definitions for the CBR or ABR service categories 🙈. (Since conformance definitions are usually network specific, some CBR or ABR implementations may, in fact, use tagging in some way 🤷♀️.) Wherever an ATM network does support tagging, meaning it transports CLP=1 cells on a "best effort" basis, it's a useful and preferable way to handle excess traffic 💜.
It's always better for the IWF to tag cells when it can anticipate that the ATM network will do so 🧚. The IWF knows the IP packet boundaries, so it can tag every cell belonging to a packet. If the ATM layer UPC is left to do it, the network would inevitably drop some cells of a packet while carrying others, and the receiver would then drop the rest 😭. So the IWF, knowing the VC GCRA parameters, SHOULD always anticipate which cells the ATM UPC will tag, and tag all cells uniformly across each affected packet 🎀. See Section 3.2 for more on excess traffic 📖.
2.3 ATM Adaptation Layer
The AAL type 5 encoding SHOULD be used, as specified in RFC 1483 and RFC 1755 🫶. For AAL-5, specifying the maximum SDU size in both the forward and reverse directions is REQUIRED 📏. Both GS and CLS specify a maximum packet size, M, as part of the TSpec, and this value SHOULD be used (corrected for AAL headers) as the maximum SDU in each direction for unicast connections and for unidirectional point-to-multipoint connections 🌈. When multiple flows are aggregated into a single VC, the M parameters of the receiver TSpecs get merged according to the rules in the GS and CLS specs 🧩.
2.4 Broadband Low Layer Information
The B-LLI Information Element is passed through the ATM network transparently between the edge devices, and it's used to specify the encapsulation method 🦋. Multiple B-LLI IEs may be sent as part of negotiation 💬. The LLC/SNAP encapsulation [18] SHOULD be supported as the default, but "null" or "VC encapsulation" MAY also be allowed 🌸. Implementations SHOULD follow RFC 1577 [19] and RFC 1755 [10] for BLLI usage 🍓✨.
2.5. Traffic Descriptors ✨
okay bestie, let's talk about the ATM traffic descriptor 💅 every single one always has a peak cell rate (PCR) 🦋 and that's for each direction!! 🔥 For VBR services it also carries a sustainable cell rate (SCR) and a maximum burst size (MBS) 💜. The SCR and MBS work together as a leaky bucket pair (rate, depth) 🪣✨, and the bucket depth for PCR is CDVT 🌸. Here's the tea: CDVT isn't signalled explicitly 🙈. The network operator just decides it, and you can think of it as a measure of the jitter the network adds 🧚
CDVT is usually pretty small, like a few cells' worth of token bucket depth 🍓, and you can't set it on a per-connection basis. So it literally can't account for the burstiness that b in the IP-layer TSpec allows 😭. The IWF might need some extra buffering to cover the depth of that token bucket 🎀
Now the ATM Burst Tolerance (BT) is basically the same thing as MBS (check TM 4.0 [6] for the exact equation, it's giving math 🤓). Both of them describe the bucket depth tied to SCR 💖. The difference is units: BT is in time, and MBS is in cells 🌈. Since SCR and MBS both get signalled, you can compute them straight from the IP layer traffic description ✨. How resources get allocated from the traffic description is implementation specific, so it's up to you, bestie 👑. And when you translate the traffic parameters, you have to account for the segmentation overhead and the minimum policed unit (see Section 4.1 below) 💅
Next up, ATM UNI Signalling 4.0 has two lowkey confusing concepts: Alternative Traffic Descriptors and Minimal Traffic Descriptors 🫶. Alternative Traffic Descriptors list other acceptable options for traffic descriptors, and we're not covering them here 🙈. Minimal Traffic Descriptors are used in "negotiation," which is the specific way an ATM connection gets set up 🦋. Roughly, using PCR as the example: you signal a minimal PCR AND a requested PCR. The requested PCR is the one you normally send, and the minimal PCR is the absolute lowest the source edge device will accept 🌸. When you've got both, the intermediate switches on the path can lower the requested PCR to a "comfortable" level 🧚. That choice is part of admission control, so it's implementation specific 💜. If the requested PCR ever drops below the minimal PCR, the call gets cleared 💀. Minimal Traffic Descriptors are a great way to give a range of acceptable values and get a higher chance of call admission 🎀✨. In general, when we talk about connection parameters, we're assuming the values you get after a successful connection setup 👑
The Best Effort indicator (only used with UBR) and the Tagging indicators (see Section 2.2) are also part of the signalled information element (IE) that holds the traffic descriptor 🌈. The UNI 4.0 traffic descriptor IE has one extra parameter, the Frame Discard indicator, which we'll get into below in Section 2.7 🍓💖
2.5.1. Translating Traffic Descriptors for Guaranteed Service 💖
Okay bestie, so for Guaranteed Service (GS) the source TSpec has a peak rate, a rate, and a bucket depth, which we call p_s, r_s, and b_s. The receiver TSpec has its own matching set: p_r, r_r, and b_r. The receiver RSpec also carries a rate, R. 🎀 The two TSpec rates exist for receiver heterogeneity, which means different receivers can ask for different rates that each cover a different slice of the sender's traffic. ✨ So whenever rates from different receivers don't match, the values MUST always be merged appropriately before they get mapped into ATM parameters. Merging first, mapping second, no skipping! 🧚
Now, here's the tea. When the sender's rate r_s and the receiver's rate r_r are different, nothing in RSVP or the int-serv specs says which part of the traffic should actually get transported. 😭 That means the implementation is totally network specific. The policing and scheduling mechanisms might just get set up with the lower receiver rate, and then traffic gets randomly dropped until the difference is made up. Kind of chaotic, ngl. 💀
The receiver TSpec rate tells you which traffic needs resources reserved, and it can be used for policing 💅. The RSpec rate, meanwhile, cannot be smaller than that, and it's used (maybe in an implementation specific way) to change the allocated service bandwidth so the delay goes down. Main character energy for the RSpec rate 👑.
When you're mapping Guaranteed Service onto an rtVBR VC, the ATM traffic descriptor parameters (PCR, SCR, MBS) can be set like this:
PCR = p_r
SCR = R
MBS = b_rOf course, there are a bunch of conditions that could lead to different choices. 🌸 The stuff below is NOT meant to be hard requirements. It's just some interpretation and guidance on the bounds of the parameter mappings that are possible. The ingress edge device usually has a buffer sitting in front of the ATM network interface. That buffer can soak up bursts that fit inside the IP-level TSpec but don't fit inside the ATM traffic descriptor. The minimal REQUIREMENT for guaranteed service is that the delay in this buffer MUST NOT exceed b/R, and the delays inside the ATM network MUST be accurately accounted for in the values of the Adspec parameters C and D that the ingress router advertises (see Section 3.3 below). Don't skip this part, it's literally the whole point 🙈.
If there's an edge device buffer of size b_r, or the ATM maximum burst size (MBS) parameter is at least b_r, then the rate parameters will generally follow this relationship:
r_r <= SCR <= R <= PCR <= APB <= line rate
r_r <= p_r <= APBAPB is the General Characterization Parameter called AVAILABLE_PATH_BANDWIDTH, which gets negotiated in the Adspec portion of the PATH message. 🦋 APB shows the narrowest bottleneck rate along the path, so it's always less than or equal to the local line rate. The receiver SHOULD choose a peak rate that's no greater than APB for the reservation to be accepted. The source peak rate p_s could be higher though, because the source has no idea what APB is. There's also zero advantage to allocating any rate above APB, so it works as an upper bound for all the other parameters. Iykyk 😌.
Normally you'd expect R <= p_r, which you'd need for that simple mapping of PCR = p_r and SCR = R from earlier. BUT a receiver is totally free to choose R > p_r to lower the GS delay [8] ✨. In that case PCR can't be set below R, since a burst of size b that lands in the buffer MUST be cleared at rate R so the first component of GS delay stays down at b/R. So here we end up with PCR = R. You might think PCR = p_r would be enough to avoid buffer overflow, since the source only generates data at a rate bounded by p_r. Not so fast! Setting PCR < R can cause the delay bound advertised by C and D to not be met. Plus, traffic always has some jitter in the network, and the arrival rate at a network element can go above p_r for short bursts of time 🥺.
Next up, the case where R <= p_r. We can still pick a PCR where R <= PCR < p_r. The edge device buffer is then needed (and actually enough) to absorb bursts, limited to a size of b_r + C_sum + R D_sum, that arrive faster than they leave. 💜 For example, the ATM VC cost could depend on PCR, while the cost of the Internet service reservation isn't strongly tied to the IP-level peak rate. So the user might be tempted to set p_r to APB, while the operator of the IP/ATM edge router wants to reduce PCR as much as possible. This is a super real concern, since the charging models of IP and ATM have historically been different when it comes to usage sensitivity. If p_r gets set close to APB, it could be many times the nominal GS allocated rate of R. Anyway, we can set PCR to R, with a buffer of size b_r + C_sum + R D_sum, and there's no loss of traffic and no violation of the GS delay bound. Phew 🫶.
Now this one is more subtle, and maybe a little controversial: setting SCR to a value below R. The big feature of GS is that it lets a receiver specify an allocated rate R that's bigger than the rate r_r that would be enough to carry the traffic. The point is to lower the queueing delay, roughly from b/r + C_TOT/r + D_TOT down to b/R + C_TOT/R + D_TOT 🔥. To actually allocate bandwidth R to the flow, we set SCR to match R. (Also, it's never necessary to set SCR above R, so SCR <= R is still true.) It's possible to set SCR as low as r_r without breaking the delay bounds or overflowing the edge device buffer. With PCR = R, a burst of size b gets buffered and sent into the ATM network at rate R, so the last byte only suffers a delay of b/R. Any traffic after that is limited to rate r_r, which is SCR, so the arriving and departing rates match up, and its delay also stays no more than b/R. Iconic 💅.
This scenario does meet the GS service requirements, but there's a catch. If you allocate SCR = r_r instead of R, the delay in the ATM network gets a component of MBS/SCR, which is b/r instead of b/R, and that goes into the D term advertised for the ATM sub-network (see further discussion in Section 3.3 below). 😭 It's also kinda against the spirit of GS to allocate r instead of R on part of the path. As mentioned above, though, this mapping could still be useful in practice when ATM network pricing creates different incentives in the tradeoff between delay and bandwidth than the ones the user buying IP integrated services has.
Another way of looking at parameter mapping says SCR might just reflect the traffic description, so SCR = r_r, while the service requirement gets expressed in the QoS parameter as CDV = b/R. 🦋 That means the ATM network might internally allocate bandwidth R, but it's free to use other methods too to hit the delay constraint. Things like statistical flow or connection aggregation could be implemented inside the ATM network and hidden from the user (or the parameter mapping module in the edge router), which only sees the interface shown in the signalled parameters. Mysterious and kinda iconic 🌈.
Quick note: this whole discussion assumes an edge device buffer size of b_r. In practice, the AAL/segmentation module might have to buffer M bytes while it converts packets into cells. Also, an extra amount of buffer equal to C_sum + R D_sum is usually needed to absorb the jitter coming from the upstream network [8] 🧚.
With ATM, it's possible to have little or no buffer in the edge router, because the ATM VC can be set up to accept bursts at peak rate. This might be unusual, since the edge router normally has enough buffer to soak up bursts according to the TSpec token bucket parameters. We'll look at two cases. First, if PCR >= p_r, then MBS can be set to b_r and no buffering is needed to absorb non-excessive bursts. The extra buffering for jitter can also be moved into MBS. This effectively shifts the buffering across the UNI and into the ATM network. ✨
For completeness, let's look at an edge router with no burst-absorbing buffers and an MBS parameter of about zero. In this case it's enough to set the rate parameters to PCR = SCR = max (R, p_r). That amounts to peak-rate allocation of bandwidth, which usually isn't very cost effective 🙈. This case could be relevant when the IP routers and ATM switches have really different buffering designs. IP-level users might ask for much bigger burst parameters than the ATM subnet can handle, and peak-rate bandwidth allocation gives you a way to work around that. Intermediate tradeoffs can also be worked out, where the burst-absorbing buffer is smaller than b bytes and SCR is set above R but below p_r. Note that jitter-absorbing buffers (C_sum + R D_sum) generally can't be avoided just by raising ATM rates, unless SCR is set to exceed the physical line rate(s) into the edge device for the flow. Not as easy as it looks, bestie 💀.
For GS over CBR, the PCR value may be mapped to the RSpec rate R, if the edge device has a buffer of size b_r + C_sum + R D_sum. With little or no burst buffering, the requirements look a lot like the zero-buffer case above, and we end up with PCR = max (R, p_r). Extra buffers that are enough to absorb network jitter, given by C_sum and D_sum, MUST always be provided in the edge router, or in the ATM network via MBS. No cap, this part is non-negotiable 🫶💖
2.5.2 Translating Traffic Descriptors for Controlled Load Service 💖
okay so the Controlled Load service TSpec has three things: a peak rate p, a "token bucket" rate r, and a matching token bucket depth b 🎀. The receiver TSpec values are what get used to work out resource allocation, and there's a simple mapping for the nrtVBR service category:
PCR = p_r
SCR = r_r
MBS = b_rthe edge device buffer tricks from the previous section (using them to reduce PCR and/or MBS) apply to CLS over nrtVBR too 🧚. Extra buffers are also needed to handle jitter that builds up on top of the b_r burst size allowed at the source, and those MUST be provided 😭. For CLS there are no Adspec parameters C and D, so how big those buffers should be is an implementation design issue 🤷♀️.
For ABR VCs, the TSpec rate r_r gets used to set the minimum cell rate (MCR) parameter 🦋. There's no matching signalled bucket depth, so the edge device SHOULD have a buffer of at least b_r bytes, plus extra buffers to soak up jitter. ABR lets the ATM network throttle the transfer rate down to MCR really fast, so a source sending above that rate can take a huge loss hit at the ingress edge device when the ATM network gets congested 💀.
For CBR, the TSpec rate r_r sets a lower bound on PCR, and again the buffering available in the edge device SHOULD be enough to handle possible bursts of b_r 🌈.
The big requirement for CLS is that network delays approximate "best-effort service under unloaded conditions" 👑. Here that's interpreted to mean that allocating bandwidth is enough if the last byte of a burst of size b_r sees a delay of about b_r/r_r. For example, a network element with no cross-traffic, a work conserving scheduler and an output link rate of r_L might give delays anywhere from M/r_L to b_r/r_L, which is way lower than b_r/r_r ✨. Getting access to the full link bandwidth (r_L), like in this example, is a more literal reading of delay "under unloaded conditions" for a shared link. But an ATM VC may only have access to bandwidth equal to its nominal allocation, which is some implementation specific function of SCR and PCR 🫶.
2.5.3 Translating Traffic Descriptors for Best Effort Service 🌸
okay, Best Effort service doesn't have any traffic description at all 🙈. The UBR service category lets you negotiate PCR, but only so the source can find the smallest physical bottleneck along the path. The ingress edge router can set PCR to the ATM line rate, and once the VC setup is done, the returned value tells you an upper bound on throughput 🔥. For UBR service, resources can be allocated for the overall service (so not per-VC) using the implementation specific admission control features of the ATM switches 💅.
Service providers often statically configure large VCs with a certain bandwidth allocation to handle all the best effort traffic between two edge routers 🍓. ABR, CBR or nrtVBR VCs are a good fit for this design, with traffic parameters set to comfortably fit the expected traffic load. Check out the IETF ION specifications for IP over ATM signalling [10, 11] if you want the details 📚.
2.6 QoS Classes and Parameters 💜
in UNI 3.x, the quality of service is indicated by one single parameter called "QoS Class," which is basically an index into a network specific table of values for the actual QoS parameters 🎀. In TM/UNI 4.0, three QoS parameters can be signalled individually, and those signalled values override whatever the QoS Class implies (the QoS Class is still there though 👀). These parameters are the Cell Loss Ratio (CLR), Cell Transfer Delay (CTD), and Cell Delay Variation (CDV) [6].
A network provider might attach other parameters to a QoS Class definition, like Severely Errored Cell Block Ratio, but those can't be signalled one by one 🙃. The ATM Forum UNI 3.0, 3.1 and TM 4.0 specs (following older ITU specs) give pretty vague qualitative definitions for QoS Classes 1 to 4. QoS Class 0 is the well-defined one: "no QoS parameters defined" 🧠. Since our mapping is based on these specs, we mostly follow this guidance: QoS Class 0 for UBR and ABR (as REQUIRED) 🚨, 1 for CBR and rtVBR, and 3 for nrtVBR 🍀. Also note that the QoS Class follows the ATM service category, not the IP service, so we don't end up with combinations that are unlikely to be supported 💅. For example, if only nrtVBR is available for GS, picking QoS Class = 1 would probably result in connection failure 😭. The QoS Class MUST NOT be read as a way to add real-time behavior to an inherently non-real-time service 🚫.
The ITU put a standard set of parameter values for a (small) number of QoS Classes in the latest version of Recommendation I.356 [21] 🌟. Network providers can define more network-specific QoS Classes on top of those. Heads up though: the QoS class definitions in the new I.356 version might not line up with the model we follow from the ATM Forum UNI specs 🙈. Apart from these definitions, there's no consistent agreement on QoS Class definitions among providers in practice, so it's kind of a vibe check 😅.
The ATM QoS parameters don't have any explicitly signalled IP layer counterparts ✨. The values that do get signalled in the ATM network are determined by the IP service definitions plus knowledge of the underlying ATM network characteristics, as explained below 🦋.
The ingress edge router SHOULD keep a table of QoS information for the set of egress routers it might set up VCs with 📋. The table can be simplified by using default values, but it's probably good practice to keep a table of current data for the most popular egress points 💖. An edge device that starts VC setup generally needs some way to propose initial values for CDV and CTD, even if they get changed by negotiation later. So by positing this table, we aren't creating any new design burden 🎀. Cached info can get updated when VCs are successfully established, and as long as IP-layer reservations can wait for VCs to finish, the values can be refined through iterated negotiation 🌸.
Both GS and CLS require that losses of packets due to congestion get minimized, so the loss rate is about the same as for an unloaded network 🫧. The loss behavior of the physical medium that isn't caused by congestion (like bit errors or fading on wireless channels) decides the order of the permitted packet loss rate 📡. The ingress edge device MUST choose a CLR value that gives the appropriate IP-level packet loss rate 🎯. The CLR value can be uniform over all egress points in the ATM network, or it can differ, for example when wireless or satellite ATM links are part of some paths 🛰️. Determining CLR MUST account for the effects of packet size distribution and ATM Frame Discard mode, which can change the effective packet loss rate by orders of magnitude [22] 🤯.
The ingress router will also tabulate values for the Minimum Path Latency (MPL) and the estimated queueing delays (D_ATM) for each egress point ⏱️. The D_ATM value gets used as part of the Adspec "D" parameter for GS, but it applies to CLS too (when the VC setup includes delay parameters) 💫. MPL covers all the constant (non-congestion related) delays, including propagation delay 🌍. D_ATM accounts for the variable part of delays in the ATM network, and it may depend on non-signalled parameters like CDVT 🌀. With these numbers, a new VC can be set up with delay-related QoS parameters given by:
CDV = D_ATM
CTD = D_ATM + MPL.(CDV and CTD may be adjusted, meaning increased, by the slack term in GS. See Section 3.3 below 🔍.)
It's kind of interesting (and maybe a bit unfortunate) that in a typical GS/rtVBR service, the delay bound advertised can contain two components of b/R instead of just one 😤. Picture the simple case where SCR = R is the rate allocated to the flow in both the IP routers and the ATM switches along the path, and the buffer allocation is MBS = b. Parekh's theory [23], which is the basis of the GS delay formula [8], says the b/R delay term only happens once. That's because once a burst of size b has been served by a congested node at rate R, the packets won't show up at a later node as one single burst 🧩. But we can't tell ahead of time whether the bottleneck will happen in the ATM network or somewhere else in the IP network. So the declaration of CDV SHOULD account for it, meaning CDV >= b/R 🚦. Once CDV is set, the ATM network can impose that delay whether or not the traffic arrives in a burst. Since the b/R delay can also happen elsewhere, it can't be removed from the first term of the GS delay formula 🙅♀️. The ATM b/R delay component shows up in the third term of the GS delay formula, D_tot. See Section 3.3 below for more on GS Adspec parameters 📝. This effect might get softened when the ATM network uses more efficient statistical resource allocation schemes 🌈.
2.7 Additional Parameters -- Frame Discard Mode 🦋
TM/UNI 4.0 lets the user pick a mode where the ATM network is aware (for congestion management purposes) of PDUs bigger than one ATM cell. These are AAL PDUs, which in our context correspond to IP packets 📦. This makes it easier to implement algorithms like partial packet discard, where a dropped cell causes the later cells in the same AAL-5 PDU to be dropped too 🧼. Several other buffer management schemes have been proposed as well [22, 24] 💡.
Frame discard can improve the efficiency and performance of end-to-end protocols like TCP, since the remaining cells of a damaged PDU are usually useless to the receiver 🙌. For IP over ATM, Frame Discard MUST always be indicated, if available 🚨.
3.0 Additional IP-Integrated Services Protocol Features 🎀
3.1 Path Characterization Parameters for IP Integrated Services with ATM ✨
Okay bestie, so this part is about setting the General Characterization Parameters (GCPs) at an ATM egress edge router 💅. GCPs get signalled from the IP source to the IP destination, and intermediate nodes tweak them using the Adspec portion of the PATH messages in rsvp 🧚. The GS-specific Adspec parameters get their own spotlight in Section 3.3 🎀. We write these as <x,y>, where x is the service and y is the parameter number. Service number 1 means the default or general values. For the definitions and all the deets, check out [25] 📚.
The IS break bit <1,2> is hands-off, obviously. Implementations following these guidelines MUST, of course, leave it alone, since they're presumably IS-aware 🙈. Same energy with the router: it MUST always bump IS_HOPS <1,4>, no exceptions 🔥. The GS and CLS service-specific break bits, <2,2> and <5,2>, MUST be set if the service isn't adequately supported 😭. Generally, GS is well supported by CBR (BCOB-A) and rtVBR, but not by UBR, ABR, or nrtVBR, because delays aren't controlled there. CLS may be adequately supported by every service category except UBR (or Best Effort in UNI 3.x) 🌈. Check Sections 5 and 6 for more tea ☕.
For GS, the ATM network MUST hit the delay numbers it advertises through the Adspec parameters MPL, C, and D 🎯. If it can't predictably meet those requirements, the GS break bit MUST be set. Both break bits MUST be set too if reservations are honored but there isn't enough allocated capacity to avoid congestion loss in practice 💀. And if the service break bits aren't set, the matching service hop counters <2,4> and <5,4> MUST be incremented ✨.
The Available Path Bandwidth (APB) parameters <x,6> tell you the minimum physical bottleneck rate along the path 🛣️. In ATM, this can be found as the negotiated PCR value for any UBR VC on the same path. That value MUST be corrected for AAL, ATM, and physical-layer headers as needed, so it reflects the real effective IP datagram bandwidth 🧮. Sometimes there's a policy cap on PCR that sits below the physical link bottleneck. In that case, the advertised APB (generally, and per service if the signalled APB values are service-specific) MUST reflect that cap, because anything beyond it gets dropped 😤. Fyi, there's no tagging of traffic over PCR in TM/UNI 4.0. These values SHOULD generally be cached by the ingress router for the set of egress routers it typically needs to set up VCs with 🗂️. APB only ever gets adjusted down, to the minimum as the composed value 📉.
In a multipoint VC, several parameters can be different for each egress point, for example because the physical links of the VC branches are different 🌸. When that happens, the IWF at the egress routers MUST correct these values in PATH messages as they exit the ATM network. We say "correct" because the ingress router SHOULD set the parameters to a value that suits the largest number of branches, or a value that does the least harm if the egress routers fail to correct them for each branch 🫶. This is the only case where the egress router needs to operate on rsvp control messages. (A similar correction MUST be implemented for any non-rsvp set-up mechanism.) The parameters where this correction is REQUIRED are the Available Path Bandwidth (APB), the Minimum Path Latency (MPL), the Path MTU (although for ATM/AAL-5 this may typically be constant), and the ATM-specific parts of the GS Adspec parameters, C_ATM and D_ATM 👑.
The ingress router table SHOULD store values for the ATM-network MPL <x,7> for the various egress points 🧠. The composed values <x,8> get formed by addition and forwarded along the path ➕. If ATM routing picks different paths for VCs to the same egress point depending on the service category, the table will usually show different values for each service 🔀. If the ATM network is very large and complicated, predicting the routes VCs take after setup can get tricky 😵💫. That can be a big source of misconfiguration, leading to mismatches between GS delay advertisements and real results 📉. The RSpec Slack term may help mitigate this problem 🦋.
AAL-5 supports message sizes up to 65,535 bytes, so setting the AAL SDU to the receiver TSpec M parameter value (plus 8 bytes for the LLC/SNAP header) generally won't be a problem 💖. In the PATH Adspec, though, the PATH_MTU parameter <x,10> for each service SHOULD be set to 9188 bytes, which is the default MTU for AAL-5 [19] 🍓.
3.2 Handling of Excess Traffic 🫶
For IP Integrated Services, network elements will carry traffic beyond the TSpec parameters whenever physical resources (bandwidth, buffers, and processing) are available 🌊. (In CLS, a "network element MUST attempt to forward the excess traffic on a best-effort basis" under certain conditions, and in GS, a traffic policers "SHOULD relegate non-conforming datagrams to best effort".) Excess traffic SHOULD be supported on a best-effort basis, but it MUST NOT interfere with the QoS (delay and loss) of conforming CLS and GS traffic, or with the normal service of non-reserved best-effort traffic 🙅♀️.
There are a few ATM solutions. The most attractive one is to use a VBR service category, with an appropriate conformance definition, and tag excess traffic as low priority using the CLP bit 💜. This avoids reordering the flow, but you need careful design of the egress router scheduler 🛠️. To avoid reordering, the excess traffic can be queued together with conforming traffic. A threshold SHOULD be used so conforming traffic isn't unnecessarily delayed by the excess 🚦. For GS, the extra delay caused by excess traffic queued ahead of conforming packets would have to be accurately reflected in the delay advertisement 📣. Note that the ingress router SHOULD tag all cells of each non-conforming packet, instead of letting the ATM network apply tagging due to ATM-level non-conformance 🏷️.
ATM standards don't require that tagged cells, whether marked by the user or by policing, get transported if possible 🤷♀️. So the operator of an edge router supporting IP-IS SHOULD find out how the ATM equipment in the path actually behaves, which may span multiple administrative domains in the ATM network 🔍. If tagged cells are simply dropped somewhere regardless of load, the operator may consider setting the break bit, at least for CLS service 🚫.
The other solutions usually involve a separate VC to carry the excess 🧚♀️. You can set up a distinct VC for each VC supporting a GS or CLS flow. Or, if lots of flows are aggregated into a single QoS VC, another VC can handle the excess for that set of flows. A VC can also be set up to handle all excess traffic from the ingress router to the egress point. Since the QoS of excess traffic isn't especially constrained, this design is quite flexible 🦄. The catch is that using a separate VC may cause misordering of packets within a flow 😬.
The service category for the excess-traffic VC is typically UBR or ABR. You could use CBR or nrtVBR if the excess traffic were predictable enough to know what rate to allocate, though this wouldn't normally be expected for excess traffic 🎈.
Whether a separate VC gets used can depend on the design of the router scheduler ⚙️. The CLS spec suggests two possible implementations. In one, excess traffic shares the Best Effort class scheduler allocation but sits at lower priority than other best-effort traffic. In the other, a separate allocation is made. The first lets excess traffic use the same VC as normal best-effort traffic, and the second suggests a separate VC 🎀.
TM/UNI 4.0 does not support tagging of traffic in excess of PCR 🙈. UNI 3.x does have a separate PCR parameter for CLP=0 cells only, but we do not recommend using that feature, because it hurts interoperability with TM/UNI 4.0 equipment 🚫. That means CBR VCs have to use solutions other than tagging. You can set the PCR higher than necessary for conformant traffic to support excess traffic on the same VC 🌈. In some cases this can be a viable solution, like when a high PCR adds little extra cost 💸. If PCR can be set as high as APB, the excess traffic is fully accommodated 💯.
3.3 Use of Guaranteed Service Adspec Parameters and Slack Term
Okay bestie, so the Adspec is how Guaranteed Service lets a receiver figure out the worst-case delay for a GS flow 🫶. Three quantities, C, D, and MPL, get added up (component by component, one set per network element) inside the PATH message as it travels from source to receiver ✨. Different receivers can end up with different delay numbers, so it's very much a "your path, your vibes" situation 💅. The maximum delay works out to:
delay <= b_r/R + C_TOT/R + D_TOT + MPLThe MPL is the Minimum Path Latency, and it covers propagation delay 🌈. b_r/R handles the bursts coming from the source, and C and D cover the other queueing, scheduling, and serialization delays 🦋. (We're skipping the effect of maximum packet size and peak rate here, so if you want the full-fat equation, check the GS specification [8] 🤓.) The service rate the receiver asks for, R, can be bigger than the TSpec rate, r_r, and that gets you lower delay, which is iconic 👑. The burst size, b_r, is the leaky bucket parameter from the receiver TSpec.
The C and D values a router advertises depend on two things: the router's packet scheduler, and the characteristics of the subnet attached to that router 🎀. Each router (or the source host) takes responsibility for its own downstream subnet in its advertisement. For example, if the subnet is a simple point-to-point link, the subnet-specific parts of C and D have to account for the link transmission rate and MTU 🧚. An ATM subnet is generally more complex, lowkey a whole mood 😭.
For this discussion, we only look at the ATM subnet-specific components, called C_ATM and D_ATM 🌸. The ATM network can be treated as a "pure delay" element, where the variable queueing delay (given by CVD) gets captured in D_ATM, and C_ATM is set to zero. You can only use C_ATM when the ATM service rate equals R, and that might happen with a CBR VC where PCR = R, for example 💜.
Usually it's simpler to just advertise the total delay variation (CDV) in D_ATM ✨.
As we talked about in Section 2.6, the edge router keeps a table with values of MPL and D_ATM for each egress router it needs to share VCs with 📋. The value of D_ATM feeds into the D parameter that the edge router advertises, and it SHOULD accurately reflect the CDV the router will get in a VC when that VC is set up 🔥. Factors that affect CDV, like statistical multiplexing in the ATM network, SHOULD be taken into account when you compile the data for the router's table 🙈. If you're not sure, D_ATM can be set to an upper bound, which is the safe move 🫶. When a RESV message arrives and causes a VC to be set up, the requested values for CTD and CDV can be relaxed using the slack term in the receiver RSpec:
CTD = D_ATM + MPL + S_ATM
CDV = D_ATM + S_ATM.S_ATM is the portion of the slack term that gets applied to the ATM part of the path 💖. Quick reminder that the slack term [8] is positive when the receiver can afford more delay than the one computed from the Adspec 🍓. The ATM edge device may take part of the slack term, or all of it (that's S). How the delay slack gets distributed among the nodes and subnets is network specific, so it's up to the network 🌈.
Also, with multipoint VCs, the egress edge router may need to correct the advertised values of C and D. See the discussion in Section 3.1 for the deets 🦋.
4.0 Miscellaneous Items
4.1 Units Conversion
Real talk, the units are where things get messy 😭. All rates and token bucket depth parameters that get mapped from IP-level parameters to ATM parameters MUST be corrected for the effects of added headers and for the segmentation of packets into cells 💅. At the IP layer, token bucket depths and rates are measured in bytes and bytes/sec, but over on the ATM side they're measured in cells and cells/sec 🧚.
Each IP packet gets wrapped into an AAL-5 PDU, which has some extra header bytes (8 for LLC/SNAP, and maybe others, like 12 for MPOA, etc.) plus an 8-byte AAL-5 trailer 🎀. The AAL-5 PDU then gets chopped into multiple ATM cells, each with a 5-byte cell header followed by a 48-byte cell payload ✨. The number of cells used to carry an IP packet, with:
B = number of IP-packet Bytes,
H = number of AAL-5 header bytes (LLC/SNAP etc.)
C = number of cells,is roughly:
C = B/48,and more precisely:
C = floor[(H + B + 8 + 47)/48]where floor[] is rounds down to the nearest integer. The '8' accounts for the AAL-5 trailer, and the '47' accounts for the last cell, which might only be partially filled 🌸.
5.0 Summary of ATM VC Setup Parameters for Guaranteed Service
This section is the cheat sheet for making ATM VCs that are properly matched for Guaranteed Service 💅. The key points: real-time timing is REQUIRED, the data flow might have a variable rate, and demotion of non-conforming traffic to best effort is REQUIRED so it stays in agreement with the definition of GS 🔥. For that reason, we prefer an rtVBR service where tagging is supported 🦋. Another good match is CBR with special handling for any non-conforming traffic, for example through another VC, since a CBR VC won't accommodate traffic in excess of PCR 🫶.
Heads up, these encodings assume point to multipoint connections, where the backward channel isn't used 👀. If the IP session is unicast only, then a point-to-point VC can be used, and the IWF may make use of the backward channel, with QoS parameters set appropriately for the service provided 💜.
We've got a mapping for every combination of IP service and ATM service category, plus comments on whether each combination meets the requirements of the IP-IS service 📋.
5.1 Encoding GS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
RtVBR with conformance definition VBR.3 [6] MEETS the requirements of GS, so this one is a certified slay 👑.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 1
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 1
Backward MBS (CLP=0) 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 9 (Real time VBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
Note 1: See discussion in Section 2.5.1.
Note 2: Value 3 (BCOB-C) can also be used.
If Bearer Class C is chosen the ATC field MUST be absent.
Note 3: The ATC value 19 is not used. The value 19 implies that the
CLR objective applies to the aggregate CLP=0+1 stream and
that does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6.5.2 Encoding GS Using CBR (ATM Forum TM/UNI 4.0)
A CBR VC MEETS the requirements of GS 🎀. The big upside is that CBR is widely supported 🌈. The downside is that data flows might not fill the pipe (utilization loss), and there's no tagging option available 😭. Excess traffic MUST be handled using a separate VC 🫶.
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 0 (Tagging not requested)
Tagging Backward bit 0 (Tagging not requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 5 (CBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 1 Note 5
QoS Class Backward 1 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
Note 1: See discussion in Section 2.5.1.
Note 2: Value 1 (BCOB-A) can also be used.
If Bearer Class A is chosen the ATC field MUST be absent.
Note 3: The ATC value 7 is not used. The value 7 implies CLR
objective applies to the aggregate CLP=0+1 stream and that
does not give desirable treatment of excess traffic.
Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol
SHOULD be specified. For BE VCs, it can be left
unspecified, allowing the VC to be shared by multiple
protocols, following RFC 1755.
Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
Note 6: See discussion in Section 2.6.5.3 Encoding GS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
Lowkey not the move 🙈. NrtVBR doesn't give delay guarantees, so it's NOT RECOMMENDED for GS 💀. If you use GS with nrtVBR and network utilization is low, the delay might look "reasonable", but it won't be controlled 😬. The encoding of GS with nrtVBR is the same as the one for CLS using nrtVBR, so check out Section 6.1 below 🫶.
5.4 Encoding GS Using ABR (ATM Forum TM/UNI 4.0)
GS using ABR is a very unlikely combo, and it DOES NOT meet the service requirements of GS 🙃. ABR is all about giving "low" loss rates. The delay objectives for ABR SHOULD be expected to be very loose 🍓. If ABR were used for GS, the VC parameters would follow the ones for CLS over ABR, so see Section 6.2 ✨.
5.5 Encoding GS Using UBR (ATM Forum TM/UNI 4.0)
UBR is the lowest common denominator of the services 🧚. It can't provide delay or loss guarantees, so it DOES NOT meet the requirements of GS 😭. But if it does get used for GS, it's encoded the same way as Best Effort over UBR, with one exception: the Forward PCR would be determined from the peak rate of the receiver TSpec. See Section 7.1 🌈.
5.6 Encoding GS Using ATM Forum UNI 3.0/3.1 Specifications
okay so, real talk: supporting GS over UNI 3.x VBR is not giving. The BCOB-C Bearer Class just doesn't represent real-time behavior, so it's a no from me 🙅♀️. Also, Appendix F of the UNI 3.1 spec blocks traffic type "VBR" with the timing requirement "End to End timing Required" when you pair it with Bearer Class X. Bestie, that's a whole vibe clash 💀
A CBR VC MEETS the requirements of GS, though. Slay 💅 Here's the table for GS using CBR:
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Mode 1 (Message mode) Note 1
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0 Note 2
Backward PCR CLP=0 0
Forward PCR CLP=0+1 Note 2
Backward PCR CLP=0+1 0
BE indicator NOT included
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 3
Traffic Type 001 (Constant Bit Rate)
Timing Requirements 01 (Timing Required)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class Note 5
QoS Class Forward 1
QoS Class Backward 1Notes, because they matter 🫶
- Note 1: Only included for UNI 3.0.
- Note 2: See the discussion in Section 2.5.1. PCR CLP=0 SHOULD be set identical to PCR CLP=0+1. Yes, it could let a CBR VC carry excess traffic as tagged cells, but that's not recommended, since UNI 4.0 doesn't support it.
- Note 3: Value 1 (BCOB-A) can also be used. If BCOB-A is used, the Traffic Type and Timing Requirements fields are not included.
- Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs it can be left unspecified, so the VC can be shared by multiple protocols, following RFC 1755 ✨
- Note 5: QoS Parameters are implied by the QoS Class.
6.0 Summary of ATM VC Setup Parameters for Controlled Load Service 🎀
This section is all about making ATM VCs that fit Controlled Load Service perfectly. CLS traffic is partly delay tolerant and has a variable rate, so NrtVBR and ABR (TM/UNI 4.0 only) are the best picks for it 🦋
Heads up: these encodings assume point-to-multipoint connections where the backward channel isn't used. If the IP session is unicast only, a point-to-point VC may be used instead, and the IWF may make use of the backward channel, with QoS parameters set appropriately for the service provided.
We give you a mapping for every combo of IP service and ATM service category, plus comments on whether each combo meets the requirements of the IP-IS service. Main character energy 👑
6.1 Encoding CLS Using Non-Real-Time VBR (ATM Forum TM/UNI 4.0)
NrtVBR MEETS the requirements for CLS 💖
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 1
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 1
Backward MBS (CLP=0) 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 10 (Non-real time VBR) Note 3
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5
Extended QoS Parameters Note 6
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTDNotes, bestie 🙈
- Note 1: See the discussion in Section 2.5.2.
- Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is used, the ATC field MUST be absent.
- Note 3: The ATC value 11 is not used. The value 11 implies that the CLR objective applies to the aggregate CLP=0+1 stream, and that does not give desirable treatment of excess traffic.
- Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs it can be left unspecified, so the VC can be shared by multiple protocols, following RFC 1755.
- Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
- Note 6: See the discussion in Section 2.6.
6.2 Encoding CLS Using ABR (ATM Forum TM/UNI 4.0)
ABR MEETS the requirements for CLS when MCR is set to the CLS TSpec rate. Iconic 🌈
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
Forward MCR CLP=0+1 Note 1
Backward MCR CLP=0+1 0
BE indicator NOT included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 0 (Tagging not requested)
Tagging Backward bit 0 (Tagging not requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 12 (ABR)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 00 (Point-to-Point)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 3
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 0 Note 4
QoS Class Backward 0 Note 4
Extended QoS Parameters Note 5
Acceptable Forward CDV
Acceptable Forward CLR
Forward Max CTD
ABR Setup Parameters Note 6
ABR Additional Parameters Note 6Notes, the fine print 💅
- Note 1: See the discussion in Section 2.5.2.
- Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is chosen, the ATC field MUST be absent.
- Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs it can be left unspecified, so the VC can be shared by multiple protocols, following RFC 1755.
- Note 4: Cf ITU Rec. I.356 [21] for new QoS Class definitions.
- Note 5: See the discussion in Section 2.6.
- Note 6: The ABR-specific parameters are beyond the scope of this document. They generally depend on local implementation and not on values mapped from IP level service parameters (except for MCR). See [6, 11] for further information.
6.3 Encoding CLS Using CBR (ATM Forum TM/UNI 4.0)
Okay, so CBR doesn't explicitly care about the variable rate of source data 🙃 BUT it can still be handy to use ATM connectivity between edge routers as a simple "pipe" service, like a leased line replacement. There's no tagging option with CBR, so excess traffic MUST be handled using a separate VC. Under that condition, CBR MEETS the requirements of CLS ✨
To use CBR for CLS, you'd use the same encoding as GS over CBR (Section 5.2). See the discussion in Section 2.5.2.
6.4 Encoding CLS Using Real-Time VBR (ATM Forum TM/UNI 4.0)
Here's the tea 🍵 Encoding CLS with rtVBR implies a hard limit on the end-to-end delay in the ATM network. That adds more complexity to the VC setup than CLS actually needs, so it's not a preferred combo. It DOES MEET the requirements of CLS though, so it's not totally cooked 🥹
If rtVBR is used to encode CLS, the encoding is basically the same as for GS. See the discussions in Section 5.1 and Section 2.5.2.
6.5 Encoding CLS Using UBR (ATM Forum TM/UNI 4.0)
This one's a bit of a pass 🥀 This encoding gives no QoS guarantees and DOES NOT MEET the requirements of CLS. If you do use it, it's coded the same way as BE over UBR (Section 7.1), except the PCR gets determined from the peak rate of the receiver TSpec.
6.6 Encoding CLS Using ATM Forum UNI 3.0/3.1 Specifications
Okay so this one is equivalent to the nrtVBR service category, and it totally meets the requirements of CLS. 💅
AAL
Type 5
Forward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Backward CPCS-SDU Size parameter M of rcvr TSpec + 8 Bytes
Mode 1 (Message mode) Note 1
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 2
Backward PCR CLP=0+1 0
Forward SCR CLP=0 Note 2
Backward SCR CLP=0 0
Forward MBS (CLP=0) Note 2
Backward MBS (CLP=0) 0
BE indicator NOT included
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 3
Traffic Type 010 (Variable Bit Rate)
Timing Requirements 00 (No Indication)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2)
User Information Layer 3
Protocol 11 (ISO/IEC TR 9577) Note 4
ISO/IEC TR 9577 IPI 204
QoS Class
QoS Class Forward 3 Note 5
QoS Class Backward 3 Note 5Now the notes, so you don't miss any tea:
- Note 1: Only included for UNI 3.0. ✨
- Note 2: See discussion in Section 2.5.2. 🎀
- Note 3: Value 3 (BCOB-C) can also be used. If BCOB-C is used Traffic Type and Timing Requirements fields are not included. 🦋
- Note 4: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. 🫶
- Note 5: Cf ITU Rec. I.356 [21] for new QoS Class definitions. QoS Parameters are implied by the QoS Class. 👑
7.0 Summary of ATM VC Setup Parameters for Best Effort Service
This section is provided for completeness only, bestie. 🌸 The IETF ION working group documents on ATM signalling support for IP over ATM [10, 11] are the ones with the definitive specs for Best Effort IP service over ATM. Go there for the real deal. ✨
The best-matched ATM service category to IP Best Effort is UBR, so that's what we set up below. The BE service does not involve reservation of resources. ABR and nrtVBR are also well suited to BE service. See discussion in Section 2.1.3. 🍓
Note, VCs supporting best effort service are usually point to point rather than point to multipoint, and the backward channels of VCs are used. In cases where VCs are set up to support best effort multicast sessions, multipoint VCs can be used, and the backward channels would be not have resources reserved. Related situations include transport of excess traffic on IP-multicast QoS sessions, or supporting the subset of multicast end systems that have not made rsvp reservations. See the discussion on VC management in [12]. 🧚
7.1 Encoding Best Effort Service Using UBR (ATM Forum TM/UNI 4.0)
AAL
Type 5
Forward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5)
Backward CPCS-SDU Size 9188 Bytes (default MTU for AAL-5)
SSCS Type 0 (Null SSCS)
Traffic Descriptor
Forward PCR CLP=0+1 Note 1
Backward PCR CLP=0+1 0
BE indicator included
Forward Frame Discard bit 1
Backward Frame Discard bit 1
Tagging Forward bit 1 (Tagging requested)
Tagging Backward bit 1 (Tagging requested)
Broadband Bearer Capability
Bearer Class 16 (BCOB-X) Note 2
ATM Transfer Capability 10 (Non-real time VBR)
Susceptible to Clipping 00 (Not Susceptible)
User Plane Configuration 01 (Point-to-Multipoint)
Broadband Low Layer Information
User Information Layer 2
Protocol 12 (ISO 8802/2) Note 3
QoS Class
QoS Class Forward 0
QoS Class Backward 0And the notes for this one:
- Note 1: See discussion in Section 2.5.3. 💖
- Note 2: Value 3 (BCOB-C) can also be used. If Bearer Class C is used, the ATC field MUST be absent. 🙈
- Note 3: For QoS VCs supporting GS or CLS, the layer 3 protocol SHOULD be specified. For BE VCs, it can be left unspecified, allowing the VC to be shared by multiple protocols, following RFC 1755. 🫶
8.0 Security Considerations
💀 Okay, this section is serious, so read it carefully. IP Integrated Services (including rsvp) and ATM are both complex resource reservation protocols, and they SHOULD be expected to have complex feature interactions. Like, complicated is the vibe. 😭
Differences in IP and ATM billing styles could cause unforeseen problems, because RESV messages can set up VCs. Say an end-user is paying a flat rate for (non-rsvp aware) internet service and sends an rsvp RESV message that runs into a (maybe distant) ATM network with a usage-sensitive billing model. Yikes. Insufficient authentication could mean services get accidentally billed to an innocent third party, or that someone steals service on purpose, or that malicious denial of service attacks happen, where tons of reservations eat up transport or processing resources at the edge devices. 🚨
The difference in how each side handles excess traffic could also lead to denial of service attacks. The ATM network might burn through transport resources (bandwidth, buffers) or connection processing resources (switch processor cycles) just trying to accommodate excess traffic that the internet service already admitted. 🔥
Problems with translating resource reservations at edge devices are probably even more complex, and more open to abuse, when the IP-ATM edge is also an administrative boundary between service providers. Also note that administrative boundaries can exist within the ATM cloud, i.e., the ingress and egress edge devices are operated by different service providers. 👑
Note, the ATM Forum Security Working Group is currently defining ATM-level security features such as data encryption and signalling authentication. See also the security issues raised in the rsvp specification [3]. 🦋
9.0 Acknowledgements
The authors got lots of super useful input from the members of the ISSLL working group. 🌈 A big thank you to Drew Perkins and Jon Bennett of Fore Systems, Roch Guerin of IBM, and Susan Thomson and Sudha Ramesh of Bellcore. 🫶✨
Appendix 1 Abbreviations
Here's the full glossary, no cap. 📚🎀
AAL ATM Adaptation Layer
ABR Available Bit Rate
APB Available Path Bandwidth (int-serv GCP)
ATC ATM Transfer Capability
ATM Asynchronous Transfer Mode
B-LLI Broadband Low Layer Information
BCOB Broadband Connection-Oriented Bearer Capability
BCOB-{A,C,X} Bearer Class A, C, or X
BE Best Effort
BT Burst Tolerance
CBR Constant Bit Rate
CDV Cell Delay Variation
CDVT Cell Delay Variation Tolerance
CLP Cell Loss Priority (bit)
CLR Cell Loss Ratio
CLS Controlled Load Service
CPCS Common Part Convergence Sublayer
CTD Cell Transfer Delay
EOM End of Message
GCP General Characterization Parameter
GCRA Generic Cell Rate Algorithm
GS Guaranteed Service
IE Information Element
IETF Internet Engineering Task Force
ION IP Over Non-broadcast multiple access networks
IP Internet Protocol
IPI Initial Protocol Identifier
IS Integrated Services
ISSLL Integrated Services over Specific Link Layers
ITU International Telecommunication Union
IWF Interworking Function
LIJ Leaf Initiated Join
LLC Logical Link Control
MBS Maximum Burst Size
MCR Minimum Cell Rate
MPL Minimum Path Latency
MTU Maximum Transfer Unit
nrtVBR Non-real-time VBR
PCR Peak Cell Rate
PDU Protocol Data Unit
PVC Permanent Virtual Connection
QoS Quality of Service
RESV Reservation Message (of rsvp protocol)
RFC Request for Comments
RSVP Resource Reservation Protocol
RSpec Reservation Specification
rtVBR Real-time VBR
SCR Sustainable Cell Rate
SDU Service Data Unit
SNAP Subnetwork Attachment Point
SSCS Service-Specific Convergence Sub-layer
SVC Switched Virtual Connection
TCP Transport Control Protocol
TM Traffic Management
TSpec Traffic Specification
UBR Unspecified Bit Rate
UNI User-Network Interface
UPC Usage Parameter Control (ATM traffic policing function)
VBR Variable Bit Rate
VC (ATM) Virtual ConnectionReferences ✨
bestie, this is the reading list, and every single one of these is load-bearing 📚🫶 Here they are, exactly as written:
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
- [3] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
- [4] The ATM Forum, "ATM User-Network Interface Specification, Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.
- [5] The ATM Forum, "ATM User-Network Interface Specification, Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.
- [6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification, Version 4.0", July 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps. - [7] The ATM Forum, "ATM Traffic Management Specification, Version 4.0", April 1996. Available at
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps. - [8] M. W. Garrett, "A Service Architecture for ATM: From Applications to Scheduling", IEEE Network Mag., Vol. 10, No. 3, pp. 6-14, May 1996.
- [9] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
- [10] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
- [11] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
- [12] Maher, M., "ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", RFC 2331, April 1998.
- [13] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998.
- [14] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
- [15] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
- [16] Shenker, S., and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.
- [17] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
- [18] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Real-time Services in an IP-ATM Network Architecture", RFC 1821, August 1995.
- [19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
- [20] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January 1994.
- [21] ITU Recommendation I.356, "B-ISDN ATM layer cell transfer performance", International Telecommunication Union, Geneva, October 1996.
- [22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Networks", IEEE J. Sel. Areas in Commun., Vol. 13, No. 4, pp. 633-41, May 1995.
- [23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, No. 2, pp. 137-150, April 1994.
- [24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, No. 4, August 1995.
- [25] S. Shenker and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
Authors' Addresses 💌
the people behind this spec, with their contact details 🌸
Mark W. Garrett
Bellcore
445 South Street
Morristown, NJ 07960
USA
Phone: +1 201 829-4439
EMail: mwg@bellcore.com
Marty Borden
Bay Networks
42 Nagog Park
Acton MA, 01720
USA
Phone: +1 508 266-1011
EMail: mborden@baynetworks.comFull Copyright Statement 📜
okay, legal stuff, but it matters, so here it is word for word 🎀
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.📦 where this page comes from
- ietf: rfc2381 1998-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms