RFC 1821
Integration of Real-time Services in an IP-ATM Network Architecture
Integration of Real-time Services in an IP-ATM Network Architecture 🦋
okay bestie, so this is RFC 1821 💖 from the Network Working Group, and the authors are M. Borden and E. Crawley (both at Bay Networks), B. Davie (at Bellcore), and S. Batsell (at NRL) 👑. It's dated August 1995 🌸 and it's filed as Informational, which means it's giving "here's some useful info for the Internet community," not a standard 💅. It doesn't list anything it obsoletes or updates, so it just stands on its own ✨.
Status of the Memo ✨
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🎀.
Abstract 💜
okay so the IETF is currently building an integrated service model that's designed to support real-time services on the Internet 🔥. At the same time, the ATM Forum is developing Asynchronous Transfer Mode networking, which also gives real-time networking support 🦋. ATM is already being used in the Internet as a link layer protocol, and both the IETF and the ATM Forum are writing specs for IP over ATM 🫶. The whole point of this paper is to clearly lay out what issues need solving when you connect the IP integrated services world with an ATM service world, so the two work as one seamless interface for end users who want real-time networking 💖.
Table of Contents 🧚
1.0 Introduction 2
2.0 Problem Space Overview 3
2.1 Initial Assumptions 3
2.2 Topologies Under Consideration 4
2.3 Providing QoS in IP over ATM - a walk-though 5
3.0 Service Model Issues 6
3.1 Traffic Characterization 7
3.2 QoS Characterization 8
4.0 Resource Reservation Styles 10
4.1 RSVP 10
4.2 ST-II 13
4.3 Mapping IP flows to ATM Connections 15
5.0 End System Issues 16
6.0 Routing Issues 16
6.1 Multicast routing 17
6.2 QoS Routing 17
6.3 Mobile Routing 18
7.0 Security Issues 19
8.0 Future Directions 20
9.0 References 22
10.0 Authors' Addresses 241.0 Introduction ✨
okay so the traditional network service on the Internet is best-effort datagram transmission 🍓. Packets from a source get sent to a destination, with no guarantee they'll arrive. For apps that do need a delivery guarantee, TCP trades packet delay for correct reception by retransmitting any packets that fail to reach the destination 🔁. For classic computer-communication apps like FTP and Telnet, where correct delivery matters more than timeliness, this is totally satisfactory 💅.
BUT a new class of app that mixes multiple media (voice, video, and computer data) has started showing up on the Internet 🎥. Examples are video teleconferencing, video-on-demand, and distributed simulation 🌈. These apps can kind of work with best-effort delivery, but trading packet delay for correct reception is not an acceptable trade-off for them 😭. Running them in the traditional mode leads to reduced quality of the received information and, potentially, inefficient use of bandwidth 💀. To fix this, the IETF is developing a real-time service environment where multiple classes of service are offered [6] ✨. This environment is going to greatly extend the existing best-effort service model so it can meet the needs of multimedia apps with real-time constraints 👑.
At the same time the IETF is doing that, Asynchronous Transfer Mode (ATM) is being developed 🦋. It started out as a replacement for the current telephone network protocols, and more recently it's been used as a link-layer protocol for computer communications 📞. Because it was built from the start with telephone voice apps in mind, a real-time service environment is an integral part of the protocol 🫶. With the ATM Forum approving UNI 3.1, the ATM standards now have several categories of service 🎀. Since long-line carriers have widely accepted ATM, using ATM in the Internet is highly likely, if not guaranteed 🔥. The big question now is: how do we successfully interface between the real-time services ATM offers and the new, integrated service environment that's about to show up in the IP protocol suite 🤔? Right now, the current IP over ATM standards assume there are no real-time IP protocols 🙈. So the purpose of this RFC is to clearly spell out the issues involved in integrating real-time services in an IP-over-ATM network [10,15,19,20,21] 💜.
In the IP-over-ATM environment, like in many others, multicast routing adds its own set of challenges 🌸. The main focus of this paper is quality of service (QoS) issues, but it's unwise at best to ignore multicast while thinking about those, especially since so many of the apps that push for real-time QoS also need efficient multicast support 🚀. So we'll keep multicast in the foreground through the rest of the discussion 👀.
One of the big reasons for this document is that the authors believe ATM should, if possible, be used as more than a leased line replacement 💅. Yes, the Internet could be overlaid on constant bit rate (CBR) permanent virtual circuits (PVCs), which would make IP over ATM a previously solved problem 🥱. But we think that's unlikely to be the most efficient way to use ATM services, whether they're offered by carriers or show up in LANs 🙅♀️. Here's the tea: a carrier offering a CBR service has to assume the peak bit rate can be used continuously with no degradation in quality, so resources have to be allocated to the connection even if that peak rate is rarely actually used 😩. This is likely to make a CBR service more expensive than a variable bit rate service with the same peak capacity 💸. Another way to look at it is that the new IP service model will let us associate information about the bandwidth requirements of applications with individual flows 📊. Surely it's not wise to throw that information away when we request a service from an ATM subnet 🙃.
While we believe there's a range of ATM capabilities that a real-time Internet can use effectively, we do not think that just because ATM has a capability, the Internet must use it 🫠. So our goal in this RFC is to start exploring how an Internet with real-time service capability might make the most effective use of ATM networks 🌟. There are a bunch of problems that have to be resolved to get there, so our major goal at this point is just to describe the scope of the problems that need addressing 🧩.
2.0 Problem Space Overview 🍑
In this section we're aiming to describe, in high-level terms, the scope of the problem that gets explored in more detail in later sections 👀.
2.1 Initial Assumptions 🎀
We start by assuming that an Integrated Services Internet will eventually happen 🔮. That's an Internet with a range of qualities of service to support both real-time and non-real-time apps 🌈. A bunch of working groups are trying to make it happen, notably:
- the Integrated Services group (
int-serv), which is working to define a new IP service model, including a set of services suited to a range of real-time applications 💖; - the Resource reservation Setup Protocol group (
rsvp), which is defining a resource reservation protocol [7] that lets an application request the appropriate service from the network 🦋; - the Internet Streams Protocol V2 group (
ST-II), which is updating [27], a stream-oriented internet protocol that provides a range of service qualities 🌊.
On top of that, the IETF IP over ATM working group and the ATM Forum Multiprotocol over ATM group are working to define a model for protocols that make use of the ATM layer 🧚.
Since these groups haven't generated standards yet, we'll have to do some extrapolation to predict the problems that might come up for IP over ATM 🔍. We're also assuming that the standards the ATM Forum is developing will mostly determine the service model for ATM, so yep, some more extrapolation may be needed 🙈. Given all of that, this paper aims to explore ways a future Integrated Services Internet might make effective use of ATM, as it seems likely to be deployed 💜.
2.2 Topologies Under Consideration 🗺️
Okay bestie, so Figure 1 shows a generic internetwork with both ATM and non-ATM subnetworks in it 🌸 This paper lays out the problems that have to get solved so you can provide suitable quality of service end-to-end across a network like that ✨ So the problem space includes:
- communication across an 'ATM-only' network between two hosts directly connected to the ATM network;
- communication between ATM-connected hosts that involves traversing some non-ATM subnets;
- communication between a host on a non-ATM subnet and a host directly connected to ATM;
- communication between two hosts, neither of which has a direct ATM connection, but which may make use of one or more ATM networks for some part of the path.
Figure 1 is shown below.Wait, that's wrong, so here is the actual figure, copied exactly:
[H]
| [H]
________|________________________ |
| | |
________|__ ______|___|____
| | | |
| ATM [R] [R] ATM |
| Cloud | | Cloud |___[H]
| | Non-ATM Internet | |
| | [R] |
|________[R] |_____________|
| | |
| | |
[H] |________________________________|
|
|
[H]
[H] = Host
[R] = Router
Figure 1In the last case, the entities connected to the ATM network are IP routers, and it's their job to manage the QoS that the ATM network(s) provide, so the desired end-to-end QoS actually reaches the hosts 💅 We want to describe the problem space in a way that covers all of these scenarios, but the last one is probably the most general, so that's the one we'll use for most of our examples 🎀 Also, we are explicitly not interested in ways of providing QoS that only apply to a subset of these situations. We claim that handling these four situations is general enough to cover other situations too, like the ones where several ATM and non-ATM networks get traversed 🦋
It's worth mentioning that the ATM networks in this case might be local or wide area, and private or public 🌈 Sometimes that distinction is significant, e.g., because there may be economic implications to a particular approach to providing QoS 💜
2.3 Providing QoS in IP over ATM - a walk-through ✨
To set the vibe for what comes next, this section walks through an example of what might happen when an application with a certain set of QoS needs starts up 🧚 For this example we'll use the fourth case from above, i.e., two hosts connected to non-ATM networks, making use of an ATM backbone 🍓
Here's the tea: a generic discussion of this situation is made difficult by the fact that reserving resources in the Internet may be sender or receiver initiated, depending on the specifics of the setup protocol 🙈 We'll try to gloss over that distinction for now, although we'll return to it in Section 4. We'll assume a unicast application, and that the traffic characteristics and the QoS requirements (such as delay, loss, throughput) of the application are known to at least one host. That host launches a request for the desired QoS, along with a description of the expected traffic, into the network. At some point this request hits a router at the edge of the ATM network 👑 The router has to examine the request and decide whether it can use an existing connection over the ATM network to honor the request, or whether it must establish a new connection. In the latter case, it must use the QoS and traffic characterizations to decide what sort of ATM connection to open and to describe the desired service to the ATM network. It must also decide where to open the connection to. Once the connection is opened, the request is forwarded across the ATM network to the exit router and then proceeds across the non-ATM part of the network by the normal means 🫶
We can see from the above description that there are several sets of issues to discuss:
- How does the IP service model, with certain service classes and associated styles of traffic and QoS characterization, map onto the ATM service model?
- How does the IP reservation model (whatever it turns out to be) map onto ATM signalling?
- How does IP over ATM routing work when service quality is added to the picture?
These issues will be discussed in the following sections 💖
3.0 Service Model Issues 🌸
There are several significant differences between the ways IP and ATM will provide QoS 😭 When IP commits to providing a certain QoS to an application according to the Internet service model, it must be able to request an appropriate QoS from the ATM network using the ATM service model. Since these service models are by no means the same, a potentially complex mapping must be performed for the IP layer to meet its commitments. The details of the differences between ATM and IP, and the problems those differences present, are described below.
We may think of a real-time service model as containing the following components:
- a way to characterize traffic (sometimes called the Tspec);
- a way to characterize the desired quality of service (the Rspec).
We label these components as traffic characterization and QoS characterization. Each of these components is discussed in turn in the following sections 🦋
As well as these aspects of the service model, both ATM and IP will have a number of mechanisms by which the model is implemented 🔥 The mechanisms include admission control, policing, and packet scheduling. A particularly important mechanism is the one by which end-nodes communicate their QoS needs and traffic characteristics to the network, and by which the network communicates admission control decisions back to the end-nodes. This is referred to as resource reservation or signalling, and it's the subject of Section 4. In fact, it seems to be the only mechanism where significant issues of IP/ATM integration arise 👀 The details of admission control, policing and packet scheduling are largely internal to a single network element, and we do not foresee significant problems caused by the integration of IP and ATM. For example, while there may be plenty of challenges in designing effective approaches to admission control for both IP and ATM, it is not apparent that there are any special challenges for the IP over ATM environment 🧠 As the walk-through of Section 2.3 described, a reservation request from a host would at some point encounter the edge of the ATM cloud. At this point, either a new connection needs to be set up across the ATM cloud, or the router can decide to carry the requested traffic over an existing virtual circuit. If the ATM cloud cannot create a new connection as requested, this would presumably result in an admission control failure, which would cause the router to deny the reservation request 💀
3.1 Traffic Characterization 🎀
The traffic characterization provided by an application or user is used by the network to decide how to provide the desired quality of service to this application, and to assess the effect the new flow will have on the service provided to existing flows. Clearly this information feeds into the admission control decision process 💅
In the Internet community, it is assumed that traffic will in general be bursty, and that bursty traffic can be characterized by a 'token bucket'. While ATM does not expect all traffic to be bursty (the Continuous Bit Rate class is being defined specifically for non-bursty traffic), it uses an essentially equivalent formulation for characterizing traffic that is bursty, referred to as the Generic Cell Rate Algorithm (GCRA) ✨ However, ATM in some classes also requires specification of peak cell rate, whereas peak rates are not currently included in the IP traffic characterizations. It may be possible to use incoming interface speeds to determine an approximate peak rate 🌈
One of the functions that must be performed in order to carry IP traffic over an ATM network is therefore a mapping from the characterization of the traffic as supplied to IP to a characterization that is acceptable for ATM. While the similarity of the two characterizations suggests this is straightforward, there is considerable flexibility in the mapping of parameters from IP to ATM 🫧 As an extreme example, a router at the edge of an ATM cloud that expects to receive bursts of IP packets on a non-ATM interface, with the bursts described by some token bucket parameters, could actually inject ATM cells at a constant rate into the ATM network. This may be achieved without significant buffering if the ATM link speed is faster than the point-to-point link speed. Alternatively, it could be achieved by buffering out the burstiness of the arriving traffic 🍬 It seems more reasonable to map an IP flow (or a group of flows) with variable bandwidth requirements onto an ATM connection that accommodates variable bit rate traffic. Determining how best to map IP traffic to ATM connections in this way is an area that warrants investigation 🔍
Now the plot twist 😱 A potential complication is the fact that the token bucket parameters are specified at the edge of the IP network, but the specification of the GCRA parameters at the entry to an ATM network will frequently happen at a router in the middle of an IP network. Thus the actual burstiness encountered at the router may differ from that described by the IP token bucket parameters, as the burstiness changes while the traffic traverses a network. The seriousness of this problem needs to be understood to permit efficient resource utilization 💜
3.2 QoS Characterization ✨
Okay so, besides telling the network what traffic they're gonna send 📦, applications also have to spell out the QoS they need from the network 💅. The whole goal is carrying IP efficiently over ATM 🦋, so we need ways to translate IP QoS specs into QoS specs that actually mean something to an ATM network 🧚.
The proposed way to specify QoS on the Internet is to pick a service class and then set some parameters that depend on which class you picked 🎀. The service classes currently on the table are:
- guaranteed, which gives you a mathematically guaranteed delay bound [23];
- predictive delay, which gives a probabilistic delay bound [24]; and
- controlled delay, which just tries to offer several levels of delay that apps can choose between [25].
These are on top of the existing best-effort class 🌸. More IP service classes are expected in the future 👀. ATM has five service classes, btw:
- CBR (constant bit rate), which emulates a leased line 🧈. It's got very tightly constrained delay and it's made for apps that can live with a fixed-bandwidth pipe;
- VBR (variable bit rate)-real-time, which tries to constrain delay for apps whose bandwidth needs bounce around 🎢;
- VBR-non-real-time, for variable-bandwidth apps that don't need tight delay limits;
- UBR (unspecified bit rate), which is the closest match to traditional IP best-effort service 💜; and
- ABR (available bit rate), which uses a complex feedback mechanism to control loss 🔁.
Each class needs some associated parameters set. For example, CBR needs a peak rate 📈. Honestly, these classes don't line up with the IP classes at all 🙃. Sometimes ATM classes need parameters that IP doesn't provide, like loss rate. In those cases it may be necessary to assume reasonable default values 🫶.
The big question is this: given IP traffic in a particular IP service class with certain QoS parameters, how should it get sent across an ATM network so that it both meets its service commitments and uses the ATM network's resources efficiently? 🤔 For example, you could push any class of IP traffic through the CBR ATM class, treating the ATM network like a point-to-point link. That would let IP meet its service commitments, but it'd be a super inefficient use of network resources anytime the IP traffic is at all bursty (which is probably most of the time) 😩. A more reasonable approach might be mapping all IP traffic into the VBR class, since that class has way more flexibility for handling bursty traffic than CBR does 💖.
At present, the IETF isn't working on any service classes where loss rate is part of the QoS specification 🙅♀️. So as long as that's the case, the fact that ATM lets you specify target loss rates is basically not an issue. But we can totally expect service classes that include loss specs to get defined as the IP service model gets refined 🔮. When that happens, we'll need to map between loss rates at the IP level and loss rates at the ATM level. It has already been shown that relatively small loss rates in an ATM network can turn into high loss rates in IP, because each lost cell can cause the loss of an entire IP packet 💀. Schemes to mitigate this, which include the proposed approach to implementing the ABR class as well as other solutions [22], have been proposed. This is clearly going to be an important issue in the future 🔥.
4.0 Resource Reservation Styles 🌈
ATM uses a signalling protocol (Q.2931) to do two jobs: set up virtual connections and allocate resources to those connections 📡. It's got a lot of the vibes of a "conventional" signalling protocol, like being sender-driven and relying on hard-state in switches to maintain connections 🧠. Some of its key characteristics are listed in the table below 📋. In the current standards, the QoS associated with a connection at setup time can't be changed afterward (it's static) 🔒. In a unicast connection, resources are allocated in both directions along the path. In the multicast case, they're only allocated from the sender to the receivers 🎯. In this case, all senders receive the same QoS ✨.
Two protocols have been proposed for resource reservation in IP 💖. The first one (chronologically) is ST-II, and the other is RSVP 🦋. Each of these, and its relationship to ATM, gets its own look in the following sections 💅.
4.1 RSVP ✨
okay so IP has always been connectionless 🌊, meaning no setup, just send and hope for the best. That's kinda the problem when you want real-time stuff like voice or video 📞. So RSVP was proposed to let the network reserve resources for a connectionless data stream 💅. ATM is the opposite vibe. It's connection-oriented, so resource reservations get made at connection setup time, using a user-network interface (UNI) and a network-network interface (NNI) signalling protocol 🎀.
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Receiver-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Soft state | Hard state |
| | (refresh/time-out) | (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Separate from | Concurrent with |
| | route establishment | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation|
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation|
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------The way RSVP is designed is totally different from ATM 💜, and it shows in a few ways:
- Reservations in IP hosts and routers are soft state 🫧. They're not permanent. They time out after some period, so reservations must be refreshed to stop that from happening, and they can also be explicitly deleted. ATM is more committed. Resources are reserved for the whole duration of a connection, and that connection must be explicitly and reliably deleted.
- Soft state means RSVP can change the QoS reserved for a flow at any time 🔄. ATM connections have a static QoS that gets fixed at setup time, so no switching mid-call.
- RSVP is simplex 👈. Resources get reserved in one direction only. In ATM, connections (and their reservations) are bi-directional in point-to-point calls and uni-directional in point-to-multipoint calls.
- In RSVP, the receiver is the one who starts the reservation 🙋♀️. In ATM, the end system sets up the connection and reserves resources. In point-to-multipoint calls, though, connection setup (and so the reservation too) has to be done by the sender.
- RSVP explicitly supports sessions with multiple senders 🎭. You can select a subset of senders and dynamically switch between them. ATM has no support for that at all.
- RSVP was designed independently of other architectural pieces, routing especially 🧭. Route setup and resource reservation happen at different times. In ATM, reservation and route setup both happen at the same time, which is connection setup time.
These differences in state establishment between RSVP and ATM, as described above, raise numerous problems. Honestly, it's a lot 😭.
For example, point-to-point ATM connections are bidirectional, and reservations can be made in both directions. That means receiver-initiated reservations in RSVP can be simulated in ATM by having the receiver set up the connection and reserve resources in the backward direction only. BUT this is potentially wasteful of connection resources 💸, since the connection is only ever used to transfer data one way, even though the two parties may be talking both ways. One option is a point-to-multipoint ATM connection with only one receiver. Of course, since the RSVP reservation request comes from the receiver(s), this request must be somehow communicated to the sender on the ATM network 📬. It's kinda like the receiver-oriented join operation of IP multicast, and the problems of implementing that over ATM, which are discussed in Section 6 🧠. In general, the efficiency of any proposed connection management scheme needs to be investigated in both unicast and multicast contexts, for a range of application requirements, especially at large scale 📈.
RSVP's use of soft state, instead of explicit connections, means the routers at the edges of the ATM network need to manage opening and closing ATM connections as RSVP reservations are made and released (or time out) 🚪. The best scheme for connection setup and tear-down depends on the cost of setting up a connection versus the cost of keeping it open for possible future use by another stream 💭. That's likely to be service class-dependent. For example, connections may be left open for reuse by best-effort traffic (as long as enough connections are available), since no resources are explicitly reserved 🙌. Real-time service classes are a different story, because leaving them open is expensive. Resources may be allocated even while the connection is idle 💀. The cost depends on the class. An open, idle guaranteed QoS connection is likely to be significantly more expensive than a connection providing predictive or controlled delay service 💅. Connections can be reused for traffic of the same class with compatible QoS requirements. Sometimes it's also possible to use a higher quality class to substitute for a lower quality one ⭐.
Another RSVP characteristic that causes problems for ATM is the use of PATH messages to convey information to receivers before any reservation is made 📨. This works in IP because routing is performed independently of reservation. So delivering PATH messages across an ATM network is likely to require a mechanism for setting up connections without reservations being made. The connection also needs enough quality to deliver PATH messages fairly reliably. In some circumstances, a low quality best effort service may not be enough for this job 🙅♀️. A related issue is advertising services before reservations. The OPWA model (one pass with advertising) requires network elements to advertise the QoS they're able to provide, so receivers can decide what level of reservation to request 📢. These advertisements may be made before any resources have been reserved in the ATM network. So it's not clear how to make meaningful advertisements of the QoS that might be provided across the ATM cloud ☁️🤔.
Finally, the multiparty model of communication is substantially different in RSVP and ATM 👯. Emulating RSVP receiver-initiation using ATM point-to-multipoint connections is likely to cause severe scaling problems as the number of receivers gets large 📉. Also, some RSVP functions aren't currently provided by ATM. For example, there's no support for different receiver requirements and capabilities. All receivers in a session receive the same QoS, which is fixed at the time the first receiver is added to the multicast tree 🌳. ATM support for multi-party sessions will likely be enhanced in later versions of the standards 🔮. Such support has to evolve in a manner compatible with RSVP and IP multicast routing protocols if large ATM clouds are going to be deployed successfully 🫶🦋
4.2 ST-II 💌
Okay bestie, ST-II [27] and ST2+ [12] (we'll just call them "ST" from here on 💅) have data distribution and resource reservation schemes that are giving ATM vibes in a lot of ways ✨
- ST is connection oriented using "hard state" 🔒. Senders set up simplex data flows to all receivers, which closely matches point-to-multipoint connections in ATM 🦋. Routing decisions are made when the connection is made and aren't changed unless there's a failure in the path. Positive acknowledgment is required from all receivers. ST2+ [12] adds a receiver-based JOIN mechanism that can reduce the burden on senders to track all receivers 🫶.
- ST reserves network resources at connection setup time 🎀. The ST CONNECT message contains a flowspec indicating the resources to be reserved for the stream. Agents along the path may change the flowspec based on restrictions they may need to impose on the stream. The final flowspec is returned to the sender in the ACCEPT message from each receiver or target 💜.
Here's the comparison table, bestie. RSVP and ATM are side by side, so you can see the similarities 👀:
-----------------------------------------------------------------
| Category | RSVP | ATM (UNI 3.0) |
-----------------------------------------------------------------
| | | |
| Orientation | Sender-based | Sender-based |
| | | |
----------------------------------------------------------------
| | | |
| State | Hard state | Hard state |
| | (explicit disconnect)| (explicit delete) |
-----------------------------------------------------------------
| | | |
|QoS SetupTime | Concurrent with | Concurrent with |
| | stream setup | route establishment |
-----------------------------------------------------------------
| | | |
|QoS Changes? | Dynamic QoS | Static QoS |
| | | (Fixed at setup time) |
-----------------------------------------------------------------
| | | Bidirectional allocation|
|Directionality| Unidirectional | for unicast |
| |resource allocation |Unidirectional allocation|
| | | for multicast |
-----------------------------------------------------------------
| | | |
|Heterogeneity | Receiver | Uniform QoS to |
| | heterogeneity | all receivers |
-----------------------------------------------------------------These similarities make mapping ST services to ATM simpler than RSVP, but the mapping is still not trivial 🙃. The task of mapping the ST flowspec into an ATM service class still has to be worked out. There may be policy issues related to opening a new VC for each stream versus aggregating flows over an existing VC.
Additionally, ST has some differences with UNI 3.1 that can cause problems when integrating the two protocols 🚧:
- In ST, changes to active stream reservations are allowed. For example, if the flowspec received from the target is not sufficient for the stream, the sender can send a CHANGE message, requesting a different QoS. UNI 3.1 does not allow changes to the QoS of a VC after it is set up. Future ATM UNI specifications are contemplating allowing changes to a VC after set up, but this is still preliminary. In the meantime, policies for over reservation or aggregation onto a larger VC may be needed 🤔.
- ST uses simplex streams that flow in only one direction. This is fine for UNI 3.1 point-to-multipoint connections, since the data flow is only in one direction. When mapping a point-to-point ST connection to a standard point-to-point ATM VC, the reverse flow connection is wasted 🗑️.
This can be solved simply by using only point-to-multipoint VCs, even if there is only one receiver ✨.
4.3 Mapping IP flows to ATM connections 🧚
In general, there is going to be a great deal of flexibility in how one maps flows at the IP level to connections at the ATM level 🌈. For example, one could imagine setting up an ATM connection when a reservation message arrives at the edge of an ATM cloud, and then tearing it down as soon as the reservation times out. However, to minimize latency or perhaps for economic reasons, it may be preferable to keep the ATM connection up for some period in case it is needed. Similarly, it may be possible or desirable to map multiple IP flows to a single ATM connection, or vice versa 🍓.
An interesting situation arises when a reservation request is received for an existing route across the cloud, but which, when added to the existing reservations using that connection, would exceed the capacity of that connection 😬. Since the current ATM standards do not allow the QoS of a connection to be changed, there are two options: tear down the old connection and create a new one with the new, larger allocation of resources, or simply add a new connection to accommodate the extra traffic. It is possible that the former would lead to more efficient resource utilization. However, one would not wish to tear down the first connection before the second was admitted, and the second might fail admission control because of the resources allocated to the first. The difficulties of this situation seem to argue for evolution of ATM standards to support QoS modification on an existing connection 🙏.
5.0 End System Issues 💻
In developing an integrated IP-ATM environment, the applications need to be as oblivious as possible of the details of the environment. The applications should not need to know about the network topology to work properly 🙈. This can be facilitated first by a common application programming interface (API), and secondly by common flow and filter specifications [18].
An example of a common API that is gaining momentum is the BSD sockets interface. This is a UNIX standard, and with Winsock2 it has also become a PC standard 🖥️. With the IETF integrated service environment just beginning to appear in the commercial marketplace, the ability to standardize on one common interface for both IP and ATM applications is still possible, and it must be seriously and quickly pursued to ensure interoperability 🔥.
Since the IP integrated service and ATM environments offer different QoS service types, an application should specify sufficient information in its flow specification so that, regardless of the topology of the network, the network can choose an acceptable QoS type to meet the application's needs 💖. Making the application provide sufficient information to quantify a QoS service, and allowing the network to choose the QoS service type, is essential to freeing the application from requiring a set network topology and allowing the network to fully utilize the features of IP and ATM 👑.
6.0 Routing Issues 🛣️
There is a fundamental difference between the routing computations for IP and ATM that can cause problems for real-time IP services 😭. ATM computes a route or path at connection setup time and leaves the path in place until the connection is terminated or there is a failure in the path. An ATM cell only carries information identifying the connection, and no information about the actual source and destination of the cell. In order to forward cells, an ATM device needs to consult a list of the established connections that map to the next hop device, without checking the final destination.
In contrast, routing decisions in IP are based on the destination address contained in every packet. This means that an IP router, as it receives each packet, has to consult a table that contains the routes to all possible destinations, and the routing decision is made based on the final destination of the packet. This makes IP routing very robust in the face of path changes and link failures, at the expense of the extra header information and the potentially larger table lookup 🧠. However, if an IP path has been selected for a given QoS, changes in the route may mean a change in the QoS of the path 💀.
6.1 Multicast routing 📡
Considerable research has gone into overlaying IP multicast models onto ATM 🔬. In the MARS (Multicast Address Resolution Server) model [1], a server is designated for the Logical IP Subnet (LIS) to supply the ATM addresses of the hosts in the IP multicast group, much like the ATM ARP server [15]. When a host or router wishes to send to a multicast group on the LIS, a query is made to the MARS, and a list of the ATM address of the hosts or routers in the group is returned. The sending host can then set up point-to-point or point-to-multipoint VCs to the other group members. When a host or a router joins an IP multicast group, it notified the MARS. Each of the current senders to the group is then notified of the new group member, so that the new member can be added to the point to multipoint VCs 🦋.
As the number of LIS hosts and multicast groups grows, the number of VCs needed for a one-to-one mapping of VCs to multicast groups can get very large 📈. Aggregation of multicast groups onto the same VC may be necessary to avoid VC explosion 💥. Aggregation is further complicated by the QoS that may be needed for particular senders in a multicast group. There may be a need to aggregate all the multicast flows requiring a certain QoS to a set of VCs, and parallel VCs may be necessary to add flows of the same QoS 🌸.
6.2 QoS Routing 🛣️
okay so most unicast and multicast IP routing protocols find the shortest path to a destination based only on a hop count or metric 🙈 OSPF [16] and MOSPF [17] can compute based on different IP Type of Service (TOS) levels as well as link metrics, but no current IP routing protocols take into account the whole range of quality of service levels that ATM or the Integrated Services models offer 💅. ngl, computing all the routes for just the shortest path in a big network is already computationally expensive, so doing it again for multiple QoS levels might be prohibitively expensive 💀.
In ATM, the Private Network-to-Network Interface (PNNI) protocol [13] passes QoS information along with routing information, so network nodes can use it to set up paths for the QoS they need ✨. Integrated PNNI (I-PNNI) [9] has been proposed as a way to pass the QoS info available in ATM over to other routing protocols in an IP environment 🦋.
Wang & Crowcroft [28] suggest that only bandwidth and delay metrics are necessary for QoS routing, and that this would work well for computing a route that needs a particular QoS at setup time. But it goes against the connectionless Internet model 😭. One possible fix for the exhaustive computation of every route with every possible QoS value would be to compute routes for a common set of QoS values, and only compute routes for uncommon QoS values as needed. That way only the first packets of a flow with an uncommon QoS take a performance hit 🌸. Sparse multicast routing protocols that compute a multicast path in advance or from the first packets of a sender (like CBT [5] and MOSPF [17]) could also use QoS routing info to set up a delivery tree with adequate resources 🧚.
However, no multicast routing protocols let QoS info be communicated at tree setup time 🙃. Getting a tree with suitable QoS is meant to be handled by RSVP, usually after the distribution tree is already set up, and it may mean recomputing the distribution tree to give the requested QoS. One way to fix this is to add some "hints" to the multicast routing protocols, so they get an idea of the QoS the multicast group will need at group initiation time and set up a distribution tree that supports it 🔥. The CBT protocol [5] has some TBD fields in its control headers to support resource reservation. Such info could also be added to a future IGMP [11] JOIN message that includes info on the PIM Rendezvous Point (RP) or CBT Core.
Another option is to recompute the multicast distribution tree based on the RSVP messages, but that has the danger of losing data during the recomputation 😱. It can also leave a timing window where other reservations come along during the tree recomputation and use the resources of both the new path and the old path, leaving the user with no path to support the QoS they want 💔.
If unicast routing is used to support multicast routing, we have the same problem of only knowing a single path to a given destination with no QoS info. If the path suggested by unicast routing doesn't have the resources for the QoS wanted, there are few choices. Schemes that use an alternate route to "guess" at a better path have been suggested and can work for certain topologies, but an underlying routing protocol that provides QoS info is necessary for a complete solution 👑. As mentioned earlier, I-PNNI has the potential to provide enough info to compute paths for the requested QoS 🎀.
6.3 Mobile Routing 📱
When you're planning an integrated IP-ATM network, potential new growth areas need to be included in the planning stages 🗺️. One big one is mobile networking. Under the mobile networking umbrella you'll find satellite extensions of the ATM cloud, mobile hosts that can join an IP subnetwork at random, and a true mobile network where all network components, including routers and/or switches, are mobile 🛰️.
The IP-ATM real-time service environment must be extended to include mobile networks, so mobile users can access the same services as fixed network users ✨. That comes with a bunch of problems to sort out. The principle problems are that mobile networks have constrained bandwidth compared to fiber, and mobile links are less stable than fixed fiber links 😬. These limitations affect IP and ATM differently. If you introduce one or more constrained components into the ATM cloud, the effects on congestion control in the overall network are unknown 🤷♀️. You can picture major buffering problems when a disadvantaged user on a mobile link tries to access info from a high speed data stream 🫠. And since ATM uses out of band signalling to set up the connection, the stability of mobile links that may have significant fading or complete loss of connectivity could have a big effect on ATM performance 📉.
For QoS, fading on a link shows up as a varying channel capacity 📶. That leads to time-dependent fluctuations in which links are available to support a level of service. Current routing protocols are not designed to operate in a rapidly changing topology. QoS routing protocols that can operate in a rapidly changing topology are required and need to be developed 🙏.
7.0 Security Issues 🔐
In a QoS environment where network resources are reserved, which could potentially deprive other users of access to those resources for some time period, authentication of the requesting host is essential 🛡️. This problem gets a lot bigger in a combined IP-ATM topology, where the requesting host can access the network through either the IP or the ATM portion of the network 😳. Differences in the security architectures of IP and ATM can lead to opportunities to reserve resources without proper authorization to do so 🚨. A common security framework over the combined IP-ATM topology would be desirable 💜. In lieu of this, the use of trusted edge devices requesting the QoS services are required as a near term solution 🧱.
this whole section is giving high stakes, bestie 🚨 resource reservation without proper auth is a real problem
Significant progress in developing a common security framework for IP is underway in the IETF [2] 🌈. The use of authentication headers in conjunction with appropriate key management is currently being considered as a long range solution to providing QoS security [3,8]. In developing this framework, the reality of ATM portions of the Internet should be taken into account 🍓. Of equal importance, the ATM Forum ad-hoc security group should take into account the current work on an IP security architecture to ensure compatibility 💅.
8.0 Future Directions ✨
okay so bestie, this section is basically the "what's next" list 🔮 and it starts with a little reality check: some stuff is really well understood and some stuff is still a total mess 💀. Things like policing, admission control, and packet or cell scheduling can be handled mostly on their own, inside IP or inside ATM, as appropriate 🧚. So yeah, there are hard problems that the IP folks or the ATM folks need to solve, but there aren't many serious problems that show up specifically because IP is running over ATM 🫶. The reason is kind of iconic: IP doesn't really care how a network element (like an ATM network) gives you a certain QoS 💅. What matters is whether the ATM service model can actually support the end-to-end IP service model 👑. So most of the hard problems for IP over ATM are really about the service models for IP and ATM 🎀. The one mechanism that matters in the IP/ATM situation is signalling or resource reservation, which we come back to below 💜.
The next bit lists areas where the authors think a lot of work is needed 🌸. The work falls into three buckets: extending the IP over ATM standards, extending the ATM service model, and extending the IP service model 🦋. Practical experience with IP QoS over ATM is expected to suggest more improvements to the service models, which is very on-brand 😭.
First up: we need ways to map the QoS and traffic characterizations (Tspecs and Rspecs) of IP flows onto suitable characterizations for ATM connections 🔥. We need an agreement so that some sort of uniform approach gets taken 🫶. Whatever mapping gets agreed on has to work when traffic crosses several networks, so the requested QoS is obtained end-to-end (when admission is possible) ✨. Real-world experience is needed to confirm that the ATM service classes can actually give IP flows suitable QoS in a reasonably efficient way 💖. The ATM service classes might need enhancing, but experience is needed to figure out what's appropriate 🌈.
Next, we need to work out how the resource reservation models of IP (RSVP and ST-II) interact with ATM signalling 💅. Mechanisms for setting up appropriate connection state with suitable QoS in ATM networks that are part of a larger integrated services Internet need to be defined 🧚. It's possible that the current IP/ATM mechanisms, such as ARP servers and MARS, could be extended to help manage this state 🍓.
There's also a need for better QoS routing ⭐. This is needed even in a pure ATM or pure IP environment, but there's also an eventual need for integrated QoS routing between ATM and IP 🦋. More research and practical experience is needed in QoS routing in IP so it can support more than the shortest best-effort path, especially when that path might traverse ATM networks 🌸. In a lot of IP networks there are multiple paths between a given source and destination pair, but current routing technologies only pay attention to the current shortest path 🙈. Once resources on the shortest path are reserved, it'll be necessary and viable to explore other paths to provide QoS to a flow 💀.
Enriching the ATM model to support dynamic QoS would really help the IP over ATM situation 👑. Right now, QoS objectives for ATM are established at call set-up and then fixed for the whole duration of the call 😭. It would be super useful to be able to provide dynamic QoS in ATM, so an existing call could be modified to provide altered services 🫶.
Another possible enhancement to the ATM service model is multicasting 🎀. The multicast QoS offered is equal for all receivers, so it may be determined by the least favorable path through the tree or by the most demanding receiver 🙈. There's also no current provision for multipoint to multipoint connections 💔. This limitation may rule out some of the services envisioned in the IP service model 🥀.
The IP model has areas of potential enrichment too 🌈. The receiver-based approach of RSVP has nice scaling properties and handles receiver heterogeneity well, but it's not clear it's ideal for all applications or for establishing state in ATM networks 💜. A sender-oriented mode for RSVP might ease the IP/ATM integration task 🧚.
Since widespread availability of QoS raises new security concerns (for example, denial of service by excessive resource reservation), it seems prudent for the IP and ATM communities to work closely and adopt compatible approaches to handling these issues 🔐✨.
This list is almost certainly incomplete 🙃. As work moves forward to define IP over ATM standards that support QoS, and to implement integrated services internetworks that include ATM, more issues are likely to pop up 💅. Still, the authors believe this paper has described the major issues that need to be considered at this time by those defining the standards and building implementations 👑🎀.
9.0 References 📚
- Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", Work in Progress, Bellcore, February 1995.
- Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.
- Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.
- Ballardie, A., and J. Crowcroft, "Multicast-Specific Security Threats and Counter-Measures", Proceedings of ISOC Symposium on Network and Distributed System Security, San Diego, Feb. 1995, pp. 2-16.
- Ballardie, T., Jain, N., Reeve, S. "Core Based Trees (CBT) Multicast, Protocol Specification", Work In Progress, University College London, Bay Networks, June, 1995.
- Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI/MIT/Xerox PARC, July 1994.
- Braden, R., Zhang, L., Estrin, Herzog, D., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Work in Progress, ISI/PARC/UCS, July 1995.
- Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC 1636, ISI, MIT, TIS, INRIA, June 1994.
- Callon, R., and B. Salkewicz, An Outline for Integrated PNNI for IP Routing", ATM Forum/ 95-0649, Bay Networks, July 1995.
- Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", Work in Progress, AT&T Bell Laboratories/ ANS, April 1995.
- Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
- Delgrossi, L., and L. Berger, Editors, "Internet Stream Protocol Version 2 (ST-2) Protocol Specification - Version ST2+", RFC 1819, ST2 Working Group, August 1995.
- Dykeman, D., Ed., "PNNI Draft Specification", ATM Forum/94-0471R8, IBM Zurich Research Lab, May 1995.
- Goyal, P., Lam, S., and Vin, H., "Determining End-to-End Delay Bounds in Heterogeneous Networks," 5th International Workshop on Network and Operating System Support for Digital Audio and Video, April, 1995. (Available via URL http://www.cs.utexas.edu/users/dmcl)
- Laubach, M., "Classical IP and ARP over ATM", RFC 1577, HP, January 1994.
- Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.
- Moy, J., "Multicast Extensions to OSPF," RFC 1584, Proteon, March 1994.
- Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN, September 1992.
- Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, ISI, Fore, Motorola Codex, Ascom Timeplex, February 1995.
- Perkins, D., and Liaw, Fong-Ching, "Beyond Classical IP-Integrated IP and ATM Architecture Overview", ATM Forum/94-0935, Fore Systems, September 1994.
- Perkins, D. and Liaw, Fong-Ching, "Beyond Classical IP-Integrated IP and ATM Protocol Specifications", ATM Forum/94-0936, Fore Systems, September 1994.
- Romanow, A., and S. Floyd, "The Dynamics of TCP Traffic over ATM Networks", Proceedings of ACM SIGCOMM U94, London, August 1994, pp.79-88.
- Shenker, S., and C. Partridge. "Specification of Guaranteed Quality of Service", Work in Progress, Xerox/BBN, July 1995.
- Shenker, S., and C. Partridge. "Specification of Predictive Quality of Service", Work in Progress, Xerox/BBN, March 1995.
- Shenker, S., C. Partridge and J. Wroclawski. "Specification of Controlled Delay Quality of Service", Work in Progress, Xerox/BBN/MIT, June 1995.
- Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications", Work in Progress, GMD/ISI/Xerox/LBL, March 1995.
- Topolcic, C., "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC 1190, BBN, October 1990.
- Wang, Z., and J. Crowcroft, "QoS Routing for Supporting Resource Reservation", University College of London white paper, 1995.
10. Authors' Addresses 💌
Eric S. Crawley Marty Borden Bay Networks 3 Federal Street Billerica, Ma 01821 508-670-8888 esc@baynetworks.com mborden@baynetworks.com
Bruce S. Davie Bellcore 445 South Street Morristown, New Jersey 07960-6438 201-829-4838 bsd@bellcore.com
Stephen G. Batsell Naval Research Laboratory Code 5521 Washington, DC 20375-5337 202-767-3834 sgb@saturn.nrl.navy.mil
📦 where this page comes from
- ietf: rfc1821 1995-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms