RFC 1946

Native ATM Support for ST2+

📅 published May 1996, from ietf

RFC 1946: Native ATM Support for ST2+ 🦋

Okay bestie, this one is Native ATM Support for ST2+ 💜. It was written by S. Jackowski from NetManage Incorporated and published in the Network Working Group 🌸. It's an Informational doc dated May 1996. There's no Obsoletes or Updates line in the header, so it doesn't obsolete or update anything ✨.

Status of This Memo 📚

So the vibe here is that this memo just provides information for the Internet community 🫶. It does not specify an Internet standard of any kind, and it's not a standard you have to follow. Distribution is unlimited, so share it with everyone 💅.

Abstract 💖

As more people want realtime stuff on the network, shared networks need to deliver data in a predictable way 🔥. That kind of deterministic delivery only works if both the sending application and the network infrastructure can request it, set it up, and enforce it. Put together, all of that is called bandwidth reservation and Quality of Service (QoS) ✨.

The IETF is working on an integrated services model for realtime stuff on the Internet 🌐. What it hasn't really focused on yet is mixing ATM with its built-in QoS and bandwidth allocation tools to carry realtime traffic over shared wires 🙈. (ATM hardware and interfaces give us the network infrastructure for that deterministic delivery, but the host-resident protocol stacks and applications still need more attention 😭.)

IETF work in the IP over ATM (ipatm) working group relies on intserv, rsvp and ST2 to handle QoS for ATM 🦋. RFC 1577 and the ATM Forum's Lan Emulation don't give network applications direct QoS and bandwidth allocation capabilities, though. Without a mapping from reservation-style QoS to ATM signalling, ATM will stay a 'wire' instead of becoming a shared media infrastructure component 🥺.

This memo describes a working implementation that lets applications directly invoke ATM services in these environments:

  • ATM to internet,
  • internet to ATM, and
  • internet to internet across ATM.

Table of Contents 🎀

   1.0     Introduction...............................................2
   2.0     ST-2 and ST-2+.............................................5
   3.0     Implementation Issues for Reservations over ATM............6
   3.1     Addressing.................................................6
   3.2     Changes to Bandwidth and QoS...............................6
   3.3     Multicasting...............................................7
   3.4     Receiver Initiated JOIN Requests to Multicast Groups.......8
   3.5     Computation of QoS Parameters..............................8
   3.6     Use of HELLOs..............................................9
   4.0     Reservation Signalling with ATM............................9
   4.1     Embedded Reservation Signalling within Q.2931.............10
   4.2     In-Band Reservation Signalling............................11
   4.3     Dedicated Virtual Circuits for Reservation Signalling.....12
   4.4     Reservation Signalling via IP over ATM or LAN Emulation...13
   4.5     Summary of Reservation Signalling Options.................14
   5.0     Mapping Reservation QoS to ATM QoS........................15
   5.1     CPCS-SDU Size Computation.................................16
   5.2     PCR Computation...........................................17
   5.3     Maximum End to End Transit Delay..........................17
   5.4     Maximum Bit Error Rate....................................18
   5.5     Accumulated Mean Delay....................................18
   5.6     Accumulated Delay Variance (jitter).......................18
   6.0     Data Stream Transmission..................................18
   7.0     Implementation Considerations and Conclusions.............19
   8.0     Security Considerations...................................20
   9.0     References................................................20
   10.0    Author's Address..........................................21

1.0 Introduction ✨

The ATM Forum and the IETF seem to approach ATM networking differently 👀.

The ATM Forum appears to believe that host systems don't need any protocols beyond OSI layer 2 to deal with ATM 🙄. They define a layer 2 API and Q.2931 signaling for all new applications.

LAN Emulation is the thing that makes the ATM interface look like a LAN/internet, and it's meant to support 'legacy' network applications 🦖. Applications can't see the ATM features at all, and there's no mechanism that lets them ask for specific ATM services. With LAN Emulation, application traffic shares virtual circuits with no policing and no guarantees of service. It basically just stretches LAN characteristics over ATM.

So the IETF, through RFC 1577[1], treats an ATM network as a wire 🔌. The ipatm working group has explicitly left specific QoS handling out of their specifications and working documents. Current approaches don't give applications access to individual virtual circuits and their guaranteed bandwidth and QoS. Instead, all IP traffic between two hosts shares virtual circuits, with no granularity for application-specific traffic or QoS requirements.

So neither LAN Emulation nor RFC 1577 (IP over ATM) uses the features that make ATM a unique and desirable technology 💅. RFC 1821 (Integration of Realtime Services in an IP-ATM Network Architecture) [2] covers many of the issues around IETF efforts to integrate ATM into the Internet, but it doesn't propose any solutions.

This document offers a framework for providing native ATM circuits to applications that need bandwidth guarantees and QoS 🧚. It identifies the requirements for a native ATM protocol that complements standard IP, and it describes one working implementation.

This document recognizes that it's critical for such a native ATM protocol to stay consistent across the four topologies described in [2]:

  • Communication across an ATM-only network between two hosts directly connected to the ATM network,
  • Communication between ATM connected hosts that involves 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 use one or more ATM networks for some part of the path.

That means that, to the host systems, the underlying type of network stays transparent even when QoS is involved in internet, ATM, and mixed networking environments 🌈. To make this consistency possible, the 'native ATM' protocol must also be:

  • Multicast capable, to optimize transmission overhead and support ATM multipoint facilities,
  • Routable, to enable transmissions across subnets and internets,
  • QoS knowledgeable, to take advantage of ATM QoS facilities,
  • Capable of Bandwidth/QoS Reservation to allocate proper facilities for application traffic as it travels across different types of networks, in order to effectively extend virtual circuits across internets, and
  • Capable of policing to ensure proper packet scheduling behavior and to protect guaranteed services at merge points.

Clearly, the protocol should support reservations 🍓. Reservation protocols enable the creation of 'virtual circuits' with guaranteed bandwidth and QoS on the LAN or internet. They can also act as signaling mechanisms that tell routers or ATM interfaces to provision circuits. Using a reservation protocol makes the characteristics of mixed networks (LANs, internet, ATM, ISDN) transparent to the host systems 🦋. A reservation lets the host or router provision ATM circuits that match it, and in mixed networks it lets routers and hosts provide bandwidth reservation and QoS across the non-ATM interfaces too. Effectively, the reservation maps ATM virtual circuits to reservations on subnets and internets.

This creates a consistent End-to-End, QoS-guaranteed service for mixed network topologies 👑.

While it's beyond the scope of this document, the same requirements apply to mixed ISDN networks, which the ITU is currently exploring for its H.323, H.223, and T.123 standards 🌸.

Arguably, the reservation protocol that provides this end-to-end guaranteed service should be connection-oriented, so real connections (ATM or ISDN) can be mapped to virtual connections on the LAN/internet 🤓. [2] points out the shortcomings of IP and RSVP [3] in the ATM environment. The biggest ones are the difficulty of mapping connectionless traffic to ATM connections, the constant softstate refreshes of RSVP (and merging of RESV messages), the receiver orientation of RSVP, and the dependence on IP multicast 💀.

[6] is an excellent document that proposes solutions to many of the issues raised in [2] 🫶. The catch is that those solutions recommend modifications to the current RSVP and ATM implementations. Recently, problems with incompatibility with the current IP over ATM model, VC explosions due to the use of multicast groups, and VC explosions due to features associated with heterogeneous receivers suggest that the current version of RSVP may be inappropriate for ATM implementations 😬.

Since ATM is connection-oriented, hard state, and origin-oriented for transmission, signaling, and multicast, and it's bandwidth and QoS knowledgeable, the simplest and most elegant approach to a native protocol for ATM would probably include a protocol that shares these characteristics ✨.

In surveying protocols described in IETF RFCs and Internet Drafts, only two seem to meet these requirements: Experimental Internet Stream Protocol: Version 2 (RFC 1190) [4] and Internet STream Protocol Version 2+ (RFC 1819) [5]; ST2 and ST2+ respectively 💜.

2.0 ST2 and ST2+ 🦋

Okay so, ST2 and ST2+ both got the Internet Protocol Version 5 (IPv5) designation 🧚. Fun fact: ST2+ is literally an updated version of ST2 💅. Both are origin-oriented reservation and multicast protocols that give you bandwidth and QoS guarantees across internets ✨. Unlike IPv4 or IPv6, ST2 and ST2+ are connection-oriented, and that's the whole vibe: once a connection is established, protocol and routing overhead can be substantially reduced 🫶. That energy carries over to QoS and Bandwidth Reservation too, which makes QoS guarantees way simpler to implement 💖.

THESE PROTOCOLS WERE INTENDED TO COMPLEMENT STANDARD CONNECTIONLESS IP, RECOGNIZING THAT WHILE MOST INTERNET TRAFFIC BENEFITS FROM CONNECTIONLESS NETWORKING, PERFORMANCE AND QoS GUARANTEES COULD BE ACHIEVED MOST EASILY WITH INTERNET CONNECTIONS. 🌈

Both ST2 and ST2+ really consist of two protocols: SCMP and ST 👯. SCMP is basically the ICMP of this world, the control and signaling protocol 📣, while ST is the low-overhead streaming protocol 🏊. ST-2 uses standard IP addresses during connection setup, but then slims down header overhead by putting a stream identifier in each data packet 💅.

ST2+ includes simplification of many of the original ST2 features, plus clarification of the ST2 specification 🧼. The big ones are:

  1. Much simpler connection setup.
  2. Flow Specification independence and consolidation of experimental Flow Specifications.
  3. Clarification on the implementation of Groups of Streams.
  4. Clarification of leaf-initiated JOINs in multicast trees (several ST2 implementations had done this).

While there's still a dramatic increase in the use of ST2 for videoconferencing, video on demand, telemetry applications and networked virtual reality 🎮, ST2+ has no commercial implementations and isn't yet supported by any router vendors 💀. This is because ST2+ was released as an RFC late in the summer of 1995 🍂. It's expected that several implementations will show up over the coming months ⏳.

So the approach in this document applies to both protocols, and honestly it would be valid for any other similar protocol used to establish 'native' ATM circuits 🦋. Since ST2 and ST2+ are so similar, this document will refer to 'the ST2 protocols' generically when describing an implementation approach to both 🫧. Where particular features of ST2+ are required or affect implementation, 'ST2+ ' will be used specifically 🎀.

3.0 Implementation Issues for Reservations over ATM 🎀

As we said above, ST is a connection-oriented, hard state, origin-oriented multicast protocol, so it maps pretty well to ATM 💞. However, ST-2 has several features that may be difficult to support in the current version of ATM signaling with Q.2931 and UNI 3.1 😬. Those are:

  1. Addressing.
  2. Changes to Bandwidth and QoS.
  3. Multicasting.
  4. Receiver initiated JOINs to multicast groups.
  5. Computation of certain QoS parameters.
  6. Use of HELLOs.

How hard it is to support these functions depends on the signaling mechanism you choose 🤔. Check out Section 4 for descriptions of possible signaling approaches and how each one affects the features listed above 📖.

3.1 Addressing 💌

Mapping an Internet address to an ATM address is always problematic, ngl 😩. It would be possible to set up a well known ARP server to resolve the IP addresses of targets 🔍. But the widespread deployment of IP over ATM and LAN emulation in host-based ATM drivers, plus the assumption that most host systems will be running IP applications that don't need specific QoS and bandwidth provisioning, makes using the ARP facilities provided by IP over ATM and LAN Emulation the most obvious choice for address resolution 🙌.

It should be noted that ATMARP returns the ATM address 📝. For some implementations (particularly kernel-based protocols), an NSAP address is also required 🧩. Since these addresses are often difficult to get from the ATM network itself before the connection exists ⏰, it may be necessary to invoke out-of-band signaling mechanisms to pass this address, or it may be better to create an NSAP address server 🖥️.

3.2 Changes to Bandwidth and QoS 🔄

Both ST-2 and ST-2+ let the origin dynamically change the QoS and Bandwidth of a particular stream 🎚️. Right now Q.2931 and UNI 3.1 don't support this feature 😭. Until that capability is available, full support of the SCMP CHANGE message for dedicated ATM circuits (one reservation = one ATM circuit) can only be done by tearing down the existing VC for a stream and setting up a new one, if efficient use of ATM resources is going to be preserved 🫠.

Of course, the CHANGE message can simply be passed across the ATM virtual circuit to the hosts or routers 📨. This lets the hosts relax resource requirements locally, and lets routers relax access to downstream circuits 🏃. But the ATM VC itself would still retain excessive bandwidth 😤.

In addition, if the implementation allows sharing of virtual circuits by multiple streams, the bandwidth/QoS of individual streams within the VC can be CHANGEd 🪄.

3.3 Multicasting 📡

ST-2 and ST-2+ support origin-oriented multicasting. That means the origin of a stream explicitly specifies the addresses of the targets it wants involved in the connection 🎯. In addition, the origin can Add or drop targets as desired. Aside from receiver-initiated JOINs (discussed in section 3.4), there's a one to one mapping between ST-2 multicast and ATM multipoint connections 🔗. Origin-initiated additions can be accomplished through an ADDPARTY, and drops can be done through DROPPARTY 🎉.

A key goal in implementing a native ATM protocol is making sure you get consistent implementation for unicast and multicast data transfers 💯. One difficulty with this is that ATM Virtual Circuits are a mismatch here: point-to-point circuits are duplex, while multipoint circuits are simplex 🙃. This means that for multicast connections to be mapped to multipoint ATM Virtual Circuits, any two-way, end-to-end signaling must be done out of band 📤. An alternative is to let the local reservation agent act as a split/merge point for the connection by establishing point-to-point Virtual Circuits for each member of the multicast group directly connected to the ATM network 🌿. For multicast group members not directly connected to the ATM network, traffic can be multicast to the router connected at the edge across a single virtual circuit associated with the reservation 🛣️.

Section 4 describes alternative mechanisms for implementing signaling 🔍.

Included in each discussion is the optimal means for mapping multicast to ATM point-to-point or multipoint circuits 🧠.

Note that the fact that ST-2 does not rely on IP multicast is a strong advantage in implementation of a native protocol for ATM 💪. The one-to-one mapping of ST-2 multicast connections to ATM multipoint virtual circuits minimizes the number of circuits required to support large multicast groups 🪐.

3.4 Receiver Initiated JOINs to Multicast Groups 🙋

ST-2+ provides an in-band mechanism to permit receivers to join an existing stream 🚪. Based on an origin-established authorization level, the JOIN can be refused immediately, can be allowed with notification of the origin, or can be allowed without notifying the origin 🔐. This capability is made available through a new SCMP JOIN message 🆕. If the receiver knows the IP address of the origin and the Stream ID, they can join the stream if they're authorized to do so 🎫.

Note that since the JOIN flows from the receiver to the origin, there will be issues in trying to support this feature with Q.2931 and UNI 3.1 😵. The JOIN may have to be sent out of band depending on the signaling mechanism chosen (section 4) because of the uni-directional flow for point to multipoint ATM connections 🛑. This is supposed to change with availability of UNI 4.0 🤞.

ST-2 did not support receiver initiated JOINs (unlike ST-2+) 🙅. However, most implementations created an out-of-band, or SCMP extension to support this facility 🛠️. Again, depending on the SCMP signaling mechanism chosen, this feature may be difficult to support 😬.

3.5 Computation of QoS Parameters 🧮

The recommended flow specifications (flowspecs) for ST-2 and ST-2+ include parameters that are not currently available to ATM virtual circuits through Q.2931 and UNI 3.1 🙈. The mapping of packet rate to cell rate, packet delay to cell delay, and other translatable QoS parameters is described in section 5 🗺️. However, the ST-2 flowspecs also include parameters like accumulated end-to-end delay and accumulated jitter 📊. These parameters assume that the SCMP messages follow the same path as the data 🛤️. Depending on the signaling mechanism chosen, this may not be true with ATM, and thus certain QoS parameters may be rendered useless 💀.

It should also be noted that since ST-2 connections are simplex, all QoS parameters are specified separately for each direction of data transfer 👈. Thus two connections and two QoS negotiations are required for a duplex connection 2️⃣. To take advantage of the full duplex nature of point-to-point ATM connections, special multiplexing of ST connections would be required by ST-2 agents 🧵.

3.6 Use of HELLOs 👋

Both ST-2 and ST-2+ support HELLO messages 🗣️. HELLOs are intended to assure that the neighboring agent is alive 💓. Failure to respond to a HELLO indicates that the connection is down and that the reservation for that particular link should be freed 🧹.

While the ATM network will notify an ST-2 agent if the network connection is down, there is still the possibility that the connection is intact but that the ST-2 agent itself is down 👻. Knowledge of the neighboring agent's status is increasingly important when multiple ST-2 connections share virtual circuits, when the neighboring agents are routers, and when there are multiple dedicated virtual circuits between agents 📈.

As such, HELLO is a desirable feature 💜. Note that some signaling schemes (section 4) provide less than optimal support for HELLO 🙃.

4.0 Reservation Signaling with ATM ✨

okay so PVCs (Permanent Virtual Circuits) are honestly no problem 💅 for ST-2, ST-2+, or RSVP. Each circuit counts as a dedicated link to the next hop 🦋. And if the PVCs are shared? Still fine. The reservation protocols can split up and regulate the bandwidth just like they would on any other link type 🎀.

Where ATM gets really interesting is when the ATM network acts like an extended LAN or internet 🌐. That's when you use SVCs (Switched Virtual Circuits) to make dynamic connections to different endpoints and routers. The ITU-TS Q.2931 SETUP message asks the network for a connection with specific bandwidth and QoS requirements, and the origin gets a CONNECT message once the connection is fully set up ✨.

For IP over ATM and LAN Emulation, SVCs get set up between endpoints, and data for a given destination shares those SVCs 💖. There's no mechanism for specific QoS guarantees on that traffic, and no way to set up virtual circuits with particular bandwidth and QoS for a certain type of traffic 😭. That's the gap reservation protocols are trying to fill 🧚. The goal is to use reservations to request individual virtual circuits with matching bandwidth and QoS for each reservation. That guarantees what the application needs while still taking full advantage of what ATM can do 👑.

There are four possible mechanisms to perform reservation signaling over ATM:

  1. Embedding reservation signaling equivalents within the ATM Q.2931 controls.
  2. Signaling in-band with the data.
  3. Signaling over dedicated signaling VCs.
  4. Implicitly sharing existing VCs for IP over ATM or LAN Emulation.
Note that ATM circuits are not necessarily reliable 💀. So the reliability mechanisms provided by SCMP must be maintained to assure delivery of all reservation signaling messages.

4.1 Embedded Reservation Signaling Equivalents within ATM Q.2931 Controls

the big idea here is to use the Q.2931 SETUP and CONNECT messages to establish both reservations and dedicated data paths (virtual circuits) across the ATM network 🔥. No dedicated signaling channels, no in-band signaling, no out-of-band mechanisms needed for endpoints to talk to each other. And since SETUP and CONNECT already carry bandwidth and QoS information, the basic concept is solid 🫶. It also speeds up connections, because you skip the multiple passes at setting up a reservation and its connection. That usually happens because most higher layer protocols (network and transport) first need a link before they can signal their own connection requirements. So with ATM, the ATM virtual circuit must be established before the network and/or transport protocols can do their own signaling.

Embedded reservation signaling lets the reservation information ride along in the SETUP and CONNECT messages, so the reservation protocol can do its signaling at the same time as the ATM signaling ⭐.

[7] describes a clever way of combining reservation signaling with ATM control plane signaling for ST-2 🧠. This "simultaneous connection establishment" process optimizes circuit setup and minimizes connection setup time, while also cutting out unnecessary network layer signaling in ST-2. To make it work, [7] needs enhancements to Q.2931 signaling and to the ST-2 protocol implementations. It also currently only applies to point-to-point connections and won't work with multipoint, mostly because multipoint communication is simplex in current ATM implementations 🙈.

Multicast with Embedded Reservation Signaling works the same way as described above. The reservation agent at the edge of the ATM network must create point-to-point virtual circuits for each target directly connected to the ATM network, and for each router that supports downstream targets. That keeps signaling two-way between targets and the origin 🦋.

Signaling itself is pretty simple:

        CONNECT maps directly to one or more (multicast) Q.2931
                SETUPs and CONNECTs.
        ACCEPT maps directly to Q.2931 CONNECTACK.
        CHANGE/CHANGE REQUEST are  not supported.
        DISCONNECT maps directly to Q.2931 RELEASE.
        HELLOs are not needed.

Unfortunately, the flowspec in the reservation protocol CONNECT message can't be passed across the ATM network inside the signaling messages. So the receiving agent has to regenerate it 😭.

User Data, which can be sent in most SCMP messages, can't be supported without substantial changes to current Q.2931 signaling 🙃.

Heterogeneous networks add another wrinkle 🌈. ATM signaling only works point to point across the ATM network itself. So if the endpoints live on other types of networks or subnets, the routers at the edge of the ATM networks must generate and regenerate endpoint-based signaling messages on behalf of the host reservation agents. CONNECT and ACCEPT messages and their associated flowspecs in particular must be regenerated. Check out Section 5 for the details on the QoS mappings and on which QoS parameters can be recreated for the generated flowspecs 📚.

This approach is worth revisiting as an optimal signaling method in pure ATM environments once ATM signaling capabilities expand 🚀. For heterogeneous networks though, other signaling mechanisms may be more appropriate 💅.

4.2 In-Band Reservation Signaling

in-band reservation signaling is the easiest one to implement 🍓. When the application requests a reservation, the reservation agent just sets up ATM virtual circuits to the endpoints with the QoS specified in the CONNECT request. Once ACCEPTed, all the data transmissions go over those virtual circuits.

Again, to support multicast, the reservation agent must create individual point-to-point virtual circuits to the targets directly connected to the ATM network, plus the routers that can reach downstream targets 🎀.

Since signaling is done in-band, all reservation signaling messages can be passed between agents. The catch is that some minimal additional bandwidth has to be allocated in the Q.2931 SETUP so the signaling messages themselves have room 🫠.

The main downside of in-band reservation signaling is that it doesn't use ATM's multipoint capabilities. That means it will overreserve ATM network bandwidth and create more virtual circuits than necessary 😩.

4.3 Dedicated Reservation Signaling Virtual Circuits

if you want the full data transmission power of ATM, dedicated virtual circuits for reservation signaling are the move 👑. They give you a guaranteed two-way signaling pipe between the endpoints of a connection, and the data gets to use ATM's multipoint capabilities. Data and signaling each have their own virtual circuits 🦋.

When an application requests a reservation, the reservation agent looks through the list of targets in the CONNECT request. For any targets without a current signaling virtual circuit, the agent sets up UBR (unspecified bit rate) virtual circuits and forwards the CONNECT message to those targets over them. ATMARP resolves any endpoint addresses 🧚. For targets that already have signaling virtual circuits, the agent just forwards the CONNECT message over the existing one ✨.

When an ACCEPT message arrives, the agent issues a Q.2931 SETUP to the matching target. Once the CONNECTACK comes back, data can start flowing 💖. Each additional ACCEPT means the Q.2931 ADDPARTY message is used to add that target to the multicast and multipoint connection. If an ADDPARTY fails, the agent may depend on the cause of the failure and try to set up a dedicated point-to-point virtual circuit to finish building the multicast group 🌸.

DISCONNECT requests turn into Q.2931 DROPPARTY messages, which drop a member from the multicast and multipoint connection 🙈. Once every target is dropped from a multipoint connection, a RELEASE can be issued to take down the virtual circuit 💀.

Signaling virtual circuits are shared among reservations, but data circuits belong to one specific reservation each 🫶. Once all reservations to a given endpoint have ended, the signaling virtual circuit to that endpoint can be RELEASEd 🔥.

Last thing: this approach would let the NSAP address be passed as user data in the ACCEPT message, so a kernel-based reservation protocol can set up the dedicated data circuit 🤓. And since connectivity to the endpoint is identical to that of the data circuit, the accumulated information in the flowspecs keeps its validity ✅.

4.4 Reservation Signaling via IP over ATM or LAN Emulation 🎀

okay so we already talked about how you could set up unique SVCs just for SCMP signaling 🙄 but ST-2's streaming, connection-oriented data transport is supposed to be the complement to IP and other connectionless protocols, not a replacement 💅. So it's simpler and honestly more elegant to just use classical IP over ATM (RFC 1577) mechanisms, or LAN Emulation 🫶. IP over ATM and LAN emulation are everywhere in host-based ATM drivers, and most host systems are running apps that don't need special QoS or bandwidth provisioning, so this is the most straightforward (if not performance optimal) option for signaling ✨. Once the end-to-end acceptance of a reservation request is done through normal LAN or IP transmission, a unique direct virtual circuit can be set up for each data flow 🦋.

If LAN Emulation is used, as long as the ST-2 implementation allows for different paths for SCMP and data, there would be no changes to the signaling mechanisms employed by the reservation agent 🌸.

For IP over ATM, all SCMP messages would be encapsulated in IP as described in both RFC 1190 and RFC 1819. This is required because current ATM drivers will not accept Ipv5 packets, and most drivers don't give direct access to the shared signaling virtual circuits used for IP 😭.

In either case, LAN Emulation or IP over ATM, the reservation agent handles SCMP messages the way it normally does 💜. However, once the first ACCEPT is received for a reservation request, a dedicated virtual circuit is established for the data flow ✨. Subsequent ACCEPTs result in the use of ADDPARTY to add multicast targets to the multipoint virtual circuit. Honestly, processing multipoint/multicast here is identical to what we covered in section 4.3 👑.

Once again, the out-of-band signaling mechanism makes it possible to carry the NSAP address of the target in the ACCEPT message 🧚.

One potential drawback to using LAN Emulation or SCMP messages encapsulated in IP over ATM is that there is no guarantee the connectivity achieved to reach the target via signaling has any relationship to the data path. This means that accumulated values in the flowspec may be rendered useless 💀.

It's also possible that the targets will actually reside outside the ATM network 🙈. That is, there may be no direct ATM access to the Targets, and it may be difficult to identify ATM addresses of the associated ATM connected routers. This approach involves some extra complexity in routing to the targets. However, since ST-2 is intended to run with IP, if ATM vendors would accept IPv5 packets or would allow direct access to the IP over ATM signaling virtual circuits, this approach would be optimal in minimizing the number of virtual circuits required 🌈.

4.5 Summary of Reservation Signaling Approaches 💖

Embedded Reservation Signaling (section 4.1) is ideal for homogeneous ATM connections, but it requires extensions to existing ATM signaling to support multipoint connections. In-Band Reservation Signaling (section 4.2) is the easiest to implement, but it cannot employ multipoint connections either 😤.

Perhaps the simplest way to do this is similar to what is suggested in [6]: separate the reservation signaling from the actual data flows, mapping the data flows directly to ATM circuits while doing the signaling separately 🦋.

Okay, there's significant complexity in doing this for IP traffic and RSVP, but the ST2 protocols lend themselves to this quite well 🔥. Because SCMP reservation signaling results in streaming, multicast connections, the 'Shortcut' mechanism described in [6] is automatically available to ST2 streams. It can bypass routers where direct ATM connections are possible 👑.

Using Reservation Signaling over LAN Emulation or IP over ATM (section 4.4) is one multipoint-capable approach to implement in hosts, since most ATM drivers shipping today provide both IP over ATM and LAN Emulation, plus the associated address resolution mechanisms 🍓. However, it isn't complete in its ability to accurately depict flowspec parameters or to resolve host ATM addresses 😬. Also, to be optimal, ATM vendors would either have to support IPv5 in their drivers or allow direct access to the IP signaling virtual circuits 🙃. So the current ideal approach to implementing the ST2 protocols over ATM is to use shared Dedicated Reservation Signaling Virtual Circuits (section 4.3) for signaling reservations, and then to establish appropriate multipoint ATM virtual circuits for the data flows ✨💅.

5.0 Mapping of Reservation QoS to ATM QoS 🎀

QoS negotiation in ST-2 (and ST-2+) is done via a two-way negotiation 🤝.

The origin proposes a QoS for the connection in a Flow Specification (Flowspec) associated with the CONNECT message. Most of the network-significant QoS parameters in the Flowspec include both a minimum and a desired value. Each ST agent along the path to the Target validates its ability to provide the specified QoS (at least the minimum value for each), updates certain values in the Flowspec, and propagates the CONNECT until it reaches the Target 🛤️. The Target can either ACCEPT the Flowspec or REFUSE it if it can't meet at least the minimum QoS requirements 🙅‍♀️. Negotiation happens as part of the process, since the Target can specify changes to the desired QoS values as long as the new value meets at least the minimum requirements specified by the Origin system. And both the Target and the Origin can assess actual network performance by reviewing the values accumulated along the path 📊.

The primary Reservation QoS parameters that impact an ATM network are:

ST-2 (RFC 1190)                                 ST-2+ (RFC 1819)

Desired PDU Bytes,                              Desired Message Size,
Limit on PDU Bytes (minimum).                   Limit on Message Size.

Desired PDU Rate,                               Desired Rate,
Limit on PDU Rate (minimum).                    Limit on Rate.
Minimum Transmission Rate in Bytes.

Limit on Delay (maximum).                       Desired Delay,
                                                Limit on Delay.
Maximum Bit Error Rate.

Accumulated Delay.
Accumulated Delay Variance (Jitter).

Q.2931 ATM signaling offers the following QoS parameters 🧁:

  • Cumulative Transit Delay,
  • Maximum End to End Transit Delay.
  • Forward Peak Cell Rate (PCR),
  • Backward Peak Cell Rate (PCR).
  • Forward Maximum CPCS-SDU size,
  • Backward Maximum CPCS-SDU size.
  • Forward QoS Class,
  • Backward QoS Class.
  • B-LLI (one byte user protocol information).

As previously noted, reservation protocols (ST and RSVP) make QoS reservations in one direction only 🫠. So, depending on the type of signaling used (see Section 4), the 'Backward' ATM parameters may not be useful. In particular, if Multipoint ATM connections are used to map multicast reservations, these parameters aren't available 🙈.

However, it would be possible to implement a multiplexing scheme that lets reservations share bi-directional point-to-point ATM connections, if the reservation agent creates a split/merge point at the ATM boundary and sets up only point-to-point VC connections to targets 🦋.

The CPCS-SDU parameters are AAL Parameters, which the AAL entity uses to break packets into cells. As such, the network doesn't modify these parameters, so they could conceivably be used for additional end-to-end signaling, along with the B-LLI 💜.

Finally, QoS Class is somewhat limited in its use and implementation 😮‍💨. While IP over ATM recommends use of Class 0 (Unspecified QoS), this isn't sufficient for guaranteed connections. Instead, Class 1 with CLP=0 will provide at least minimum QoS services for the traffic 🔥.

5.1 CPCS-SDU Size Computation 🌸

The CPCS-SDU size computation is the easiest QoS mapping 🥰. Since ST-2 doesn't require a Service Specific Convergence Sublayer (SSCS), if AAL 5 is used, the ST packet size plus 8 bytes (for the AAL 5 Trailer) will be the CPCS-SDU size. Note that the ST-2 packet size also includes an 8-byte header for ST-2. Thus the CPCS-SDU size is:

CPCS-SDUsize = PDUbytes + 8 + 8.

For ST-2+, the header is larger than it is for ST-2, so the CPCS-SDU size is:

CPCS-SDUsize = PDUbytes + 12 + 8.

5.2 PCR Computation 🧮

The Peak Cell Rate (PCR) computation is only slightly more complex 😅. The PCR will be the peak packet rate divided by the ATM payload size.

Since PDU rates in ST-2 are specified in tenths of packets per second, AAL 5 requires an 8 byte trailer, and the ATM payload size is 48 bytes, the computation for PCR goes like this ✨.

The requested maximum byte transmission rate for ST-2 is:

PDUbytes * PDUrate * 10.

Accounting for the AAL 5 and ST headers, the maximum byte rate is:

Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.

Translating into cells and eliminating the possibility of a fractional PDU:

PCR = ((PDUbytes + 8 + 8 + 48) / 48) * PDUrate * 10.

For ST-2+, not only is the header size 12 bytes, but the Rate is in messages per second, not tenths of packets per second. Thus, the PCR for ST-2+ is:

PCR = ((PDUbytes + 12 + 8 + 48) / 48) * PDUrate.

5.3 Maximum End to End Transit Delay. ⏱️

The End to End Transit Delay is a little more complex 🫣. The requested end to end delay must account for not only the PDU size requested by the user, but also the additional 8-byte AAL 5 header. The translation of the user-requested LimitOn Delay is preserved as long as the delay computation is based on the CPCS-SDU size instead of the PDU size 💅.

On top of the end to end delay introduced by the ATM network, there's additional delay created by the fragmentation of packets 🍓. Reassembly of these packets can only happen at the rate they're received. The time (in milliseconds) required to receive a cell (inter-cell arrival time) is:

T = 1000 / PCR.

The number of cells in a CPCS-SDU is:

C = (CPCS-SDUsize + 48) / 48.

Thus the delay for a packet is:

LimitonDelay = (C - 1) * T + MaxCellTransitDelay.

Therefore, the requested Maximum End to End Transit delay is:

MaxCellTransitDelay = Limiton Delay - (C-1) * T.

5.4 Maximum Bit Error Rate 🙈

Q.2931 signaling doesn't let you directly specify the requested bit error rate or a corresponding cell error rate 😤. Instead, this service is supposed to be offered through selection of QoS class.

Since these classes have few actual implementations at this time, there's no effective mapping for bit error rate 💀.

5.5 Accumulated Mean Delay 🧚

ST allows accumulation of the Mean Delay generated by each ST agent node and intervening circuits 🌈. With an ATM circuit, each agent should factor in the overhead of the ATM connection. The delay associated with the ATM circuit is reflected in the Q.2931 CONNECT message as the Cummulative Transit Delay. Since this is a cell-based computation, the delay experienced for an ST packet, including the CPCS-SDU header and ST header, is, as computed in Section 5.3:

Delay = (C - 1) * T + CummulativeTransit Delay.

5.6 Accumulated Delay Variance (Jitter) is where things get fun 🦋. Cell Delay Variance is not currently available as a Q.2931 parameter 🙈. So we can assume that the reassembly of cells into packets will be consistent, since the cell transmission rate should be constant for each packet. ✨ Except where a specific ATM service says otherwise, the ST agent should use its standard mechanisms for tracking packet arrival times, and then use that for Accumulated Delay Variance 💖.

6.0 Data Stream Transmission 🎀

Once virtual circuits for data transmission are established through one of the mechanisms described in section 4, the ST data must be transmitted over the connection 📨. RFC 1483 describes mechanisms for encapsulating packet transmissions over AAL5 🧚. LLC encapsulation could be used, but it is not necessary 🤷‍♀️. If it is used, the computations in section 5 should be redone to include the LLC headers in addition to the AAL5 trailer currently used 🧮. Those new values should then be substituted for the QoS values in the SETUP message 💅.

Instead, ST data packets can be encapsulated in standard AAL5 format with an 8 byte trailer and sent directly over the data virtual circuit 🌸. The mechanisms for computing the QoS values in the SETUP message are described in section 5 🫶.

7.0 Implementation Experience and Conclusions 👑

All of the signaling mechanisms described in Section 4 were implemented and tested in a mixed ATM network/routed LAN environment 🔥.

Initially it appeared that the best approach was to do signaling via IP over ATM or LANE 🤔. However, IP over ATM required IP encapsulation of the SCMP packets, and some applications use the accumulated values in the flowspecs. Those values are not guaranteed to be accurate in LANE and IP/ATM 💀. So using virtual circuits dedicated to SCMP signaling turned out to be the best implementation for taking full advantage of the ATM features ✨.

Also, the issue of mapping ATM address to E.164 NSAP addresses was resolved through an external signaling mechanism (the User Data field of the ST-2 CONNECT and ACCEPT messages) 🧩. It appears that ATM vendors need to implement a consistent addressing mechanism throughout their interfaces 📌.

From a performance point of view, using ST over ATM provided more than triple the performance of raw IP 😭🔥. The differences became increasingly clear as more simultaneous applications were run. ST got dedicated virtual circuits, while the IP traffic suffered and saw inconsistent performance over shared circuits 🙈. It got even more dramatic in mixed network environments, where all traffic shared the same LAN/router connections. When both IP and ST traffic were sent, the ST traffic maintained its quality, while the IP traffic saw increasing variation in performance 💅👑.

Clearly, using a connection-oriented, origin-oriented reservation protocol to provide consistent end-to-end guaranteed QoS and bandwidth in mixed ATM/internet environments is not only feasible. It results in dramatic performance and quality improvements for transmission of realtime traffic 🦋🌈.

8.0 Security Considerations 🔐

This memo raises no security considerations. However, with their connection-oriented and origin controlled natures, ST-2 and ST-2+ lend themselves to better internet security 🛡️. Discussion of this is beyond the scope of this document 💜.

9.0 References 📚

[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett Packard Laboratories, December, 1993.

[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration of Real-time Services in an IP-ATM network Architecture", RFC 1821, August 1995.

[3] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP Version 1 Functional Specification", Work in Progress, November 1995.

[4] Topolcic, C., "Experimental Internet Stream Protocol: Version 2 (ST-II)", RFC 1190, October 1990.

[5] DelGrossi, L., and L. Berger, "Internet STream Protocol Version 2+", RFC 1819, July 1995.

[6] V. Firoiu, R. Guerin, D. Kandlur, A. Birman "Provisioning of RSVP-based Services over a Large ATM Network', IBM T.J. Watson Research Center, October 1995.

[7] S. Damaskos, A. Anastassios Gavras, "Connection Oriented Protocols over ATM: A Case Study", German National Research Corporation for Mathematics and Data Processing (GMD) and Research Centre for Open Communications Systems (FOKUS), February 1994.

[8] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.

[9] M. Graf, T. Kober, H. Stuttgen, "ST-II over ATM Implementation Issues", IBM European Networking Center, October 1995.

10.0 Author's Address 💌

       Steve Jackowski
       NetManage Incorporated
       269 Mt. Hermon Road, Suite 201
       Scotts Valley, Ca 95066

       Phone:  (408) 439-6834
       Fax:    (408) 438-5115
       EMail:  Stevej@NetManage.com
📦 where this page comes from