Planning IP Multicasting

With IP multicasting, one device can send a single data stream that the network replicates only as necessary so that multiple devices receive the data. Because of the minimal overhead required to create the data stream and the low overhead on the network, multicast communication is particularly suitable for multiple-user multimedia applications such as video conferencing, distance learning, and collaborative computing. You can also use multicast traffic to discover resources on the internetwork and to support datacasting applications such as file distribution or database synchronization.

Using the IP multicast components of the Windows Server 2003 TCP/IP protocol and the Routing and Remote Access service, you can send and receive IP multicast traffic from multicast-enabled portions of your intranet or the Internet and from remote access clients. You can use IP multicast to optimize server loading and network bandwidth.

Figure 1.13 shows the tasks involved in planning IP multicasting.

Figure 1.13: Planning IP Multicasting

In multicast routing, routers communicate multicast group membership information to each other using multicast routing protocols, and forward data across the internetwork. Multicast forwarding refers to the process of forwarding multicast traffic to networks on which other multicast devices are listening. The multicast-capable portion of the Internet is referred to as the Internet multicast backbone, or MBone.

All computers running Windows Server 2003 can both send and receive IP multicast traffic. Windows Server 2003 TCP/IP can listen for IPv4 multicast traffic and use a multicast forwarding table to determine where to forward incoming multicast traffic.

Figure 1.14 shows one common configuration of IP multicast components. For examples of a number of supported multicast configurations, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).

Figure 1.14: IP Multicast Components

Planning MADCAP Servers

The Multicast Address Dynamic Client Allocation Protocol (MADCAP), built on a client/server model, enables a computer to request an IP multicast address from one or more multicast address allocation servers, known as MADCAP servers. If a client sends a message and does not receive a response, it can retransmit its request.

MADCAP as defined in RFC 2730, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)," differs substantially and is separate from DHCP. However, the Windows Server 2003 DHCP service combines support for both the DHCP and MADCAP protocols for IPv4. Although MADCAP is packaged in the DHCP service, the DHCP and MADCAP services are independent of each other. A DHCP client might or might not be a MADCAP client, and a MADCAP client might or might not be a DHCP client.

MADCAP Without DHCP

To use the DHCP service to deploy MADCAP servers independently of DHCP servers, create one or more multicast scopes, but do not create other scopes or superscopes. The MADCAP server also functions as a DHCP server only if you configure other scopes or superscopes.

MADCAP Security

The IPSec protocol meets MADCAP requirements for client/server identification and integrity protection as described in RFC 2730, and requires no modifications to the MADCAP protocol. Therefore, when you require strong security, use IPSec to protect all of the unicast messages of the MADCAP protocol.

For more information about MADCAP, including how to use IPSec in conjunction with MADCAP, see RFC 2730, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)."

Planning IP Multicast-Enabled Routers

To implement IP multicasting on a multiple-router intranet, you must install routers enabled for multicast routing and configured with one or more multicast routing protocols.

Windows Server 2003 does not provide any multicast routing protocols. To provide multicast forwarding within a single-router intranet or when connecting a single-router intranet to the Internet, you can configure the Internet Group Management Protocol (IGMP) routing protocol component of the Routing and Remote Access service with interfaces set to IGMP router mode and IGMP proxy mode. The IGMP routing protocol component exchanges and updates information in the IP multicast forwarding table about host membership in specific groups.

The IGMP routing protocol is not a multicast routing protocol. To support efficient multicast forwarding and routing on a multiple-router intranet, you must also install IP multicast-enabled routers that use one or more multicast routing protocols. Multicast routers use multicast routing protocols to communicate multicast group information with each other.

Note

You can configure the IGMP router mode and IGMP proxy mode interfaces to provide multicast forwarding support in multiple-router intranets, but doing so is not efficient and is therefore not recommended or supported.

Although Windows Server 2003 does not include any multicast routing protocols, the Routing and Remote Access service is an extensible platform that can support multicast routing protocols. Multicast routing protocols include Protocol-Independent Multicast (PIM) in both Sparse Mode (PIM-SM) and Dense Mode (PIM-DM), Multicast Extensions to OSPF (MOSPF), and the Distance Vector Multicast Routing Protocol (DVMRP). Your choice of multicast routing protocol will depend on the size and type of network and the distribution of multicast group members.

• Protocol-Independent Multicast (PIM). The PIM protocol routes to multicast groups whose members span wide-area and interdomain internetworks. PIM functions independently of any unicast routing protocol. A multicast group that uses PIM can declare itself sparse or dense, using either Sparse Mode or Dense Mode:

  • Protocol-Independent Multicast Sparse Mode (PIM-SM), the most widely used multicast routing protocol, is designed for multicast groups whose members are distributed sparsely across a large region. PIM-SM can operate in a LAN environment but is most efficient in a WAN environment. Using a dense-mode protocol for a multicast group whose members are distributed thinly can cause unnecessary transmission and router storage of data packets or membership report information. This overhead might be acceptable where multicast group members are populated densely, but it is inefficient for a sparse mode multicast group. In sparse mode, routers must explicitly join and leave multicast groups, which eliminates unnecessary traffic and storage.

  • Protocol-Independent Multicast Dense Mode (PIM-DM) is a dense-mode multicast routing protocol designed for multicast groups whose members are distributed thickly over an area where bandwidth is plentiful. PIM-DM is interoperable with the sparse mode, PIM-SM. PIM-DM does not scale well.

• Multicast Extensions to OSPF (MOSPF). The MOSPF protocol, an extension of OSPF, is also a dense-mode multicast routing protocol. MOSPF employs a unicast routing protocol that requires that each router in a network be aware of all available links. 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.

• Distance Vector Multicast Routing Protocol (DVMRP). The original IPv4 multicast routing protocol, DVMRP runs over multicast-capable LANs such as Ethernet. DVMRP can also tunnel IP multicast packets as unicast packets through routers with no multicast capability. DVMRP is a dense-mode multicast routing protocol that does not scale well.

Configuring IGMP

To support IPv4 multicast applications on a single-router intranet or when connecting a single-router intranet to the Internet, you can use the Routing and Remote Access service on one or more computers running Windows Server 2003, add the IGMP routing protocol component on each server, and configure the server's outbound interface for IGMP router mode and its inbound interface for IGMP proxy mode. If your multicast applications cross the Internet, the outbound interface is the intranet interface and the inbound interface is the Internet interface.

• IGMP router mode on the outbound interface. In Windows Server 2003, an outbound interface running in IGMP router mode listens for IGMP Membership Report messages and tracks group membership. Enable IGMP router mode on the interfaces to listening multicast hosts. The TCP/IP protocol and the IGMP routing protocol component for interfaces running in IGMP router mode forward multicast traffic.

• IGMP proxy mode on the inbound interface. IGMP proxy mode is designed to pass IGMP Membership Report messages within a single-router intranet or from a single-router intranet to the MBone. (As explained earlier, in a multiple-router intranet, you must install routers that use one or more multicast routing protocols.) With IGMP proxy mode enabled on the inbound interface, hosts can receive multicast traffic from multicast sources and can send multicast traffic to other hosts.

Within a single-router intranet, or when connecting a single-router intranet to the Internet, you do not need routers running multicast routing protocols. However, within a multiple-router intranet that uses multicast routers running multicast routing protocols, you can still use the Routing and Remote Access service as a multicast forwarding router on the periphery of your intranet.

RFC 1112, "Host Extensions for IP Multicasting," defines address and host extensions for IP hosts that support multicasting, and defines IGMP Version 1. RFC 2236, "Internet Group Management Protocol (IGMP), Version 2," defines IGMP Version 2. Windows Server 2003 supports IGMP Version 3, described in the Internet Draft "Internet Group Management Protocol, Version 3." Under IGMP Version 3, hosts can specify interest in receiving multicast traffic from specified sources or from all but a specific set of sources.

Configuring IP Multicast Scopes

Multicast addressing supports dynamic membership, under which individual computers can join or leave a multicast group at any time. Group membership is not limited by size, and computers are not restricted to membership in any single group.

On all IP networks, each computer must first be configured with its own unicast IP address. After assigning this unicast address, you can configure the computer to support a multicast address. A multicast group of computers shares the same multicast IP address. IPv4 multicast addresses range, in dotted decimal notation, from 224.0.0.0 through 239.255.255.255 (224.0.0.0/4). Such a multicast group also uses a MAC-layer multicast address, which allows all devices to filter unsolicited multicast traffic at the link layer. Ethernet addresses reserved for multicasting range from 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF.

Typically, you specify IP address ranges for multicast scopes on your MADCAP server in the following ways:

• Administrative scoping is designed for multicast IP addresses used privately on your intranet. You use the 239.192.0.0 range of the multicast (Class D) address space with a subnet mask of 255.252.0.0. This is known as the IPv4 Organization Local Scope. It provides 262,144 group addresses (2¹⁸) for use in all subnets on your network. For more information about administrative scoping, see RFC 2365, "Administratively Scoped IP Multicast."

• Global scoping is designed for multicast IP addresses used on the Internet. You use the 233.0.0.0 range of the multicast address space. Global addresses are allocated in the following way:

  • IANA (or another network registry) allocates and reserves the first 8 bits of the range (the "233" portion).

  • The next 16 bits are based on your Autonomous System (AS) number. For information about obtaining your existing AS number or acquiring a new one, see "Using Multicast Scopes" in Help and Support Center for Windows Server 2003.

  • The last 8 bits provide the IP address range from which to configure any multicast scopes for group addresses that you want to use publicly on the Internet. Use a subnet mask of 255.255.255.0.

  For more information about global scoping, see RFC 3180, "GLOP Addressing in 233/8." For more information about AS numbering, see RFC 1930, "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)."

Configuring Client Computers

On participating clients, install and configure the appropriate MADCAP-aware hardware and software. For example, for video conferencing, install video conferencing software and a video camera, sound card, and audio headset.

Standards for the multicast transmission of a data stream between the subnets of an internetwork include RFC 1112, "Host Extensions for IP Multicasting"; RFC 2236, "Internet Group Management Protocol, Version 2"; and the Internet Draft "Internet Group Management Protocol, Version 3." Such standards instruct routers how and where to route multicast traffic.

For more information about IP multicasting, including multiple supported multicast configurations, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit), and for information about Windows Server 2003 TCP/IP, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).