The Cable Guy - February 2002

Overview of IP Multicas

By The Cable Guy

In addition to unicast and broadcast support, IP (version 4) also provides a mechanism to send and receive IP multicast traffic. IP multicast traffic is sent to a single destination IP address but is received and processed by multiple IP hosts, regardless of their location on an IP internetwork. A host listens for a specific IP multicast address and receives all packets to that IP address.

IP multicast is more efficient than IP unicast or broadcast for one-to-many delivery of data. Unlike unicast, only one copy of the data is sent. Unlike broadcast, the traffic is only received and processed by computers that are listening for it.

The additional elements of IP multicast include the following:

• The set of hosts listening on a specific IP multicast address is called a host group.
• Host group membership is dynamic, and hosts can join and leave the group at any time.
• There are no limitations to the size of a host group.
• A host group can span IP routers across multiple network segments. This configuration requires IP multicast support on IP routers and the ability for hosts to register their interest in receiving multicast traffic with the router. Host registration is accomplished using the Internet Group Management Protocol (IGMP).
• A host can send traffic to an IP multicast address without belonging to the corresponding host group.

IP multicast addresses, also known as group addresses, are in the class D range of 224.0.0.0 to 239.255.255.255 as defined by setting the first four high order bits to 1110. In network prefix or Classless Inter-Domain Routing (CIDR) notation, IP multicast addresses are summarized as 224.0.0.0/4. Multicast addresses in the range 224.0.0.0 to 224.0.0.255 (224.0.0.0/24) are reserved for the local subnet and are not forwarded by IP routers regardless of the Time to Live (TTL) in the IP header. The following are examples of reserved IP multicast addresses:

• 224.0.0.1 - all hosts on this subnet.
• 224.0.0.2 - all routers on this subnet.
• 224.0.0.5 - Open Shortest Path First (OSPF) Version 2, designed to reach all OSPF routers on a network.
• 224.0.0.6 - OSPF Version 2, designed to reach all OSPF designated routers on a network.
• 224.0.0.9 - Routing Information Protocol (RIP) Version 2.
• 224.0.1.1 - Network Time Protocol.

Mapping IP Multicast to MAC-Layer Multicast

To support IP multicasting, the Internet authorities have reserved the multicast address range of 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF for Ethernet and Fiber Distributed Data Interface (FDDI) media access control (MAC) addresses. To map an IP multicast address to a MAC-layer multicast address, the low order 23 bits of the IP multicast address are mapped directly to the low order 23 bits in the MAC-layer multicast address. Because the first 4 bits of an IP multicast address are fixed according to the class D convention, there are 5 bits in the IP multicast address that do not map to the MAC-layer multicast address. Therefore, it is possible for a host to receive MAC-layer multicast packets for groups to which it does not belong. However, these packets are dropped by IP once the destination IP address is determined.

For example, the multicast address 224.192.16.1 becomes 01-00-5E-40-10-01. To use the 23 low order bits, the first octet is not used, and only the last 7 bits of the second octet is used. The third and fourth octets are converted directly to hexadecimal numbers. The second octet, 192 in binary is 11000000. If you drop the high order bit, it becomes 1000000 or 64 (in decimal), or 0x40 (in hexadecimal). For the next octet, 16 in hexadecimal is 0x10. For the last octet, 1 in hexadecimal is 0x01. Therefore, the MAC address corresponding to 224.192.16.1 becomes 01-00-5E-40-10-01.

Token Ring uses this same method for MAC-layer multicast addressing. However, many Token Ring network adapters do not support it. Therefore, by default, the functional address 0xC0-00-00-04-00-00 is used for all IP multicast traffic sent over Token Ring networks. For more information about Token Ring support for IP multicasting, see RFC 1469.

IP Multicast–Enabled Intranet

In an IP multicast–enabled intranet, any host can send IP multicast traffic to any group address, and any host can receive IP multicast traffic from any group address regardless of their location. To facilitate this capability, IP multicast must be supported by the hosts and routers of the intranet.

Host Support for IP Multicast

For a host to send IP multicast packets, it must:

• Determine the IP multicast address to use.

  The IP multicast address can be hard-coded by the application or obtained through a mechanism that allocates a unique multicast address.

• Place the IP multicast packet on the medium.

  The sending host must construct an IP packet containing the wanted destination IP multicast address and place it on the medium. In the case of shared access technologies such as Ethernet, FDDI, and Token Ring, the destination MAC address is created from the IP multicast address as previously described.

For a host to receive IP multicast packets, it must:

• Inform IP to receive multicast traffic.

  To determine the IP multicast address to use, the application must first determine whether to create a new host group or use an existing host group. To join an existing group, the application can use a hard-coded multicast address or an address derived from a universal resource locator (URL) string.

  After the group address is determined, an application must inform IP to receive multicast traffic at a specified destination IP multicast address. For example, the application can use Windows Sockets functions to notify IP of the multicast groups joined. If multiple applications are using the same IP multicast address, then IP must pass a copy of the multicast packet to each application. IP must track which applications are using which multicast addresses as applications join or leave a host group. Additionally, for a multihomed host, IP must track the application membership of host groups for each subnet.

• Register the multicast MAC address with the network adapter.

  If the network technology supports hardware-based multicasting, then the network adapter is told to pass up packets for a specific multicast address. In the case of shared access technologies such as Ethernet, FDDI, and Token Ring, the Windows NdisRequest( ) function is used to inform the network adapter to respond to a multicast MAC address corresponding to a IP multicast address.

• Inform local routers.

  The host must inform local subnet routers that it is listening for multicast traffic at a specific group address. The protocol that registers host group information is the Internet Group Management Protocol (IGMP). The IGMP Host Membership Report message is sent by a host to register membership in a specific host group.

  There are three versions of IGMP in use today: IGMP version 1 (IGMP v1), IGMP version 2 (IGMP v2), and IGMP version 3 (IGMP v3). Windows 2000 supports IGMP v1 and IGMP v2. Windows XP and Windows Server 2003 TCP/IP supports IGMP v1, IGMP v2, and IGMP v3. To configure computers running Windows XP to use IGMP v1 or IGMP v2, see You Cannot Configure Windows XP to Use IGMP Version 1 or Version 2 Support.

Router Support for IP Multicast

To forward IP multicast packets to only those subnets for which there are group members, an IP multicast router must be able to:

• Receive all IP multicast traffic.
• Forward IP multicast traffic.
• Receive and process IGMP Host Membership Report messages.
• Query attached subnets for host membership status.
• Communicate group membership to other IP multicast routers.

Receive All IP Multicast Traffic

For shared access technologies, such as Ethernet and FDDI, the normal listening mode for network adapters is unicast listening mode. The listening mode is the way that the network adapter analyzes the destination MAC address of incoming frames to decide to process them further. In unicast listening mode, the only frames that are considered for further processing are in a table of interesting destination MAC addresses on the network adapter. Typically, the only interesting addresses are the broadcast address (0xFF-FF-FF-FF-FF-FF) and the unicast address, also known as the MAC address, of the adapter.

However, for an IP multicast router to receive all IP multicast traffic, it must place the network adapter in a special listening mode called multicast promiscuous mode. Multicast promiscuous mode analyzes the Institute of Electrical and Electronics Engineers (IEEE)-defined Individual/Group (I/G) bit to determine whether the frame requires further processing. The I/G bit for Ethernet and FDDI addresses is the last bit of the first byte of the destination MAC address.

The values of the I/G bit are the following:

• If set to 0, then the address is a unicast (or individual) address.
• If set to 1, then the address is a multicast (or group) address. The multicast bit is also set for the broadcast address.

When the network adapter is placed in multicast promiscuous listening mode, any frames with the multicast bit set to 1 are passed up for further processing.

Multicast promiscuous mode is different than promiscuous mode. In promiscuous mode, all frames—regardless of the destination MAC address—are passed up for processing. Promiscuous mode is used by protocol analyzers, also known as network sniffers, such as the full version of Microsoft Network Monitor that is part of the Microsoft Systems Management Server. Network adapters of hosts are typically not placed in multicast promiscuous mode.

Forward IP Multicast Traffic

The ability to forward IP multicast packets is a capability of the TCP/IP protocol. The TCP/IP protocol for Windows 2000 and Windows Server 2003 supports multicast forwarding. When multicast forwarding is enabled (using the Routing and Remote Access service), non-local subnet IP multicast packets are analyzed to determine over which interfaces the packet is forwarded. The analysis is done by comparing the source address and the destination group address to entries in the IP multicast forwarding table. Upon receipt of a non-local IP multicast packet, the Time to Live (TTL) in the IP header is decremented by 1. If the TTL is greater than 0 after decrementing, then the multicast forwarding table is checked. If an entry in the multicast forwarding table is found that matches the destination IP multicast address, the IP multicast packet is forwarded with its new TTL over the appropriate interfaces.

The multicast forwarding process does not distinguish between hosts on locally attached subnets who are receiving multicast traffic or hosts on a network segment that are downstream from the locally attached subnet across another router on the subnet. In other words, a multicast router might forward a multicast packet on a subnet for which there are no hosts listening. The multicast packet is forwarded because another router on that subnet indicated that a host in its direction is receiving the multicast traffic.

The multicast forwarding table does not record each host group member or the number of host group members; only that there is at least one host group member for a specific group address.

Receive and Process IGMP Host Membership Report Messages

Multicast routers receive IGMP Host Membership Report messages from all hosts on all locally attached subnets. This information is used to track host group membership by placing entries in the multicast forwarding table. Because all multicast routers are listening in multicast promiscuous mode, they receive all IGMP Host Membership Report messages sent to any group address.

To improve the leave latency, which is the time between when the last host on a subnet has left the group and when no more multicast traffic for that group is forwarded to that subnet, a host that might be the last member of a group on a subnet sends an IGMP Leave Group message. After sending multicast-address-specific IGMP queries to the group in the IGMP Leave Group message and receiving no response, the router can determine that there are no more group members on that subnet.

Query Attached Subnets for Host Membership Status

On a specific subnet, there can be a mixture of IGMP v1, IGMP v2, and IGMP v3 hosts. When an IGMP v1 host stops receiving IP multicast traffic for a specific group address (the host leaves the group), it does not send an IGMP Leave Group message to inform the local routers. Consequently, the host can leave the group; if it is the last member on the subnet, then the local routers continue to forward multicast traffic for that group to the subnet.

To compensate for the lack of reporting ability of IGMP v1 hosts and the possible loss of IGMP Host Membership Report and Leave Group messages, multicast routers periodically send IGMP Host Membership Query messages to the local subnet for host membership information. A host that is still a member of a multicast group responds to the query with an IGMP Host Membership Report message. To keep multiple hosts on a particular subnet from sending IGMP Host Membership Report messages for the same group, a random response timer is used on the hosts to delay the transmission of the IGMP Host Membership Report message. If the message is sent by another host on that subnet before the response timer expires, a message is not sent.

For the Windows 2000 Server and Windows Server 2003 Routing and Remote Access service, the ability to receive and process IGMP Host Membership Report messages and query attached subnets for host membership status is provided by adding the IGMP routing protocol component and enabling IGMP router mode on an interface.

Communicate Group Membership to Other IP Multicast Routers

To create multicast-enabled IP internetworks containing more than one router, multicast routers must communicate group membership information to each other so group members can receive IP multicast traffic regardless of their location on the IP internetwork.

Multicast routers exchange host membership information using a multicast routing protocol such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), or Protocol Independent Multicast (PIM). Group membership is either communicated explicitly, by exchanging group address and subnet information, or implicitly, by informing upstream routers whether or not group members exist downstream from the source of the multicast traffic.

The goals of a multicast routing protocol include the following:

• Forward traffic away from the source to prevent loops.
• Minimize or eliminate multicast traffic to subnets that do not need the traffic.
• Minimize CPU and memory load on the router for scalability.
• Minimize the overhead of the routing protocol.
• Minimize the join latency, the time it takes for the first host member on a subnet to begin receiving group traffic.

Multicast routing is more complex than unicast routing. With unicast routing, unicast traffic is forwarded to a globally unique destination. Unicast routes summarize ranges of globally unique destinations. Unicast routes in the network are comparatively consistent and only need to be updated when the topology of the IP internetwork changes.

With multicast routing, multicast traffic is forwarded to an ambiguous group destination. Group addresses represent individual groups, and in general, cannot be summarized in the multicast forwarding table. The location of group members is not consistent, and the multicast forwarding tables of multicast routers might need to be updated whenever a host group member joins or leaves a host group.

Just as unicast routing protocols update the unicast IP routing table, multicast routing protocols update the IP multicast forwarding table. The Windows 2000 Server and Windows Server 2003 Routing and Remote Access service does not include any multicast routing protocols, although it provides a platform on which third-party protocols can run. The only component provided with Windows 2000 Server and Windows Server 2003 that can update entries in the multicast forwarding table is the IGMP routing protocol component.

For More Information

For more information about IP multicast support in Windows 2000, consult the following resources:

• Windows 2000 Server Documentation (Networking\Routing and Remote Access\Routing)
• IP Multicast Support chapter of the Windows 2000 Server Resource Kit
• PIM-SM Multicast Routing Protocol white paper
• Microsoft Product Support Services Knowledge Base

For a list of all The Cable Guy articles, click here.