Appendix A – IP Multicast

Article
08/31/2011

Abstract

This appendix describes Internet Protocol (IP) multicast for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) and its support in Microsoft® Windows Server™ 2003 and Windows® XP operating systems. IP multicast is a one-to-many delivery mechanism that is useful for efficiently distributing data to interested listening hosts at arbitrary locations on a private network or on the Internet. Network administrators must understand multicast concepts, multicast addressing and forwarding, multicast address allocation, and reliable multicast to effectively use and troubleshoot IP multicast traffic.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this appendix that has been updated for Windows Vista and Windows Server 2008, click here.

Overview of IP Multicast

In addition to unicast and broadcast support, IP 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 network. 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 set of hosts listening on a specific IP multicast address is called a host group. A host can send traffic to an IP multicast address without belonging to the corresponding host group. Host group membership is dynamic. Hosts can join or leave the group at any time and 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 from their neighboring routers. Hosts use the Internet Group Management Protocol (IGMP) for IPv4 and Multicast Listener Discovery (MLD) for IPv6 for host group membership registration.

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. Figure A-1 shows an example of an IP multicast-enabled intranet.

Figure A-1 An IP multicast-enabled intranet

To facilitate this capability, the hosts and routers of the network must support IP multicast.

Host Support for IP Multicast

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

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 destination IP multicast address and place it on the medium. In the case of shared access technologies such as Ethernet and Token Ring, the destination media access control (MAC) address is derived from the IP multicast address.

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

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 join an existing host group. To join an existing group, the application can use a hard-coded multicast address or an address derived from a Uniform Resource Locator (URL) string.

After the group address is determined, an application must inform IP to receive multicast traffic sent to the group 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, 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. 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 informed to pass up packets for a specific multicast address. The host uses the Windows NdisRequest() function 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 using IGMP or MLD.

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.

For shared access technologies, 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 stored on the network adapter. Typically, the only interesting addresses are the broadcast address (0xFF-FF-FF-FF-FF-FF) and the unicast 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 addresses is the low-order 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 to 1 for the broadcast address.
When the network adapter is placed in multicast promiscuous listening mode, any frames with the I/G 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. Protocol analyzers, such as the full version of Microsoft Network Monitor that is part of the Microsoft Systems Management Server, use promiscuous mode. Network adapters of hosts are typically not placed in multicast promiscuous mode.
Forward IP multicast traffic.

IP multicast packet forwarding is a capability of IP. When IP multicast forwarding is enabled, IP analyzes IP multicast data packets to determine the interfaces over which the packet is to be forwarded. IP performs this analysis by comparing the IP source and destination group addresses to entries in the IP multicast forwarding table. Upon receipt of a non-local IP multicast packet, the Time to Live (TTL) in the IPv4 header or the Hop Limit field in the IPv6 header is decremented by 1. If the TTL or hop limit is greater than 0 after decrementing, 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 or hop limit over the appropriate interfaces.

The multicast forwarding process does not distinguish between hosts on locally attached subnets that 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 router forwards the packet 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 the multicast traffic needs to be forwarded over specific interfaces.
Receive and process multicast group membership messages sent by hosts.

Multicast routers receive IGMP or MLD messages from hosts on all locally attached subnets. This information is used to track host group membership by placing or removing entries in the multicast forwarding table. Because all multicast routers are listening in multicast promiscuous mode, they receive all IGMP and MLD 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 or MLD Multicast Listener Done message. After sending multicast-address-specific IGMP or MLD queries to the group being left and receiving no response, the router determines that there are no more group members on that subnet.
Query attached subnets for host membership status.

Multicast routers periodically send general IGMP and MLD query messages to the local subnet to query for host membership information. A host that is still a member of a multicast group responds to the query.
Communicate group membership to other IP multicast routers.

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

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 processor and memory load on the router for scalability.
- Minimize the overhead of the routing protocol.
- Minimize the join latency, which is 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 network 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.

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

Multicast Addresses

Multicast addresses are defined for both IPv4 and IPv6 addresses.

IPv4 Multicast Addresses

IPv4 multicast addresses, also known as group addresses, are in the class D range of 224.0.0.0/4 (from 224.0.0.0 to 239.255.255.255) as defined by setting the first four high order bits to 1110. Multicast addresses in the range 224.0.0.0/24 (from 224.0.0.0 to 224.0.0.255) are reserved for the local subnet and are not forwarded by IPv4 routers regardless of the TTL value in the IPv4 header. The following are examples of reserved IPv4 multicast addresses:

224.0.0.1 - all hosts on this subnet
224.0.0.2 - all routers on this subnet
224.0.0.5 – all Open Shortest Path First (OSPF) routers on a subnet
224.0.0.6 – all OSPF designated routers on a subnet
224.0.0.9 - Routing Information Protocol (RIP) Version 2

For the current list of reserved IPv4 multicast addresses, see https://www.iana.org/assignments/multicast-addresses.

Mapping IPv4 Multicast to MAC-Layer Multicast

To support IPv4 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 MAC addresses. To map an IPv4 multicast address to a MAC-layer multicast address, the low order 23 bits of the IPv4 multicast address are mapped directly to the low order 23 bits in the MAC-layer multicast address. Figure A-2 shows the mapping of an IPv4 multicast address to an Ethernet multicast address.

Figure A-2 Mapping IPv4 multicast addresses to Ethernet multicast addresses

For example:

The IPv4 multicast address 224.0.0.1 is mapped to 01-00-5E-00-00-01.

When mapping 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. For the second and third octets, 0 in hexadecimal is 0x00. For the last octet, 1 in hexadecimal is 0x01. Therefore, the destination MAC address corresponding to 224.0.0.1 becomes 01-00-5E-00-00-01.
The IPv4 multicast address 224.192.16.1 is mapped to 01-00-5E-40-10-01.

For 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 third octet, 16 in hexadecimal is 0x10. For the last octet, 1 in hexadecimal is 0x01. Therefore, the destination MAC address corresponding to 224.192.16.1 becomes 01-00-5E-40-10-01.

Because the first 4 bits of an IPv4 multicast address are fixed according to the class D convention, there are 5 bits in the IPv4 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, IPv4 drops these packets once the destination IPv4 address is determined.

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 IPv4 multicasting, see RFC 1469.

IPv6 Multicast Addresses

IPv6 multicast addresses have the first eight bits fixed at 1111 1111 (FF00::/8). Therefore, an IPv6 multicast address always begins with FF. Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header. Beyond the first eight bits, IPv6 multicast addresses include additional structure to identify flags, their scope, and the multicast group. Figure A-3 shows the structure of the IPv6 multicast address.

Figure A-3 The structure of the IPv6 multicast address

The fields in the multicast address are:

Flags Indicates flags set on the multicast address. The size of this field is 4 bits. As of RFC 3513, the only flag defined is the Transient (T) flag, which uses the low-order bit of the Flags field. When set to 0, the T flag indicates that the multicast address is a permanently assigned (well-known) multicast address allocated by the IANA. When set to 1, the T flag indicates that the multicast address is a transient (non-permanently-assigned) multicast address.
Scope Indicates the scope of the IPv6 network for which the multicast traffic must be delivered. The size of this field is 4 bits. In addition to information provided by multicast routing protocols, routers use the multicast scope to determine whether multicast traffic can be forwarded. Commonly used values for the Scope field include 1 for node-local scope, 2 for link-local scope, and 5 for site-local scope. Additional values for the Scope field are defined in RFC 3513.
Group ID Identifies the multicast group and is unique within the scope. The size of this field is 112 bits. Permanently assigned group IDs are independent of the scope. Transient group IDs are relevant only to a specific scope. Multicast addresses from FF01:: through FF0F:: are reserved, well-known addresses.

To identify all nodes for the node-local and link-local scopes, the following addresses are defined:

FF01::1 (node-local scope all-nodes multicast address)
FF02::1 (link-local scope all-nodes multicast address)

To identify all routers for the node-local, link-local, and site-local scopes, the following addresses are defined:

FF01::2 (node-local scope all-routers multicast address)
FF02::2 (link-local scope all-routers multicast address)
FF05::2 (site-local scope all-routers multicast address)

For the current list of permanently assigned IPv6 multicast addresses, see https://www.iana.org/assignments/ipv6-multicast-addresses.

IPv6 multicast addresses replace all forms of IPv4 broadcast addresses. The IPv4 network broadcast (all host bits are set to 1 in a classful environment), subnet broadcast (all host bits are set to 1 in a classless environment), and limited broadcast (255.255.255.255) addresses are replaced by the link-local scope all-nodes multicast address (FF02::1) in IPv6.

Solicited-Node Address

The solicited-node address facilitates the efficient querying of network nodes during link-layer address resolution, the resolving of a link-layer address of a known IPv6 address. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform link-layer address resolution. However, instead of using the local-link scope all-nodes multicast address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used. The solicited-node multicast address is constructed from the prefix FF02::1:FF00:0/104 and the last 24 bits of the unicast IPv6 address being resolved. Figure A-4 shows the mapping of unicast IPv6 address to its corresponding solicited node multicast address.

Figure A-4 Mapping an IPv6 unicast address to its corresponding solicited node multicast address

For example, Node A is assigned the link-local address of FE80::2AA:FF:FE28:9C5A and is also listening on the corresponding solicited-node multicast address of FF02::1:FF28:9C5A (the bolding is used to highlight the correspondence of the last six hexadecimal digits). Node B on the local link must resolve Node A’s link-local address FE80::2AA:FF:FE28:9C5A to its corresponding link-layer address. Node B sends a Neighbor Solicitation message to the solicited node multicast address of FF02::1:FF28:9C5A. Because Node A is listening on this multicast address, it processes the Neighbor Solicitation message and sends back a unicast Neighbor Advertisement message in reply.

The result of using the solicited-node multicast address is that link-layer address resolutions, a common occurrence on a link, are not using a mechanism that disturbs all network nodes. By using the solicited-node address, very few nodes are disturbed during address resolution. In practice, due to the relationship between the link-layer MAC address, the IPv6 interface ID, and the solicited-node address, the solicited-node address acts as a pseudo-unicast address for very efficient address resolution.

Mapping IPv6 Multicast to MAC-Layer Multicast

To support IPv6 multicasting, the Internet authorities have reserved the multicast address range of 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF for Ethernet MAC addresses. To map an IPv6 multicast address to a MAC-layer multicast address, the low order 32 bits of the IPv6 multicast address are mapped directly to the low order 32 bits in the MAC-layer multicast address. Figure A-5 shows the mapping of an IPv6 multicast address to an Ethernet multicast address.

Figure A-5 Mapping IPv6 multicast addresses to Ethernet multicast addresses

For example:

The link-local scope all-nodes multicast address of FF02::1 maps to the Ethernet multicast address of 33-33-00-00-00-01.
The example solicited-node address of FF02::1:FF3F:2A1C maps to the Ethernet multicast address of 33-33-FF-3F-2A-1C.

Recommended Multicast IPv6 Addresses

Because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast MAC addresses, RFC 3513 recommends assigning the group ID from the low-order 32 bits of the IPv6 multicast address and setting the remaining original Group ID field bits to 0. By using only the low-order 32 bits, each group ID maps to a unique Ethernet multicast MAC address.

Multicast Subnet Membership Management

For multicast subnet group membership, IPv4 nodes use IGMP and IPv6 nodes use MLD.

IGMP for IPv4

Routers and hosts use IGMP to manage subnet host membership in IPv4 multicast groups. IGMP messages take the following forms:

When a host joins a host group, it sends an IGMP Host Membership Report message to the all-hosts IPv4 multicast address (224.0.0.1) or to the specified IPv4 multicast address declaring its membership in a specific host group by referencing the IPv4 multicast address.
When a router polls a network to ensure that there are members of a specific host group, it sends an IGMP Host Membership Query message to the all-hosts IPv4 multicast address. If no responses to the poll are received after several polls, the router assumes no membership in that group for that network and stops advertising that group-network information to other routers.
When a host leaves an IPv4 multicast group and has determined that it is the last member of that group on the subnet, it sends an IGMP Leave Group message.

The Internet Protocol (TCP/IP) component in Windows Server 2003 and Windows XP supports IGMP, IGMP version 2 (IGMP v2), and IGMP version 3 (IGMP v3). There is no IGMP-related configuration required for a Windows-based computer to use all three versions of IGMP.

IGMP is defined in RFC 1112. IGMP v2 is defined in RFC 2236. IGMP v3 is defined in RFC 3376.

MLD for IPv6

MLD is the IPv6 equivalent of IGMP v2 for IPv4. MLD is a set of ICMPv6 messages exchanged by routers and nodes, enabling routers to discover the set of multicast addresses for which there are listening nodes for each attached interface. Like IGMPv2, MLD only discovers the list of multicast addresses for which there is at least one listener, not the list of individual multicast listeners for each multicast address. MLD is described in RFC 2710.

The three types of MLD messages are:

When a host joins a host group, it sends an MLD Multicast Listener Report message to the specific IPv6 multicast address declaring its membership in a specific host group.
When a router polls a network to ensure that there are members of a specific host group, it sends an MLD Multicast Listener Report message to the link-local scope all-hosts IPv6 multicast address (FF02::1).
When a host leaves an IPv6 multicast group and has determined that it is the last member of that group on the subnet, the host sends an MLD Multicast Listener Done message.

Table A-1 lists IGMPv2 messages and their corresponding MLD equivalents.

Table A-1 IGMPv2 messages and their MLD equivalents

IGMPv2 message	MLD equivalent
Host Membership Report	Multicast Listener Report
Host Membership Query	Multicast Listener Query
Leave Group	Multicast Listener Done

IPv4 Multicast Forwarding Support in Windows Server 2003

Multicast forwarding in Windows Server 2003 consists of the following:

IPv4 multicast forwarding by the Internet Protocol (TCP/IP) component
The IGMP routing protocol component of Routing and Remote Access

IPv4 Multicast Forwarding

In Windows, IPv4 multicast forwarding is supported by the Internet Protocol (TCP/IP) component. The Microsoft TCP/IP version 6 protocol component does not support IPv6-based multicast forwarding. IPv4 multicast forwarding is enabled when you configure and enable Routing and Remote Access. The Internet Protocol (TCP/IP) component maintains an IPv4 multicast forwarding table, which can be viewed from the Routing and Remote Access snap-in or by using the netsh routing ip show mfe command.

IGMP Routing Protocol Component

Because there are no multicast routing protocols provided with Windows Server 2003, the maintenance of entries in the IPv4 multicast forwarding table is a function of IGMP, a component that is added as an IPv4 routing protocol.

To add the IGMP routing protocol component, do the following:

Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing And Remote Access.
In the console tree, open Routing And Remote Access, the server name, and then IP Routing.
In the console tree, right-click General, and then click New Routing Protocol.
In the Select Routing Protocol dialog box, click IGMP Router And Proxy, and then click OK.

The IGMP routing protocol component might have already been added, depending on your choices in the Routing and Remote Access Server Setup wizard.

Although the IGMP routing protocol component provides some limited ability to create or extend multicast-enabled IPv4 networks, it is not the equivalent of a multicast routing protocol, such as DVMRP or PIM. It is not recommended for use to create a multicast-enabled IPv4 network of an arbitrary size or topology.

After the IGMP routing protocol is added, you must add router interfaces by doing the following:

Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing And Remote Access.
In the console tree, open Routing And Remote Access, the server name, and then IP Routing.
In the console tree, right-click IGMP, and then click New Interface.
In Interfaces, click the interface you want to enable, and then click OK.
On the General tab of the IGMP Properties dialog box for the interface, verify that the Enable IGMP check box is selected.
Under Mode, click IGMP Router or IGMP Proxy. Under IGMP Protocol Version, select the version of IGMP being used in your network.
Click OK.

Figure A-6 shows the General tab for the properties of an IGMP interface.

Figure A-6 The General tab for the properties of an IGMP interface

Figure A-6 The General tab for the properties of an IGMP interface

When you add an interface to the IGMP routing protocol component in the Routing and Remote Access snap-in, you must configure the interface with one of the following:

IGMP router mode
IGMP proxy mode

IGMP Router Mode

When an IGMP routing protocol interface is configured in IGMP router mode, it performs the following functions:

Listens in multicast promiscuous mode.
Listens for IGMP Host Membership Report messages and Leave Group messages.
Sends IGMP Host Membership Queries.
Maintains entries in the IPv4 multicast forwarding table.

IGMP router mode can be enabled on multiple interfaces. For each interface, a specific version of IGMP can be configured. The default version is IGMP v3.

IGMP Proxy Mode

While the purpose of IGMP router mode is to act as a multicast router, the purpose of IGMP proxy mode is to act as a multicast proxy for hosts on interfaces on which IGMP router mode is enabled. When an IGMP routing protocol interface is configured in IGMP router mode, it performs the following functions:

Forwards IGMP Host Membership Reports

All IGMP Host Membership Reports received on IGMP router mode interfaces are retransmitted on the IGMP proxy mode interface.
Registers multicast MAC addresses

For shared access technologies such as Ethernet, the network adapter is left in unicast listening mode. For each unique group registered by IGMP Host Membership Reports forwarded on the IGMP proxy mode interface, the network adapter is programmed to pass up frames with the corresponding multicast MAC address. Each additional multicast MAC address is an entry in the table of interesting destination MAC addresses on the network adapter. Each network adapter has a maximum number of entries it can store. If the maximum number of entries is used, then the IGMP routing protocol enables multicast promiscuous listening mode on the network adapter.
Adds entries to the multicast forwarding table

When non-local multicast traffic is received on an IGMP router mode interface, the IGMP routing protocol adds or updates an entry to the multicast forwarding table to forward the multicast traffic out the IGMP proxy mode interface. The end result of this process is that any non-local multicast traffic received on IGMP router mode interfaces is flooded, or copied, to the IGMP proxy mode interface.
Receives multicast traffic received on IGMP proxy mode interfaces

Multicast traffic received on the IGMP proxy mode interface corresponding to the groups registered by hosts on IGMP router mode interfaces are forwarded to the appropriate interfaces using the IP protocol and the multicast forwarding table.

The purpose of IGMP proxy mode is to connect a Windows Server 2003 router to a multicast-enabled IPv4 network, such as the multicast backbone of the IPv4 Internet (MBone), or a private intranet that is using multicast routing protocols, such as DVMRP and PIM. Figure A-7 shows an example of using IGMP router mode and IGMP proxy mode to connect a small office network to the MBone.

Figure A-7 Using IGMP proxy mode to connect a small office network to the MBone

The IGMP proxy mode interface acts like a host and joins host groups on behalf of hosts on its IGMP router mode interfaces. Multicast traffic sent to host members on IGMP router mode interfaces are received on the IGMP proxy mode interface and forwarded by the Internet Protocol (TCP/IP) component. Multicast traffic sent by hosts on IGMP router mode interfaces are flooded on the IGMP proxy mode interface where a downstream IPv4 multicast-enabled router can either forward the traffic or ignore it.

IGMP proxy mode can only be enabled on a single IGMP routing protocol interface. The correct interface on which to enable IGMP proxy mode is the interface attached to a subnet containing a multicast router running multicast routing protocols. In other words, the IGMP proxy mode interface "points" to the multicast-enabled intranet.

IPv4 Multicast Address Allocation with MADCAP

The Multicast Address Dynamic Client Allocation Protocol (MADCAP) is an Internet standard for multicast address allocation defined in RFC 2730. The primary benefit of MADCAP is that you can use it to leverage your existing Windows Dynamic Host Configuration Protocol (DHCP) infrastructure to assign multicast IPv4 addresses in the same way that you assign unicast IPv4 addresses.

The multicast address allocation uses the following components:

MADCAP servers

MADCAP servers allocate IPv4 multicast addresses. For Windows, a MADCAP server is a computer running Windows Server 2003 and the DHCP Server service. Using the DHCP snap-in, you must configure and activate at least one multicast scope.
MADCAP clients

MADCAP clients use the MADCAP protocol to request IPv4 multicast addresses from a MADCAP server. Both Windows Server 2003 and Windows XP support a MADCAP application programming interface (API) so that an application can use MADCAP to request, renew, or release a unique IPv4 multicast address from a MADCAP server.

An example of a MADCAP client application is a video conferencing server service that uses MADCAP to receive a unique multicast address and then communicate that address to connecting video clients. After the initial connection negotiation, the video client computer listens on the IPv4 multicast address for the video stream.

Using Multicast Scopes

A multicast scope is a range of IPv4 multicast addresses that the MADCAP server is configured to assign to requesting MADCAP clients. When deciding the multicast address ranges to use for multicast scopes on your MADCAP server, there are two ranges of addresses that are recommended:

Administratively scoped multicast addresses are in the 239.192.0.0/14 range (from 239.192.0.1 to 239.255.255.255) and are intended for use by an organization using multicast scopes privately for its own internal use. Administratively scoped multicast addresses are described in detail in RFC 2365.
Globally scoped multicast addresses are in the range 233.0.0.0/8 (from 233.0.0.1 to 233.255.255.255) and are intended for use by an organization using multicast scopes on the Internet. Within the 233.0.0.0/8 range, the second and third octets are used for the autonomous system (AS) number, assigned to the organization by an Internet Assigned Numbers Authority (IANA) registry. The last octet identifies the multicast group. For more information on AS numbering, see RFC 1930.

The Windows Server 2003 DHCP Server service supports both the DHCP and MADCAP protocols. These protocols function separately and are not dependent on each other. To configure a DHCP-only server, configure DHCP scopes but no multicast scopes. To configure a MADCAP-only server, configure multicast scopes but no DHCP scopes.

To create a multicast scope on a computer running Windows Server 2003 and the DHCP Server service, do the following:

Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click DHCP.
In the console tree, click the applicable DHCP server.
On the Action menu, click New Multicast Scope.
Follow the instructions in the New Multicast Scope wizard.

The New Multicast Scope wizard guides you through the configuration of the multicast address range, exclusions, lease duration, and scope activation.

Reliable Multicast with Pragmatic General Multicast (PGM)

Multicast data streams are typically sent using the User Datagram Protocol (UDP). Transmission Control Protocol (TCP) is not used because it is designed for one-to-one unicast streams of data. Multicast data streams sent over UDP are inherently unreliable because UDP does not provide guaranteed delivery or retransmission of lost packets. Unless reliability is provided by the upper layer protocol, lost packets in UDP-based multicast data streams cannot be detected or recovered.

The Reliable Multicast Transport working group of Internet Engineering Task Force (IETF) has created a set of standards for the reliable transmission of multicast data streams from one or multiple senders to multiple receivers. There are many protocol standards that provide reliable multicast at the transport or application layers. Existing reliable multicast protocols fall into the following four categories:

Negative acknowledgement (NACK)-only

Receivers send NACK packets to request, from the sender, the retransmission of missing packets in the multicast data stream. NACK-only protocols do not require any additional support from routers in the network.
Tree-based acknowledgement (ACK)

Receivers send positive acknowledgments to indicate multicast data packets that are successfully received.
Asynchronous Layered Coding (ALC)

Senders provide forward error correction (FEC) with no messages from receivers or the routers of the network.
Router assist

Receivers send NACK packets. Routers in the network assist with retransmitting lost packets.

PGM Overview

PGM is a router assist type of reliable multicast protocol that is described in RFC 3208. PGM-enabled receivers use NACK packets to request the retransmission of missing packets. PGM-enabled routers in a network define a logical PGM topology and can facilitate the recovery of lost packets by sending them on behalf of the sender. The PGM topology is overlaid on top of the physical IPv4 network topology. PGM routers define a series of PGM hops between a sender and its receivers. Although defined in RFC 3208, PGM routers are not required. The PGM topology of a network can consist of the single logical hop between the sender and the receivers.

PGM does not provide all of the capabilities of TCP for multicast data streams. For example, PGM does not provide sender or receiver-side flow control, byte stream windowing, or congestion control. PGM provides basic reliability for PGM-enabled applications.

PGM is a transport layer multicast protocol that runs directly over IPv4 using protocol number 113. It does not use TCP or UDP for its own messages or for multicast data transmission. PGM is the only reliable multicast protocol supported by Windows Server 2003.

Adding and Using the Reliable Multicast Protocol

To use PGM on computers running Windows Server 2003, you must add the Reliable Multicast Protocol component and create PGM-enabled applications.

Adding the Reliable Multicast Protocol

To add the Reliable Multicast Protocol to a connection, complete the following steps:

Click Start, click Control Panel, and then double-click Network Connections.
In Network Connections, right-click the connection, and then click Properties.
In the properties dialog box for the connection, click Install.
In Select Network Component Type, double-click Protocol.
In the Network Protocol list, click Reliable Multicast Protocol, and then click OK.
To save changes to the connection properties, click Close.

The Reliable Multicast Protocol component appears in the list of items being used by the connection, but has no configurable properties.

Writing PGM-enabled Applications

To use PGM, an application must use Windows Sockets and the PGM socket options. A sender application uses Windows Sockets to create a PGM socket, bind the socket to any address, and then connect to the multicast group address. A receiver application uses Windows Sockets to create a PGM socket, bind the socket to the multicast group address, post a listen on the new socket, and then use the accept() function to obtain a socket handle for the PGM session.

Microsoft products that use PGM include Message Queuing (also known as MSMQ) and Automated Deployment Services (ADS).

How PGM and the Reliable Multicast Protocol Works

A receiver uses the following process:

The multicast application opens a listen socket with the appropriate reliable multicast socket options.
The receiver sends an IGMP Host Membership Report message to inform the local routers of the receiver's membership in the multicast group.

A sender uses the following process:

The multicast application opens a send socket with the appropriate reliable multicast socket options.
The multicast application begins to send data. PGM packets containing data are sent beginning with a sequence number of 0, and are incremented by 1 for subsequent packets.
The multicast-enabled routers forward the multicast data packets throughout the IPv4 network to the subnets that contain group members.

When a receiver determines that there is a missing packet, it sends a PGM message to its nearest PGM router, requesting that the missing packet with a specific sequence number be resent. This request is forwarded to either the original source or a PGM router that stores copies of recent packets sent by the source. In either case, the missing packet is sent directly to the requesting receiver.