Chapter 8. Multicast Addressing

Return Home

Chapter 8

Multicast Addressing

What Is Multicast?

Mapping IP Multicast to the Link Layer

Joining the Group

IGMP

Multicast Routing Protocols

Mbone

Multicast Addresses

Transient and Permanent Addresses

Generic Assignments

IANA Assignments

Scope of Multicast Addresses Using TTL

Administrative Scopes

IP Stacks and Multicast

Why Multicast?

Efficiency of Bandwidth Usage and Scaling

Discovering

Efficient Channel

Industry

Summary

FAQ

References

 

IP Multicast is an excellent example of using IP addresses for special purposes. In fact, apart from IPv6 rich addressing structure, multicast is probably the most special use of addresses in the IP technology.

Solutions in this chapter:

          What is multicast?

          Multicast addresses

          IP stacks

          Why use multicast?

What Is Multicast?

Multicast is a technology used to address multiple hosts as a group. A host multicasts to a group of hosts by sending an IP packet to a special IP address that identifies the group. An IP address is used to designate a group of hosts. The IP address that defines a multicast group is in the range of 224.0.0.0 to 239.255.255.255, defined as Class D addresses. Each group has its specific IP address in that range, so many groups can be defined at the same time by using a different IP address.

The membership in a group is dynamic because hosts can join and leave the group as they want. The multicast standard is described in RFC1112.

Multicast is similar to broadcast since only one packet is sent to all hosts, whereas unicast means that one packet is sent to one host. However, multicast differs from broadcast because broadcasting involves sending a packet to all hosts, without exception, on the specified network, whereas multicast sends a packet to the group of hosts. Those hosts that are not part of the group will not process the multicast packet since it is not addressed to them.

One typical example of multicasting is to listen to a videoconference using a 2 Mbits/sec channel on a network. Not all users of a network may want to listen to the videoconference, so the idea is to join the group, or the videoconference in this case. Furthermore, if 10 users of the same physical network wants to listen to this videoconference, then using unicast technology means using 2Mbits/sec * 10 users = 20 Mbits/sec sustained for those users. More users means more bandwidth used. By using multicast, only one channel of 2Mbits/sec is used, independently of the number of users: even 1000 users will still use only 2Mbits/sec.

For Managers Only

Multicast Saves Bandwidth

One advantage of IP multicast is a very important saving in bandwidth for protocols that are broadcast-type by nature, like videoconferences.

Multicast traffic is bidirectional: a host can receive or send multicast packets.

Mapping IP Multicast to the Link Layer

Like any other IP packets, IP multicast packets have to be mapped to the link layer addresses. Multicast has been defined for the link layers of Ethernet, Token-Ring, and others, like ATM. On Ethernet, the low-order 23 bits of the IP multicast address is placed in the lower part of the Ethernet multicast address 01-00-5E-00-00-00. RFC1469 describes multicast over Token-Ring and RFC2022 describes ATM networks.

Joining the Group

To join a multicast group either by a user who wants to listen to a multimedia channel or by a specific application, it is actually very simple: the kernel has to be configured to process the IP multicast address of the group or channel. Then, all packets with an IP destination address as the group IP multicast address will be processed by the host and sent to the upper layer applications.

But, if the multicast channel comes from far away (meaning that it comes from another network), it is possible that this channel is not currently multicasted on the local network of the host. In this case, the host will have to tell its neighbor router that it wants to listen to this multicast channel. This is done using the Internet Group Management Protocol (IGMP), documented in RFC2236. Then this router will try to get that channel from its source and send the multicast packets of that channel to the local network. This entire process involves routing multicast over the larger network.

IGMP

When a host joins a multicast group, it sends a report to the all-hosts group (224.0.0.1) on its local network. Routers can then learn who is joining which group. When a host is leaving a multicast group, it sends a report to the all-routers group (224.0.0.2) on its local network.

Routers also send queries periodically to an all-hosts group address to request reports of group membership to all hosts on each multicast network to which it connects. In this way, a multicast router knows the membership of all groups for all multicast hosts.

RFC2236 describes in detail all the state diagrams and transitions of IGMP for hosts and routers.

Multicast Routing Protocols

Since multicast needs special processing for routers, the IETF defines multicast routing protocols to help routers control the routing of those multicast channels over the networks. The first one was Distance Vector Multicast Routing Protocol (DVMRP), which has been used a lot; however, the RFC (RFC1075) now has experimental status, which means that its implementation is not recommended. This multicast routing protocol was based on the Routing Information Protocol (RIP), and inherits its simplicity. Other protocols have been developed for multicast routing, like the Protocol Independent Multicast (PIM) protocol and Multicast extensions to OSPF (MOSPF).

Within the IETF, there has been work on enhancing the multicast routing and other related issues, mostly under the mboned, idmr, pim, and malloc working groups.

For Managers Only

Stay Up to Date on Multicast Routing

Multicast routing is not easy. Although it is not too difficult, it has undergone many revisions in the multicast routing protocols at the IETF. If you want to deploy multicast in your organization network you should get the latest information on the best current practices.

Mbone

It is often really important to test standards on a real network with real users. The Mbone (Multicast backbone) is an initiative of volunteers who test multicast technology over the Internet. It is still used frequently during multicast events and to test new protocols or applications.

Because not all the ISPs support multicast natively in their infrastructure and routers, the Mbone was created by using a mix of tunnels and native multicast links.

For Managers

Practical Experience of Multicast

If you want to understand and learn about multicast networks, you should connect to the Mbone. It is an easy way to try this great technology. Although you will probably find that Mbone is not as stable as a production network, it serves its original purpose: to experiment this technology in real world, in order to send feedback to the IETF engineers and developers.

Multicast Addresses

Multicast addresses are in the 224.0.0.0 to 239.255.255.255 range, or in binary have the four high-order bits as 1110. This is defined as Class D addresses. Class E addresses, which cover the 240.0.0.0 to 255.255.255.255 range, have been reserved for future addressing modes.

Transient and Permanent Addresses

Two types of multicast addresses can be defined: the permanent and the transient. The permanent addresses are defined in the protocol itself, as the all-hosts and all-routers described in the next section. Permanent addresses can also be assigned by the IANA for other protocols or other uses.

Transient addresses are used for some period of time. For example, a transient address will be used to multicast a videoconference of an event. After the event is finished, the transient address can be reused. In this way, there should be coordination of transient addresses used to be sure that two people or organizations will not use the same transient address for different needs. Back in the old days of the Mbone, you either preannounce it on a specific Mbone channel or on a Web page. Currently, IETF working groups are defining a more protocol-based approach.

Generic Assignments

In the protocol definition, some addresses have already been reserved. The address 224.0.0.0 is reserved and guaranteed not to be assigned to any group. The address 224.0.0.1 is assigned to all IP hosts on the directly connected network. In other words, it is a link-local address. Any hosts, including routers, printers and the like, are members of this group. So as soon as an IP device is configured for multicast, it is automatically and statically a member of this group. The address 224.0.0.2 is assigned to all IP routers on the directly connected network. Only routers are members of this group.

 

 

 

IANA Assignments

RFC1112 didnt define permanent addresses other than the all-hosts address. But the task of assigning permanent multicast addresses has been done by the Internet Assigned Numbers Authority (IANA).

IANA assigns addresses in the 224.0.0.0 to 224.0.0.255 range for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. Multicast routers should not forward any multicast datagram with destination addresses in this range, regardless of its TTL. For example, in that range, multicast addresses have been assigned for the use of some protocols:

224.0.0.4   DVMRP     Routers
224.0.0.5   OSPFIGP   OSPFIGP All Routers
224.0.0.6   OSPFIGP   OSPFIGP Designated Routers
224.0.0.9   RIP2 Routers
224.0.0.12 DHCP Server / Relay Agent
224.0.0.13 All PIM Routers
224.0.0.18 VRRP
224.0.0.22 IGMP

In the 224.0.1.0+ range, multicast addresses are defined for protocols but can be forwarded by routers like:

224.0.1.1   NTP       Network Time Protocol
224.0.1.3   Rwhod
SUN NIS+ Information Service
224.0.1.22 SVRLOC Service Location Protocol
224.0.1.75 SIP Session Initiation Protocol

Or, addresses are assigned to permanent conferencing, like the IETF events:

224.0.1.10 IETF-1-LOW-AUDIO
224.0.1.11 IETF-1-AUDIO
224.0.1.12 IETF-1-VIDEO
224.0.1.13 IETF-2-LOW-AUDIO
224.0.1.14 IETF-2-AUDIO
224.0.1.15 IETF-2-VIDEO

For IPv6, the first assignments are defined in RFC2375. Others are handled by IANA. The current list of assignments is available at: ftp://ftp.iana.org/in-notes/iana/assignments/multicast-addresses.

Scope of Multicast Addresses Using TTL

When holding an internal videoconference inside the company, we would like to control that this conference will not be received or seen on the Internet or outside the company. Even within the company network, we also might want to restrict the conference to one subnet.

Scoping has been realized by using the TTL field in the IP header. By using TTL = 1, this tells any IP router not to forward this packet to another network, since each router must decrement by 1 the TTL field, and if the TTL = 0, then the packet should not be forwarded. TTL was there to detect routing loops , as described in previous chapters.

In multicast, scoping of multicast addresses was based on the TTL value of the IP packet, and so is controlled by the source host. By defining specific thresholds and by configuring appropriately the multicast routers, Mbone people were able to scope many but not all of the situations.

Scoping using the TTL works has some limitations, because it is based on the number of routers in the network topology, not on the administrative boundaries. Also it conflicts with some routing functions like pruning.

Administrative Scopes

A new scoping approach based on special multicast addresses in the range 239.0.0.0 to 239.255.255.255 has been defined in RFC2365. It is based on an administrative scope instead of a network topology scope. So the network manager can configure the administrative scope as needed, without taking care of the network topology.

The following scopes are defined:

          The IPv4 Local Scope, defined as 239.255.0.0/16, is for any local multicast channels. The locality is site dependent, but we can define local scope to have one site in a city by configuring its site boundary routers not to forward local scope multicast packets.

          The IPv4 Organization Local Scope, defined as 239.192.0.0/14, is for an organization scope that can include many sites.

          Link-local scope, defined as 224.0.0.0/24.

          The global scope (meaning the full Internet) is defined as 224.0.1.0-238.255.255.255.

For Managers Only

Managing Multicast with Administrative Scopes

By using administrative scopes, it is much more easier to manage multicast routing, so it enables organizations to deploy multicast with the control they need.

IP Stacks and Multicast

Most current IP stacks support multicast, either installed by default or configured to do so. It is not easy to find whether the kernel of a computer supports multicast. The basic way is to find if the host has the all-hosts address (224.0.0.1) configured, since, by definition, if a host is multicast enabled, this address is configured. Another (harder) way is to send an all-hosts (224.0.0.1) packet on the local network and have a network sniffer see who responds to it. Another way is to use commands that show the 224.0.0.1 address. On Unix and NT, using netstat rn can show a route to the multicast group 224.0.0.1. Figure 8.1 shows an example of a netstat command on a Sun Solaris 2.6 computer.

Sun Microsystems Inc.    SunOS 5.6        Generic August 1997
host1% netstat -rn

Routing Table:
  Destination             Gateway            Flags   Ref    Use    Interface
-------------------- -------------------- ----- ----- ------ ---------
198.202.48.128        198.202.48.134         U         3    9310   hme0
224.0.0.0             198.202.48.134         U         3       0   hme0
default               198.202.48.131         UG        0 153900  
127.0.0.1             127.0.0.1              UH        0       0   lo0

Figure 8.1 Netstat command on Solaris.

The second line in the routing table shows that 224.0.0.0 network is available, which means that multicast is enabled on that computer.

Why Multicast?

The first and most well-known use of multicast is to save bandwidth when casting a videoconference to a number of users. But multicast can do more.

Efficiency of Bandwidth Usage and Scaling

As discussed in this chapter, multicast has been used since the beginning to save bandwidth, especially for any content that is for many users, for example, audio and video. Other examples are netnews sent to many servers and software upgrades for a whole network sent to all hosts. All these examples save bandwidth by sending only one copy of the content whatever the number of clients , instead of one copy per client in the standard unicast way.

Discovering

Many discussions on IP are related to making it easier and autoconfigurable, and enabling devices to discover automatically servers, services, and the like. Examples of this are wireless and small devices that do not have permanent memory, and have to discover where they are, who they are, and which services are available. Another example is the famous dentist office, meaning that IP should be able to be more plug-and-play, so a dentist can deploy an IP network of many devices without a network administrator. Although IPv6 helps a lot in this and is the key technology for that purpose, multicast is very interesting, because hosts that need to discover things can multicast their request on specific channels in order to get more information from listening servers. This is actually being implemented in the Service Location Protocol (SLP), described in RFC2608. IPv6 uses multicast to get this autoconfiguration working. Even more, IPv6 uses multicast for renumbering a whole network, when the organization changes ISP and needs to renumber. In comparison, in IPv4, renumbering is a complex and very difficult task. Chapters 9 and 10 cover IPv6.

Efficient Channel

Without multicast, the only way to send a packet to computers that have the same characteristics (like running a specific protocol) or are routers, was either to know the addresses of them, which is a very difficult task when the number is important, or to use broadcast. If broadcasts were used for all those purposes, then all computers would have to process those packets, even if the packet is not for them. Not only that, but broadcast is limited to the link-local, where multicast can be used over multiple networks. So multicast is an easy way to send information to unknown parties that share the same characteristics without disturbing others.

Industry

The history of multicast shows that industry was not very supportive. But now, an industry consortium has been formed on IP multicast by Stardust Inc. This will help multicast to be used and deployed, and to deliver products to the market. Information is available at http://www.ipmulticast.com. They provide very good information on everything related to IP multicast and also organize events and meetings. Excellent technical white papers and references are available at this site.

Summary

Multicast is a great technology that enables a group of computers sharing a multicast address to communicate together. The IP addresses used in multicast are from 224.0.0.0 to 239.255.255.255, defined as Class D addresses. Class E addresses are reserved for future addressing needs. With IGMP and multicast routing protocols, a network with subnets as well as the Internet by the Mbone, can be configured to use and forward multicast packets. Hosts can report they are joining or leaving a group using IGMP.

Although a few addresses, like 224.0.0.1 as all-hosts and 224.0.0.2 as all-routers, on the local network are defined in the protocol, IANA is the authority that assigns other multicast addresses.

Scoping is an important issue of multicast. The traditional way uses the TTL IP header field to manage the scope, but it has some limitations depending on the need. A new range of multicast addresses have been assigned and defined as Local Scope and Organizational Local Scope to help organizations manage the scope of the multicast traffic.

Multicast can be used for effective bandwidth usage, discovery, and efficient channels. IPv6 uses multicast in its core functions and industry is supporting it. You are invited to join the Mbone if you wants to learn by practice.

FAQ

Q: Where can I find information about IP multicast support in industry?

A: IP Multicast Initiative: http://www.ipmulticast.com/.

Q: Which IP multicast addresses have been allocated?

A: Allocation of IP multicast addresses is done by IANA (http://www.iana.org). The current list of assignments can be found at ftp://ftp.iana.org/in-notes/iana/assignments/multicast-addresses.

Q: Who is working on multicast protocols and standards?

A: Many IETF working groups are working on multicast. Please refer to the IETF working group pages to get the most current work (http://www.ietf.org).

References

[RFC1075] Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. Nov-01-1988. (Status: Experimental)

[RFC1112] Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. Obsoletes RFC0988, RFC1054; updated by RFC2236 and STD0005. (Status: Standard)

[RFC1469] IP Multicast over Token-Ring Local Area Networks. T. Pusater. June 1993. (Status: Proposed Standard)

[RFC2022] Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. Armitage. November 1996. (Status: Proposed Standard)

[RFC2236] Internet Group Management Protocol, version 2. W. Fenner. November 1997. Updates RFC1112. (Status: Proposed Standard)

[RFC2608] Service Location Protocol, version 2. E. Guttman, C. Perkins, J. Veizades, M. Day. June 1999. Updates RFC2165. (Status: Proposed Standard)