RFC 2226

IP Broadcast over ATM Networks

📅 published October 1997, from ietf

RFC 2226: IP Broadcast over ATM Networks 🦋

okay so this one is by T. Smith (IBM Corporation) and G. Armitage (Lucent Technologies) 💅 it's a Standards Track doc from the Network Working Group, dated October 1997, and it's giving "how do we get broadcasts working over ATM" 🎀 it doesn't obsolete or update anything (the title block doesn't list anything).

Status of this Memo ✨

this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌈

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

Abstract 🌸

okay so the big idea: this memo explains how the IP multicast service being built by the IP over ATM working group can be used for IP broadcast 🦋 the move is to treat broadcast as a special case of multicast, where every host in the subnet or cluster is a member of the group. iconic 👑

you're expected to already know the services from RFC 2022 💅

1. Introduction ✨

so the IETF's first step for running IP over ATM is RFC 1577 [1] 🧚 it handles unicast between hosts and routers inside Logical IP Subnets (LISs), and it proposes a centralized ATM ARP Server that gives IP-to-ATM address resolution to LIS members 💖

two classes got left out: multicast and broadcast 😭 multicast means one transmit operation makes a packet get received by multiple remote destinations. broadcast typically means one transmit operation makes a packet get received by all IP hosts that are members of a particular 'subnet' 🍓

for multicast support (transmission to IP addresses in the Class D space) we get RFC 2022 ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] 🎀 it makes an analog of the RFC 1577 ARP Server called the MARS (Multicast Address Resolution Server). the MARS is a centralized registry and distribution mechanism for mappings between IP multicast addresses and groups of ATM unicast addresses. it also defines host behavior for setting up and managing point to multipoint VCs, based on what the MARS returns, when hosts want to send packets to a multicast group ✨

this memo is about how RFC 2022 can be used to fake IP broadcast inside Logical IP Subnets 🦋 real talk, the broadcast technique doesn't vibe well with ATM's point-to-point nature, but some apps still want broadcasts anyway 💀 for example, a client-server setup where the client looks for a server by sending out a broadcast, or routing protocols, most notably RIP 🧚

2. Review of Unicast and Multicast. 🌈

both unicast and multicast use the point-to-point and point-to-multipoint capabilities from the ATM Forum UNI 3.1 document [4] 💅

so for unicast, an IP address has a single ATM level destination 🎀 unicast goes over point to point Virtual Channels (VCs) between source and destination. the ARP Server holds the mappings between IP destination addresses and their ATM destination addresses. when a host wants a particular mapping, it sends an ARP_REQUEST to the ARP Server 🍓 the ARP Server answers with either an ARP_REPLY carrying the destination's ATM address, or an ARP_NAK if it can't resolve the address. if it works, the host sets up a VC to the destination interface, and that VC gets used to forward the first (and every later) packet to that IP destination 💖 RFC 1577 goes deeper on how hosts get grouped into Logical IP Subnets (LISs) and how the ARP Server sets up the first mappings for the LIS members it serves 🫶

multicast host behavior is kinda similar. the sender has to set up and manage a point to multipoint VC whose leaf nodes are the group's actual members 😭 under UNI 3.1, only the source (root) interface can set up and change these VCs 👑

the MARS is an upgrade of the ARP Server model and does two key jobs ✨

the first job is keeping a list of the ATM addresses for each group's members 💜 that list comes from a host registration process with two messages: a MARS_JOIN, which says a host wants to join the specified group(s), and a MARS_LEAVE, which says a host wants to leave the specified group(s) 🦋

MARS_JOIN and MARS_LEAVE messages also get passed along to all group members, so active senders can adjust their point to multipoint VCs to match 🌸

the second job is handing out group membership info (basically what the ARP Server does for unicast mappings) 🧚 when a host has to send an IP packet with a Class D destination address, it sends a MARS_REQUEST to the MARS 🍓 if the group has members, the MARS replies with a MARS_MULTI (maybe in multiple segments) carrying a set of ATM addresses. the host then sets up an initial point to multipoint VC using those ATM addresses as the leaf nodes 💖 if the MARS had no mapping, it returns a MARS_NAK 💀

(RFC 2022 also covers how the MARS can set up Class D groups using either multicast servers, or meshes of point to multipoint VCs from host to host. from the host's side though, that's invisible, and it isn't the main point for IP broadcast support 🙈)

this memo explains how a host can use the registration and group management functions in an existing MARS based IP/ATM network to fake IP broadcasts 🎀

3. Broadcast as a special case of Multicast. 🦋

lowkey a lot of the problems you hit building a broadcast solution also show up when building a multicast solution 🫶 in fact, broadcast can be seen as a special case of multicast. broadcast is just a multicast group whose members include all the members in the LIS ✨

there are two broadcast groups this memo covers 💅

  1. 255.255.255.255 - "All ones" broadcast
  2. x.z - CIDR-prefix (subnet) directed broadcast

broadcast (1) is sometimes called a limited broadcast to this physical network 🌈 broadcast (2) is the broadcast for subnets or networks in the old paradigm 👑 per [6] and [7], the whole subnets-and-networks idea is being replaced by Classless Inter-Domain Routing, which uses routing address space more efficiently 🧚 the CIDR-prefix (x) is the combo of an IP address and a subnet mask that names the subnet number. the host portion (z) is all ones 🍓 these broadcasts have different scopes at the IP or network layer, but they have exactly the same scope at the link layer 😭 namely, every LIS member gets a copy 💖

these addresses can be used in two situations 🎀

  • broadcasting to all members of a given LIS where a priori knowledge of a host's IP address and subnet mask is known (e.g. the CIDR-prefix directed broadcast)
  • broadcasting to all members of a physical network without knowing a host's IP address and subnet mask (e.g. the all ones broadcast)

on a broadcast medium like Ethernet, both situations end up at the same physical destination 🦋 every station on that network gets the broadcast, even if they're on different logical subnets or they aren't IP stations at all ✨ ATM is different though 💀 since ATM is non-broadcast, a registration process has to happen first 😭 and if some stations register for some broadcast groups but not others, the broadcast groups end up with different memberships 🙈 and then the idea of "broadcast" gets super inconsistent 🫠

one case that needs the all ones broadcast is a diskless boot, or bootp client 🧚 the host boots up and doesn't know its own IP address or subnet mask 💖 obviously it doesn't know which subnet it's on 🌸 so to send a broadcast to its bootp server, the diskless workstation has to use the group that has no subnet info, i.e. the 255.255.255.255 broadcast group 🎀 going a bit further: once the bootp server gets that broadcast, it can not send back either a directed frame or a subnet directed broadcast to answer the diskless workstation 😭 instead, the bootp server MUST also use the 255.255.255.255 group to talk to the client 💅

the all ones broadcast is required at the IP layer, and it also matters at the link layer when deciding which broadcast group to register with in MARS 🦋 so a bootp client that wants a link layer broadcast can only register for 255.255.255.255 in the MARS address space, since its subnet is unknown at that point 🌈 since some apps have to use the all ones address in MARS for their broadcast group, and we want to keep the number of broadcast groups LIS members use to a minimum ✨ the all ones group in MARS MUST be used by all members of the LIS when registering to receive broadcast transmissions 🫶 the VCC used for transmitting any broadcast packet is based on the members registered in the MARS under the 255.255.255.255 address position 💜 from here on in this memo, that VCC is called the "broadcast channel" 🦋

to be continued! part 2 is coming bestie 🧚💖

4. The MARS role in broadcast. 🎀

Okay so there are a bunch of ways people have tried to solve broadcast, and they're listed in Appendix A 🧚. This memo zeroes in on one MARS solution that honestly seems to handle the broadcast problem the best 💅.

There are some MARS architecture traits that absolutely have to stay intact ✨:

  • MARS doesn't know anything about subnet prefixes or subnet masks. Each group address registered with MARS gets managed on its own 🌸.
  • A MARS can only serve one LIS 🦋. This keeps the broadcast group 255.255.255.255 joined only by hosts from one LIS, so its scope stays the conventional one 🔥.
  • The Multicast Server (MCS) described in [2] can handle the broadcast groups in this memo without any changes 💖. It also cuts down on how many channels the network uses ✨.

The MARS doesn't need any extra code or special algorithms to resolve IP broadcast addresses 🙌. It's basically just a general database holding {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and it doesn't care what type or length the 'Protocol address' is 🧠. Whether hosts see it as Class D, as 'broadcast', or even as IP is purely a host-side thing 💅.

Endpoints will probably want to use this IP broadcast emulation so they can find out their own IP address at boot time 🍓. That means the MARS should NOT expect to see both the IP source and ATM source address fields of the MARS_JOIN filled in 🙈. Honestly that makes sense, because only the ATM source address gets used when an endpoint registers as a group member 💜.

The MARS architecture is enough to keep the broadcast group list intact without changing anything 🫶.

5. Host Requirements for Broadcast.

Here's a list of extra traits a MARS-compliant host has to have to actually use the broadcast function 📋. These are required, babe 💅:

  • A host must register as a MARS client.
  • A host, soon after registration MUST issue a MARS_JOIN to the all ones broadcast address (i.e. 255.255.255.255) with the mar$flags.layer3grp reset 🦋.
  • When transmitting packets, the host should map all IP layer broadcasts to the VCC (broadcast channel) created and maintained based on the all ones entry in MARS ✨.
  • A host MUST monitor the MARS_JOIN/MARS_LEAVE messages for 255.255.255.255 to keep the broadcast channel current 👀.
  • A broadcast channel should be torn down after a period of inactivity 😴. The corresponding timeout period MAY be specified with a minimum value of one minute, and a RECOMMENDED default value of 20 minutes ⏰.

Okay, so you should note that while every member taking part in the broadcast MUST be a member of the all ones group, not every member is going to actually send broadcast info 🙃. Some members will only ever listen passively 👂. So in a LIS with n stations, there might be fewer than n channels terminated at each station for broadcast info 🌈. You can cut it down even more by adding a Multicast Server (MCS) to the broadcast environment, which could drop the number of VCs to two (one incoming, one outgoing), or to just one for a station that only wants to listen 🎧.

Broadcasting in this environment can seriously tax the resources of the network and the hosts using it 💀. So an implementer MAY choose to provide a way to retract the host's entry in the broadcast group, either after it's been established or before joining 🧹. The MARS_LEAVE is used to request withdrawal from the group if the host wants to turn off broadcast reception after joining 🚪. The default behavior SHALL be to join the all ones broadcast group in MARS 👑.

6. Implications of IP broadcast on ATM level resources. 🌸

RFC 2022 talks about some of the consequences that large multicast groups have for ATM level resources, both inside the network and inside end station ATM interfaces 🧚‍♀️.

The default mechanism is for IP multicasting to be done with meshes of point to multipoint VCs, going directly from the source host to the group members 🕸️. In certain situations, system administrators can redirect multicast traffic through ATM level Multicast Servers (MCSs), in a way that's completely transparent to end hosts 🫣. This can be done on an individual group basis ✨.

It's enough to note here that the IP broadcast 'multicast group' will be the biggest consumer of VCs in your ATM network whenever it's active 💥. That's why it'll probably be the first multicast group to get one or more ATM MCSs assigned to support it 🥇. There's nothing unique about an MCS assigned to support IP broadcast traffic though, so this memo won't go into it any further 🤷‍♀️. RFC 2022 has more on how multiple MCSs could be used for fault-tolerant architectures 🛡️.

7. Further discussion. 💬

On the ip-atm forum there was a big discussion about "auto configuration" and "diskless boot" 🗣️. This memo describes a broadcast solution that needs MARS. So at a minimum, the ATM address of the MARS must be manually configured into a diskless workstation 🔧. People have proposed things like universal channel numbers and universal ATM addresses, but no agreement has been reached yet 🤞.

Another topic is multiprotocol support 🌈. MARS is designed to be protocol independent 🧩. This memo specifically covers the IP broadcast case and figures out which addresses work best in the IP address space 📍. But the principles apply to any layer 3 protocol, so more work should be done to find suitable addresses for other layer 3 protocols 🔍.

Finally, there's been support for a link layer broadcast that would be independent of the layer 3 protocol 🧃. Such a solution might give a simpler set of rules for how broadcast applications get used 📘. Some solutions also make more efficient use of VCCs too 💫.

Security Considerations 🔐

This memo covers one specific use of the MARS architecture and its components to provide the broadcast function 🎯. Because of that, the security implications are no greater or less than those of using any of the other multicast groups available in the multicast address range 🛡️. If security enhancements are ever needed, they would have to be added as an extension to the base architecture in RFC 2022 🚨.

Acknowledgments 🫶

The apparent simplicity of this memo owes a lot to the services provided in [2], which is itself the product of lots of discussion on the IETF's IP-ATM working group mailing list 💖. Grenville Armitage worked on this document while at Bellcore ✨.

References 📚

  • [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, December 1993.
  • [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1995.
  • [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
  • [4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
  • [5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
  • [6] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
  • [7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997.

Authors' Addresses 🧑‍💻

Timothy J. Smith
Network Routing Systems,
International Business Machines Corporation.
N21/664
P.O.Box 12195
Research Triangle Park, NC 27709

Phone: (919) 254-4723
EMail: tjsmith@vnet.ibm.com


Grenville Armitage
Bell Labs, Lucent Technologies.
101 Crawfords Corner Rd,
Holmdel, NJ, 07733

EMail: gja@lucent.com

Appendix A. Broadcast alternatives 🦄

Throughout the development of this memo, a bunch of alternatives got explored and then ditched for one reason or another 🗑️. This appendix documents those alternatives and why they weren't picked 📝.

A.1. ARP Server Broadcast Solutions. 🖥️

The ARP Server is a strong candidate for supporting broadcasting 💪. There's an ARP Server for every LIS, and it holds the entire LIS membership 🗂️. Those are the fundamental ingredients the broadcast function needs 🧱.

A.1.1. Base Solution without modifications to ARP Server. 🙂

You could start with what's already in RFC 1577 and nothing else 🧃. A host can easily work out the range of members in its LIS from its own IP address and subnet mask 🧮. It can then send an ARP Request for every member of the LIS 📨. With that info, the host can set up point-to-point connections with all members, or set up a point-to-multipoint connection to all of them 🔗. Easy peasy, the poor man's broadcast 🥲.

This solution is super straightforward, but it has a bunch of problems 😬:

  • The load on the ARP Server is very large 📈. If every station on a LIS decides to do broadcasting, the initial surge of ARP Requests would be huge 🌊. Some kind of slow start sequence would be needed 🐢.
  • The amount of resources required makes this a non-scalable solution 🚫. The authors believe broadcasting will need an MCS to reduce the number of channel resources required to support each broadcast 'group' 🧠. Using the ARP Server this way doesn't let an MCS get introduced transparently 🙅‍♀️. (Basic RFC1577 interfaces also don't implement the extended LLC/SNAP encapsulation required to safely use more than one MCS 🫠.)
  • The diskless boot solution can't function in this environment, because the host may be unable to figure out which subnet it belongs to 💔.

A.1.2. Enhanced ARP Server solution. 🧩

This solution is similar to the base solution, except it takes some of the (MARS) multicast solution and embeds it in the ARP Server 🪄. The first enhancement is adding the MARS_MULTI command to the set of opcodes the ARP Server supports 🆕. That would let a host issue a single request and get back the list of members in one or more MARS_REPLY packets 📬. Instead of a registration mechanism, the ARP Server could just use the list of members that have already registered 📋. When a request comes in for the subnet broadcast address, the ARP Server would aggregate the list and send the results to the requester 🎁.

This suffers from two drawbacks 👇:

  1. Scalability with regard to number of VCs is still an issue 📉. You'd eventually need to add some sort of multicast server solution to the ARP Server 🛠️.
  2. The diskless boot scenario is still broken 😭. There's no way for a station to perform a MARS_MULTI without first knowing its IP address and subnet mask 🙃.

The diskless boot problem could be solved by adding a registration process to the ARP Server, where anyone could register to the 255.255.255.255 address 🔓. But those changes would make the ARP Server look more and more like MARS 🪞✨.

A.2. MARS Solutions ✨

okay so if we want to keep the ARP Server unchanged like RFC 1577 describes, the other option is the Multicast Address Resolution Server (MARS) from [2] 🧚

MARS has three features that are super useful for broadcasting 💖

  1. It has a generalized registration approach, which means any address can have a group of entities registered to it. So if the subnet address isn't known, a host can register for an address that is known, like 255.255.255.255. 🎀
  2. The command set lets lists of members get passed in a single MARS_MULTI packet. This reduces traffic 📉
  3. MARS has an architecture for dealing with scalability issues. Multicast Servers (MCSs) may be used to set up the point-to-multipoint channels, and they reduce the number of channels a host needs to set up to just one. Hosts that want to broadcast send the packet to the MCS instead, and then the MCS forwards it to all members of the LIS. ✨

A.2.1. CIDR-prefix (Subnet) Broadcast solution 🌸

One of the earliest ideas was to just say broadcast support would be implemented by using a single multicast group in the class D address space, namely the CIDR-prefix (subnet) broadcast address group. All members of a LIS would be required to register to this address and use it as required. A host that wants to use either the 255.255.255.255 broadcast or the network broadcast address would internally map the VC to the subnet broadcast VC. The all ones and network broadcast addresses would exist on MARS, but they'd be unused 🙈

The problem with this approach goes back to the diskless workstation problem. Because the workstation may not know which subnet it belongs to, it doesn't know which group to register with. bestie, that's a real vibe check 💀

A.2.2. All one's first, subnet broadcast second 🦋

This solution admits that the diskless boot problem needs a generic address (one that doesn't contain CIDR-prefix (subnet) information) to register with and to use until subnet knowledge is known. Basically, all stations first register to the 255.255.255.255 group. Then, once they know their subnet information, they could optionally de-register from the all ones group and register to the CIDR-prefix (subnet) broadcast group. 👑

This solution looks like it solves a couple of problems:

  1. The bootp client can function if the server stays registered to the all ones group continuously.
  2. There is less traffic using the all ones group, because the preferred transactions will be on the subnet broadcast channel.

Unfortunately, the first point has a flaw 😭 The server must continually be registered to two groups, the all ones group and the subnet broadcast group. If this server has multiple processes running different IP applications, it may be difficult for the link layer to know which broadcast VC to use. If it always uses the all ones group, then it will be missing members that have removed themselves from the all ones group and registered to the subnet broadcast group. If it always uses the subnet broadcast group, the diskless boot scenario gets broken. While making the decision at the link layer may require additional control flows to be built into the path, it may also require rewriting application software.

In some implementations, a simple constant is used to tell the link layer that this packet is to be transmitted to the broadcast "MAC" address. The assumption is that the physical network broadcast and the logical protocol broadcast are one and the same. As pointed out earlier, this is not the case with ATM. So applications would need to specifically identify the subnet broadcast group address to take advantage of the smaller group. 🌈

These problems could be solved in a number of ways, but it was thought that they added unnecessarily to the complexity of the broadcast solution. Honestly, valid choice imo. 💅

Appendix B. Should MARS Be Limited to a Single LIS? 🧚

RFC 2022 explicitly states that a network administrator MUST ensure that each LIS is served by a separate MARS, creating a one-to-one mapping between cluster and a unicast LIS. But it also mentions that relaxation of this restriction MAY occur after future research warrants it. This appendix discusses some of the potential implications to broadcast should this restriction be removed. 🔥

The most obvious change would be that the notion of a cluster would span more than one LIS. Therefore, the broadcast group of 255.255.255.255 would contain members from more than one LIS. 👀

It also should be emphasized that the one LIS limitation is not a restriction of the MARS architecture. Rather, it is only enforced if an administrator chooses to do so. So it's a choice, not a rule baked into MARS. iconic 🫶

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🦋

📦 where this page comes from