RFC 2382

A Framework for Integrated Services and RSVP over ATM

📅 published August 1998, from ietf

RFC 2382: A Framework for Integrated Services and RSVP over ATM 🦋

Network Working Group 🌸 (the group that wrote it) Request for Comments: 2382 💖 Category: Informational ✨ (it's for info, not an official standard, so no pressure!) Date: August 1998 🎀

Authors: E. Crawley (Editor, Argon Networks), L. Berger (Fore Systems), S. Berson (ISI), F. Baker (Cisco Systems), M. Borden (Bay Networks), and J. Krawczyk (ArrowPoint Communications). That's a whole squad 💅

Obsoletes / Updates: This header doesn't list anything it obsoletes or updates, so it stands on its own. 🧚

Status of this Memo 🌈

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. So basically: read it, share it, no gatekeeping 💜

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract ✨

Okay so this document lays out the issues and the big-picture framework for running IP Integrated Services with RSVP over ATM. 🍓 It gives an overall approach to the problem(s) and all the related drama. The actual fixes are supposed to show up in later documents from the ISATM subgroup of the ISSLL working group. Think of this one as the set-up episode 📺

1. Introduction ✨

The Internet currently has one class of service, usually called "best effort." 🌸 It's basically first-come, first-serve scheduling at every hop in the network. Honestly it's been iconic for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), and so on 💅 But for real-time traffic like voice and video, the current Internet only really slays across unloaded parts of the network 🙈 To get proper quality real-time traffic, the Internet is getting new classes of service and a QoS signalling protocol [1,6,7], and best effort is staying right where it is. The QoS signalling protocol is RSVP [1], the Resource ReSerVation Protocol, along with the service models.

One of the big features of ATM technology is that you can request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). 🦋 ATM also lets you request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs let leaf nodes get added and removed from the VC dynamically, which gives you a way to support IP multicast. It's only natural that RSVP and the Internet Integrated Services (IIS) model would want to use the QoS properties of any underlying link layer, ATM included, and this memo focuses on ATM. 💖

Classical IP over ATM [10] has already solved part of this problem by supporting IP unicast best effort traffic over ATM. 🎀 It's built on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts inside one LIS talk to each other over the ATM network, but hosts on different subnets can only communicate by going through an IP router, even though it might be possible to open a direct VC between the two hosts over the ATM network. 🙃 Classical IP over ATM also provides an Address Resolution Protocol (ATMARP) so ATM edge devices can resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (hosts or routers), a single VC gets created on demand and shared for all the traffic between those two devices. The second part of the RSVP and IIS over ATM problem is IP multicast, and that's being handled by MARS [5], the Multicast Address Resolution Server. 🧚

MARS complements ATMARP by letting an IP address resolve into a list of native ATM addresses, instead of just one address. Iconic teamwork 🫶

The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over ATM (MPOA) [18] also handle IP best effort traffic over ATM, using similar approaches. 🌈

A big remaining issue for IP in an ATM environment is blending RSVP signalling with ATM signalling to support the Internet Integrated Services (IIS) model. 😭 There are two main areas involved in supporting the IIS model: QoS translation and VC management. QoS translation is about mapping a QoS from the IIS model to a proper ATM QoS. VC management is about how many VCs are needed and which traffic flows get routed over which VCs. Two jobs, both important 👑

This document is a guide to the issues for IIS over ATM. It's meant to frame the problems that the further documents will tackle. Here, we'll talk about the modes and models for RSVP operation over ATM first, then how ATM VCs get managed for RSVP data and control, and finally encapsulations and how they relate to the models we just covered. 💅

This document is part of a group of documents from the ISATM subgroup of the ISSLL working group, all about running IntServ and RSVP over ATM. [14] talks about mapping the IntServ models for Controlled Load and Guaranteed Service to ATM. [15 and 16] cover detailed implementation requirements and guidelines for RSVP over ATM, respectively. These documents might not cover every issue raised here, but they should give you enough info to start building solutions for IntServ and RSVP over ATM. ✨

1.2. Terms 🎀

Several terms used in this document also get used in lots of other contexts, often with different meanings, so here's exactly what they mean in this doc:

  • Sender means the ingress point to the ATM network, aka the "cloud." 🦋
  • Receiver means the egress point from the ATM network, aka the "cloud." 🧚
  • Reservation refers to an RSVP initiated request for resources. RSVP starts these requests based on RESV message processing. RESV messages that just refresh state do not trigger resource requests. Resource requests may be made based on RSVP sessions and RSVP reservation styles. RSVP styles decide whether the reserved resources get used by one sender or shared by multiple senders. See [1] for details of each. Every new request is called an RSVP reservation here, or just reservation. 💖
  • Flow is the data traffic tied to a particular reservation. What counts as a flow depends on the RSVP style: for shared style reservations there's one flow per session, and for distinct style reservations there's one flow per sender (per session). 🌈

2. Issues Regarding the Operation of RSVP and IntServ over ATM 🔥

The issues for RSVP and IntServ over ATM fall into a few general buckets:

  • How to make RSVP run over ATM now and in the future 🌸
  • When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP 🎀
  • How to map the IntServ models to ATM QoS models 🦋
  • How to know that an ATM network is providing the QoS needed for a flow 👀
  • How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to-many connection-oriented world of ATM 🙈

2.1. Modes/Models for RSVP and IntServ over ATM 💜

[3] discusses several different models for running IP over ATM networks. [17, 18, and 20] also provide models for IP in ATM environments. Any one of these models works, as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. 🧚 It's really important that the RSVP PATH messages follow the same IP path as the data, so the right PATH state gets installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points have to be the same in both directions for the RSVP control and data messages. Note that the RSVP protocol does not require symmetric routing, so you're not stuck doing it the same way both ways 🙌 The PATH state that RSVP installs lets RESV messages "retrace" the hops the PATH message crossed. Within each of the IP over ATM models, there are decisions to make about using different types of data distribution in ATM, as well as different connection initiation. The next sections look at some of the different ways QoS connections can be set up for RSVP. 🫶

2.1.1. UNI 3.x and 4.0 🌈

In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9] and the 4.0 specification, both permanent and switched virtual circuits (PVC and SVC) can be established with a specified service category and specific traffic descriptors, in point-to-point and point-to-multipoint setups. The service categories are CBR, VBR, and UBR for UNI 3.x, and VBR-rt and ABR for 4.0. 😭 Additional QoS parameters aren't available in UNI 3.x, and the ones that are available are vendor-specific. So honestly the level of QoS control in standard UNI 3.x networks is kinda limited 🙃 Still, using these building blocks, it's possible to use RSVP and the IntServ models. ATM 4.0 with the Traffic Management (TM) 4.0 specification [21] gives you way more control over QoS 👑 [14] has the details on mapping the IntServ models to UNI 3.x and 4.0 service categories and traffic parameters. ✨

2.1.1.1. Permanent Virtual Circuits (PVCs) 🎀

PVCs act like dedicated point-to-point lines in a network, so RSVP can operate exactly the same way it would over any point-to-point network. 💖 The QoS of the PVC must be consistent and equivalent to the type of traffic and service model in use. The devices on either end of the PVC have to provide traffic control services so they can multiplex multiple flows over the same PVC. With PVCs, there's no issue about when or how long it takes to set up VCs, since they're made in advance. The catch is that the PVC's resources are limited to whatever was pre-allocated 🙈 And PVCs that aren't fully used can tie up ATM network resources that could have been used for SVCs. Not a great look 😬

There's also an extra network engineering issue with PVCs. Often, multiple PVCs get set up so that if they were all running at full capacity, the link would be over-subscribed. This is the "statistical multiplexing gain," and it makes providing IIS over PVCs very difficult and unreliable. 💀 So any application of IIS over PVCs has to be assured that the PVCs can actually receive all the requested QoS. Bestie, double-check your PVCs before you commit 🫶

2.1.1.2 Switched Virtual Circuits (SVCs) 🦋

SVCs let paths in the ATM network get set up "on demand" 💅 That gives you flexibility when you're running RSVP over ATM, but ngl it also brings some complexity 🙈 Parallel VCs can be set up so you get a best-effort path and a better service class path through the network, like in Figure 1. The cost and time to set up SVCs can affect how much you use them. For example, it might be smarter to start by sending QoS traffic over VCs that already exist, until an SVC with the desired QoS can be set up for the flow 🧚 Scaling issues can come into play if you use a single RSVP flow per VC, as we'll talk about in Section 4.3.1.1. The number of VCs in any ATM device may also be limited, so the number of RSVP flows a device can support can be strictly limited to the number of VCs available, if we assume one flow per VC 💀 Section 4 goes deeper into VC management for RSVP.

                             Data Flow ==========>

                     +-----+
                     |     |      -------------->  +----+
                     | Src |    -------------->    | R1 |
                     |    *|  -------------->      +----+
                     +-----+       QoS VCs
                          /\
                          ||
                      VC  ||
                      Initiator

                    Figure 1: Data Flow VC Initiation

Okay so RSVP is receiver oriented, but ATM is sender oriented 🌸 That might sound like a big problem, but it's actually fine! The sender or ingress point receives RSVP RESV messages and can figure out whether a new VC has to be set up to the destination or egress point ✨

2.1.1.3 Point to MultiPoint 🌈

Here's the thing: to provide QoS for IP multicast (a super important RSVP feature), data flows have to get distributed to multiple destinations from a given source 📡 Point-to-multipoint VCs give you exactly that. It's key to map the actions of IP multicasting and RSVP (like IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) onto add party and drop party functions for ATM 🫶 Point-to-multipoint VCs, as defined in UNI 3.x and UNI 4.0, have a single service class for all destinations. Which is kind of messy, because it's contrary to the RSVP "heterogeneous receiver" concept 🙃 You can set up a different VC to each receiver asking for a different QoS, as shown in Figure 2. But this can run into scaling and resource problems again when you're managing multiple VCs on the same interface to different destinations 😭

                                    +----+
                           +------> | R1 |
                           |        +----+
                           |
                           |        +----+
              +-----+ -----+   +--> | R2 |
              |     | ---------+    +----+  Receiver Request Types:
              | Src |                       ---->  QoS 1 and QoS 2
              |     | .........+    +----+  ....>  Best-Effort
              +-----+ .....+   +..> | R3 |
                           :        +----+
                       /\  :
                       ||  :        +----+
                       ||  +......> | R4 |
                       ||           +----+
                     Single
                  IP Multicast
                     Group

                    Figure 2: Types of Multicast Receivers

RSVP sends messages both up and down the multicast distribution tree 🌳 So if you've got a large ATM cloud with lots of receivers, this could cause an RSVP message implosion at an ATM ingress point 🤯

ATM 4.0 takes point-to-multipoint VCs up a notch by adding a Leaf Initiated Join (LIJ) capability 💜 LIJ lets an ATM end point join an existing point-to-multipoint VC without necessarily contacting the source of the VC. That can lighten the load on the ATM source point when it comes to setting up new branches, and it matches the receiver-based model of RSVP and IP multicast even more closely 👑 Still, a lot of the same scaling issues stick around, and any new branches added to a point-to-multipoint VC must use the same QoS as the existing branches 🙈

2.1.1.4 Multicast Servers 🧜‍♀️

IP-over-ATM has this concept of a multicast server (or reflector) that can accept cells from multiple senders and send them via a point-to-multipoint VC to a set of receivers 🎀 It basically moves the VC scaling issues we just talked about for point-to-multipoint VCs over to the multicast server 🫠 On top of that, the multicast server will need to know how to interpret RSVP packets, or receive instructions from another node, so it can provide VCs with the appropriate QoS for the RSVP flows 💅

2.1.2 Hop-by-Hop vs. Short Cut 🦋

If the ATM "cloud" is made up of a number of logical IP subnets (LISs), then it's possible to use "short cuts" from a node on one LIS directly to a node on another LIS, skipping the router hops between the LISs ⭐ NHRP [4] is one mechanism for figuring out the ATM address of the egress point on the ATM network, given a destination IP address. Whether significant benefit actually comes from short cut routes vs. the extra state they require? That's a topic for further study 🧐

2.1.3 Future Models 🔮

ATM is constantly evolving, and if we assume RSVP and IntServ applications are going to be widespread, it makes total sense to consider changes to ATM that would improve how RSVP and IntServ run over it 🚀 Same goes for the RSVP protocol and the IntServ models, which will keep evolving. Changes that affect them should also be considered 💖 The following are a few ideas that have been discussed that would make integrating the IntServ models and RSVP easier or more complete. They're here to encourage continued development and discussion of ideas that can help with the integration of RSVP, IntServ, and ATM 🫶

2.1.3.1 Heterogeneous Point-to-MultiPoint 🌸

The IntServ models and RSVP support the idea of "heterogeneous receivers". Basically, not all receivers of a particular multicast flow have to ask for the same QoS from the network, as shown in Figure 2 🍓

The most important scenario that can use this feature happens when some receivers in an RSVP session ask for a specific QoS while others receive the flow with a best-effort service 💅 In some cases, where there are multiple senders on a shared-reservation flow (like an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. Other receivers might choose to reserve more, maybe to allow for some amount of "over-speaking" or to record the conference (post processing during playback can separate the senders by their source addresses) 🎙️

To prevent denial-of-service attacks via reservations, the service models do not let the service elements just drop non-conforming packets 🛡️ For example, the Controlled Load service model [7] assigns non-conformant packets to best-effort status (which may result in packet drops if there's congestion) 😬

Emulating these behaviors over an ATM network is problematic and needs to be studied 🥲 If a single maximum QoS is used over a point-to-multipoint VC, resources could get wasted when cells get sent over certain links where the reassembled packets will eventually be dropped. And the "maximum QoS" might actually cause a degradation in service to the best-effort branches 💀

The term "variegated VC" has been coined to describe a point-to-multipoint VC that allows a different QoS on each branch ✨ This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to go into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one 🧠 The "best-effort for non-conforming packets" behavior must also be retained. Early Packet Discard (EPD) schemes must be used so that all the cells for a given packet can be discarded at the same time, instead of discarding only a few cells from several packets. Otherwise, all the packets end up useless to the receivers 🗑️

2.1.3.2 Lightweight Signalling 🪶

Q.2931 signalling is very complete, but it carries a significant burden for signalling in all possible public and private connections 😮‍💨 It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks ⚡

2.1.3.3 QoS Renegotiation 🔄

Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC 🙌 This would get rid of the need to set up and tear down VCs every time the QoS changes. RSVP lets receivers change their reservations and senders change their traffic descriptors dynamically. This, along with the merging of reservations, can create a situation where the QoS needs of a VC change. Allowing changes to the QoS of an existing VC would let these features work without creating a new VC 🦋 In the ITU-T ATM specifications [24,25], some cell rates can be renegotiated or changed. Specifically, the Peak Cell Rate (PCR) of an existing VC can be changed, and in some cases, QoS parameters may be renegotiated during the call setup phase. Honestly? It's unclear if this is enough for the QoS renegotiation needs of the IntServ models 🤔

2.1.3.4 Group Addressing 🧩

The model of one-to-many communications provided by point-to-multipoint VCs doesn't really match the many-to-many communications provided by IP multicasting 🙃 A scaleable mapping from IP multicast addresses to an ATM "group address" could solve this problem 💜

2.1.3.5 Label Switching 🏷️

The MultiProtocol Label Switching (MPLS) working group is discussing ways to optimize the use of ATM and other switched networks for IP. They do this by encapsulating the data with a header that interior switches use to achieve faster forwarding lookups 🏎️ [22] discusses a framework for this work. It's unclear how this work will affect IntServ and RSVP over label switched networks, but there may be some interactions 👀

2.1.4 QoS Routing 🛣️

RSVP is explicitly not a routing protocol 🙅‍♀️ However, since it conveys QoS information, it might prove to be a valuable input to a routing protocol that makes path determinations based on QoS and network load information. In other words, instead of just asking for the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow, if routing has the ability to use that information to determine a route 🧭 Other forms of QoS routing have existed in the past, like using the IP TOS and Precedence bits to select a path through the network. Some have discussed using these same bits to select one of a set of parallel ATM VCs as a form of QoS routing 💅 ATM routing has also considered the problem of QoS routing through the Private Network-to-Network Interface (PNNI) [26] routing protocol, for routing ATM VCs on a path that can support their needs. The work in this area is just starting, and there are numerous issues to consider 📚 [23], as part of the work of the QoSR working group, frames the issues for QoS Routing in the Internet 🖼️

2.2 Reliance on Unicast and Multicast Routing 🗺️

RSVP was designed to support both unicast and IP multicast applications, which means RSVP needs to work closely with multicast and unicast routing 🫶 Unicast routing over ATM has been addressed in [10] and [11]. MARS [5] provides multicast address resolution for IP over ATM networks, which is an important part of the solution for multicast 🎉 But it still relies on multicast routing protocols to connect multicast senders and receivers on different subnets 😤

2.3 Aggregation of Flows 🦋

Okay bestie, some of the scaling drama from the earlier sections can be fixed by squishing several RSVP flows onto a single VC ✨, but only if every flow in the bundle has the same destinations. Real talk, it's a lot of work 😭. You have to juggle the VCs and schedule packets inside each VC at the root point, and the switches in the core of the ATM network can't reschedule flows within a VC 💀. Virtual Paths (VPs) can be used to bundle multiple VCs together. We'll get into that more for multicast data distribution in section 4.2.3.4 🫶.

2.4 Mapping QoS Parameters 🎀

Mapping QoS parameters from the IntServ models onto ATM service classes is a huge deal if you want RSVP and IntServ to work over ATM 👑. [14] covers this super thoroughly for the Controlled Load and Guaranteed Service models 💅. The extra twist is that you can make some guidelines for matching a service model's parameters to the traffic descriptors of an ATM traffic class, but implementation details, policy, and cost factors can make a strict one-to-one mapping messy 🙈. So what we actually need is a set of workable mappings that work across different network requirements and scenarios, as long as they can still meet the needs of the service model(s) 🌸.

2.5 Directly Connected ATM Hosts 🧚

It's obvious that hosts plugged straight into ATM networks need to be considered for RSVP and IntServ over ATM 💖. RSVP over ATM functionality must not assume that an ATM host has all the features of a router 🙅‍♀️, but things like MARS and NHRP clients would be a great bonus ✨. A host must manage its VCs just like any other ATM sender or receiver, as described later in section 4 💜.

2.6 Accounting and Policy Issues 💸

Since RSVP and IntServ create classes of preferential service, you need some form of administrative control and/or cost allocation to control who gets access 🔥. There are certain policies that are specific to ATM and IP over ATM, and they need to be studied to see how they interoperate with the IP and IntServ policies being developed 🤓. A typical IP policy would be that only certain users are allowed to make reservations. That one translates pretty well to IP over ATM, since it's pretty similar to the mechanisms used for Call Admission Control (CAC) 🫶.

There may be a need for policies specific to IP over ATM. For example, signalling costs in ATM are high compared to IP, so an IP over ATM specific policy might restrict the ability to change the prevailing QoS in a VC 😤. If VCs are relatively scarce, there might also be specific accounting costs for creating a new VC 💀. The work so far has been preliminary, and there's still a lot to do 🌈. The policy mechanisms outlined in [12] and [13] give the basic building blocks for implementing policies for RSVP and IntServ over any media, not just ATM 🍓.

3. Framework for IntServ and RSVP over ATM 🗺️

Now that we've covered some of the issues for IntServ and RSVP over ATM, we can build a framework for solutions 🌟. The problem splits into two very distinct areas: mapping IntServ models onto ATM service categories and QoS parameters, and running RSVP over ATM 💅.

Mapping IntServ models to ATM service categories and QoS parameters comes down to figuring out which categories can support the goals of the service models, then matching up the parameters and variables between the IntServ description and the ATM description(s) 🎀. ATM has such a huge variety of service categories and parameters, so more than one ATM service category should be able to support each of the two IntServ models 🦋. That gives you lots of flexibility when it comes to configuration and deployment ✨. [14] examines this topic completely 📚.

Running RSVP over ATM requires careful management of VCs so they match the dynamics of the RSVP protocol 🫧. VCs need to be managed for both the RSVP QoS data and the RSVP signalling messages 💜. The rest of this document discusses several approaches to managing VCs for RSVP, and [15] and [16] talk about how they apply to implementations in terms of interoperability requirements and implementation guidelines 🌸.

4. RSVP VC Management 👑

This section goes deeper into the issues around managing SVCs for RSVP and IntServ 🔍.

4.1 VC Initiation 🚀

Remember section 2.1.1.2? There's an apparent mismatch between RSVP and ATM 🙃. RSVP control is receiver oriented, but ATM control is sender oriented 🔄. This might seem like a major problem at first, but honestly it's not that deal-breaking 😌. RSVP reservation (RESV) requests are generated at the receiver, but the actual allocation of resources happens at the subnet sender 🧠. So for data flows, subnet senders establish all the QoS VCs, and the subnet receiver must be able to accept incoming QoS VCs, as shown in Figure 1 🖼️. These restrictions line up with RSVP version 1 processing rules, and they let senders use different flow-to-VC mappings and even different QoS renegotiation techniques without interoperability problems 🎉.

Using the reverse path provided by point-to-point VCs for receivers is for further study 🔮. There are two related issues. First, using the reverse path requires the VC initiator to set appropriate reverse path QoS parameters 📝. Second, reverse paths aren't available with point-to-multipoint VCs, so reverse paths could only be used to support unicast RSVP reservations 💔.

4.2 Data VC Management 💖

Any RSVP over ATM implementation must map RSVP and RSVP-associated data flows onto ATM Virtual Circuits (VCs) 🧩. LAN Emulation [17], Classical IP [10], and more recently NHRP [4] all talk about mapping IP traffic onto ATM SVCs 📡. The catch is they only cover a single QoS class, i.e., best effort traffic 😬. Once QoS comes into the picture, VC mapping has to be revisited 🔁. For RSVP controlled QoS flows, one big question is which VCs to use for QoS data flows 🤔.

In the Classical IP over ATM and current NHRP models, a single point-to-point VC is used for all traffic between two ATM attached hosts (routers and end-stations) 🛣️. Such a single VC probably won't be adequate or optimal when you're supporting data flows with multiple QoS types 😵. RSVP's basic purpose is to install support for flows with multiple QoS types, so any RSVP over ATM solution has to address VC usage for QoS data flows, as shown in Figure 1 🏆.

RSVP reservation styles must also be taken into account in any VC usage strategy 🎨.

This section describes issues and methods for managing VCs associated with QoS data flows 🗂️. When establishing and maintaining VCs, the subnet sender has to deal with several complicating factors: multiple QoS reservations, requests for QoS changes, ATM short-cuts, and several multicast specific issues 🌀. The multicast specific issues come from the nature of ATM connections 🦄. The key multicast related issues are heterogeneity, data distribution, receiver transitions, and end-point identification 🌈.

4.2.1 Reservation to VC Mapping 🧭

There are various approaches for mapping reservations onto VCs 🗺️. A distinguishing attribute of all of them is how reservations get combined onto individual VCs 🔗. When mapping reservations onto VCs, individual VCs can support a single reservation, or reservations can be combined with others onto "aggregate" VCs 🫂. In the first case, each reservation is supported by one or more VCs. Multicast reservation requests may turn into the setup of multiple VCs, as described in more detail in section 4.2.2 🌱. Unicast reservation requests will always turn into the setup of a single QoS VC 🎯. In both cases, each VC only carries data for a single reservation 🙌. The biggest benefit of this approach is ease of implementation 🍭, but the cost is longer VC setup time and more VCs and associated resources being used 🥲.

When multiple reservations are combined onto a single VC, it's called the "aggregation" model ✨. With this model, large VCs could be set up between IP routers and hosts in an ATM network 🏗️. These VCs could be managed much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed today 🛠️. Traffic from multiple sources across multiple RSVP sessions might be multiplexed onto the same VC 🔀. This approach has a bunch of advantages 🤩. First, there's typically no signalling latency, since the VCs already exist when the traffic starts flowing, so no time gets wasted setting them up ⏱️. Second, the heterogeneity problem (section 4.2.2) over ATM in full has been reduced to a solved problem 🏅. Finally, the dynamic QoS problem (section 4.2.7) for ATM has also been reduced to a solved problem 🎉.

The aggregation model can be used with point-to-point and point-to-multipoint VCs 💫. The tricky part is that picking what QoS to use for the VCs can be hard without knowing the likely reservation types and sizes 😅. It does get easier, though, because the VCs can be changed as needed 🫶.

4.2.2 Unicast Data VC Management 💌

Unicast data VC management is way simpler than multicast data VC management, but there are still some similar issues 🌷. If you think of unicast as a devolved case of multicast, then implementing the multicast solutions will cover unicast too 🧃. However, some folks may want to consider unicast-only implementations 🙋‍♀️. In those situations, the choice of using a single flow per VC or aggregating flows onto a single VC still exists, but the heterogeneity problem discussed in the following section goes away 🎈.

4.2.3 Multicast Heterogeneity 🌈

As mentioned in section 2.1.3.1 and shown in figure 2, multicast heterogeneity happens when receivers request different qualities of service within a single session 🧩. That means the amount of requested resources differs on a per next hop basis 📊. A related type of heterogeneity comes from best-effort receivers 🙈. In any IP multicast group, some receivers might request QoS (via RSVP) and some won't 🤷‍♀️. In shared media networks like Ethernet, receivers that haven't requested resources can typically get identical service to those that have, with no complications ✅. That's not the case with ATM 🚫. In ATM networks, any additional end-points of a VC must be explicitly added 📥. There may be costs for adding a best-effort receiver, and there might not be enough resources 😩. So an RSVP over ATM solution will need to support heterogeneous receivers, even though ATM doesn't currently provide that support directly 💪.

RSVP heterogeneity is supported over ATM through the way RSVP reservations are mapped into ATM VCs 🗺️. There are four alternative approaches to this mapping, so there are multiple models for supporting RSVP heterogeneity over ATM 🍰. Section 4.2.3.1 examines the multiple VCs per RSVP reservation (or full heterogeneity) model, where a single reservation can be forwarded onto several VCs, each with a different QoS 🌟. Section 4.2.3.2 presents a limited heterogeneity model where exactly one QoS VC is used along with a best effort VC 🥰. Section 4.2.3.3 examines the VC per RSVP reservation (or homogeneous) model, where each RSVP reservation maps to a single ATM VC 🎀. Section 4.2.3.4 describes the aggregation model, which lets multiple RSVP reservations be aggregated into a single VC 🦋.

4.2.3.1 Full Heterogeneity Model

okay so RSVP supports heterogeneous QoS, which means different receivers in the same multicast group can ask for a different QoS 🎀 but here's the iconic part: some receivers might not have a reservation at all and just want the traffic on a best effort basis 🙈 IP lets people join a multicast group whenever they want on a best effort basis, and ATM as part of the Internet needs to keep giving that vibe too 💅 So we define the "full heterogeneity" model as one where there's a separate VC for each distinct QoS in a multicast session, including best effort and one or more qualities of service ✨

ngl full heterogeneity gives users exactly what they ask for, but it eats more network resources than the other options 😭 How much extra bandwidth goes to duplicate traffic depends on the network topology and who's in the group 🌸

4.2.3.2 Limited Heterogeneity Model

we define "limited heterogeneity" as the case where receivers in a multicast session can only use best effort or one single alternate quality of service 🦋 That alternate QoS can be picked either by higher level protocols or by dynamic renegotiation of QoS, which we'll get to below 🧚

so to support limited heterogeneity, each ATM edge device in a session needs at most two VCs 💜 One is a point-to-multipoint best effort VC that serves every best effort IP destination for this RSVP session 🍓

The other is a point to multipoint VC with QoS, and it serves all IP destinations for this RSVP session that have an RSVP reservation set up ✨

same as with full heterogeneity, the downside of limited heterogeneity is that each packet has to be duplicated at the network layer, with one copy going into each of the 2 VCs 🙃 Again, how much excess traffic there is depends on the network topology and group membership 🫶 And if any of the existing QoS VC endpoints can't upgrade to the new QoS, then the new reservation fails, even though the resources exist for the new receiver 💀

4.2.3.3 Homogeneous and Modified Homogeneous Models

we define the "homogeneous" model as the case where all receivers in a multicast session use a single quality of service VC 👑 Best-effort receivers also use that one single RSVP triggered QoS VC 💖 The single VC can be point-to-point or point-to-multipoint, whichever makes sense ✨ The QoS VC is sized to provide the maximum resources requested by all RSVP next-hops 🔥

this model is basically how the current RSVP spec handles heterogeneous requests, so it's giving continuity 🌈 The current processing rules and traffic control interface describe a model where the largest requested reservation for a specific outgoing interface is used for resource allocation, and traffic goes out at the higher rate to all next-hops 💅 This approach would be the simplest method for RSVP over ATM implementations 🎀

it's simple to build, but ngl giving better than best-effort service might be the opposite of what the user actually wants 😬 There might be charges, or resources might get allocated wrongfully 💸 There are two specific problems. The first is that a user making a small reservation, or none at all, would share QoS VC resources without making (and maybe paying for) an RSVP reservation 🙈 The second is that a receiver might not get any data at all 😭 That can happen when there aren't enough resources to add a receiver, and the rejected user wouldn't be added to the single VC, so they wouldn't even get traffic on a best effort basis 💀

not sending data to best-effort receivers just because of another receiver's RSVP request is clearly unacceptable 🙅‍♀️ The limited heterogeneous model makes sure data always goes to both QoS and best-effort receivers, but it does that by replicating data at the sender in all cases 😵 It's possible to extend the homogeneous model so data always reaches best-effort receivers AND we avoid replication in the normal case ✨ The extension adds special handling for when a best-effort receiver can't be added to the QoS VC 🦋 In that case, a best effort VC can be set up to any receivers that couldn't join the QoS VC 🧚 Only in this special error case would senders have to replicate data 🫶 We define this approach as the "modified homogeneous" model 👑

4.2.3.4 Aggregation

the last scheme is the multiple RSVP reservations per VC (aka aggregation) model 🌸 With this model, big VCs could be set up between IP routers and hosts in an ATM network 💜 These VCs could be managed pretty much like IP Integrated Service (IIS) point-to-point links (e.g. T-1, DS-3) are managed right now 🍓 Traffic from multiple sources over multiple RSVP sessions might get multiplexed on the same VC 🌈

this approach has a bunch of perks ✨ First, there's typically no signalling latency, because the VCs already exist when traffic starts flowing, so no time gets wasted setting them up ⭐ Second, the heterogeneity problem in full over ATM has been reduced to a solved problem 💅 Finally, the dynamic QoS problem for ATM has also been reduced to a solved problem 🔥 This approach works with point-to-point and point-to-multipoint VCs 🎀 The catch is that picking which QoS to use for which VC is hard 😩 but it gets way easier if the VCs can be changed as needed 🫶

4.2.4 Multicast End-Point Identification

okay bestie, implementations MUST be able to identify ATM end-points participating in an IP multicast group 🦋 Those ATM end-points will be IP multicast receivers and/or next-hops 🧚 Both QoS and best-effort end-points MUST be identified 💅 RSVP next-hop information gives you QoS end-points, but NOT best-effort end-points 😬 Another issue is identifying end-points of multicast traffic handled by non-RSVP capable next-hops 🙈 In this case, a PATH message travels through a non-RSVP egress router on the way to the next hop RSVP node 🌸 When the next hop RSVP node sends a RESV message, it might arrive at the source over a different route than the one the data is using 😵 The source will get the RESV message but won't know which egress router needs the QoS 💀 For unicast sessions there's no problem, since the ATM end-point will be the IP next-hop router ✨ Unfortunately, multicast routing might not be able to uniquely identify the IP next-hop router 😭 So it's possible that a multicast end-point can't be identified 💔

in the most common case, MARS will be used to identify all end-points of a multicast group 🎀 In the router to router case, a multicast routing protocol might provide all next-hops for a particular multicast group 🌈 Either way, RSVP over ATM implementations MUST obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms 💖 That full list can be compared against the RSVP identified end-points to figure out the list of best-effort receivers 🔥 There's no straightforward solution for uniquely identifying end-points of multicast traffic handled by non-RSVP next hops 😩 The preferred solution is to use multicast routing protocols that support unique end-point identification 👑 Where those routing protocols aren't available, all IP routers that will be used to support RSVP over ATM SHOULD support RSVP 🫶 To ensure proper behavior, implementations SHOULD, by default, only establish RSVP-initiated VCs to RSVP capable end-points 🙌

4.2.5 Multicast Data Distribution

two models are planned for IP multicast data distribution over ATM 🧚 In one model, senders establish point-to-multipoint VCs to all ATM attached destinations, and data is then sent over those VCs 🌸 This is often called "multicast mesh" or "VC mesh" mode distribution 🍓 In the second model, senders send data over point-to-point VCs to a central point, and the central point relays the data onto point-to-multipoint VCs that have been set up to all receivers of the IP multicast group 🦋 This is often called "multicast server" mode distribution 💜 RSVP over ATM solutions MUST ensure that IP multicast data is distributed with appropriate QoS ✨

in the Classical IP context, multicast server support is provided via MARS [5] 🌈 MARS doesn't currently provide a way to communicate QoS requirements to a MARS multicast server 😬 So RSVP over ATM implementations MUST, by default, support "mesh-mode" distribution for RSVP controlled multicast flows 💅 When using multicast servers that don't support QoS requests, a sender MUST set the service, not global, break bit(s) 🔥

4.2.6 Receiver Transitions

okay so when you're setting up point-to-multipoint VCs for multicast RSVP sessions, there's going to be a moment where some receivers have been added to a QoS VC and some haven't 🫣 During those transition times, it's possible to start sending data on the newly established VC 🧚 The question is when to start sending data on the new VC 🤔 If data goes out on both the new VC and the old VC, then data gets delivered with proper QoS to some receivers and with the old QoS to all receivers 😳 That means QoS receivers can get duplicate data 🙈 If data only goes out on the new QoS VC, the receivers that haven't been added yet will lose information 💀 So it all comes down to whether you send to both the old and new VCs or just one of them ✨ In one case duplicate information gets received, and in the other some information might not get received at all 🫠

this issue needs to be considered for three cases 💖

  • When establishing the first QoS VC 🎀
  • When establishing a VC to support a QoS change 🦋
  • When adding a new end-point to an already established QoS VC 🌸

the first two cases are very similar 👯 In both, it's possible to send data on the partially completed new VC, and the duplicate-versus-lost-information tradeoff is the same 💅 The last case is when an end-point has to be added to an existing QoS VC 🧚 In this case the end-point must be both added to the QoS VC and dropped from a best-effort VC 🫶 The question is which one to do first 🤷‍♀️ If the add is requested first, then the end-point may get duplicate information 😵 If the drop is requested first, then the end-point may lose information 😭

to make behaviour predictable and get data to all receivers, data can only be sent on a new VC once all parties have been added 👑 That way, all data gets delivered only once to everyone 🔥 This approach doesn't quite apply to the last case 🙃 In the last case, the add operation should be completed first, and then the drop operation 💅 This means receivers MUST be prepared to receive some duplicate packets at times of QoS setup 🫶

4.2.7 Dynamic QoS ✨

okay so RSVP is giving dynamic QoS 💅 which means the resources someone asked for can change at any point. there are a few usual reasons a reservation's QoS might get switched up:

  1. an existing receiver asks for a new QoS that's bigger (or smaller) 🦋
  2. a sender changes its traffic specification (TSpec), and that can make the receivers change what they ask for 🌸
  3. a new sender joins a multicast group with a bigger traffic specification than the current senders, so the reservations get bigger 📈
  4. a new receiver makes a reservation that's bigger than the ones already there 🫶

okay now the messy part 😭. if the limited heterogeneity model is in use and the merge node for the bigger reservation is an ATM edge device, that bigger reservation has to be set up across the ATM network. the thing is, ATM service (as currently defined in UNI 3.x and UNI 4.0) doesn't let you renegotiate the QoS of a VC. so changing a reservation really means making a brand new VC with the new QoS and then tearing down the old one. tearing down and setting up VCs is a whole process, it takes a non-trivial amount of processing time, and it can have a substantial latency 💀. there are a few ways to deal with this mismatch, and any RSVP over ATM solution will need to pick a specific approach 🔥.

the default way to support RSVP reservation changes is to try replacing the existing VC with a new one that's appropriately sized 💖. while the replacement VC is being set up, the old VC has to be left in place and unmodified. that keeps QoS data delivery from getting interrupted. once the replacement VC is up, data moves over to it and the old VC gets closed 🎀. if setting up the replacement fails, the old QoS VC should keep being used. if the new reservation is bigger than the old one, the reservation request should get an error back. if the new reservation is smaller than the old one, the request should be treated as though the change worked ✨. leaving the bigger allocation in place isn't ideal, but it does the best job of getting service to the user 🧚. implementations should retry replacing the too-large VC after some reasonable amount of time has passed.

there's one more catch 👀: only one QoS change can be processed at a time per reservation. if the RSVP requested QoS changes again while the first replacement VC is still being set up, that replacement VC gets released and the whole replacement process starts over 😩. to cut down on changes and avoid piling up signalling load, implementations may limit how many changes they process in a given period. one way to do it is to have each ATM edge device configured with a time parameter T (which can change over time) for the minimum amount of time it waits between changes to the QoS of a particular VC 🌈. so if a VC's QoS changes at time t, any messages that would change that VC's QoS and arrive before time t+T get queued up. if several of those messages show up during the interval, the redundant ones can be thrown away. then at time t+T, whatever changes are left (if any) can be carried out 🍓. this timer idea would work for any network structure in general, and it might be worth building into RSVP itself 💜.

the sequence of events for a single VC would go like this:

  • Wait if timer is active
  • Establish VC with new QoS
  • Remap data traffic to new VC
  • Tear down old VC
  • Activate timer

there's also an interesting interaction between heterogeneous reservations and dynamic QoS 🤯. say a RESV message comes in from a new next-hop and the resources it's asking for are bigger than any existing reservation. now both dynamic QoS and heterogeneity have to be handled. the big question is whether to add the new next-hop first or switch to the new QoS first. it's actually a pretty straightforward special case 🙈. the older, smaller reservation doesn't support the new next-hop, so the dynamic QoS process should start first. and since only the new next-hop needs the new QoS, that next-hop should be the first end-point of the new VC. that way, if setup to the new next-hop fails, the signalling gets kept to a minimum 👑.

4.2.8 Short-Cuts 🦋

short-cuts [4] let ATM attached routers and hosts set up point-to-point VCs directly across LIS boundaries, meaning the VC end-points are on different IP subnets 🌸. people have started asking whether short-cuts and RSVP can work together. one area of concern is handling asymmetric short-cuts ⚠️. specifically, how can RSVP handle a case where a downstream short-cut doesn't have a matching upstream short-cut? in that situation, the PATH and RESV messages end up following different paths.

here's the good news 🥹. looking at RSVP, the protocol already has mechanisms that can support short-cuts. it's the same mechanism that handles RESV messages showing up at the wrong router and the wrong interface. the key idea is that RSVP only processes messages that arrive on the proper interface, and it forwards messages that arrive on the wrong interface 💅. the proper interface is indicated in the NHOP object of the message. so the existing RSVP mechanisms already support asymmetric short-cuts ✨. the short-cut model of VC establishment still brings up a few issues when running with RSVP though. the major ones are dealing with best-effort short-cuts that are already established, deciding when to establish short-cuts, and QoS-only short-cuts. implementations will need to sort these out 🔥.

the big question for any RSVP over ATM solution is when to set up a short-cut for a QoS data flow 🤔. the default behavior is to just follow best-effort traffic. if a short-cut has already been set up for best-effort traffic to a destination or next-hop, that same end-point should also be used when setting up RSVP triggered VCs for QoS traffic going to the same destination or next-hop 🎀. this happens naturally when PATH messages get forwarded over the best-effort short-cut. one thing to note: with this approach, if best-effort short-cuts never get established, then RSVP triggered QoS short-cuts won't ever get established either 😬. more study is expected in this area 🧚.

4.2.9 VC Teardown 🫧

RSVP can tell from explicit messages or from timeouts when a data VC isn't needed anymore 👀. so data VCs set up to support RSVP controlled flows should only be released when RSVP says so. VCs must not be timed out for inactivity by either the VC initiator or the VC receiver 🙅‍♀️. this clashes with VCs timing out the way RFC 1755 [11], section 3.4 on VC Teardown describes. RFC 1755 recommends tearing down a VC that's been inactive for a certain amount of time, and twenty minutes is recommended. this timeout is usually implemented at both the VC initiator and the VC receiver. but section 3.1 of the update to RFC 1755 [11] says inactivity timers must not be used at the VC receiver 😳.

when this timeout hits for an RSVP initiated VC, a valid VC with QoS gets torn down unexpectedly 💔. that's fine for best-effort traffic, but it's really important that RSVP controlled VCs don't get torn down. if there's no choice and the VC has to be torn down, the RSVP daemon must be notified so a reservation failure message can be sent 🚨.

for VCs initiated at the request of RSVP, the configurable inactivity timer mentioned in [11] must be set to "infinite" ♾️. setting the inactivity timer value at the VC initiator shouldn't be a problem, since the right value can be passed along internally at the originator 💜. setting the inactivity timer at the VC receiver is harder, though, and it would take some mechanism to signal that an incoming VC was RSVP initiated 😵. to avoid that complexity and to stay compliant with [11], implementations must not use an inactivity timer to clear received connections 🫶.

4.3 RSVP Control Management 🎀

one last important thing is giving the RSVP messages themselves a data path 🛣️. there are two main types of messages in RSVP, PATH and RESV. PATH messages can go to unicast or multicast addresses, while RESV messages only go to unicast addresses 💖. the other RSVP messages get handled similarly to either PATH or RESV, although RERR messages might be a bit more complicated 🙈. so ATM VCs used for RSVP signalling messages need to support both unicast and multicast functionality ✨. there are a few different approaches for assigning VCs to RSVP signalling messages.

the main approaches are:

  • use same VC as data
  • single VC per session
  • single point-to-multipoint VC multiplexed among sessions
  • multiple point-to-point VCs multiplexed among sessions

a few different issues affect which way you pick to assign VCs for RSVP signalling 🧠. one is how many extra VCs you'll need for RSVP signalling. tied to that is how much multiplexing happens on the RSVP VCs. in general, more multiplexing means fewer VCs 🌸. another issue is the latency of setting up new RSVP signalling VCs dynamically ⏱️. and the last one is how complicated it is to implement 🥴. the rest of this section goes through the issues and tradeoffs between these approaches and suggests guidelines for when to use each one 🍓.

4.3.1 Mixed data and control traffic 💅

in this scheme, RSVP signalling messages ride on the same VCs as the data traffic 🫧. the big perk is that you don't need any VCs beyond the ones the data traffic already needs 🙌. another win is that there's no ATM signalling latency for PATH messages, since they follow the same routing as the data messages 🏃‍♀️. but there can be a major problem when the data traffic on a VC is nonconforming 😭. with nonconforming traffic, RSVP signalling messages may get dropped. RSVP can handle a moderate number of dropped messages, but excessive drops would lead to repeatedly tearing down and re-establishing QoS VCs, which is a very undesirable behavior for ATM 💀. because of these problems, this might not be the best choice for carrying RSVP signalling messages, even though it keeps the number of VCs as low as possible 🥲.

one variation is to use the best-effort data path for signalling traffic 🌤️. in this scheme, there's no issue with nonconforming traffic, but there is an issue with congestion in the ATM network ☁️. RSVP gives some resiliency to message loss from congestion, but RSVP control messages should be offered a preferred class of service 👑. a related variation that's promising but still needs further study is to have a packet scheduling algorithm (before traffic enters the ATM network) that gives priority to RSVP signalling traffic 🌈. this can be difficult to do at the IP layer 🫠.

4.3.1.1 Single RSVP VC per RSVP Reservation ✨

okay so this one is giving simple 💖 Every RSVP reservation gets its own parallel RSVP signalling VC. Yes, that means twice the number of VCs 😭 but the payoff is that RSVP signalling messages get a separate VC of their own.

That separate VC is the big win 🫶 It means the RSVP signalling messages have their own traffic contract, and compliant signalling messages aren't at risk of being dropped because of other noncompliant traffic (which can happen with the scheme in section 4.3.1). 🙈

The advantage here is pure simplicity. Whenever a data VC gets created, a separate RSVP signalling VC gets created right alongside it. The downside is that extra ATM signalling has to happen. It also needs twice the minimum number of VCs and adds some extra latency, but honestly it's quite simple, and that's the whole vibe 🍓

4.3.1.2 Multiplexed point-to-multipoint RSVP VCs

this scheme is a little more chaotic but iykyk 🌸 There's a single point-to-multipoint RSVP signalling VC for each unique ingress router and unique set of egress routers. Any RSVP signalling traffic that shares the same ingress router and the same egress routers gets multiplexed onto that one VC. That can save a bunch of VCs 💅

The catch is that things get messy when the destinations keep changing. When the egress routers change, the ingress router first checks whether it already has a point-to-multipoint RSVP signalling VC for the new list of egress routers. If one exists, the RSVP signalling traffic can switch over to it. If no such VC exists, one approach is to create a new VC with the new list of egress routers. Other approaches include modifying the existing VC to add an egress router, or using a separate new VC for the new egress routers. 🦋

When a destination drops out of a group, one option is to keep sending to the existing VC, even though some traffic gets wasted 💀

The number of VCs in this scheme depends on traffic patterns across the ATM network, but it is always less than the number used with the Single RSVP VC per data VC. Existing best effort data VCs could also be reused for RSVP signalling. Reusing them saves on the number of VCs, but comes at the cost of a higher probability of RSVP signalling packet loss. 😬

One place this scheme could work really well is the core of the network, where there's the most opportunity to take advantage of multiplexing savings. The exact savings depend on the traffic patterns and the topology of the ATM network. ✨

4.3.1.3 Multiplexed point-to-point RSVP VCs

this one is the flexible queen 👑 Multiple point-to-point RSVP signalling VCs get used for a single point-to-multipoint data VC. It allows multiplexing of RSVP signalling traffic, but it requires the same traffic to be sent on each of several VCs. Still, it's quite flexible and allows a large amount of multiplexing. 🧚

Since point-to-point VCs can set up a reverse channel at the same time as the forward channel, this scheme could save a lot on signalling cost 🔥 Signalling traffic could also share existing best effort VCs. That reduces the total number of VCs needed, but it might cause signalling traffic drops if there's congestion in the ATM network. 🙃

This point-to-point scheme would work well in the core of the network, where there's lots of opportunity for multiplexing. In the core, RSVP VCs can also stay permanently established, either as Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual Circuits (SVCs). 🦋

The number of VCs in this scheme depends on traffic patterns, but in the core of a network it would be approximately n(n-1)/2, where n is the number of IP nodes in the network. In the core, this will typically be small compared to the total number of VCs. 🌈

4.3.2 QoS for RSVP VCs

okay now the QoS question 🎀 There's an issue of what QoS, if any, should be assigned to the RSVP signalling VCs. For the other RSVP VC schemes, a QoS (possibly best effort) will be needed. What QoS to use partly depends on the expected level of multiplexing on the VCs, and on the expected reliability of best effort VCs.

Here's the key bit: RSVP signalling is infrequent (typically every 30 seconds), so only a relatively small QoS should be needed. This matters a lot, because using a larger QoS risks the VC setup being rejected for lack of resources. 😭

Falling back to best effort when a QoS call gets rejected is possible. But if the ATM net is congested, there will likely be RSVP packet loss on the best effort VC too. Additional experimentation is needed in this area. 🔬

5. Encapsulation

ok encapsulation time 🧁 RSVP is a signalling protocol used to control flows of IP data packets, so encapsulation for both RSVP packets and the associated IP data packets must be defined. The methods for transmitting IP packets over ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based on the encapsulations defined in RFC1483 [19]. RFC1483 specifies two encapsulations, LLC Encapsulation and VC-based multiplexing. The former allows multiple protocols to be encapsulated over the same VC, and the latter requires different VCs for different protocols. 💅

For the purposes of RSVP over ATM, any encapsulation can be used, as long as the VCs are managed in accordance with the methods outlined in Section 4. Obviously, running multiple protocol data streams over the same VC with LLC encapsulation can cause the same problems as running multiple flows over the same VC. 🙈

None of the transmission methods directly address the issue of QoS. However, RFC1755 [11] does suggest some common values for VC setup for best-effort traffic. [14] discusses the relationship between the RFC1755 setup parameters and those needed to support IntServ flows in greater detail. 🫶

6. Security Considerations

this is serious, bestie 🚨 The same considerations stated in [1] and [11] apply to this document. There are no additional security issues raised in this document. 🔒

7. References

  • [1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2209, September 1997.
  • [2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Realtime Services in an IP-ATM Network Architecture", RFC 1821, August 1995.
  • [3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", RFC 1932, April 1996.
  • [4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  • [5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
  • [6] Shenker, S., and C. Partridge, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
  • [7] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
  • [8] ATM Forum. ATM User-Network Interface Specification Version 3.0. Prentice Hall, September 1993.
  • [9] ATM Forum. ATM User Network Interface (UNI) Specification Version 3.1. Prentice Hall, June 1995.
  • [10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
  • [11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
  • [12] Herzog, S., "RSVP Extensions for Policy Control", Work in Progress.
  • [13] Herzog, S., "Local Policy Modules (LPM): Policy Control for RSVP", Work in Progress.
  • [14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load and Guaranteed Service with ATM", RFC 2381, August 1998.
  • [15] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
  • [16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379, August 1998.
  • [17] ATM Forum Technical Committee. LAN Emulation over ATM, Version 1.0 Specification, af-lane-0021.000, January 1995.
  • [18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-0824r9, September 1996.
  • [19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
  • [20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2 - LUNI Specification, December 1996.
  • [21] ATM Forum Technical Committee. Traffic Management Specification v4.0, af-tm-0056.000, April 1996.
  • [22] Callon, R., et al., "A Framework for Multiprotocol Label Switching, Work in Progress.
  • [23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
  • [24] ITU-T. Digital Subscriber Signaling System No. 2-Connection modification: Peak cell rate modification by the connection owner, ITU-T Recommendation Q.2963.1, July 1996.
  • [25] ITU-T. Digital Subscriber Signaling System No. 2-Connection characteristics negotiation during call/connection establishment phase, ITU-T Recommendation Q.2962, July 1996.
  • [26] ATM Forum Technical Committee. Private Network-Network Interface Specification v1.0 (PNNI), March 1996.

8. Authors' Addresses

Eric S. Crawley
Argon Networks
25 Porter Road
Littleton, Ma 01460

Phone: +1 978 486-0665
EMail: esc@argon.com


Lou Berger
FORE Systems
6905 Rockledge Drive
Suite 800
Bethesda, MD 20817

Phone: +1 301 571-2534
EMail: lberger@fore.com


Steven Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: +1 310 822-1511
EMail: berson@isi.edu


Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111

Phone: +1 805 681-0115
EMail: fred@cisco.com

Marty Borden
Bay Networks
125 Nagog Park
Acton, MA 01720

Phone: +1 978 266-1011
EMail: mborden@baynetworks.com


John J. Krawczyk
ArrowPoint Communications
235 Littleton Road
Westford, Massachusetts 01886

Phone: +1 978 692-5875
EMail: jj@arrowpoint.com

Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀

okay so bestie, the legal bit! 🫶 You're totally allowed to copy this document and hand it out to people. You can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions. The one thing that has to come along for the ride is the copyright notice and this paragraph, on every copy and every derivative work. ✨

BUT (and this is the tea 🍵) you can't modify this document itself. No deleting the copyright notice, no removing the references to the Internet Society or other Internet organizations. The exceptions are when you're developing Internet standards, in which case you follow the copyright procedures in the Internet Standards process, or when you're translating it into a language other than English. 🌸

The permissions here are perpetual, which means they're forever. The Internet Society and its successors or assigns can't take them back. 🦋

Now the disclaimer, and it's giving serious energy 😭. This document and everything in it is provided "AS IS". THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. So no guarantees, bestie. 💀🫶

📦 where this page comes from