RFC 1754

RFC 1754: IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 🎀

okay bestie, here's the header tea ☕ This is RFC 1754, written by M. Laubach from Com21, Inc. It's filed under the Network Working Group as Category: Informational, dated January 1995. The header doesn't list anything it obsoletes or updates, so no drama there 💅

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸

1. Abstract 💖

This doc is an early list of requirements sent to the ATM Forum's Multiprotocol BOF for running IP over ATM networks. The IETF IP over ATM Working Group and other working groups came up with the list. It's published for the community. Everything in here is accurate as of the publication date, but it can change, and later RFCs will show any changes 🦋

The content was sent by the IETF Liaison to the ATM Forum as contribution number 94-0954 in the ATM Forum's documentation process on 14 September 1994 🧚

2. Notice 🌸

This contribution was written to help the ATM Forum. It's being offered to the Forum as a starting point for discussion between the ATM Forum Multiprotocol BOF and the IETF. The statements can change in form and content after more study and discussion. Honestly, the IETF reserves the right to add to, amend or modify the statements in here 🙈

3. Introduction 💅

First, here's the charter from the IETF's IP over ATM Working Group (IPATM WG). It's included for the ATM Forum folks who might not know it yet 🎀

The IPATM WG is all about running internetworking protocols over Asynchronous Transfer Mode (ATM) networks. Its big goal is to produce standards for the TCP/IP protocol suite, plus recommendations that other internetworking protocol standards (like ISO CLNP and IEEE 802.2 Bridging) could use ✨

At first, the WG will develop experimental protocols for encapsulation, multicasting, addressing, address resolution, call set up, and network management, so internetwork protocols can run over ATM. It may submit these protocols for IETF standardization later 🦋

The WG will not develop physical layer standards for ATM, because other standards groups already cover that really well 💅

The WG will also build models of ATM internetworking architectures to guide the specific IP over ATM protocols 🌈

It will keep a list of technical unknowns about internetworking over ATM. That list will steer the WG's future work, or get sent to other standards or research groups when that makes more sense 🫶

The WG will coordinate with other relevant standards bodies (like ANSI T1S1.5) so it doesn't duplicate their work and its work fits in with everything else happening in this area. It will also pick among ATM protocol options (like choosing an adaptation layer) and make recommendations to the ATM standards bodies about what internetworking over ATM needs, wherever current ATM standards fall short 👑

Historically, a lot of IPATM WG participants work for companies that are principal members of the ATM Forum. Those people have been passing requirements between the two organizations informally. Now that the ATM Forum has its Multiprotocol BOF activities going, it's time to write down IETF requirements more formally 📝

At the July 1994 IETF meeting in Toronto, Canada, the ATM Forum Liaison, Drew Perkins, asked the IP over ATM Working Group to make a list of requirements as input for the ATM Forum's Multiprotocol BOF activities. This document is the answer to that request 💜

4. List of Requirements for Consideration 🌈

heads up bestie: this RFC is from 1995, before the capitalized BCP 14 key words were a thing, so its must, should, and may wording stays lowercase exactly as the original has it 🙈

4.1. Standardization & Logistics 💖

• Formal communications between the IETF and the ATM Forum should go through IETF <> ATM Forum Liaison(s), specific written communications (like this document), and/or presentations at official IETF or ATM Forum meetings.
• IETF standards define how the TCP/IP protocol suite is defined, deployed, and carried over specific network technologies, including ATM networks [1][2][8].
• Any formal communications that affect IETF standards or processes must be made publicly available, because the IETF is a public international standards body. Ideally, these communications are written as Internet Drafts [1], which is the IETF's version of incoming contributions 🎀
• We invite and encourage ATM Forum members to join the IETF standards process. See [1], [2], and [8] for info on how to participate 🫶

4.2. IPv4 Encapsulation 🦋

• RFC 1483 [3] and RFC 1577 [4] define how IP is encapsulated and carried over ATM networks. The IPATM WG asks that any ATM Forum Multiprotocol work support these standards as specified, and that any future changes to them go through the IETF standards process 💅

4.3. Routing ✨

• RFC 1577 defines the default Logical IP Subnet (LIS) model 🌸
• The IETF Routing over Large Clouds Working Group is developing the Next Hop Resolution Protocol. It allows routing (and subnets) to be optimized incrementally by sending datagrams over preferential ATM paths [9] 🧚
• The IETF IP over ATM Working Group will work on the next generation IP over ATM standards after RFC 1577 moves from draft to proposed status. Requirements to the ATM Forum are coming soon 👑
• ATM signaling should indicate whether a connection is over a LAN or WAN, and include feedback on time vs byte charging 💜

4.4. Security 🔥

• ATM signaling should support a user information element (IE) that is used to convey security and authentication information between IP members and applications. The IPATM WG would like to define the IP specific content of this IE 🔐

4.5. Broadcast and Multicast 🌈

• The IPATM WG is currently discussing models for how best to map IP multicast facilities onto ATM facilities. This work is still preliminary, but the IETF does support the ATM Forum's currently planned multicasting enhancements, like leaf-initiated joins and support for multiple multicast congestion management policies. A further list of requirements will come at a later time 🦋

4.6. Signaling and Addressing 💖

• The IPATM WG is currently producing a specification for using UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577. It will be published as an informational reference for UNI 3.0 signaling, and as a proposed standard for UNI 3.1 signaling once UNI 3.1 is ratified and officially published 📝
• IPv6 packets will include a Flow ID field intended to support service classes in some way. Until the semantics of this field are fully defined, it's hard to say much, but presumably a soft mapping between this and the VC to be used is desirable. A further list of requirements will come at a later time 🫶
• IPv6 addresses will be 16 bytes, and there will likely be a defined embedding of them inside 20-byte NSAP format. There will also likely be a mapping of US-GOSIP-like NSAPs into IPv6 addresses (deleting the unuseful bytes), but that is still controversial in the IPv6 discussions. A further list of requirements will come at a later time 💅

4.7. Quality of Service, Performance, and Traffic Management 👑

• ATM should support extremely bursty applications with significant elasticity in their bandwidth demands 🔥
• ATM should support elastic applications, as defined in RFC-1633 [7], very efficiently. That means enabling high bottleneck utilization while keeping delay reasonably bounded (i.e., doubling delay wouldn't be terrible for elastic apps). This should not come at the expense of delay sensitive classes of service 🌸
• ATM should provide a class of service that strives to cooperate with existing TCP congestion avoidance. This explicitly supports not only directly ATM-attached and -aware endstations, but also endstations on LANs (or using LAN Emulation) that run current TCP implementations and are interconnected via ATM-attached bridges and routers 🧚
• Predictive QoS should be supported in addition to guaranteed QoS, for applications that are somewhat tolerant of delay variation and low levels of loss ✨
• IP uses both point-to-point and point-to-multipoint (future) connections. To meet IP's needs, an ABR-like service would need to apply to both types of connections [6] 🦋
• No specification of minimum or maximum bandwidths by the ATM end-systems [6] 💜
• As simple as possible [6] 🎀
• Full line-rate transmission over otherwise-idle links [6] 🌈
• When end-to-end delay through the network is less than 1 second, the cell loss for AAL5 frames over an ABR-like service should be on the order of 3 in 10**8 cells for 1500 byte frames, or 3 in 10**9 cells for 18 Kbyte frames [6] 🫶

7. References 📚

okay bestie, here's the reading list 🧚 every single source this doc leans on, with all the details so you can go find them yourself 💖

• [1] IETF Secretariat and G. Malkin, "The Tao of the IETF - A Guide for New Attendees of the Internet Engineering Task Force", FYI 17, RFC 1718, CNRI, Xylogics, Inc., November 1994.
• [2] Internet Architecture Board, and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, IAB, IESG, March 1994.
• [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
• [4] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994.
• [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
• [6] McCloghrie, K., "Lan-Emulation's Needs for Traffic Management", ATM-Forum/94-0533, ATM Forum, June 1994.
• [7] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, USC/Information Sciences Institute, MIT, Xerox PARC, June 1994.
• [8] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 1720, USC/Information Sciences Institute, July 1994.
• [9] Malis, A., "Routing Over Large Clouds Liaison to the ATM Forum Multiprotocol BOF", ATM-Forum/94-0766, ATM Forum, September 1994.

---

8. IETF <> ATM Forum Liaison 💌

this is the contact for the IETF <> ATM Forum liaison, so if you need to reach the people bridging the two worlds, here's where to find them 🫶

Drew Perkins
FORE Systems, Inc.
174 Thornhill Road
Warrendale, PA 15086
Phone: (412) 772-6527
Fax:   (412) 772-6500
Email: ddp@fore.com

---

9. Author's Address 🖋️

and finally, the author! Mark Laubach, the brain behind all of this 💜

Mark Laubach
Com21, Inc.
2113 Landings Drive
Mountain View, CA 94043

Phone: (415) 254-5882
Fax:   (415) 254-5883
EMail: laubach@com21.com