RFC 1680

IPng Support for ATM Services 🦋

okay bestie, this is RFC 1680 💖 it's Request for Comments: 1680, written by C. Brazdziunas at Bellcore and dated August 1994. it's in the Informational category, and its header doesn't list anything it obsoletes or updates. it lives in the Network Working Group 🧚 the whole doc is about how IPng should work with ATM services ✨

Status of This Memo 💖

so this memo is just here to inform the Internet community 📚 it does not specify an Internet standard of any kind, so don't go treating it like one 💀 distribution is unlimited, so share it wherever 🌈

Abstract 🎀

this doc was submitted to the IETF IPng area as a response to RFC 1550 💌 publishing it doesn't mean the IPng area agrees with any of the ideas inside 🙈 comments should go to the big-internet@munnari.oz.au mailing list 📬

Executive Summary 👑

so this white paper covers the engineering considerations for IPng, which RFC 1550 [1] asked for 💜 the big idea is that IPng should support both the link technologies that exist now and the new ones it'll be carried over. like, Ethernet just mashes up traffic from upper layer protocols onto one single channel 😭 but "sophisticated" link techs like ATM are showing up in the market and let several virtual channels run over one wire (or fiber), potentially picked based on an application's network performance objectives 🔥

we need support for both the sophisticated (ATM) and the existing link techs in any IPng candidate 🫶 end-to-end apps will talk across a network where IPng packets go over Ethernet and Hippi, and also over sophisticated link levels like ATM. starting out, IPng over ATM subnetworks won't do a virtual circuit per application, but the hooks for that mapping should be in place, while still keeping IPng packets working across conventional subnetworks ✨ app support for QOS-based link level service needs these types of ATM info to be mappable (or derivable) from higher level protocols like IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and the ATM virtual circuit identifier 🌸 some of this might be derivable from info provided by proposed resource reservation protocols for an integrated services Internet [4], but the ATM virtual circuit identifier should be efficiently derivable from IPng packet information 👑

an IPng candidate should show evidence that mapping an app's IPng packets to ATM virtual circuit(s) can work in a heterogeneous Internet architecture 🚀 it also has to keep in mind the gigabit/sec rates that IPng/ATM subnetworks will eventually be running at ⚡

1. Introduction ✨

this paper describes the parameters needed to map IPng (or any protocol operating above the link level) to ATM services 💖 ATM is a sophisticated link level tech that gives TCP/UDP-level apps the potential to map to a single ATM virtual circuit for transport across ATM network(s), customized to that app's network performance and traffic needs 🦋 that's a big step up from lots of today's link techs, which can only support one level of network performance, shared by every app on a single endpoint 😤

the future Internet will be a mix of conventional and sophisticated link techs 🌈 sophisticated link layer features like ATM need to be built into an internet where data travels across ATM but also across a bunch of other LAN and WAN techs. future networks will likely be a combo of best-effort link level subnetworks like Ethernet and sophisticated subnetworks that can support quality of service-based connections like ATM 💅 picture data starting on an Ethernet, passing through an ATM network, then an FDDI network, another ATM network, and finally arriving at its destination on a HIPPI network 😭 IPng packets will travel through that whole chain of interconnected network techs as ATM becomes one of the components of the future Internet 🧚

to support per-application customizable link level connections, four types of ATM info should be derivable from higher level protocols like IPng 🎀 this info includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier that maps to a single IPng application (i.e., a single TCP/UDP application). some of these mappings could potentially be derivable through info from proposed resource reservation protocols supporting an integrated services Internet [4]. however, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information 💜

the organization of this white paper goes like this 🗺️ first, the characteristics of ATM are described, focusing on functions not provided by today's LAN technologies. that section gives the background needed for the next one, which covers the parameters needed to map IPng services to ATM services 🌸

2. Terminology 🌸

in this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack 💅 for example, each instance of a "telnet" or "ftp" session running on an end station is a distinct application 🫶

3. Characteristics of ATM Service 🔥

ATM has several characteristics that set it apart from current link level techs 😤 first of all, ATM can provide many virtual channels to transmit info over a single wire (or fiber) 🦋 this is very similar to X.25, where many logical channels can be established over a single physical media. but unlike X.25, ATM lets each of these channels or circuits have a customizable set of performance and quality of service characteristics 💖 link level techs like Ethernet give you a single channel with a single performance and quality of service characteristic. so in a sense, a single ATM link level media looks like an array of link level techs, each with customizable characteristics 🌈

ATM virtual circuits can be established dynamically using its signaling protocol 🧚 ATM signaling is a source-initiated negotiation process for connection establishment 💌 this protocol tells elements in the network about the characteristics of the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether they can accept a call, or where a signaling request should be forwarded if the end destination (from the link level perspective) hasn't been reached 💀 in short, ATM signaling doesn't support any routing functionality or network admission control 🙃

ATM signaling establishes a "hard state" in the network for a call ✨ "hard state" means the state of a connection in intermediate switching equipment can be set, and once it's established it'll be maintained until a message is received by one of the ends of the call asking for a change in the connection's state [2]. so an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) gets guaranteed service from the ATM network 👑 the ATM network is responsible for maintaining the connection state 🫶 the price the ATM termination points pay for that guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear down the connection 😭

each ATM endpoint in a network has an ATM address associated with it to support dynamic connection establishment via signaling 🎀 these addresses are hierarchical in structure and globally unique [3]. as a result, these addresses are routable 🦋 this allows ATM networks to eventually support a large number of ATM endpoints, once a routing architecture and protocols to support it become available 🌸

the ATM User-Network Interface (UNI) signaling protocol, based on ITU-TS Q.93B, allows many different service parameters to be specified for describing connection characteristics [3] 💅 these parameters fall into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector 🧚 AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. network QOS objectives describe the service the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user: circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. each of these categories is further specified through network provider objectives for various ATM performance parameters, which may include cell transfer delay, cell delay variation, and cell loss ratio 💜

the connection traffic descriptor specifies characteristics of the data generated by the user of the connection 🔥 this info lets the ATM network commit the resources needed to support the traffic flow with the quality of service the user expects 😤 characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. lastly, the transit network selection parameter lets an ATM user select a preferred network provider to service the connection [3] 👑

4. Parameters Required to Map IPng to ATM 🦋

there are several parameters required to map ATM services from a higher level service like IPng ✨ these ATM parameters can be categorized as: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier 💖 the first three categories support ATM signaling. the last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, supports an ATM virtual circuit per application when the end-to-end connection travels across an ATM subnetwork(s) (this doesn't assume ATM is the only type of subnetwork that the connection travels across) 🧚 below, mapping issues for each of these parameters will be described 🌈

4.1. Addressing 💅

ATM supports routable addresses for each ATM endpoint to facilitate dynamic establishment of connections 🦋 these addresses need to be derived from a higher level address, such as an IPng address, and IPng routing information 🫶 this type of mapping isn't new. it's a mapping that's currently done to support current IP over link technologies like Ethernet 🙃 an IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5] 💜 in addition, support for IP routing over large ATM networks is being worked on in the IETF's "Routing over Large Clouds" working group 🌸

4.2. Quality of Service 💅

Okay so, like we covered in section 3, an ATM virtual circuit gets set up based on a user's traffic characteristics and network performance objectives 🦋. The catch is that stuff like delay and throughput requirements can only be defined at the application level (transport or above), not at the internetworking (IPng) level 🙈. A file transfer moving a 100 MB file needs totally different link level performance than a network time app. The file transfer needs high throughput and a low error rate ✨, while the network time app could honestly be fine with a best-effort service 💀.

Current IP doesn't really offer much quality of service specification, and it gives zero support for an app to specify its link level performance needs directly 😭. Why? Link technologies like Ethernet only come with one type of link level performance, so every app over IP today gets the exact same link service. Main character energy? Nope, everyone's an extra rn 💀.

IPng packets don't need to explicitly carry info describing an app's traffic characteristics and network performance objectives (e.g., delay = low, throughput = 10 Mb/s) 🧚. That info could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4].

4.3. Connection Management 🎀

The establishment and release of ATM connections should ultimately be controlled by the apps using the circuits 👑. As covered in section 3, ATM signaling creates a "hard state" in the network, which is controlled by the ATM termination points [2]. Right now IP has no explicit mechanism for link level connection management 🙈. Future support for it could come through resource reservation protocols, and it doesn't necessarily need to be handled directly by info inside the IPng protocol itself 💅.

4.4. Connection Identifier 🦋

A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits 🌸. Right now, app traffic flows get identified at the transport level by UDP/TCP source and destination ports plus IP protocol identifiers. This level of identification should also be available at the IPng level, so the info in IPng packets can identify an app's flow and map to an ATM virtual circuit that supports that flow when the IPng packets travel across ATM subnetwork(s) 💖.

Identifying an application's traffic flow with the current IP protocol takes a combo of five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and the IP protocol identifier 😵. This application connection identifier for IP is complex, and it could potentially be costly to implement in IP end stations and routers 🥲. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet 🫶.

Currently, ATM gives you 24 bits for virtual circuit identification (VPI and VCI) ✨. That's enough room for 2^24 (16,777,216) connections [6]. The actual number of bits used for the ATM virtual circuit, however, is set through negotiation between the ATM endpoint and the ATM network. This number is useful as an upper bound for the number of mappings that need to be supported by IPng 🧚.

An IPng candidate should be able to show how IPng packets from an application can map to an ATM virtual circuit 🔥. On top of that, this mapping should be big enough to support a mapping for every IPng application on an end system to an ATM virtual circuit 👑. Careful consideration should be given to the complexity of this mapping for IPng to ATM, since it eventually needs to handle gigabit/sec rates 🚀.

---

References 📚

[1] Bradner, S., and A. Mankin, "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, Harvard University, NRL, December 1993.

[2] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August 1988.

[3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993.

[4] Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Work in Progress, October 1993.

[5] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994.

[6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993.

Security Considerations 🔐

Okay bestie, this part is short and kinda dramatic 😭. The memo says:

Security issues are not discussed in this memo.

Author's Address 🎀

Christina Brazdziunas

Bellcore

445 South Street

Morristown, NJ 07960

Phone: (201) 829-4173

EMail: crb@faline.bellcore.com 💌