Win2K's Premier IP Multicast Functionality

IP multicast, an important IP-based network-infrastructure component, lets a network deliver one data stream from a source to a group of destinations. This process saves network bandwidth and provides Quality of Service (QoS) for time-sensitive applications such as multimedia products. In Windows 2000, Microsoft provides more support for IP multicast than the company included in earlier Windows versions. Windows NT 4.0 and Windows 9x provide only host-level support for the Internet Group Management Protocol (IGMP), the fundamental protocol of IP multicast. Win2K supports IGMP at the host level and the router level. In addition, Win2K supports IP multicast forwarding, administrative scoping, and the multicast DHCP service, and includes a built-in multicast application. You can use this application for video and audio conferencing with other Win2K users. After you're familiar with each Win2K IP multicast component, one way that you can take advantage of its benefits is in your intranet.

IGMP
IGMP is an Internet protocol that defines the IP multicast concept, which is a group concept. All hosts that participate in a multicast event belong to a multicast group. A Class D address in the 224.0.0.0-to-239.255.255.255 range represents a specific group. (For information about IP multicast basics, see "Related Articles in Previous Issues" page 102.) A host that supports IGMP can send and receive multicast data as a member of a multicast group and report its membership status to a router in the local subnet. A router or Layer 3 device that supports IGMP can query hosts in its directly connected subnets to identify which subnets contain a multicast member in a specific multicast group. Such a device keeps and updates this group membership information in its IGMP group database or table. The device uses IGMP group membership information to forward the appropriate multicast data from one of the device's network interfaces to another of its interfaces.

IGMP group information is also important to IP multicast routing protocols, which use the information to determine whether a subnet should be in a multicast distribution tree when the subnet is transmitting specific multicast traffic in a network. For more information about IP multicast routing protocols and multicast distribution trees, see "Related Articles in Previous Issues."

In their OS and networking products, vendors have implemented two versions of IGMP: IGMPv1, which the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1112 defines, and IGMPv2, which RFC 2236 defines. The difference between IGMPv1 and IGMPv2 is that a host that supports IGMPv2 will proactively notify the local router when the host leaves a multicast group, but a host that supports IGMPv1 will leave without notification. Letting the router know when a host leaves a multicast group lets the router immediately stop multicasting data to the subnet on which the host resides if the host is the last multicast group member in the subnet. Otherwise, the router delivers data to the subnet until the router discovers that no multicast group members are in that subnet. This process wastes the router's and subnet's resources.

Since Win95, Microsoft OSs have supported IGMPv1 at the host level. Win2K, NT 4.0 Service Pack 4 (SP4) and later, and Win98 provide IGMPv2 support at the host level. In Win2K Server, Microsoft has enhanced IGMP support by providing an IGMP router as part of RRAS. If you use a Win2K Server system as a router to forward multicast data, you can enable the IGMP-router mode on the server's RRAS routing interfaces. To do so, go to Start, Administrative Tools, RRAS, and find the IGMP node in the IP routing directory. Right-click the network interface of the subnet that you want to configure in IGMP, and click Properties. The Properties window's General tab, which Figure 1 shows, presents the option to use either version 1 or version 2 of IGMP. The Router tab contains several configurable IGMP router settings, such as the Query Interval setting, which defines how often the router sends an IGMP query to the subnet, and the Last Member Query Count setting, which specifies how many times the router sends a query to the subnet before the router determines that no multicast member exists in that subnet. The default settings should work for you, but you can make changes as necessary.

After you enable IGMP-router mode, the IGMP router starts to maintain group membership information in an IGMP group table. To find the IGMP group table, right-click the IGMP node in the RRAS IP routing directory and select Show Group Table. The table shows you which subnets—among the subnets that the server is currently connected to—have a host participating in multicast groups. Although several hosts might be in the same subnet in the same multicast group, the IGMP router maintains the group membership information of only one host in each multicast group in each subnet. As long as the IGMP router knows a subnet contains a host in a multicast group, the router will forward multicast data destined for that group to the subnet. All hosts that listen to the group's multicast address in the subnet will receive the data.

IP Multicast Forwarding
Win2K RRAS supports two unicast routing protocols, Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), but it doesn't support a multicast routing protocol such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast extended OSPF (MOSPF), or Protocol Independent Multicast (PIM). However, Win2K provides a multicast-forwarding function that forwards multicast data from one subnet to another. You can use this function to implement a single-router multicast network and integrate Win2K RRAS into an existing multicast network.

For example, suppose your network contains three subnets and uses a Win2K Server system as a router to connect the three subnets. The network users are in different subnets and want to use Win2K's Phone Dialer (i.e., a multicast conference application that requires a network that supports multicasting) to conduct a group meeting. To enable multicast functionality in the network, enable the IGMP-router mode in each of the three RRAS routing interfaces on the Win2K Server system, as Figure 2 illustrates. When users in different subnets join a Phone Dialer conference, the server automatically forwards multicast data among the subnets based on the IGMP group membership information that the users' computers report. Win2K RRAS maintains a separate multicast-forwarding table that reflects how RRAS forwards multicast traffic. To find this multicast-forwarding table, right-click General in the RRAS IP routing directory, and select the Show Multicast Forwarding Table option.

In addition to local multicast forwarding, Win2K RRAS supports the ability to use IGMP-proxy mode to exchange multicast data with a remote multicast network. When you enable IGMP-proxy mode on an interface, RRAS will retransmit all IGMP host membership reports that the IGMP-router mode interfaces receive to the IGMP-proxy mode interface. Acting as an IGMP host, the IGMP-proxy mode interface forwards the membership reports to the connected multicast router. If a host on the interface is in the multicast group, the IGMP-proxy mode interface transmits multicast data from the multicast router to a corresponding IGMP-router interface. An IGMP-router mode interface always sends nonlocal multicast traffic to the IGMP-proxy mode interface, which, in turn, forwards the traffic to the multicast router.

You can use IGMP-proxy mode to integrate Win2K RRAS into your corporate multicast network by connecting a departmental network or branch-office network to the corporate network through a Win2K Server system. Figure 3 shows this configuration. For example, suppose you use a Win2K Server system to connect a departmental network that contains two user subnets to the corporate network. To set up the departmental network to participate in corporate multicast events, enable IGMP-proxy mode on Interface 3 and IGMP-router mode on Interface 1 and Interface 2. Interface 3 will proxy multicast traffic between the departmental network and corporate network. RRAS lets you enable IGMP-proxy mode for only one interface per local router. That interface should always be the one connected to the remote multicast network.

Multicast Boundaries
Win2K RRAS supports both Time to Live (TTL) and scope-based multicast boundaries (aka TTL scoping and administrative scoping, respectively) in multicast forwarding. A TTL-based boundary defines the number of network hops that multicast traffic can traverse. For a TTL-based boundary, you can define a TTL value for each router's interface. Before RRAS forwards an IP multicast packet to a subnet, RRAS compares the TTL value of the router interface that connects to the subnet with the packet's TTL value. If the packet's TTL value is greater than the interface's TTL value, RRAS decreases the packet's TTL value by 1 and forwards the data. Otherwise, RRAS drops the data. To define an interface's TTL value, right-click Gen-eral in the RRAS IP routing directory, select Properties, then select the Multicast Boundaries tab, which Figure 4 shows. By default, a subnet's TTL value is 1.

A scope-based boundary defines an area outside of which routers don't forward certain multicast traffic. This area is based on a configured range of multicast addresses called a multicast scope. RFC 2365 calls this technique administratively scoped IP multicast and defines it as an Internet protocol. The administratively scoped multicast addresses range from 239 .0.0.0 to 239.255.255.255 (or 239.0.0.0/8), and you can use them only within an organization. You use a specific RRAS interface to specify one or more scope-based boundaries, and you define a scope-based boundary only on the interface of a router that sits on a boundary.

For example, in Figure 2, if you don't want the Win2K Server system to forward multicast data that uses addresses in the 239.192.0.0/16 range from Interface 1 and Interface 2 to Interface 3, set a scope-based boundary on Interface 3. To do so, define the multicast address range, 239.192.0.0/16, in a multicast scope definition, then assign the scope to Interface 3. You define and assign a multicast scope on the Multicast Boundaries tab.

RFC 2365 defines addresses in the 239.255.0.0/16 range as local scope addresses. A router, including RRAS, configured with a multicast scope such as 239.192.0.0/16, automatically doesn't forward data sent to any address in 239.255.0.0/16 outside the boundary.

Microsoft recommends using scope-based boundaries rather than TTL-based boundaries. Scope-based boundaries let you better control your multicast traffic and ensure that specific multicast traffic travels only within a specified area. (For more information about TTL-based versus scope-based boundaries, see "Related Articles in Previous Issues.")

Multicast DHCP and MADCAP
An IP multicast application requires an IP multicast address. Traditionally, administrators had to configure an IP multicast address in an IP multicast application—a process similar to configuring a static IP unicast address for a computer. This process adds administrative burden to multicast-address management when organizations deploy multicast applications. The IETF addressed this burden with multicast DHCP. Multicast DHCP, which is a separate protocol from unicast DHCP, lets a multicast application request and lease a multicast address from a multicast DHCP server. RFC 2730 defines multicast DHCP as Multicast Address Dynamic Client Allocation Protocol (MADCAP).

   Previous  [1]  2  Next