RFC 966

Host groups: A multicast extension to the Internet Protocol

📅 published December 1985, from ietf

RFC 966: Host Groups, A Multicast Extension to the Internet Protocol 🎀✨

Okay bestie, this one is from December 1985, and it's giving pure OG internet energy 🦋. It was written by S. E. Deering and D. R. Cheriton, both at Stanford University 🎓. The header doesn't list a category, and it doesn't say what it obsoletes or updates, so there's no drama there 💅.

1. Status of this Memo ✨

Okay so this memo defines a model of service for Internet multicasting, and it proposes an extension to the Internet Protocol (IP) to support that multicast service 🌈. They're literally asking for discussion and suggestions for improvements, and distribution is unlimited 💜.

2. Acknowledgements 🫶

This memo was adapted from a paper [7] presented at the Ninth Data Communications Symposium. The work was sponsored in part by the Defense Advanced Research Projects Agency under contract N00039-83-K-0431 and National Science Foundation Grant DCR-83-52048 💖.

The Internet task force on end-to-end protocols, headed by Bob Braden, gave valuable input on the development of the host group model 🧚.

3. Introduction 💜

In this paper, they describe a model of multicast service they call host groups 🍓 and propose it as a way to support multicast in the DARPA Internet environment [14]. The argument is that it's feasible to build this as an extension of the existing "unicast" IP datagram model and mechanism 👑.

Multicast is the transmission of a datagram packet to a set of zero or more destination hosts in a network or internetwork, using a single address that specifies the set of destination hosts. For example, hosts A, B, C and D may be associated with multicast address X. When transmitted, a packet with destination address X is delivered with datagram reliability to hosts A, B, C and D 💅.

Multicast has two primary uses: distributed binding and multi-destination delivery. As a binding mechanism, multicast is a robust and often more efficient alternative to name servers for finding a particular object or service when a particular host address isn't known. For example, in a distributed file system, all the file servers may be associated with one well-known multicast address. To bind a file name to a particular server, a client sends a query packet containing the file name to the file server multicast address, for delivery to all the file servers. The server that recognizes the file name then responds to the client, allowing subsequent interaction directly with that server host 🫶. Even when name servers are employed, multicast can be used as the first step in the binding process, which is finding a name server 🔍.

Multi-destination delivery is useful to several applications, including:

  • distributed, replicated databases [6,9].
  • conferencing [11].
  • distributed parallel computation, including distributed gaming [2].

Ideally, multicast transmission to a set of hosts isn't more complicated or expensive for the sender than transmission to a single host. Similarly, multicast transmission shouldn't be more expensive for the networks and gateways than traversing the shortest path tree that connects the sending host to the hosts identified by the multicast address 🌸.

Multicast, transmission to a set of hosts, is properly distinguished from broadcast, transmission to all hosts on a network or internetwork. Broadcast isn't a generally useful facility, since there are few reasons for communicating with all hosts 🙈.

A variety of local network applications and systems make use of multicast. For instance, the V distributed system [8] uses network-level multicast for implementing efficient operations on groups of processes spanning multiple machines. Similar use is being made for replicated databases [6] and other distributed applications [4]. Providing multicast in the Internet environment would allow porting such local network distributed applications to the Internet, as well as making some existing Internet applications more robust and portable (by, for example, removing "wired-in" lists of addresses, such as gateway addresses) 🎀.

At present, an Internet application that logically requires multicast must send individually addressed packets to each recipient. There are two problems with this approach. Firstly, requiring the sending host to know the specific addresses of all the recipients defeats its use as a binding mechanism. For example, a diskless workstation needs, on boot, to determine the network address of a disk server, and it's undesirable to "wire in" specific network addresses. With a multicast facility, the multicast address of the boot servers (or name servers that hold the addresses of the boot servers) can be well-known, allowing the workstation to transmit its initial queries to this address 💖.

Secondly, transmitting multiple copies of the same packet makes inefficient use of network bandwidth, gateway resources and sender resources. For instance, the same packet may repeatedly traverse the same network links and pass through the same gateways. Furthermore, the local network level can't recognize multi-destination delivery to take advantage of multicast facilities that the underlying network technologies may provide. For example, local-area bus, ring, or radio networks, as well as satellite-based wide-area networks, can provide efficient multicast delivery directly. Besides using excessive communication resources, the use of multiple transmissions to effect multicast severely limits the amount of parallelism in transmission and processing that can be achieved compared to an integrated multicast facility 😭.

The next section describes the host group model of multicast service. Section 5 describes the extensions to IP that support the host group model. Section 6 discusses the implementation of multicast within the networks and gateways making up the Internet. Section 7 relates this model to other proposals. Finally, they conclude with remarks on their experimental prototype implementation of host groups and comments on future directions for investigation 🌈✨.

4. The Host Group Model ✨

okay so the Internet already has this huge name space of individual host addresses 🌸. The host group model is like, "what if one address could point at a whole GROUP of hosts?" 💅 A host group is a set of zero or more Internet hosts <1>. Yes, zero. A group can be empty 🙈. When an IP packet gets sent with a host group address as its destination, it's delivered with "best effort" datagram reliability to all members of that host group 🦋.

The sender doesn't have to be a member of the destination group. We call that an open group, as opposed to a closed group, where only members are allowed to send to it. We went with open groups because they're more flexible and more consistent as an extension of conventional unicast models, even though they may be harder to implement 🧚.

Dynamic management of group membership gives you flexible binding of Internet addresses to hosts 💖. Hosts can join and leave groups over time. A host can also belong to more than one group at once. And a host may belong to no groups at times, and during those times it's unreachable within the Internet architecture 💀. A host doesn't even need an individual Internet address. Some hosts may only be associated with multi-host group addresses. For example, there might be no reason to contact one particular time server on the Internet, so time servers wouldn't need individual addresses ⭐.

Internet addresses get dynamically allocated for transient groups, which often last only as long as a single distributed program is running 🎀. There's also a range of host group identifiers reserved for permanent groups. One use of permanent host group identifiers is for groups with standard logical meanings, like "name server group", "boot server group", "Internet monitor group", and so on 👑.

Right now in the Internet architecture, addresses are bound to single hosts. The host group model generalizes that. One address can bind to multiple hosts on multiple networks, more than one address can be bound (in part) to one host, and the binding of an address to a host can be dynamic, meaning it can be modified under application control 🌈. Within this more general model, the current architecture is still supported as a special case, keeping its current semantics and implementation. slay 💅✨

Here's a closer look at the model in the subsections below 🫶.

4.1. Host Group Management

Dynamic binding of Internet addresses to hosts is handled by three operations that are made available to clients of the Internet Protocol <2> 🎀:

CreateGroup ( type ) --> outcome, group-address, access-key

This requests the creation of a new transient host group with the invoking host as its only member. The type argument says whether the group is restricted or unrestricted. A restricted group limits membership based on the access-key. Only hosts presenting a valid host access-key are allowed to join. All unrestricted host groups have a null access-key. outcome tells you whether the request was approved or denied. If it's approved, a new transient group address comes back in group-address. access-key is the protection key (or password) associated with the new group. This should fail only if there are no free transient group addresses 🔒.

JoinGroup ( group-address, access-key ) --> outcome

This requests that the invoking host become a member of the identified host group, whether it's permanent or transient. outcome tells you whether the request was approved or denied. A request is denied if the access key is invalid 🚫.

LeaveGroup ( group-address ) --> outcome

This requests that the invoking host be dropped from membership in the identified group, permanent or transient. outcome tells you whether the request was approved or denied 👋.

There's no operation to destroy a transient host group, because a transient host group is considered to no longer exist once its membership goes to zero 🌙.

Permanent host group addresses are allocated and published by Internet administrators, the same way well-known TCP and UDP port numbers are. In other words, they're published in future editions of the "Assigned Numbers" document [17] 📖.

4.2. Packet Transmission

Transmission of a packet in the host group model is controlled by two scope parameters. One is the destination internetwork address, and the other is the "distance" to the destination host(s). Specifically, there's:

Send ( dest-address, source-address, data, distance )

This transmits the specified data in an internetwork datagram to the host(s) identified by dest-address that are within the specified distance. So the destination address works much like it does on conventional networks, except delivery might go to multiple hosts. The distance parameter needs a bit more discussion 🧭.

Distance can be measured in several ways, including number of network hops, time to deliver, and what might be called administrative distance. Administrative distance is the distance between the administrations of two different networks. For example, in a company, the networks of the research group and the advanced development group might be considered pretty close to each other, the networks of corporate management are more distant, and the networks of other companies are much more distant 🏢. You might want to restrict a query to members within your own administrative domain, because servers outside that domain may not be trusted 🙅‍♀️. Similarly, error reporting outside of an administrative domain may not be productive, and it might even be confusing 😭.

Besides limiting the scope of transmission, the distance parameter can also control the scope of multicast as a binding mechanism, and it can be used to implement an expanding scope of search for a desired service. For instance, to locate a name server that knows about a given name, you might check with nearby name servers first, then expand the distance (by incrementing the distance on retransmission) to include more distant name servers until the name is found 🔍.

To reach all members of a group, a sender specifies the maximum value for the distance parameter. This maximum must exceed the "diameter" of the Internet 🌍.

Packet reception works the same as in conventional architectures. That is:

Receive () --> dest-address, source-address, data

This returns the next internetwork datagram that is, or has been, received 📬.

4.3. Delivery Requirements

We've got several requirements for the packet delivery mechanism that are essential if host groups are going to be a useful, actually-used facility 💜.

Firstly, since broadcast local-area networks are everywhere and most communication stays local to individual networks, the delivery mechanism must be able to exploit the hardware's capability for very efficient multicast within a single local-area network 📡.

Secondly, the delivery mechanism must scale in sophistication to deliver efficiently across the Internet as it gets high-speed wide-area communication links and higher-performance gateways 🚀. The former are coming in with high-speed satellite channels and long-haul fiber optic links. The latter are made feasible by the falling cost of memory and processing power, plus the growing importance of controlling access to relatively unprotected local network environments 🔐. A host group delivery mechanism must be able to take advantage of these trends as they show up 🌸.

Finally, the delivery mechanism must avoid "systematic errors" in delivery to members of the host group. In other words, a small number of repeated transmissions must result in delivery to all group members within the specified distance, unless a member is disconnected or has failed 🔁. We call this property coverage. Most reliable protocols make this basic assumption for unicast delivery, and it's just as important to guarantee it for multicast. Otherwise, applications using multicast may fail in unexpected ways when coverage isn't provided 😱. For efficiency, the multicast delivery mechanism should also avoid regularly delivering multiple copies of a packet to individual hosts 🙌.

Failure notification isn't viewed as an essential requirement, given the datagram semantics of delivery. However, a host group extension to IP should provide "hint"-level failure notification, as the natural extension of the failure notification used for unicast 🦋✨

5. Extensions to IP ✨

okay so this section is about the specific extensions to the DARPA Internet Protocol that make the host group model work 🦋 The extensions only need to be implemented on hosts that want to join host groups or send to them. existing implementations are totally unaffected, so nobody's code breaks 🫶

5.1. Group Addresses 🌸

a chunk of the 32-bit IP address space gets set aside for host group addresses 💜 the range is picked to be easy to recognize and to not clash with regular individual addresses. two options would work: Class A addresses with a distinguished (currently unused) network number, or Class D addresses (the ones starting with 111) 💅 the group range also gets split into two buckets, permanent group addresses and temporary group addresses.

host group addresses can be used just like individual addresses in the source, destination, and options fields of IP datagrams 🎀 each IP implementation adds the addresses of every group it belongs to onto its own list of individual addresses. locally originated datagrams get their source addresses checked against that list, and incoming datagrams that aren't destined to an address on the list get dropped 🙈 and that list is always changing, because it updates every time IP users create, join, or leave groups ✨

5.2. Group Management 🧚

to handle CreateGroup, JoinGroup, and LeaveGroup, an IP module has to talk to one or more multicast agents. those agents live in neighbouring gateways or other special-purpose hosts 🌈 all of these conversations are handled by the Internet Group Management Protocol (IGMP), which is an integral part of the IP implementation, just like ICMP [15] 💖 a proposed specification for IGMP is in Appendix I, so go check that out 🔥

5.3. Multicast Delivery 🍓

to send a datagram to a host group, an IP module has to map the destination group address to a local network address 💅 same as with individual IP addresses, the mapping algorithm is specific to each local network, so it's up to the network 🫶

on networks that directly support multicast, the IP host group address gets mapped to a local network multicast address. that address covers all the local members of the group plus one or more multicast agents ✨ networks that don't directly support multicast are more of a mixed bag: the mapping could be to a more general broadcast address, to a list of local unicast addresses, or maybe to the address of a single machine that handles multi-destination relaying 😭

5.4. Distance Control 👑

the existing Time to Live field in the IP header can give you crude control over how far multicast datagrams travel 💀 for finer control, a new IP option gets defined to specify the maximum delivery distance in "administrative units" 🌈 the examples are "this network", "this department", "this company", "this country", and so on. the set of units and how they're encoded is still to be determined 🎀

6. Implementation 🦋

okay this section sketches out a design for actually implementing the host group model across the Internet 💖 the point is to back up that the host group model is feasible, and also to call out some problems that still need solving 🔥

implementing host groups means building two things: a binding mechanism (binding Internet addresses to zero or more hosts) and a packet delivery mechanism (delivering a packet to each host that its destination address binds to) 🧚 this fits most naturally into the gateways of the Internet and the switching nodes of the constituent point-to-point networks, rather than into separate machines. the reason is that multicast binding and delivery is basically a natural extension of unicast binding and delivery, which is routing plus store-and-forward 💜 so a multicast packet gets routed and transmitted to multiple destinations, instead of just one 💅

the plan is to start with a basic, simple implementation that gives coverage, then refine it with optimizations that improve delivery efficiency and group management 🌸

6.1. Basic Implementation ✨

a host group defines a network group, which is the set of networks that contain current members of the host group 🎀 when a packet gets sent to a host group, one copy goes to each network in that network group. then, within each network, a copy goes to each host that belongs to the group 🫶

to make multicast delivery work, every Internet gateway keeps track of these data structures:

  • routing table: conventional Internet routing information, including the distance and direction to the nearest gateway on every network 🌈
  • network membership table: a set of records, one for every currently existing host group. the network membership record for a group lists the network group, meaning the networks that contain members of the group 💖
  • local host membership table: a set of records, one for each host group that has members on directly attached networks. each local host membership record says which local hosts are members of the associated host group. for networks that support multicast or broadcast, the record can contain just the local network-specific multicast address used by the group, plus a count of local members. otherwise, local group members can be identified by a list of unicast addresses that get used in the software implementation of multicast within the network 🔥

a host uses the multicast delivery service by sending a group-destined IP datagram to an immediate neighbour gateway, which is a gateway directly attached to the same network as the sending host 💅 when a gateway gets a group-destined datagram from a directly attached network, it looks up the network membership record that matches the datagram's destination address 🧚 then, for each network listed in that membership record, it checks its routing table. if the routing table says a member network is directly attached, the gateway transmits a copy of the datagram on that network, using the network-specific multicast address allocated for the group there ✨

for a member network that isn't directly attached, the gateway makes a copy of the datagram with an additional inter-gateway header that identifies the destination network 😭 that inter-gateway datagram gets forwarded to the nearest gateway on the destination network, using conventional store-and-forward routing techniques 🌸 at the gateway on the destination network, the datagram has its inter-gateway header stripped off and gets transmitted to the group's multicast address on that network 💜 relaying gateways drop the datagram whenever it goes past its distance limit 🙈

the network membership records and the network-specific multicast structures get updated based on group management requests from hosts 🫶 a host sends a request to create, join, or leave a group to an immediate neighbour gateway. if a host requests creating a group, the serving gateway creates a new network membership record and distributes it to all the other gateways 🎀 if the host is the first on its network to join a group, or the last on its network to leave one, the group's network membership record gets updated in all gateways 🌈

those updates don't have to happen atomically at every gateway. the reason is the datagram delivery semantics: hosts can handle misrouted and lost packets caused by temporary gateway inconsistencies, as long as those inconsistencies get resolved within normal host retransmission periods 🦋 in this way, the network membership data is pretty similar to the network reachability data that conventional routing algorithms keep track of, so it can be handled by similar mechanisms 💖

a lot of the time, a host joins a group that already has members on the same network, or leaves a group that still has remaining members on that network 👑 in that case, it's just a local matter between the hosts and gateways on that single network. only the local host membership table needs updating, to include or exclude the host ✨

this basic strategy meets the delivery requirements stated at the end of Section 4 💅 but it's far from optimal, in terms of either delivery efficiency or group management overhead 😭 so below, we go over some further refinements to the basic implementation 🔥

6.2. Multicast Routing Between Networks 🧚

multicast routing among the Internet gateways works a lot like store-and-forward routing in a point-to-point network 💜 the big difference is that the links between the nodes (gateways) can be a mix of broadcast and unicast-type networks, with very different throughput and delay characteristics 🌸 also, packets are addressed to networks rather than hosts, at the gateway level 🎀

the plan is to use the extended reverse path forwarding algorithm of Dalal and Metcalfe [10] 💖 it was originally designed for broadcast, but it's a simple and efficient technique that can also work well for multicast delivery, as long as the network membership records in each gateway get augmented with information from neighbouring gateways 🌈 this algorithm uses the source network identifier, not a destination network identifier, to make routing decisions 🫶 since the source address of a datagram can itself be a group address, it can't be used to identify the datagram's source network. so the first gateway has to add a header that specifies the source network 🦋 this approach cuts down on redundant transmissions when multiple destination networks are reachable across a common inter-gateway link, which was a problem with the basic implementation 🔥

we ruled out techniques that fail to deliver along the branches of the shortest delay tree rooted at the source, such as Wall's center-based forwarding [16] 💅 the reason is that it compromises the meaning of the multicast distance parameter and hurts multicast performance overall 😭 we also turned down the idea of having a multicast packet carry more than one network identifier in its inter-gateway header to show multiple destination networks. the variable-length headers that would create would cause buffering and fragmentation problems in the gateways 🙈

6.3. Multicasting Within Networks 🌸

a simple optimization inside a network is to have the sender use the local multicast address of a host group for its initial transmission 🎀 this lets the local host group members receive the transmission right away, along with the gateways, which now have to "eavesdrop" on all multicast transmissions 🧚 a gateway only forwards the datagram if the destination host group has members on other networks 💜 this scheme drops the cost of reaching local group members to one packet transmission, down from the two required in the basic implementation <3>, so transmission to local members ends up being basically as efficient as the local multicast support the network provides 👑✨

A similar glow-up for cutting down packet traffic 🦋 shows up when a datagram has to cross a network to get from one gateway to another, and that network also has members of the destination group. Again, you can use a network-specific multicast address that covers the member hosts plus the gateways, and boom, you get the effect you want ✨. But here's the tea 🍵: in this case, hosts must be prepared to accept datagrams that include an inter-gateway header. The other option is that every datagram carries a spare field in its header, which gateways can use in place of an extra inter-gateway header. Pick your fighter 💅.

6.4. Distributing Membership Information 🌸

Okay, so here's a refinement to how host group membership gets maintained 🧚. Gateways only store the host group membership record for a group if they're directly connected to a member network. Info about other groups only gets cached in the gateway for as long as it's needed to route to those groups. 🫶

When a gateway gets a datagram to forward to a group it has no network membership record for (which can only happen if the gateway isn't directly connected to a member network), here's what it does 👀. It temporarily assumes that the destination group has members on every network in the internetwork, except the ones directly attached to the sending gateway, and routes the datagram that way. In the inter-gateway header of the outgoing packet, the gateway sets a bit saying it wants a copy of the network membership record for the destination host group. When that datagram reaches a gateway on a member network, that gateway sends a copy of the membership record back to the requesting gateway and clears the copy request bit in the datagram. Iconic request-and-response energy 💜.

Copies of network membership records sent to gateways outside a group's member networks get cached so those gateways can use them in later transmissions. But the danger is that a stale cache entry could lead to systematic delivery failures 😭. To counter that, the inter-gateway header has a field holding a hash value or checksum of the network membership record used to route the datagram. Gateways on member networks compare the checksum on incoming datagrams with their up-to-date records. If the checksums don't match, an up-to-date copy of the record goes back to the gateway that had the bad record. Self-correcting, periodt 💅.

This caching strategy keeps intergateway traffic low for groups that are only used within one network, or within the set of networks where members live, which are the expected common cases 🌈. Partial replication with caching also cuts the overhead of sending network traffic to spread updates and keep all the copies consistent. And it reduces the total space all the gateways need to support a large number of host groups. Main character energy for scaling ⭐.

We haven't addressed here how to keep up-to-date, consistent network membership records across the set of gateways connected to members of a group. This can be viewed as a distributed database problem, which has been well studied in other contexts 🍓. The loose consistency requirements on network membership records suggest that the techniques used in Grapevine [3] might be useful for this application 🎀.

The use of unreliable multicast by higher-level protocols, and the implementation of multicast within various individual networks, have been well-studied (see [7] for references and discussion). However, there's relatively little published work on the use or implementation of internetwork multicasting 🥺.

Boggs, in his thesis [4], describes a number of distributed applications that are impossible or very awkward to support without the flexible binding nature of broadcast addressing. He recognizes that almost all of his applications would be best served by a multicast mechanism, but he advocates "directed broadcast" anyway, because it's easy to implement within many kinds of networks and can be extended across an internetwork without placing any new burden on internetwork gateways 🤷‍♀️. In RFC-919 [13], Mogul proposes adopting directed broadcast for the DARPA Internet 🛰️.

Broadcasting has the undesirable side effect of delivering packets to more hosts than necessary. That adds overhead for uninvolved parties and can possibly create security problems 🚨. As more and more applications take advantage of broadcasting, the overhead on all hosts keeps rising. Clearly, broadcast does not scale up to a large internetwork 💀. As an attempt to handle the scaling problem, directed broadcast is less attractive than true multicast, because the set of hosts a single "send" operation can reach is an artifact of the internetwork topology, rather than a grouping that means something to the sender 🙈.

In RFC-947 [12], Lebowitz and Mankins propose using broadcast repeaters that pick up broadcast datagrams from one network and relay them to other networks for broadcast there. This technique is even less selective about its targets than Bogg's directed broadcast method 📢.

Aguilar [1] suggests allowing an IP datagram to carry multiple destination addresses, which the gateways use to route the datagram to each recipient. That facility would ease some of the inefficiencies of sending individual datagrams to a group. But it wouldn't be able to take advantage of local network multicast facilities. More seriously, Aguilar's scheme requires the sender to know the individual IP addresses of all members of the destination group, so it lacks the flexible binding nature of true multicast or broadcast 🙅‍♀️.

8. Concluding Remarks 💖

We have described a model of multicast communication for the Internet. As an extension of the existing Internet architecture, it views unicast communication and time-to-live constraints as special cases of the more general form of communication that arises with multicast 🧠. We've argued that this model is implementable in the Internet and that it provides a powerful facility for a variety of applications 👑. In some cases, it provides a facility that certain applications require to work in the Internet environment. In other cases, it provides a more efficient, robust, and possibly more elegant way of implementing existing Internet applications ✨.

We are currently implementing a prototype host group facility as an extension of IP 🛠️. For practical reasons, this prototype implements all group management functions and multicast routing outside of the Internet gateways, in special hosts called multicast agents, which are similar to the broadcast repeaters of Lebowitz and Mankins. The collection of multicast agents effectively provides a second gateway system on top of the existing Internet, for multicast purposes 🌐. The major costs of this separation are redundant routing tables between gateways and multicast agents, plus the increased delay and unreliability of extra hops in the delivery path 😬. Much of the routing information in the multicast agents must be "wired-in," because they don't have access to the gateways' routing tables. Even so, this rudimentary implementation gives us an environment for evaluating the interface to the multicast service, and for investigating group management and multicast routing protocols for eventual use in the gateways. It also serves as a testbed for porting multicast-based distributed applications to the Internet 🧪.

For now, we're restricting group membership to local networks that already have a broadcast or multicast capability, such as the Ethernet. We feel that, in the future, any network that is going to support hosts other than just gateways must have a multicast addressing mode. Efficient implementation of multicast within point-to-point or virtual circuit networks deserves investigation 🔍.

A significant issue raised by the host group model is authentication and access control in the Internet. Gateways must control which hosts can create and join host groups, presumably making that decision based on the identity of the requestor (which requires authentication) and on permissions (access control lists) 🔐. This issue doesn't come up in conventional internetwork architectures, because host addresses are administratively assigned, with no notion of the dynamic assignment and binding that host groups provide. We believe access control should be recognized as a proper and necessary function of gateways, so as to protect the hosts of local networks from general internetwork activity 🛡️. Thus, group access control can be subsumed as part of this more general mechanism, although more investigation of the general issue is called for.

On a philosophical point, there was considerable reluctance to make open use of multicast on local networks, because it was network-specific and not provided across the Internet. We were originally of that school 🙃. However, we recognized that our "hidden" uses of multicast in the V distributed system were essential, unless we resorted to dramatically poorer solutions, namely wired-in addresses. We also recognized, as described in this paper, that an adequate multicast facility for the Internet was feasible. As a consequence, we now argue that multicast is an important and basic facility to provide in local networks and internetworks 🌟. Higher levels of communication, including applications, should feel free to make use of this powerful facility. Networks and internetworks lacking multicast should be regarded as deficient relative to the future (and present) requirements of sophisticated distributed applications and communication systems 💅🌈.

Appendix I. Internet Group Management Protocol (IGMP) 🎀

The Internet Group Management Protocol (IGMP) is used between IP hosts and their immediate neighbour multicast agents to support the allocation of temporary group addresses and the addition and deletion of members of a group 🦋.

Like ICMP, IGMP is a required part of all IP implementations. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. IGMP messages are formatted similarly to ICMP messages, and the different IGMP message types are given values distinct from ICMP message types, so that both protocols may share common implementation modules or, perhaps, be merged into a single protocol 🤓.

IGMP interactions take the form of request-response transactions. A request message is sent by hosts to the permanent group of all immediate neighbour multicast agents. Multicast agents reply to the IP source address of a request. If no reply is received within a (currently unspecified) timeout interval, a host retransmits its request, up to some (currently unspecified) maximum number of times 🔁. IGMP transactions are considered idempotent, so multicast agents need not recognize and filter out duplicate requests, nor buffer replies <4> ✨.

The IGMP message formats and procedures are defined below, in the style used in the ICMP specification 📝.

Create Group Request or Create Group Reply Message

Okay so this is where the IGMP group-management messages get real 📦✨

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Access Key                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fields

Addresses

bestie, a Create Group Request goes out with the sending host's individual IP address as its source 🫶 and the well-known group address of the multicast agents as its destination. The matching Create Group Reply flips those two addresses around 🔄

IGMP Fields

Type

  • 101 for Create Group Request
  • 102 for Create Group Reply

Code

For a Create Group Request, the Code field tells you whether the group is going to be restricted 👀

  • 0 = unrestricted
  • 1 = restricted

For a Create Group Reply, the Code field spills the outcome of the request 💅

  • 0 = request approved
  • 1 = request denied, no resources

Checksum

The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message, starting from the IGMP Type. When you compute it, the checksum field should be zero. This checksum may be replaced in the future 🔮

Identifier

An identifier that helps match Requests and Replies together 🎀

Sequence Number

A sequence number that also helps match Requests and Replies 🧚

Group Address

For a Create Group Request, this is a value of 0 🌸

For a Create Group Reply, it's either a newly allocated group address (if the request is approved) or a value of 0 (if it's denied) ✨

Access Key

For a Create Group Request, this is a value of 0 🔐

For a Create Group Reply, it's either a pseudo-random 64-bit number (if the request for a restricted group is approved) or 0 💜

Description

A host that wants to grab a brand new temporary group sends a Create Group Request to the group of local multicast agents. If no Reply shows up within t seconds, the Request gets retransmitted. If there's still no Reply after n transmissions, the request is officially deemed to have failed 😭

The first Reply that arrives (if any) tells you how things went. The request could get denied because of lack of resources, like no table space in gateways or all temporary addresses being in use 🍓

If the request is approved, the requesting host becomes the first and only current member of the new host group. Iconic ✨

The Identifier and Sequence Number fields are how the Reply gets matched to its Request. The multicast agents may choose to use these values so they don't accidentally allocate more than one new group for a single request, like when a Reply gets lost and the Request is retransmitted 🧠

Honestly though, the multicast agents must be prepared to recover temporary group addresses without needing explicit Leave Group Requests from every member. They may choose to just allocate a new address for every retransmission and recover the unused ones when needed <5> 🦋

Join Group Request or Join Group Reply Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Access Key                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fields

Addresses

A Join Group Request goes out with the sending host's individual IP address as its source 💖 and the well-known group address of the multicast agents as its destination. The Join Group Reply has those two addresses reversed 🔁

IGMP Fields

Type

  • 103 for Join Group Request
  • 104 for Join Group Reply

Code

For a Join Group Request, the Code field just holds 0 🙃

For a Join Group Reply, the Code field spills the outcome:

  • 0 = request approved
  • 1 = request denied, no resources
  • 2 = request denied, invalid group address
  • 3 = request denied, invalid access key

Checksum

Same deal as before: the 16-bit one's complement of the one's complement sum of the IGMP message starting from the IGMP Type. The checksum field should be zero while you compute it, and this checksum may be replaced in the future 🔮

Identifier

An identifier to help match Request and Reply messages 🎀

Sequence Number

A sequence number to help match Request and Reply messages 🌈

Group Address

For a Join Group Request, this is a host group address 🌸

For a Join Group Reply, it's the same group address as in the corresponding request 💅

Access Key

For a Join Group Request, this is the access key allocated when the group was created (or 0 for unrestricted groups) 🗝️

For a Join Group Reply, it's the same access key as in the corresponding request 🫶

Description

A host that wants to hop into an existing group sends a Join Group Request to the group of local multicast agents. If no Reply message is received within t seconds, the Request is retransmitted. If no reply comes back after n transmissions, the request is deemed to have failed 😭

The first Reply to arrive (if any) decides the outcome. The request might get denied because of an invalid access key, an invalid specified group address (like a group that doesn't exist), or lack of resources (like no table space in gateways) 🙈

The Identifier and Sequence Number fields are how Replies get matched to their Requests. If a multicast agent gets a request from a host to join a group it already belongs to, the agent approves it, assuming the request was just a retransmission for a lost Reply. Very understanding of them 🥹

Leave Group Request or Leave Group Reply Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fields

Addresses

A Leave Group Request goes out with the sending host's individual IP address as its source 👋 and the well-known group address of the multicast agents as its destination. The Leave Group Reply has those two addresses reversed 🔄

IGMP Fields

Type

  • 105 for Leave Group Request
  • 106 for Leave Group Reply

Code

For a Leave Group Request, the Code field contains 0 🫠

For a Leave Group Reply, the Code field spills the outcome:

  • 0 = request approved
  • 2 = request denied, invalid group address

Checksum

Still the 16-bit one's complement of the one's complement sum of the IGMP message starting from the IGMP Type. The checksum field should be zero when you compute it, and this checksum may be replaced in the future 🔮

Identifier

An identifier to help match Request and Reply messages 🎀

Sequence Number

A sequence number to help match Request and Reply messages 🌈

Group Address

For a Leave Group Request, this is a host group address 🌸

For a Leave Group Reply, it's the same group address as in the corresponding request 💜

Description

A host that wants to leave an existing group sends a Leave Group Request to the group of local multicast agents. If no Reply message is received within t seconds, the Request is retransmitted. If no reply comes back after n transmissions, the request is deemed to have succeeded ✅

The first Reply to arrive (if any) tells you the outcome. The request may be denied only if the specified group address is invalid (for example, an individual address rather than a group address) 🙃

The Identifier and Sequence Number fields are used to match the Reply to the corresponding Request, just like with other ICMP transactions. If a multicast agent gets a request from a host to leave a group it doesn't belong to, the agent approves it, assuming the request was a retransmission for a lost Reply. Kind of iconic of them 🫶

Notes

<1> In reality, Internet addresses (individual or group) are bound to network interfaces or network attachment points, not the host machines per se. 🧐

<2> In this procedure call notation, the arguments for an operation are listed in parentheses after the operation name, and the returned values, if any, are listed after a --> symbol. 📝

<3> One unicast transmission from sender to gateway and one multicast transmission from gateway to local group members 📡

<4> This protocol may eventually be replaced by a more general reliable transaction protocol designed for this type of client/server interaction, as suggested in RFC-955 [5]. 🌟

<5> Multicast agents can use an ICMP Echo message to determine if a group has any current members. The Echo message should be transmitted several times before deciding the group address is no longer in use. 🔍

References 📚✨

okay bestie, here's the whole receipts drawer 💅

[1] L. Aguilar. Datagram Routing for Internet Multicasting. In ACM SIGCOMM '84 Communications Architectures and Protocols, pages 58-63. ACM, June, 1984.

[2] E. J. Berglund and D. R. Cheriton. Amaze: A distributed multi-player game program using the distributed V kernel. In Proceedings of the Fourth International Conference on Distributed Systems. IEEE, May, 1984.

[3] A. D. Birrell et al. Grapevine: an exercise in distributed computing. Communications of the ACM 25(4):260-274, April, 1982.

[4] D. R. Boggs. Internet Broadcasting. PhD thesis, Stanford University, January, 1982.

[5] R. Braden. Towards a Transport Service for Transaction Processing Applications. Technical Report RFC-919, SRI Network Information Center, September, 1985.

[6] J-M. Chang. Simplifying Distributed Database Design by Using a Broadcast Network. In SIGMOD '84. ACM, June, 1984.

[7] D. R. Cheriton and S. E. Deering. Host Groups: A Multicast Extension for Datagram Internetworks. In Proceedings of the Ninth Data Communications Symposium. ACM/IEEE, September, 1985.

[8] D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems 3(3), May, 1985.

[9] F. Cristian et al. Atomic Broadcast: from simple message diffusion to Byzantine agreement. In 15th International Conference on Fault Tolerant Computing. , Ann Arbor, Michigan, June, 1985.

[10] Y. K. Dalal and R. M. Metcalfe. Reverse Path Forwarding of Broadcast Packets. Communications of the ACM 21(2):1040-1047, December, 1978.

[11] H. Forsdick. MMCF: A Multi-Media Conferencing Facility. personal communication.

[12] K. Lebowitz and D. Mankins. Multi-network Broadcasting within the Internet.Technical Report RFC-947, SRI Network Information Center, June, 1985.

[13] J. Mogul. Broadcasting Internet Datagrams. Technical Report RFC-919, SRI Network Information Center, October, 1984.

[14] J. Postel. Internet Protocol. Technical Report RFC-791, SRI Network Information Center, September, 1981.

[15] J. Postel. Internet Control Message Protocol. Technical Report RFC-792, SRI Network Information Center, September, 1981.

[16] D. W, Wall. Mechanisms for Broadcast and Selective Broadcast. Technical Report 190, Computer Systems Laboratory, Stanford University, June, 1980.

[17] J. K. Reynolds and J. Postel. Assigned Numbers. Technical Report RFC-960, SRI Network Information Center, September, 1981.

📦 where this page comes from