3.5 Multicast Addressing

Although IP multicast will be discussed in more detail in section 7, a brief overview is provided here.

3.5.1 Unicast, Broadcast and Multicast

IP addresses, or rather, IP transmissions can be unicast, broadcast or multicast, depending on the destination host or hosts that are to receive a transmission.

3.5.1.1 Unicast

Unicast is used for direct host-to-host communication, when two hosts need only to exchange data with one another. As MAC address uniquely identify a host, and no two MAC addresses are the same, unicast uses the unique MAC address for each host. With the specific MAC address, any source host should be able to contact the destination host without confusion. Thus, in unicast communication, there is a unique address for every host on a network.

For unicast communication, the source host must know or be able to learn what every destination MAC is for every station it wishes to communicate with. This may not be done on a host-by-host basis in a routed environment. Therefore, the host has a default gateway that it uses when the destination host does not reside on the same subnet as the source host.

3.5.1.2 Broadcast

While unicast messages target a single host on a network, broadcast messages are meant to reach all hosts on a broadcast domain, which is a group of network segments where a broadcast is flooded. With broadcast communication, a global address, called the broadcast address, is used that all hosts will respond to. Because the broadcast frame is addressed to include every host, every host must process the frame; although every host need not respond. An example of a broadcast message is an ARP request. When a host has a packet destined for a host that is not located on the same network, the source host must ARP for the default gateway's MAC address so it can send the datagram to the router. The ARP request is a broadcast message sent to all devices in the broadcast domain, however, only the default gateway will respond to the broadcast message, while the other hosts will evaluate the frame, but will not respond.

3.5.1.3 Multicast

Multicast has elements of both unicast and broadcast. It allows multiple recipients to receive messages without flooding them to all hosts on a broadcast domain. Instead, multicast sends messages or data to multicast group addresses. Routers then forward copies of the packet out every interface that has hosts who have subscribed to the group address. This is one difference between multicast and broadcast. While routers forward broadcasts to all hosts, they send copies of packets only to subscribed hosts.

Multicast uses addressing that only hosts that are subscribed to that multicast group will respond to. Thus a host or an application must subscribe to a specific IP Multicast Group to become a member. Once a member of the group, IP multicast packets containing that group address in the destination field in the header will arrive at the host and be processed. If the host did not subscribe to the group, it will not process packets addressed to that group.

3.5.2 Multicast Addressing

The range of multicast addresses is 224.0.0.0 through 239.255.255.255. This falls within the class D IP address range. As with the class A, B and C IP address ranges, IANA has reserved part of the multicast address range for private use. The private multicast IP address range is 239.0.0.0 through 239.255.255.255 as defined by RFC 1918. Additional multicast addresses have also been reserved. A full list of reserved multicast addresses can be viewed at: http://www.iana.org/assignments/multicast-addresses. Some of the reserved multicast addresses are listed below.

Reserved Multicast Addresses

Address Purpose

224.0.0.0 - 224.0.0.18

Use by network protocols

224.0.0.1

All hosts on a subnet

224.0.0.2

All routers on a subnet

224.0.0.4

DVMRP routers

224.0.0.5

All OSPF routers

224.0.0.6

OSPF Designated Router (DR) routers

224.0.0.9

RIPv2 routers

224.0.0.10

EIGRP routers

224.0.0.13

All PIM routers

224.0.0.69 - 224.0.0.100

Reserved

224.0.1.253 - 224.0.1.255

Unassigned

224.0.1.0 - 224.0.1.255

Multicast Applications

224.0.1.1

Network Time Protocol (NTP)

224.0.1.8

NIS+

224.0.1.39

Cisco-Route Processor (RP)-Announce

224.0.1.40

Cisco-Route Processor (RP)-Discovery

224.0.1.179 - 224.0.1.255

Unassigned

239.0.0.0 - 239.255.255.255

Private multicast domain

Multicast addresses in the range 224.0.0.0 through 224.0.0.255 are local-link addresses that are meant to remain on the local subnet and are, thus, not forwarded over a router. Multicast addresses in the range

224.0.1.0 through 224.0.1.255 are global addresses that can be routed and forwarded across multiple routers.

3.5.2.1 Multicast Address Mapping

In unicast, MAC addresses are Layer 2 addresses. Layer 3 logical IP addresses are required in order to reach remote hosts. Once the packet reaches the remote subnet the ARP table, or an ARP request is used to find the MAC address that is associated to the Layer 3 IP address is found and the packet forwarded to the destination host.

IP multicast uses the reserved IEEE 802 address 01-00-5e-00-00-00 for multicast addresses at the MAC layer. Ethernet interfaces map the lower 23 bits of the IP multicast address to the lower 23 bits of this reserved IEEE 802 address. Thus, the IP multicast address 224.0.1.12 (e0-00-01-0c) is mapped to the MAC layer as01-00-5e-00-01-0c. The easiest way is to map Layer 3 to Layer 2 manually is to do a binary conversion so that you can see what the last 23 bits of the Layer 3 IP address is. Once you have that number you can insert it into the MAC address. Any IP address that has the same values in the last 23 bits will map to the same multicast MAC address. This is because the high order bit of a Class D address lies in the first octet and is in the 16's value position, which leaves 28 bits for host specification. However, multicast address mapping only uses the last 23 bits of the Layer 3 IP address. This leaves five bits out of the mapping and causes an overlap of 25, or 32 Layer 3 address for every 1 Layer 2 address. With a ratio of 32:1 there is a significant amount of address ambiguity. Thus, 224.0.1.12 and 225.128.1.12 map to the same MAC address 01-00-5e-00-01-0c because their last 23 bits are identical (00000.00000001.00001100 or 00-01-0c).

3.5.3 Managing Multicast Traffic

Multicast has the ability to specify which multiple hosts will receive the transmission on a Layer 2 basis. However, the hosts listen for the correct MAC address once the information is received on the host interface. This works on the basis of host subscription to groups and is implemented and facilitated within the internetwork by several methods and protocols. Each of these methods and protocols is used to for specific tasks or to achieve specific ends within the multicast environment.

3.5.3.1 Group Subscription and Maintenance

For a host to receive multicast traffic, it must send a request to a multicast-enabled router for the data belonging to the specified multicast group. The multicast-enabled router receives all group advertisements and routes and listens on all interfaces for a request from a host for multicast group traffic. Once a host requests to become a member of a group, the router interface to which the host is attached activates the requested group on only that interface. For as long as the host is a member of the group, multicast data for that group will be forwarded to the interface to which the host is attached and any host subscribed to the group will receive the data.

Multicast uses three major host subscription protocols to facilitate multicast traffic. These protocols are: Internet Group Management Protocol version 1 (IGMPv1), Internet Group Management Protocol version 2 (IGMPv2), and Cisco Group Management Protocol (CGMP).

3.5.3.1.1 IGMPvl

IGMPvl, which is described in RFC 1112, allows hosts to subscribe or join specified multicast groups. It provides simple message types for communication between end hosts and the local router and is not routable.

These messages are:

  • Membership Query, which is sent by the host and is used to request membership to a multicast group. This is controlled by a Membership Query cycle which runs every 60 seconds.

  • Membership Report, which is sent by the router to check if hosts are still in multicast groups in the segment. Once one host on an interface has reported its membership to a group that no other hosts on that interface need to report. This reduces bandwidth and processor utilization.

IGMPv1 has a latency problem when a host leaves a group. The router periodically sends out a Membership Report to check group membership. The router maintains a timer that is reset every time a response is received from a host on an interface. The timer runs for 90 seconds, or three Membership Query cycles (3 x 60 = 90). If the timer expires and no response is received from the hosts on the interface, the router disables multicast forwarding on that interface.

3.5.3.1.2 IGMPv2

IGMPv2, which is described in RFC 2236, is an enhancement of IGMPv1. It thus provides the same functionality as IGMPv1, but with a few enhancements to overcome the latency problem in IGMPv1 when a host leaves a group.

IGMPv2 uses the four types of message; one of which is provided for backward compatibility with IGMPv1. These messages are:

  • Membership Query, which is sent by the Designated Querier to discover if a host wants to join a group.

  • Version 2 Membership Report, which is sent to the group address with the multicast group members to verify that hosts are still in multicast groups on the segment.

  • Leave Group, which is sent by the hosts to destination 224.0.0.2 when the host wants to leave a group. This message is sent without having to wait for the Version 2 Membership Report message.

  • Version 1 Membership Report, which is sent for backward compatibility with IGMPv1 hosts.

The Designated Querier When there are more than one multicast routers on a segment, the multicast router with the lowest IP address becomes the Designated Querier and is the only router on that segment that sends the Membership Query messages for that segment.

IGMP is enabled on an interface when the multicast routing protocol is enabled. The version of IGMP that the interface is to use can be specified by using the ip igmp version [1 | 2] command. You can also query the known multicast groups on a router by using the show ip igmp groups command.

Note: Although IGMPv2 is backward compatible with IGMPv1, the functionality of IGMPv2 is lost when operating with other IGMPv1 devices. An IGMPv2 device, whether a host or a router, has to use IGMPv1 frame formats when communicating with an IGMPv1 device.

3.5.3.1.3 CGMP

CGMP is a Cisco proprietary protocol that controls multicast traffic at Layer 2. It is not used by hosts, but by the switches and routers that the host is connected to. When a host sends an IGMP Membership Report message to advertise membership of a multicast group, the message is forwarded to the multicast router, which processes the request and processes it accordingly. The router then sends the switch the CGMP message. With the CGMP message, the switch can assign the multicast group to the port that the requesting host is attached to. This prevents that switch from sending multicast packets out all its ports - remember that Layer-2 switches are not aware of Layer-3 IGMP messages.

The switch uses CGMP Fast-Leave Processing to detect IGMPv2 leave messages that are sent by hosts on any of the supervisor engine module ports. When the IGMPv2 leave message is sent, the switch will disable multicast for that port.

You can enable CGMP on the router by using the ip cgmp command, and on the switch by using the set cgmp enable command.

3.5.3.2 Routing Multicast Traffic

As in unicast communication, routing protocols and routing tables are used to get data to and from remote destinations in multicast communication, albeit differently. Multicast uses a spanning tree system to mange the distribution of multicast data. In addition, it uses several protocol methods to ensure that delivery is as efficient as possible.

3.5.3.2.1 Distribution Trees

Multicast has two types of trees: Source Trees, which use the architecture of the source of the multicast traffic as the root of the tree; and Shared Trees, which uses an architecture where multiple sources share a common rendezvous point. Each of these methods allows sourced multicast data to reach an arbitrary number of recipients of the multicast group.

  • Source Trees use special notation in what becomes a multicast route table, which is slightly different from a unicast route table. Unicast route tables use the destination address and next hop information to establish a topology for forwarding information. Source Trees use a similar table, but instead of having the destination address listed and then the next hop to get to the destination, Source Tree uses the notation of (S, G) to specify the source host's IP address and the multicast group address that it is sourcing information for. With Source Trees, traffic flows across the shortest path to the destination host. This is known as choosing the shortest path tree (SPT).

  • There are two types of Shared Tree distribution: unidirectional and bidirectional. They both work on the basis that there may be multiple sources for one multicast group. Instead of each individual source creating its own SPT and distributing the data apart from the other sources, a shared root is designated. Multiple sources for a multicast group forward their data to a shared root or rendezvous point (RP). The rendezvous point then follows SPT to forward the data to the members of the group.

  • In Unidirectional Shared Tree distribution, all destination hosts of a multicast group receive the data from a RP regardless of where they are located in the network.

  • In Bidirectional Shared Tree distribution, destination hosts that are upstream of the RP it can receive data directly from the upstream source, without having to come from the RP.

3.5.3.2.2 Multicast Delivery

There are several methods that can be used to ensure the efficient delivery of multicast traffic. The common methods are Reverse Path Forwarding (RPF), which works in tandem with the routing protocols, time-to-live (TTL) attributes, and routing protocols.

Reverse Path Forwarding (RPF) works in tandem with the routing protocols, and is based on the upstream information. When a router receives incoming multicast packet, it verifies that the packet came in on an interface that leads back to the source. The packet is forwarded by the router if the verification is positive, otherwise the packet is discarded. This prevents potential loops. In addition, a multicast forwarding cache is implemented for the RPF lookups to avoid increased overhead on the router's processor.