How IPv4 Multicasting Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

• IP Multicasting Architecture

• IP Multicasting Protocols

• IP Multicasting Processes and Interactions

• IP Multicasting with Routing and Remote Access

• IP Multicasting Interfaces

• Related Information

Internet Protocol (IP) multicasting is the sending of a single datagram to multiple hosts on a network or internetwork. Of the three delivery methods supported by IP, multicasting is the method that is most practical for one-to-many delivery. Unlike IP multicasting, IP unicasting sends a separate datagram to each recipient host. IP broadcasting sends a single datagram to all hosts on a single network segment (also known as subnet), even to those not interested in receiving it. Recent trends toward multimedia applications such as video conferencing necessitate the use of multicasting to efficiently send traffic to multiple hosts.

Before sending or receiving IP multicast data, a network must be enabled for multicasting, as follows:

• Hosts must be configured to send and receive multicast data..

• Routers must support the Internet Group Membership Protocol (IGMP), multicast forwarding, and multicast routing protocols.

Windows Server 2003 supports IP multicasting in the following ways:

• All computers running Windows Server 2003 can both send and receive multicast data.

• Windows Server 2003 TCP/IP (IPv4) can forward multicast IP traffic.

• Windows Server 2003 Routing and Remote Access supports IGMP for forwarding multicast traffic in a single-router intranet and for passing group membership information from a single-router intranet to a multicast-enabled intranet or the Internet.

• Routing and Remote Access provides a platform for true IP multicast routing protocols for forwarding multicast traffic across an intranet.

This section covers the following:

• The components of IP multicasting and the role of each

• The protocols that support multicasting

• How multicasting works

• How Routing and Remote Access supports multicasting

• The interfaces available for developing multicast-enabled applications and multicast routing protocols

This document describes how multicasting works in an IPv4 network. In addition to IPv4, the Windows Server 2003 family includes the latest version of IP, known as IP version 6 (IPv6). For information about how multicasting works with IPv6, see “IPv6 Technical Reference.”

IP Multicasting Architecture

To support multicasting in an internetwork, the hosts and routers must be multicast-enabled. In an IP multicast-enabled intranet, any host can send IP multicast datagrams, and any host can receive IP multicast datagrams, including sending and receiving across the Internet.

The source host sends multicast datagrams to a single Class D IP address, known as the group address. Any host that is interested in receiving the datagrams contacts a local router to join the multicast group and then receives all subsequent datagrams sent to that address.

Routers use a multicast routing protocol to determine which subnets include at least one interested multicast group member and to forward multicast datagrams only to those subnets that have group members or a router that has downstream group members. The IP header of a multicast datagram includes a Time-to-Live (TTL) value that determines how far routers can forward a multicast datagram.

The following figure shows how multicasting components fit in an internetwork.

IP Multicasting Architecture

In this illustration, the following is occurring:

1. Host A in Subnet 1 is the multicasting source and is sending multicast data to the multicast group address.

2. Host B in Subnet 1 has requested group membership from its local router. Because Host B has joined the multicast group, its network adapter is listening for datagrams sent to the multicast group address. The remaining host in Subnet 1 has not requested group membership, so its network adapter is filtering out traffic sent to the multicast group address.

3. Routers forward multicast data to any subnet that has group members or a router that has downstream group members. In this example, the routers are forwarding multicast data from Subnet 1 to Subnet 3. The data is also sent across Subnet 2, although it has no group members, because there are downstream group members.

4. Host C in Subnet 3 has requested group membership and is also receiving the multicast data.

5. Host D in Subnet 3 is sending a request to its local router to join the group. After Host D joins the group, its network adapter will also listen for traffic sent to the multicast group address.

Alternatively, multicast data might come from the multicast-enabled portion of the Internet, known as the MBone.

The following table introduces the multicasting components, which are described later in this section.

IP Multicasting Components

Component	Description
Host (source or receiver)	A host is any client or server on the network. A multicast-enabled host is configured to send and receive (or only send) multicast data.
Router	A multicast router is capable of handling host requests to join or leave a group and of forwarding multicast data to subnets that contain group members. A multicast router can be either a non-Microsoft router that uses a multicast routing protocol or a Windows Server 2003-based server running the Routing and Remote Access service.
Multicast address	A Class D IP address used for sending IP multicast data. An IP multicast source sends the data to a single multicast address, as described later in this section. A specific IP multicast address is also known as a group address.
Multicast group	A multicast group is the set of hosts that listen for a specific IP multicast address. A multicast group is also known as a host group.
MBone	The Internet multicast backbone, or the portion of the Internet that supports multicast routing.

Host

On a multicast-enabled network, a host that is configured to send multicast data can send datagrams to a single designated Class D IP address so that multiple hosts can receive the data. A host that is configured to receive multicast data can use IGMP to join a multicast group and then listen for datagrams sent to the multicast address. Hosts can send and receive multicast data from anywhere on an intranet or the Internet.

A host supports IP multicasting at one of the following levels:

• Level 0 - No support for sending or receiving IP multicast datagrams.

• Level 1 - Supports sending but not receiving IP multicast datagrams.

• Level 2 - Supports both sending and receiving IP multicast datagrams.

TCP/IP for Windows Server 2003 (as well as Windows XP) supports all levels of IP multicasting and, by default, is configured for Level 2 support. You can modify the level of support by changing the IGMPLevel subkey under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry.

Note

• It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

Router

The role of a multicast router is to:

• Manage multicast group membership by processing IGMP requests to join or leave groups.

• Forward multicast traffic to subnets of the internetwork that contain multicast group members.

Multicast routing is more complex than unicast routing. The following table compares the characteristics of unicast routing and multicast routing.

Unicast Routing and Multicast Routing Comparison

Unicast Routing Characteristics	Multicast Routing Characteristics
Unicast traffic is sent to a globally unique destination.	Multicast traffic is sent to an ambiguous group destination.
Unicast routes in the routing table summarize ranges of globally unique destinations.	Because group addresses represent different groups with different members, group addresses generally cannot be summarized in the IP multicast forwarding table.
Unicast routes are comparatively consistent, so the routing table needs to be updated only when the topology of the internetwork changes. Unicast routing protocols update the unicast routing table.	The location of group members is not consistent, so the IP multicast forwarding table might need to be updated whenever a group member joins or leaves a multicast group. Multicast routing protocols update the IP multicast forwarding table.

Multicast routers can be hardware or software routers. Non-Microsoft routers that are multicast-enabled run a multicast routing protocol, such as one of the following:

• Distance Vector Multicast Routing Protocol (DVMRP)

• Multicast Extensions to Open Shortest Path First (MOSPF)

• Protocol Independent Multicast (PIM)

These protocols are briefly described later in this document. These protocols are not included with Windows Server 2003.

Windows Server 2003 Routing and Remote Access can be used for multicast forwarding. The Routing and Remote Access service includes an IGMP routing protocol component that uses two modes, router mode and proxy mode, to add entries to the TCP/IP multicast forwarding table. Because Routing and Remote Access is not designed to replace a true multicast routing protocol, it supports several specific configurations, which are described later in this document.

Multicast Addresses

IP addresses in the Class D range are reserved for IP multicasting. Class D addresses are in the range of 224.0.0.0 to 239.255.255.255, with the four high-order bits always set to 1110. In network prefix or classless interdomain routing (CIDR) notation, IP multicast addresses are summarized as 224.0.0.0/4.

Within the Class D range of addresses, certain ranges of multicast addresses have special meaning, as follows:

• Addresses in the range of 224.0.0.0 to 224.0.0.255 (224.0.0.0/24) are reserved for local subnet multicast traffic. Datagrams sent to addresses in this range are not forwarded by IP routers.

• Addresses in the range of 224.0.1.0 to 238.255.255.255 are known as globally scoped addresses, which means they can be used for multicasting across an intranet or the Internet. Some addresses within this range are reserved by the Internet Assigned Numbers Authority (IANA) for special purposes.

• Addresses in the range of 239.0.0.0 to 239.255.255.255 (239.0.0.0/8) are reserved for administratively scoped addresses. Administratively scoped addresses as defined by RFC 2365 are used to prevent the forwarding of multicast traffic across boundaries configured for the address. Multicast boundaries are described in more detail later in this document.

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

• 224.0.0.6 - OSPF version 2, designed to reach all OSPF-designated routers and designated backup routers

• 224.0.0.9 - Routing Information Protocol (RIP) version 2

• 224.0.1.1 - Network Time Protocol

For the latest list of reserved multicast addresses, see the IANA link.

MAC-Level Multicast Addresses

As described previously, a multicast datagram is sent to a single group address, and only members of the group receive the datagram. For a network adapter to receive a multicast datagram, the IP multicast address must be mapped to a hardware, or media access control (MAC), multicast address. The network adapter then listens for any datagrams that are addressed to this MAC-level address and passes the datagrams up to the operating system.

The Internet Assigned Numbers Authority (IANA) has reserved a range of multicast addresses for Ethernet and Fiber Distributed Data Interface (FDDI) networks. The following table lists the MAC-level multicast addresses used for different types of networks.

MAC-Level Multicast Addresses

Network Type	Multicast Addresses	Related RFC
Ethernet and FDDI	0x01-00-5E-00-00-00 to 0x01-00-5E-7F-FF-FF	1112
Token Ring	0xC0-00-00-04-00-00	1469

Token Ring can use the same method of MAC-level multicast addressing as Ethernet and FDDI, but many Token Ring network adapters do not support it. By default, therefore, all IP multicast addresses on Token Ring networks are mapped to the single functional address specified in the preceding table. You can modify the use of this functional address by editing the TrFunctionalMcastAddress subkey under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry. IP multicasting on Token Ring network adapters is supported for Windows 2000, Windows XP, and the Windows Server 2003 family.

Note

• It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

IP Multicast to MAC-Level Multicast Address Mapping

To map an IP multicast address to a MAC-level multicast address, the 23 low-order bits of the IP multicast address are mapped directly to the 23 low-order bits of the MAC-level multicast address. The 25 high-order bits in the MAC-level multicast address are fixed. The following figure illustrates how the IP multicast address is mapped to the MAC-level multicast address.

IP Multicast Address Mapped to Ethernet or FDDI MAC Address

This figure also illustrates the following:

• The 4 high-order bits of the IP multicast address are fixed according to the Class D address definition.

• The 5 remaining bits (bits 5 to 9) in the IP multicast address are not mapped to the MAC-level multicast address, so the resulting MAC address is not unique. This means that it is possible for a host to receive MAC-level multicast datagrams for up to 32 groups to which it does not belong. However, IP drops datagrams that do not match a multicast address that is registered by an application or another protocol.

• The low-order bit of the first octet in a MAC-level destination address is the Individual/Group bit. This bit is set to 0 for a unicast or individual address and to 1 for a multicast address or a broadcast address.

Example of MAC-level address mapping

If the IP multicast address is 224.192.16.1, the MAC-level multicast address becomes 0x01-00-5E-40-10-01, as illustrated in the following figure.

Sample Address Mapping

The 23 low-order bits in the IP multicast address map directly to the MAC-level multicast address. Because the entire third and fourth octets are included in the mapping, they can be converted directly to hexadecimal. The high-order bit of the second octet is dropped from the mapping, so that octet must be converted to binary first. In this example, dropping the high-order bit results in a value of 1000000, which converts to decimal 64 and hexadecimal 0x40. The shading in the figure shows that the 25 high-order bits of the MAC-level multicast address are fixed values.

Multicast Groups

The set of hosts listening for a specific IP multicast address is called a multicast group or a host group. Multicast groups have the following attributes:

• Group membership is dynamic; hosts can join and leave the group at any time.

• Members of a group can be located anywhere on a multicast-enabled network.

• A host need not be a member of a multicast group to send data to the group’s IP multicast address.

• Group members can receive both unicast and multicast traffic.

• A host can be a member of any number of multicast groups.

• A multicast group has no size limits.

• Multicast groups can be either transient or permanent. Permanent groups are assigned a well-known multicast address. For example, multicast address 224.0.0.1 is a permanent address for the all-hosts multicast group. Membership in a permanent group is transient; only the address is permanent.

MBone

The MBone, or Internet multicast backbone, is the portion of the Internet that supports the forwarding of Internet-based IP multicast traffic. The MBone, used in conjunction with tunneling, provides a way for multicast traffic to travel across portions of the Internet that do not support multicasting.

Tunneling is the encapsulation of a datagram within another datagram. For multicast traffic to traverse the Internet, each IP multicast datagram must be encapsulated within an IP unicast datagram, which is known as IP-in-IP tunneling. An IP-in-IP tunnel is used to forward information between endpoints in an IP internetwork that have differing capabilities, thus acting as a logical link between the endpoints. The encapsulating IP header includes the addresses of the endpoints as the source and destination addresses. The following figure illustrates an encapsulated IP datagram.

IP-in-IP Datagram Structure

The MBone consists of a series of multicast-enabled islands. These islands are collections of contiguous networks that use routers that support multicast routing. IP-in-IP tunneling allows the multicast traffic to travel from one island to another. The IP header of the unicast datagram is addressed from a router in one multicast-enabled island to a router in another multicast-enabled island.

The MBone is used for audio and video multicasts of Internet Engineering Task Force (IETF), the National Aeronautics and Space Administration, and the United States House of Representatives and Senate meetings, among other uses. Support for the MBone can vary among Internet service providers (ISPs).

IP Multicasting Protocols

A variety of protocols are used for various aspects of IP multicasting. The following table briefly identifies the protocols described in this section.

Protocols Used for IP Multicasting

Protocol	Description	RFC
IGMP	Internet Group Management Protocol. Hosts use this protocol to make group membership requests. Routers use this protocol to query for active group members in a subnet. (Note: IPv6 uses Multicast Listener Discovery (MLD) instead of IGMP to manage group membership.)	1112
DVMRP	Distance Vector Multicast Routing Protocol. This is a multicast routing protocol.	1075
MOSPF	Multicast Extensions to Open Shortest Path First. This is a multicast routing protocol.	1584
PIM	Protocol-Independent Multicast. This is a multicast routing protocol.	2117
MADCAP	Multicast Address Dynamic Client Allocation Protocol. This protocol enables a host to request an IP multicast address from a multicast address allocation server.	2730
PGM	Pragmatic General Multicast. PGM is a reliable multicast transport protocol. Typically, multicast datagrams are delivered by using UDP, which is an inherently unreliable transport protocol. Hosts and routers that are PGM-enabled can recover lost multicast datagrams.	3208

IGMP

Internet Group Management Protocol (IGMP) maintains host group membership on a local subnet. Hosts use IGMP to communicate multicast group membership requests with their local multicast router. Routers receive the group membership requests and periodically send out queries to determine which host groups are active or inactive on the local subnet. This protocol is required to support Level 2 multicasting.

IGMP messages are encapsulated in IP datagrams and use IP protocol number 0x02. The following illustrates the resulting datagram.

Encapsulated IGMP Message

There are three versions of IGMP:

• IGMP version 1 is provided by TCP/IP for Microsoft Windows NT Server 4.0 Service Pack 3 and earlier.

• IGMP version 2 is provided by TCP/IP for Microsoft Windows NT Server 4.0 Service Pack 4 and later and Windows 2000. Routers using this version are backward-compatible with hosts using IGMP version 1.

• IGMP version 3 is provided by TCP/IP for Windows XP and Windows Server 2003. Routers using this version are backward-compatible with hosts using IGMP version 2 or IGMP version 1. Hosts running Windows XP or Windows Server 2003 use IGMP version 3 by default. To configure a host running Windows XP SP2 or later to use IGMP version 1 or IGMP version 2, use the IGMPVersion subkey under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ in the registry.

  Note

  • It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.

This section describes the differences between the three versions of IGMP.

IGMP Version 1

IGMP version 1 consists of the following two types of messages:

• Host Membership Report

• Host Membership Query

The following table describes the fields in IGMP version 1 messages.

Fields in IGMP Version 1 Messages

IGMP Version 1 Field	Length	Description
Version	4 bits	Identifies the IGMP version. It is set to 1.
Type	4 bits	Identifies the type of message: 0x1 for Host Membership Query 0x2 for Host Membership Report
Unused	1 octet	Set to 0 by sender, ignored by receiver.
Checksum	2 octets	Used to test for data transmission errors.
Group Address	4 octets	Specifies the group address for the type of message: 0.0.0.0 for Host Membership Query The multicast group address to be joined for Host Membership Report

Host Membership Report

To join a multicast group, a host sends an IGMP Host Membership Report message to the specific group address, regardless of whether other hosts on the subnet are already multicast group members. Unlike a multicast router, a host does not keep track of the multicast group membership of other hosts on its subnet. A multicast router uses a special listening mode called multicast promiscuous mode so that it can receive all IP multicast traffic. Because it listens in multicast promiscuous mode, a multicast router receives and processes IGMP Host Membership Report messages that are sent to any multicast address.

Host Membership Query

An IGMP version 1 multicast router (known as a multicast query router) periodically sends an IGMP Host Membership Query message to IP address 224.0.0.1 (the all-hosts group) to obtain updated information about multicast group membership on the subnet. The multicast routing protocols determine which router is to send the query messages.

Multicast routers do not need to track the specific hosts that belong to a group, but only that at least one host in a subnet belongs to the group. For each multicast group that has members on the subnet, one multicast group member responds 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 on the hosts delays the transmission of the IGMP Host Membership Report message. If another host on the same subnet sends a message before the response timer expires, a host does not send its own message.

Addresses and TTLs used for IGMP version 1 messages

The following table summarizes the values of the source and destination IP addresses in the IP header, the TTL in the IP header, and the Group Address in the IGMP header for the two types of IGMP version 1 messages.

Addresses and TTLs Used for IGMP Version 1 Messages

Address	IGMP Host Membership Report	IGMP Host Membership Query
Source IP address (IP header)	<HostInterfaceIPAddress>	<RouterInterfaceIPAddress>
Destination IP address (IP header)	<GroupAddress>	224.0.0.1
TTL	1	1
Group address	<GroupAddress>	0.0.0.0

IGMP version 1 has no explicit mechanism for hosts to notify a router that it is ready to leave a multicast group.

For more information about IGMP version 1, see Appendix I of RFC 1112 in the IETF RFC Database.

IGMP Version 2

IGMP version 2 extends the functionality of IGMP version 1 by including the following:

• A procedure for determining which router in a subnet is to be the multicast query router

• A new message for when hosts leave a multicast group

• A new group-specific query message

• A new version of the Host Membership Report

The following table describes the fields in IGMP version 2 messages.

Fields in IGMP Version 2 Messages

IGMP Version 2 Field	Length	Description
Type	1 octet	Identifies the type of message: 0x11 for Host Membership Query 0x12 for IGMP version 1 Host Membership Report 0x16 for IGMP version 2 Host Membership Report 0x17 for Leave Group Message
Maximum Response Time	1 octet	Specifies the maximum allowable time (in tenths of a second) for a host to respond to a router query. Used only in query messages. For Routing and Remote Access routers, this value is configured with the Query response interval from either of the following sources: Routing and Remote Access Microsoft Management Console (MMC) snap-in Router tab for the IGMP interface properties Netsh routing ip igmp set interface command
Checksum	2 octets	Used to test for data transmission errors.
Group Address	4 octets	Specifies the group address for the type of message: 0.0.0.0 for general Host Membership Query message The specific multicast group address for Group-Specific Host Membership Query, Host Membership Report, and Leave Group messages

Note

• The Version field is eliminated and the Type field is 8 bits in IGMP version 2. The hexadecimal value of the Type field in version 2 messages is the result of concatenating the version 1 hexadecimal values of the Version field (0x1) and the Type field (0x1 for Host Membership Query and 0x2 for Host Membership Report).

Query router election

In contrast to IGMP version 1, in which the multicast routing protocols determine the multicast query router, IGMP version 2 uses a simple election process to choose one router on each subnet to send the periodic IGMP Host Membership Query messages. The elected router is the one with the numerically lowest IP address. During the election process, each router listens for IGMP queries from other routers. If a router receives a query with a lower source IP address, that router does not send multicast queries. If a router does not receive a query with a lower source IP address, it becomes the multicast query router for the subnet.

Leave Group message

The Leave Group message reduces leave latency, which is the time it takes for a multicast router to stop forwarding multicast traffic to a subnet that no longer contains multicast group members. If a host responds to the last IGMP query, it might be the last or only member of the multicast group. When this host leaves the group, it sends an IGMP Leave Group message to the all-routers multicast group (224.0.0.2). Upon receipt of the Leave Group message, the router sends a series of group-specific queries to the multicast group. If no host responds to the group-specific queries, the router determines that the multicast group on that subnet contains no members.

IGMP group-specific query

An IGMP Host Membership Query is sent to 224.0.0.1 (the all-hosts group) to find out which multicast groups have members on the subnet. IGMP version 2 routers can also send a group-specific query to a specific group address to find out if that group has any members on the subnet.

IGMP version 2 Host Membership Report

The IGMP version 2 Host Membership Report has the same function as the IGMP version 1 Host Membership Report, except that it is used by IGMP version 2 routers.

Addresses and TTLs used for IGMP version 2 messages

The following table summarizes the values of the source IP address, the destination IP address and the TTL in the IP header, as well as the value of the Group Address in the IGMP header for the two additional types of IGMP version 2 messages.

Addresses and TTLs Used for IGMP Version 2 Messages

Address	IGMP Leave Group Message	IGMP Group-Specific Query
Source IP address (IP header)	<HostInterfaceIPAddress>	<RouterInterfaceIPAddress>
Destination IP address (IP header)	224.0.0.2	<GroupBeingQueried>
TTL	1	1
Group address	<GroupBeingLeft>	<GroupBeingQueried>

For more information about IGMP version 2, see RFC 2236 in the IETF RFC Database.

IGMP Version 3

IGMP version 3 extends the functionality of IGMP version 2 by adding support for source filtering, also known as source-specific multicasting. With IGMP version 3, it is possible to have multiple sources for a multicast data stream so that hosts can join the group and receive the data from the nearest source. For example, you might use this feature for an organization-wide video conference. You can have multiple sources multicast the video conference and place the sources in different regions so that hosts can join the group and specify the source topologically nearest them.

IGMP version 3 has a modified version of the Host Membership Query message and includes a new version of the Host Membership Report.

Source filtering

Source filtering is the ability of a host to specify that it receive multicast traffic only from specific source addresses. With IGMP version 1 and IGMP version 2, a host reports group membership regardless of the source of the multicast traffic sent to its group. If multicast traffic is sent to a group from multiple sources, a subnet with a group member receives one multicast datagram from each source.

IGMP version 3 allows a host to specify either of the following for a particular multicast group:

• The sources from which it is to receive messages pertaining to the group (a list of included sources).

• The sources from which it is not to receive messages pertaining to the group (a list of excluded sources).

Multicast routers and multicast routing protocols use the source-specific information in the IGMP version 3 Host Membership Report message to prevent forwarding and delivering multicast messages from specific sources to subnets that have no interested group members.

IGMP version 3 Host Membership Query

The IGMP version 3 Host Membership Query message has the same Type value and the same format as the IGMP version 2 Host Membership Query message, except that it includes additional fields after the Group Address field. The additional fields provide query parameters for routers and specify the included or excluded sources for the multicast group being queried. The list of included or excluded sources is used only for queries to a specific group that uses source filtering.

The first 8 octets of the IGMP version 3 Host Membership Query message are the same as IGMP version 2. The Type value for the modified Host Membership Query remains 0x11. The following table describes the fields in IGMP version 3 Host Membership Query messages.

Fields in IGMP Version 3 Host Membership Query Messages

IGMP Version 3 Field	Length	Description
Type	1 octet	Identifies the type of message: 0x11 for Host Membership Query
Maximum Response Time	1 octet	Specifies the maximum allowable time (in tenths of a second) for a host to respond to a general (not group-specific) router query. For Routing and Remote Access routers, this value is configured with the Query response interval from either of the following sources: Routing and Remote Access snap-in Router tab for the IGMP interface properties Netsh routing ip igmp set interface command
Checksum	2 octets	Used to test for data transmission errors.
Group Address	4 octets	Specifies the group address for the query message: 0.0.0.0 for general Host Membership Query The specific multicast group address for Group-Specific Host Membership Query, Host Membership Report, and Leave Group
Reserved	4 bits	Set to 0 by sender, ignored by receiver.
Suppress Router-Side Processing	1 bit	Set to 1 to specify that receiving routers are to suppress normal timer updates when they receive a query.
Querier’s Robustness Variable (QRV)	3 bits	Allows tuning for expected datagram loss on the network. IGMP can recover QRV-1 lost datagrams. For Routing and Remote Access routers, this value is configured with the Robustness variable from either of the following sources: Routing and Remote Access snap-in Router tab for the IGMP interface properties Netsh routing ip igmp set interface command
Querier’s Query Interval Code	1 octet	Specifies how many seconds the router waits between general queries. For Routing and Remote Access routers, this value is configured with the Query interval from either of the following sources: Routing and Remote Access snap-in Router tab for the IGMP interface properties Netsh routing ip igmp set interface command
Number of Sources	2 octets	Specifies the number of source addresses included in the query message.
Source Addresses	4 octets per address	Specifies the IP addresses of multicast sources.

IGMP version 3 Host Membership Report

A host uses the IGMP version 3 Host Membership Report message to specify all the multicast groups it wants to join, and for each group address, either the sources from which it is to receive multicast data (the list of included sources) or the sources from which it is not to receive multicast data (the list of excluded sources).

The IGMP version 3 Host Membership Report message contains a series of group records. Each record contains the multicast group address and the associated list of sources. The Host Membership Report message is sent to the multicast address 224.0.0.22, which is a reserved multicast address for all IGMP version 3-capable multicast routers.

The following table describes the fields in IGMP version 3 Host Membership Report messages.

Fields in IGMP Version 3 Host Membership Report Messages

IGMP Version 3 Field	Length	Description
Type	1 octet	Identifies the type of message: 0x12 for IGMP version 1 Host Membership Report 0x16 for IGMP version 2 Host Membership Report 0x22 for IGMP version 3 Host Membership Report
Reserved	1 octet	Set to 0 by sender, ignored by receiver.
Checksum	2 octets	Used to test for data transmission errors.
Reserved	2 octets	Set to 0 by sender, ignored by receiver.
Number of Records	2 octets	Specifies the number of group records in the message.
Group Records	Variable	Each record specifies the IP address for a multicast group being joined or left and a list of included or excluded sources.

Addresses and TTLs used for IGMP version 3 messages

The following table summarizes the values of the source and destination IP addresses, the TTL in the IP header, and the value of the Group Address in the IGMP header for the two additional types of IGMP version 3 messages.

Addresses and TTLs Used for IGMP Version 3 Messages

Address	IGMP Host Membership Query for Specific Groups and Sources	IGMP Host Membership Report
Source IP address (IP header)	<RouterInterfaceIPAddress>	<HostInterfaceIPAddress>
Destination IP address (IP header)	<GroupBeingQueried>	224.0.0.22
TTL (IP header)	1	1
Group address (IGMP header)	<GroupBeingQueried>	<GroupAddress> in individual group address records

For more information about IGMP version 3, see RFC 3376 in the IETF RFC Database.

Multicast Routing Protocols: DVMRP, MOSPF, and PIM

The goals of multicast routing protocols include the following:

• Forward traffic away from the source to prevent loops.

• Minimize or eliminate multicast traffic to subnets that do not need to receive it.

• Minimize CPU and memory load on the router for scalability.

• Minimize the traffic overhead of a routing protocol.

• Minimize the join latency, which is the time it takes for the first group member on a subnet to begin receiving group traffic.

Multicast routing protocols use a variety of algorithms to create efficient multicast delivery paths through the internetwork. Unicast routers use the IP destination address to forward traffic toward the destination. Because multicast traffic is sent to a group address, multicast routers use the source address to forward traffic away from the source to avoid looping the traffic back to the source.

This section provides a brief introduction to the most common multicasting routing protocols. These protocols are not provided with Windows Server 2003.

Distance Vector Multicast Routing Protocol (DVMRP)

DVMRP is a multicast routing protocol that grew from Routing Information Protocol (RIP), a unicast routing protocol that forwards datagrams based on information about the next hop toward the destination. In contrast to RIP, DVMRP forwards datagrams based on information about the previous hop back toward the source.

DVMRP builds a delivery tree for determining where to forward datagrams. It floods the first multicast datagrams to a multicast group across the internetwork and then prunes the branches of the tree that lead to subnets that do not include group members.

DVMRP is most efficient in environments where multicast group members are densely distributed over the internetwork. DVMRP runs on internetworks with multicast routers and also supports tunneling (encapsulating multicast datagrams within a unicast datagram for forwarding through non-multicast routers). DVMRP does not scale well.

Multicast Extensions to OSPF (MOSPF)

MOSPF is a multicast routing protocol that is an extension to Open Shortest Path First (OSPF). This protocol builds a delivery tree for determining where to forward datagrams by using group membership information from IGMP and the OSPF link-state database. The trees are built on demand for each source-group pair.

MOSPF is intended for use on a single organization’s network and does not scale well. MOSPF requires OSPF as its accompanying unicast routing protocol. It can sometimes put a heavy load on router CPU bandwidth.

MOSPF is most efficient in environments where multicast group members are densely distributed over the internetwork. It does not support tunneling but can work in multicast environments with non-MOSPF routers.

Protocol-Independent Multicast (PIM)

PIM consists of two protocols: PIM Dense Mode (PIM-DM) and PIM Sparse Mode (PIM-SM). PIM-DM is most efficient in environments where multicast group members are densely distributed over the internetwork. PIM-SM is most efficient in environments where group members are sparsely distributed. A multicast group that uses PIM can declare itself sparse or dense.

The PIM protocol establishes routes to multicast groups whose members span wide-area and interdomain internetworks. PIM functions independently of any specific unicast routing protocol, although it does use the existing unicast routing table.

PIM-DM

This protocol is designed for multicast groups whose members are distributed densely over an area where bandwidth is plentiful. Like DVMRP, PIM-DM first floods multicast traffic across the internetwork and then prunes the subnets that have no group members.

PIM-DM is interoperable with PIM-SM. PIM-DM does not scale well.

PIM-SM

PIM-SM is the most widely used multicast routing protocol. It is designed for multicast groups with members distributed sparsely across a large region and is most efficient in a WAN environment. The flood-and-prune method used by PIM-DM can cause unnecessary traffic. In contrast, PIM-SM forwards multicast traffic only to routers that explicitly request it. With PIM-SM, routers must explicitly join and leave multicast groups to receive or stop receiving multicast traffic.

MADCAP

Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a method for hosts to request a multicast address from a multicast address allocation server. If multiple hosts use the same IP multicast address for different applications, multicast traffic can be forwarded to the incorrect group members. MADCAP prevents this problem by allocating unique multicast addresses. It supports dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

MADCAP is an extension of the Dynamic Host Configuration Protocol (DHCP) standard, but is separate from DHCP. The Windows Server 2003 DHCP service supports both DHCP and MADCAP, but the functions are independent.

Multicast administrative scopes configured on the DHCP server define ranges of IP multicast addresses. Unique IP multicast addresses are allocated to a single DHCP client, similar to how unique unicast IP addresses are assigned to clients.

For more information about MADCAP and its support in Windows Server 2003, see “DHCP Technical Reference.” For more information about the IETF definition of MADCAP, see RFC 2730 in the IETF RFC Database.

PGM

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for multicast-enabled applications that require properly sequenced, duplicate-free delivery of datagrams. Typically, multicast datagrams are sent as UDP datagrams, but UDP is inherently unreliable because it does not guarantee packet delivery or retransmit lost packets. PGM ensures that a host that is a member of a multicast group either receives all the transmitted datagrams or detects unrecoverable lost datagrams. It is implemented on both source and destination hosts.

PGM is a transport-layer protocol that runs directly over IP and uses IP protocol number 113. It is the type of reliable multicast protocol known as router assist. With this type of protocol, PGM-enabled receiving hosts use negative acknowledgement (NAK) packets to request the retransmission of lost multicast datagrams, and PGM-enabled routers on the network can retransmit lost packets on behalf of the sender. The PGM-enabled routers define a logical PGM topology that overlays the physical IP internetwork topology. This topology defines the series of hops used for PGM packets between the sending host and the receiving hosts. Routers are not required for PGM: the PGM topology can consist of a single logical hop between the sending host and its receiving hosts.

PGM is currently the only reliable multicast protocol supported by Windows Server 2003. To use PGM with Windows Server 2003, you must add the Reliable Multicast Protocol component in Network Connections to sending and receiving hosts and create PGM-enabled applications. For more information about creating PGM-enabled applications, see “Reliable Multicast Programming (PGM)” on MSDN.

With PGM, a session is established during multicast datagram transmission. The source host caches transmission for retransmission in the event of an error. If a receiving host detects an error, it sends a unicast NAK to the next upstream PGM router. The PGM router confirms receipt of the NAK packet and forwards the NAK packet upstream until it reaches the source host. The source host then retransmits the datagram and routers forward it only to the subnets that require it.

IP Multicasting Processes and Interactions

In a multicast-enabled intranet, hosts send and receive multicast datagrams and routers manage group membership and forward multicast datagrams. The Windows Server 2003 implementation of TCP/IP supports all levels of multicasting.

Host Processes

In a Level 2 multicast-enabled intranet, any host can send IP multicast datagrams to any group address, and any host can receive IP multicast datagrams from any group address. In a Level 1 multicast-enabled intranet, any host can send multicast datagrams but cannot receive them. This section describes what happens when hosts send and receive multicast datagrams.

Sending IP Multicast Datagrams

To send IP multicast datagrams, a host determines the IP multicast address to use, constructs the multicast datagram, and then places the multicast datagram on the medium.

An IP multicast address can be obtained in any of the following ways:

• Assigned by the application

• Selected from well-known (reserved) IP multicast addresses defined by the IANA

• Allocated by an address allocation protocol, such as MADCAP

The sending host constructs the IP datagram by using its own IP address as the source address, the obtained IP multicast address as the destination address, and an appropriate TTL value.

The TTL value for an IP multicast datagram determines how many subnets the datagram can travel. As specified earlier, IP multicast addresses in the range 224.0.0.0 to 224.0.0.255 (224.0.0.0/24) are reserved for local subnet multicast traffic. By convention, the TTL value is 1 for a datagram sent to an address in this range, but routers do not forward multicast traffic sent to an address in this range even if the TTL is greater than 1. For multicast datagrams that are to be forwarded across an intranet or the Internet, the TTL value must be high enough to reach all members of the multicast group. The following table describes the conventional definitions for TTL values.

TTL Value Conventional Definitions

TTL Value	Definition
0	Restricted to the same host
1	Restricted to the local subnet, no router hops
32	Restricted to the site
64	Restricted to the region
128	Restricted to the continent
255	Worldwide (unrestricted)

After the host constructs the IP multicast datagram, the datagram passes through the IP routing process and is sent to Address Resolution Protocol (ARP), which maps the IP address to the hardware address. An ARP extension processes IP multicast addresses. If the IP address is in the multicast range, ARP does not check the ARP cache or broadcast a request datagram to locate the corresponding MAC address. Instead, for Ethernet and FDDI networks, ARP maps the IP destination address to the MAC-level address, as described in “IP Multicast Architecture.” For Token Ring networks, ARP assigns a single functional address, as described in “IP Multicasting Architecture” earlier in this document. For more information about how ARP works, see “How TCP/IP Works.” For more information about the IP routing process, see “Unicast IPv4 Routing Technical Reference.”

Receiving IP Multicast Datagrams

To receive IP multicast datagrams, a host notifies IP to process multicast datagrams for a specific group address, registers the appropriate multicast MAC address with the network adapter, and notifies the local router to join the multicast group.

To determine the specific group address to use, the host can obtain an address from the application or derive the address from a universal resource locator (URL). On the MBone, multicasts are typically announced with the Session Description Protocol (SDP). SDP provides all the information needed to receive a multicast, including the multicast name and description, the times it is active, the type of media it uses, as well as the IP addresses, ports, and protocol it uses. The information is sent to a well-known IP address and port where a host running the session directory tool receives it.

After determining the group address, the host informs IP to process multicast datagrams with that destination address. For shared access technologies such as Ethernet, FDDI, and Token Ring (in which all attached nodes use a common wire), IP contacts the Network Interface layer to have the MAC-level multicast address that corresponds to the group address added to the table of interesting destination MAC addresses, which identifies the datagrams to be received and passed up to the operating system. To accomplish this task in the Windows Server 2003 family, IP uses the NDISRequest() function.

If the group address of interest is outside the range of 224.0.0.0 through 224.0.0.255 or 224.0.0.0/24 (the group address is non-local), the host sends an IGMP Host Membership Report message to the local router to inform it to forward datagrams for that group address to the host’s subnet.

If the host has multiple applications that use the same IP multicast address, IP keeps track of group membership for each application and passes a copy of the multicast datagram to each application. If a host is multihomed, IP keeps track of group membership for each subnet.

A host stops receiving datagrams for a specific multicast group address when the corresponding MAC-level address is removed from the table of interesting destination MAC addresses. This occurs when a multicast-enabled application notifies Windows Sockets to stop receiving datagrams for a specific group address, such as at application shutdown.

Router Processes

Multicast routers handle multicast group membership and forward IP multicast datagrams to the subnets that have at least one group member. Multicast routers do the following:

• Send and receive IGMP group membership messages.

• Communicate group membership to other multicast routers.

• Receive all IP multicast traffic.

• Forward IP multicast traffic.

Send and Receive IGMP Group Membership Messages

Receive and process IGMP Host Membership Report and Leave Group messages

Multicast routers receive IGMP Host Membership Report messages from any hosts on local subnets and process these messages by placing entries that track group membership in the IP multicast forwarding table. Because multicast routers listen in multicast promiscuous mode, they receive all IGMP Host Membership Report messages sent to any group address.

An IGMP version 2 host that might be the last group member on a subnet sends a Leave Group message. Multicast routers process these messages by sending group-specific queries to the multicast group. If no host responds to the queries, the multicast router removes the entry for the subnet from the IP multicast forwarding table.

Query local subnets for host membership status

Any single subnet can support any combination of IGMP version 1, IGMP version 2, and IGMP version 3 hosts. Because IGMP version 1 does not support Leave Group messages, an IGMP version 1 host cannot notify the local router when it leaves a multicast group. In addition, because UDP is used to send multicast datagrams, it is possible for IGMP Host Membership Report and Leave Group messages to be lost. In cases such as these, multicast routers can continue to forward multicast traffic to a subnet that no longer has any group members.

To improve leave latency, multicast routers periodically send IGMP Host Membership Query messages to the local subnet to obtain updated host membership information. For each multicast group that has members on the subnet, one multicast group member responds to the query with an IGMP Host Membership Report message. Multicast routers then process these messages to update the IP multicast forwarding table.

Communicate Group Membership to Other Multicast Routers

In a multicast-enabled internetwork that contains multiple routers, each router communicates group membership information with its neighboring routers so that group members located anywhere on the internetwork receive the group traffic.

Multicast routers communicate group membership information either explicitly, by exchanging group address and subnet information, or implicitly by informing upstream routers whether group members exist downstream from the source host. The routers use a multicast routing protocol such as DVMRP, MOSPF, or PIM to exchange the group membership information.

Receive All IP Multicast Traffic

To receive all multicast traffic, a multicast router must put its network adapter in a special listening mode. A listening mode is the way a network adapter analyzes the destination MAC address of incoming datagrams to determine whether to process them further.

For shared access technologies such as Ethernet, FDDI, and Token Ring, the normal listening mode for network adapters is unicast listening mode. In unicast listening mode, the only datagrams 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 MAC address of the network adapter.

The special listening mode needed to receive all multicast traffic is called multicast promiscuous mode. Multicast promiscuous mode analyzes the Individual/Group bit in the destination MAC address to determine whether the datagram requires further processing. The Individual/Group bit for Ethernet and FDDI addresses is the low-order bit of the first octet in the destination MAC address. This bit is set to 1 for multicast addresses. When the network adapter is placed in multicast promiscuous mode, any datagrams with the Individual/Group bit set to 1 are passed up to the operating system for further processing.

Multicast promiscuous mode is different from promiscuous mode. In promiscuous mode, all datagrams — regardless of the destination MAC address — are passed up to the operating system for processing. Promiscuous mode is used by protocol analyzers, also known as network sniffers, such as the full version of Network Monitor that is part of the Microsoft Systems Management Server.

A network adapter that supports promiscuous mode might not support multicast promiscuous mode. However, multicast promiscuous mode is supported by most network adapters.

Forward IP Multicast Traffic

Multicast routers forward multicast traffic downstream, away from the source host and toward subnets that have at least one group member. The Windows Server 2003 implementation of TCP/IP supports multicast forwarding.

At each hop in the multicast forwarding process, the router decrements the TTL in the IP header. If the resulting TTL is greater than zero, the router compares the source address and destination group address to entries in the local IP multicast forwarding table and then forwards the datagram over the appropriate interfaces. If the TTL equals 0 after decrementing, the router silently discards the multicast datagram. Destination addresses in the range of 224.0.0.0 to 224.0.0.255 (224.0.0.0/24) designate multicast traffic on the local subnet. Multicast routers do not forward datagrams sent to addresses in this range, regardless of the TTL value.

Entries in an IP multicast forwarding table do not identify which, or how many, hosts are group members, but only that at least one host is a member. An entry in an IP multicast forwarding table identifies a subnet that has either a group member or a router that has downstream group members. A multicast router, therefore, can forward multicast datagrams to a subnet that has no group members because the subnet is on the path to other subnets that do have group members.

Multicast boundaries

Multicast boundaries are configurable administrative barriers that limit how far routers can forward multicast traffic across an internetwork. Without boundaries, a multicast router forwards all appropriate multicast traffic throughout the internetwork. With boundaries, a multicast router forwards appropriate multicast traffic only over a limited area of the internetwork. There are two types of multicast boundaries, as follows:

• Scope-based boundaries. A scope is a range of IP multicast addresses and is defined by specifying the address range as an IP address and mask. Multicast addresses in the range of 239.0.0.0 to 239.255.255.255 (239.0.0.0/8) are used to specify administrative scopes, as defined in RFC 2365. However, the range of 239.255.0.0/16 is defined as a local scope and cannot be divided further.

  An administrative scope becomes a boundary, beyond which multicast datagrams are not forwarded. Routers that support administratively scoped multicasts can have each interface configured with a scoped boundary. Such a router is called a boundary router. Datagrams that match the interface boundary definition of a boundary router do not get forwarded in either direction.

• TTL-based boundaries. TTL-based boundaries prevent the forwarding of multicast datagrams beyond a specified number of router hops, as described earlier in this section. TTL-based boundaries apply to all multicast datagrams regardless of the group address. TTL-based boundaries are less precise than scope-based boundaries because of interactions with multicast routing protocols.

IP Multicasting with Routing and Remote Access

Routing and Remote Access can forward multicast traffic in limited network configurations. The primary use of Routing and Remote Access as a multicast router is to connect a subnet to a multicast-enabled intranet that contains routers running multicast routing protocols. To fully support efficient multicast forwarding on a multiple-router intranet, it is necessary to install multicast routers that run one or more multicast routing protocols.

Windows Server 2003 Routing and Remote Access supports IGMP version 1, version 2, and version 3 and also supports multicast boundaries and multicast heartbeat. This section describes how Routing and Remote Access supports multicast traffic.

Routing and Remote Access Architecture

The following figure illustrates the components of Windows Server 2003 Routing and Remote Access. The components in clear boxes are unique to multicasting and are discussed in this document. For information about components that pertain to unicasting or to both unicasting and multicasting, see “Unicast IPv4 Routing Technical Reference.”

IP Multicast Components in Routing and Remote Access

The following table describes the multicast components of Routing and Remote Access.

Multicast Components in Routing and Remote Access

Component	Description
IGMP	In Routing and Remote Access, IGMP is implemented as a routing protocol component. This implementation of IGMP has two modes: router mode and proxy mode. This component does the following: Communicates multicast group membership information to the Multicast Group Manager. Uses Windows Sockets to send and receive IGMP traffic.
Multicast Group Manager	The Multicast Group Manager component does the following: Maintains multicast group membership. Coordinates operations between all multicast routing protocols when multiple multicast routing protocols are enabled on a router. Communicates IP multicast forwarding table entries from multicast routing protocols to the IP Multicast Forwarder.
IP Multicast Forwarder	The IP Multicast Forwarder component does the following: Stores the multicast forwarding entries received from Multicast Group Manager. Communicates source and group information from received multicast traffic to Multicast Group Manager. Forwards multicast datagrams.

Routing and Remote Access Support for Multicast Forwarding

In Routing and Remote Access, IGMP is implemented as a routing protocol component. The IGMP routing protocol component has two modes: IGMP router mode and IGMP proxy mode.

The Routing and Remote Access Server Setup Wizard adds the IGMP routing protocol component. You can then use the Routing and Remote Access snap-in to accomplish the following:

• Add router interfaces to the IGMP routing protocol.

• Configure each interface for one of the two operating modes and for the IGMP version.

• Remove IGMP as a routing protocol component.

You can configure IGMP router interfaces by using the Router tab on the properties of an IGMP interface in the Routing and Remote Access snap-in or by using the netsh routing ip igmp set interface command.

IGMP Router Mode

An interface that is configured for IGMP router mode supports the following functions:

• Listens in multicast promiscuous mode. If the network technology supports it, such as with Ethernet and FDDI, the router-mode interface is placed in multicast promiscuous mode. If the network technology does not support multicast promiscuous mode, an IP Router Manager event is logged in the system event log.

• Receives and processes IGMP group membership messages. The IGMP router-mode interface receives and processes IGMP Host Membership Report messages and Leave Group messages that are sent by hosts on the subnet as they join and leave groups.

• Sends IGMP Host Membership queries. The IGMP router-mode interface sends periodic general (all-hosts) queries and group-specific queries to obtain updated group membership information from the subnet.

• Elects an IGMP query router. Only one router on a subnet sends the IGMP queries. As an IGMP multicast router, the IGMP router-mode interface elects an IGMP query router for the subnet.

• Maintains the IP multicast forwarding table. The IP multicast forwarding table for the TCP/IP protocol is updated based on IGMP group membership messages and multicast datagrams received on the router-mode interface. An IP multicast forwarding table entry contains the multicast group address, the source IP address, a list of interfaces that receive forwarded traffic (next-hop interfaces), and the single interface on which traffic must be received to be forwarded (the previous-hop interface). The multicast group and source IP addresses are obtained from the multicast datagram. The next-hop interfaces are determined by the registration of multicast group members using IGMP (and any multicast routing protocols, if present). The previous-hop interface is the interface that is closest — in terms of routing metrics — to the source of the IP traffic. The previous-hop interface is determined by checking the multicast routing table and identifying a single interface that is the best route back to the source of the IP multicast datagram. The best route is the closest matching multicast route based on the routing metrics.

You can configure IGMP router mode on multiple interfaces. For each interface, any version of IGMP can be configured. The default version is IGMP version 3.

IGMP Proxy Mode

The purpose of IGMP proxy mode is to act as a proxy for multicast hosts on IGMP router-mode interfaces. As a proxy, the IGMP proxy-mode interface forwards IGMP membership messages for the multicast hosts to a router that is running a multicast routing protocol.

IGMP proxy mode is designed to connect a Windows Server 2003-based router to a multicast-enabled IP internetwork that uses a multicast routing protocol, such as DVMRP, MOSPF, or PIM. The IGMP proxy-mode interface acts like a host and joins multicast groups on behalf of hosts on the IGMP router-mode interfaces. Multicast traffic that is sent to host members on IGMP router-mode interfaces is received on the IGMP proxy-mode interface and is forwarded by the IP multicast forwarding process. Multicast traffic that is sent by hosts on IGMP router-mode interfaces is flooded on the IGMP proxy-mode interface where a downstream IP multicast router can either forward the traffic or ignore it.

An interface configured for IGMP proxy mode performs the following functions:

• 2Forwards IGMP Membership Messages. The IGMP proxy-mode interface forwards all IGMP Host Membership Report messages and IGMP Leave Group messages received on the IGMP router-mode interfaces. The IGMP proxy-mode interface does not use the IP multicast forwarding table to forward these messages. It forwards the messages with a TTL value of 1.

• Registers multicast MAC addresses. For shared-access technologies such as Ethernet, the network adapter remains in unicast listening mode. For each multicast group that is registered by an IGMP Host Membership Report and forwarded on the IGMP proxy-mode interface, the IGMP router-mode interface adds the MAC address mapped from the multicast group address to the table of interesting destination MAC addresses on the network adapter for the proxy-mode interface. The network adapter then listens for any datagrams that are addressed to these addresses and passes them up to the operating system for further processing. The network adapter remains in unicast listening mode, unless there are too many MAC addresses to fit in the network adapter’s table of interesting MAC addresses. In this case, the IGMP routing protocol component enables multicast promiscuous listening mode on the network adapter.

• Maintains the IP multicast forwarding table. The IP multicast forwarding table for the TCP/IP protocol is updated based on multicast datagrams received on both the IGMP router-mode interface and the IGMP proxy-mode interface. When non-local multicast traffic is received on an IGMP router-mode interface, entries are added to the IP multicast forwarding table to forward the traffic across the IGMP proxy-mode interface. These entries cause all non-local multicast traffic that is received on an IGMP router-mode interface to be forwarded across the IGMP proxy-mode interface, regardless of whether there are downstream group members.

You can enable IGMP proxy mode only on one IGMP routing protocol component interface. Enable IGMP proxy mode on the interface that is attached to a subnet where there is a multicast router running multicast routing protocols.

IGMP Router Mode vs. IGMP Proxy Mode

The following table compares the functions of IGMP router mode and IGMP proxy mode.

IGMP Router Mode and IGMP Proxy Mode

Function	IGMP Router Mode	IGMP Proxy Mode
Listening mode	Multicast promiscuous mode.	Unicast listening mode.
IGMP router or host	Acts as an IGMP-based multicast router and listens for IGMP Host Membership Report messages.	Acts as an IGMP-based host by forwarding IGMP Host Membership Reports and responding to IGMP queries. Listens for IGMP Host Membership Report messages as a host, not as a router.
Updating the IP multicast forwarding table	Updates the IP multicast forwarding table based on IGMP traffic.	Updates the IP multicast forwarding table to flood (forward throughout the intranet) non-local multicast traffic that is received on IGMP router-mode interfaces.
IGMP queries	Sends IGMP queries to maintain an up-to-date forwarding table.	Sends no IGMP queries.

IGMP Router-Mode Processes and Interactions

A Routing and Remote Access router running the IGMP routing protocol component with an interface configured for IGMP router mode maintains group membership information and the IP multicast forwarding table.

Maintaining group membership information

The process of managing group membership information for hosts on an IGMP router-mode interface is as follows:

1. When a host joins a multicast group, it sends an IGMP Host Membership Report message to the router on the local subnet.

2. The router updates the IP multicast forwarding table with the group address and the IGMP router-mode interface that received the message.

3. The IGMP routing protocol adds the multicast MAC address (mapped from the multicast group address, as described in “IP Multicasting Architecture”) to the table of interesting destination MAC addresses on the network adapter for IGMP proxy-mode interface.

   Note

   • The NDISRequest( ) function adds the multicast MAC address to the table of interesting addresses on the network adapter.

4. The router forwards the IGMP Host Membership Report message using the IGMP proxy-mode interface.

5. The neighboring multicast router receives the IGMP Host Membership Report message, updates its IP multicast forwarding table, and informs downstream multicast routers that a host member exists on the IGMP proxy-mode interface subnet.

6. Periodically (based on the Querier’s Query Interval Code), the router elected as querier sends an IGMP Host Membership Query message. If the router receives a response from a multicast group member, the router updates the expiration time for the group and retains the group entry in the IP multicast forwarding table. If the router does not receive a response to the query, the router sets the expiration time for the group to 0 and removes the group entry from the IP multicast forwarding table.

Forwarding IP multicast traffic

The process of forwarding multicasts from hosts on a router-mode interface works as follows:

1. A multicast host sends multicast traffic to a specific group address, and if the address is not local, the IGMP router-mode interface receives the traffic.

2. When the router receives the first datagram for a specific multicast group, the IGMP routing protocol component adds an entry to the IP multicast forwarding table to indicate that group members exist on the IGMP proxy-mode interface.

3. The multicast traffic passes to the multicast forwarding process, and, based on entries in the IP multicast forwarding table, the traffic is forwarded using the IGMP proxy-mode interface.

4. The neighboring multicast router receives the multicast traffic and passes it to the multicast forwarding process. The multicast router either forwards the traffic to group members or silently discards it based on the entries in its IP multicast forwarding table.

Routing and Remote Access Support for Multicast Boundaries

Routing and Remote Access supports multicast boundaries, as described earlier in this document. In addition to supporting scope-based boundaries and TTL-based boundaries, Windows Server 2003-based routers support boundaries defined by the rate of multicast traffic. With multicast rate limiting, multicast traffic forwarding can be restricted for traffic beyond a specified rate in kilobytes per second. You can configure multicast boundaries by using the General node under the IP Routing node in the console tree of the Routing and Remote Access snap-in.

Multicast Heartbeat

Multicast heartbeat is the ability of a server running Routing and Remote Access to listen for a regular multicast notification to a specified group address to verify that IP multicast connectivity is available on the network. If the heartbeat is not received within a configured amount of time, the server running Routing and Remote Access sets the multicast heartbeat status of the configured interface to inactive.

A polling mechanism can periodically check the multicast heartbeat status to detect when the multicast heartbeat is missing. For example, Simple Network Management Protocol (SNMP) can be used to send a message when the status becomes inactive.

Simple Network Time Protocol (SNTP) is frequently used for the multicast heartbeat. SNTP performs time synchronization and uses the reserved IP multicast address 224.0.1.1. If the SNTP server (the source of the heartbeat traffic) is strategically placed, the loss of the heartbeat indicates a problem with the IP multicast routing infrastructure. Windows Server 2003 includes an SNTP server called the Windows Time service (W32Time) and an SNTP client. For more information about SNTP, see RFC 1769.

You can configure the multicast heartbeat by using the Multicast Heartbeat tab of the properties for the General node under the IP Routing node in the console tree of the Routing and Remote Access snap-in.

Supported Multicast Configurations

The IGMP routing protocol component of Windows Server 2003 Routing and Remote Access is not designed as a substitute for multicast routing protocols such as DVMRP, MOSPF, or PIM. Therefore, this protocol works best for specific internetwork configurations of limited size. The recommended and supported configurations for a Windows Server 2003-based router using the IGMP routing protocol component are described in the following sections.

Single-Router Intranet

A Windows Server 2003-based router can provide full multicasting capabilities in a single-router intranet. The following figure illustrates a single-router intranet.

Single-Router Intranet

In this configuration, each router interface is added to the IGMP routing protocol component and is configured for IGMP router mode.

Any host on any subnet can send multicast traffic to, and receive multicast traffic from, any other host. The Windows Server 2003-based router forwards all multicast traffic to subnets that contain group members.

Single-Router Intranet Connected to the Internet

A Windows Server 2003-based router supports multicasting in a single-router intranet that is connected to the MBone. The following figure illustrates this configuration.

Single-Router Intranet Connected to the Internet

In this configuration, all router interfaces are added to the IGMP routing protocol component. All private intranet interfaces are configured for IGMP router mode, and the Internet interface is configured for IGMP proxy mode.

As hosts join and leave multicast groups, they send IGMP membership messages to the local intranet router interface. These messages are then copied to the Internet interface. Multicast traffic from the Internet is sent to the Internet interface. When the Internet interface receives the multicast traffic, it forwards the traffic to the host on the appropriate subnet. Multicast traffic sent by a host on an intranet subnet is copied to the Internet interface. The multicast router at the ISP either ignores or forwards the multicast traffic, depending on whether there are any group members downstream.

If multicast traffic is sent between two hosts on the private intranet, the traffic is nevertheless copied to the Internet interface and is received by the multicast router at the ISP. You can prevent intranet multicast traffic from being copied to the Internet interface if you configure applications and MADCAP servers to use IP multicast addresses from the administratively scoped range (239.0.0.0 to 239.254.255.255) and configure the Internet interface with the appropriate scope-based boundary.

Peripheral Router in a Multicast-Enabled Intranet

A peripheral router is a router that is attached to multiple networks, one of which contains another router. In this case, the other router is a multicast router running a multicast routing protocol that is used in a multicast-enabled intranet. A peripheral router in a multicast-enabled intranet is a configuration that is very similar to the single-router intranet connected to the Internet. In this configuration, a Windows Server 2003-based router can act as the peripheral router.

The following figure illustrates a Windows Server 2003-based router acting as a peripheral router in a multicast-enabled intranet.

Peripheral Router in a Multicast-Enabled Intranet

In this configuration, all the peripheral router interfaces are added to the IGMP routing protocol component. All interfaces except the one with the multicast router are configured for IGMP router mode. The interface connected to the subnet that contains the multicast router is configured for IGMP proxy mode.

When a host joins or leaves a multicast group, it sends an IGMP membership message. The message is copied to the interface that is configured for IGMP proxy mode. Multicast traffic from the multicast-enabled intranet is forwarded to the subnet attached to the IGMP proxy-mode interface. When the Windows Server 2003-based router receives the multicast traffic, it forwards the traffic to the host on the appropriate subnet. Multicast traffic that is sent by a host on an attached subnet is copied to the IGMP proxy-mode interface. The multicast router either ignores the multicast traffic or forwards it to downstream group members.

Multicast Support for Remote Access Clients

The Windows Server 2003 IGMP routing protocol component is commonly used to provide multicast services for dial-up or virtual private network (VPN) remote access clients. In this situation, the remote access or VPN server acts as a peripheral router to a multicast-enabled IP internetwork.

Two configurations are possible, depending on which of the following types of connectivity is provided to the remote access clients:

• Access to the MBone is provided by an ISP for dial-up clients.

• Access to a private multicast-enabled intranet is provided for dial-up or VPN clients.

MBone access for ISP dial-up clients

The following figure illustrates a configuration in which the Windows Server 2003 Routing and Remote Access service acts as an ISP to provide access to the Internet for dial-up clients.

MBone Access for ISP Dial-Up Clients

In this configuration, the interface named Internal, which represents a logical adapter to which all the ISP clients connect, and the interface that is connected to the Internet are added to the IGMP routing protocol component. The Internal interface is configured for IGMP router mode, and the Internet interface is configured for IGMP proxy mode.

When a remote access client joins or leaves a multicast group, it sends an IGMP membership message. This message is copied to the interface that is connected to the Internet. Multicast traffic from the Internet is sent to the IGMP proxy-mode interface. When this interface receives the multicast traffic, it forwards the traffic to the connected remote access client. When a connected remote access client sends multicast traffic, the traffic is forwarded to other connected group members and is copied to the IGMP proxy-mode interface. The multicast router on the Internet either ignores the multicast traffic or forwards it to downstream group members.

Intranet access for dial-up or VPN clients

The following figure illustrates a configuration in which the Windows Server 2003 Routing and Remote Access service provides access to a private intranet for dial-up or VPN remote access clients.

Intranet Access for Dial-Up or VPN Clients

In this configuration, the interface named Internal and the interface that is connected to the multicast-enabled intranet are added to the IGMP routing protocol component. The Internal interface represents all remote access clients. The intranet interface is attached to a subnet that contains a router running a multicast routing protocol, such as DVMRP, MOSPF, or PIM. The Internal interface is configured for IGMP router mode, and the intranet interface is configured for IGMP proxy mode.

When a remote access client joins or leaves a multicast group, it sends an IGMP membership message. This message is copied to the interface that is connected to the multicast-enabled intranet. Multicast traffic from the intranet is sent to the IGMP proxy-mode interface. When this interface receives the multicast traffic, it forwards the traffic to connected remote group members. When a remote access client sends multicast traffic, the traffic is forwarded to other connected group members and is copied to the IGMP proxy-mode interface. The multicast router on the intranet either discards the multicast traffic or forwards it to downstream group members.

Multicast Support for Branch Office Networks

A Windows Server 2003-based router can provide multicast forwarding capabilities for single-router branch offices connected to a hub office that has a multicast-enabled intranet. This configuration requires proper configuration of both the branch office and hub office router.

The following figure illustrates the use of a Windows Server 2003-based router to support multicasting for a branch office network.

Multicast Support for Branch Office Networks

For the branch office router, all the interfaces are added to the IGMP routing protocol component. The interfaces for the branch office subnets are configured for IGMP router mode, and the interface that connects to the hub office router is configured for IGMP proxy mode. The interface that connects to the hub office router can be a LAN interface (such as one that uses a T-carrier or frame relay connection) or a demand-dial interface (such as one that uses dial-up analog phone lines, ISDN, or a router-to-router VPN connection). A demand-dial interface can be either on-demand or persistent.

For the hub office router, all the interfaces are added to the IGMP routing protocol component. The interface that connects to the branch office router is configured for IGMP router mode. This interface can be a LAN interface (such as one that uses a T-carrier or frame relay connection) or a demand-dial interface (such as one that uses dial-up analog phone lines, ISDN, or a router-to-router VPN connection). The interface that connects to the multicast-enabled intranet is configured for IGMP proxy mode.

When a host joins or leaves a multicast group, it sends an IGMP membership message. The message is copied across the branch office link to the multicast-enabled intranet. Multicast traffic from branch office hosts is copied from the branch office subnets across the branch office link to the multicast-enabled intranet.

If multicast traffic is sent between two hosts on the branch office intranet, the traffic is copied to the branch office link, which results in inefficient use of bandwidth over the link to the hub office. You can configure applications and MADCAP servers to use IP multicast addresses from the administratively scoped range (239.0.0.0 to 239.254.255.255) to prevent local branch office multicast traffic from being copied to the branch office link. In this case, the interface to the hub office is configured with the appropriate scope-based boundaries.

IP Multicasting Interfaces

Windows Server 2003 provides application programming interfaces (APIs) that support the following types of development for multicasting:

• Multicast applications

• Reliable multicasting for multicast applications

• Multicast routing protocols

Multicast Applications

You can write multicast applications by using Windows Sockets, which is an API for developing applications that communicate by using TCP/IP. Windows Sockets 2 supports IGMP versions 2 and 3. For more information about how the Windows Sockets interface relates to TCP/IP, see “How TCP/IP Works.”

For more information about developing multicast applications, see the Platform SDK Windows Sockets 2 documentation about Multicast Programming on MSDN.

Reliable Multicasting for Multicast Applications

PGM is an API for developing multicast applications that use a reliable multicast transport protocol rather than UDP. PGM, which is also known as reliable multicast, is implemented in Windows through Windows Sockets. You can use PGM to write multicast applications that have reliability requirements.

For more information about how to use reliable multicast in Windows, see the Microsoft Windows Server 2003 Family Platform SDK for Windows Sockets 2 documentation about Reliable Multicast Programming (PGM) on MSDN.

Multicast Routing Protocols

Routing and Remote Access is an extensible platform that supports non-Microsoft routing protocols. The Multicast Group Manager (MGM) API enables developers to write multicast routing protocols that work with routers running the MGM component of Routing and Remote Access.

For more information about developing multicast routing protocols with the MGM API, see the Routing and Remote Access Services SDK documentation about MGM Programming Considerations on MSDN.

Related Information

The following resources contain additional information that is relevant to this section.

Related Technical Reference Subjects

• IPv6 Technical Reference

• TCP/IP Technical Reference

• Unicast IPv4 Routing Technical Reference

Related RFCs

For more information about IP multicasting, see the following RFCs in the IETF RFC Database.

• RFC 2365, “Administratively Scoped IP Multicast.”

• RFC 1075, “Distance Vector Multicast Routing Protocol.”

• RFC 1112, “Host extensions for IP multicasting.”

• RFC 2236, “Internet Group Management Protocol, Version 2.”

• RFC 3376, “Internet Group Management Protocol, Version 3.”

• RFC 1853, “IP in IP Tunneling.”

• RFC 1469, “IP Multicast over Token-Ring Local Area Networks.”

• RFC 2730, “Multicast Address Dynamic Client Allocation Protocol (MADCAP).”

• RFC 1584, “Multicast Extensions to OSPF.”

• RFC 3208, “PGM Reliable Transport Protocol Specification.”

• RFC 2117, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification.”

• RFC 1769, “Simple Network Time Protocol (SNTP).”