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).
Win2K is the first commercial product to support MADCAP. The Win2K DHCP service includes both unicast DHCP and MADCAP services. You can configure the MADCAP service on the same DHCP server that allocates unicast addresses or a dedicated DHCP server that assigns only multicast addresses. In Win2K's DHCP manager GUI, which Figure 5 shows, you can create one or more multicast address scopes on a DHCP server. To create a multicast address scope, right-click the DHCP server node in the DHCP manager GUI, and click New Multicast Scope, which brings up a multicast scope wizard that walks you through the creation of a multicast address scope. In the wizard, you can define a range of multicast addresses that a client can lease from the scope, the client's TTL value, and the duration of a limited lease or an unlimited lease duration. Give the defined scope a meaningful name, such as 1 Day scope, and specify a scope lifetime. The DHCP server will remove the scope from the server's service at that time and date. By default, a scope's lifetime is infinite.
If you have a MADCAP server in your network, a MADCAP client can lease a multicast address from that server. Figure 6 illustrates this process. Before the client can lease a multicast address, it must have had a unicast IP address (i.e., static or dynamic) for IP communication. To discover MADCAP servers in the network, a client multicasts a discovery message to 239.255.255.254. Win2K MADCAP servers always listen to this multicast address. All MADCAP servers that receive the discovery message unicast an offer message to the client. The offer message contains a list of multicast address scopes that the server offers and the servers' IDs. After the client receives all available multicast address scopes, it must choose the scope it wants. In a multicast application, a user can manually select a multicast scope or the application can automatically select a scope. The selection method depends on the application implementation. The client then multicasts a request message that includes the scope name, number of multicast addresses the client needs, and the MADCAP server's ID to 239.255 .255.254. In a unicast acknowledgment message, only the MADCAP server that contains the requested scope and the matching server ID replies to the client. The reply contains one or more of the multicast addresses that the client requested.
When a MADCAP server and client reside in different subnets, you don't need to configure the DHCP agent or helper configuration in the router that connects the subnets to relay DHCP messages that use unicast DHCP. However, you need to make sure that your network supports multicast because the MADCAP discovery and request messages use multicast. If you've set up scope-based boundaries in your network, ensure that each area contains at least one MADCAP server because a scope-based boundary will block messages to the local scope address 239.255.255.254 if the MADCAP server resides in a separate area.
Although Microsoft's Phone Dialer and Exchange 2000 Server conferencing application are two of the few MADCAP-enabled applications available, future multicast applications will include MADCAP support to ease multicast address management. In addition, Microsoft provides seven MADCAP API functions in its Platform Software Development Kit (SDK—http://msdn.micro soft.com/library/psdk/network/mdhcp_ref_09rn.htm) to help software developers build MADCAP-enabled multicast applications. If you develop Windows-based multicast applications, add MADCAP support to your products. If you buy multicast applications from vendors, ask for MADCAP-enabled products.
Phone Dialer
Win2K provides a built-in multimedia application called Phone Dialer that lets you make voice calls and conduct video and audio conferences over IP networks. Phone Dialer provides multicast functionality through its video and audio conferencing capabilities, and the application supports MADCAP as a client. To use Phone Dialer, click Start, Programs, Accessories, Communications, Phone Dialer.
To host or participate in a video or audio conference, you must have working video and audio devices in your Win2K system, a MADCAP server, and Microsoft Site Server Internet Locator Service (ILS) on a Win2K Server system in your network. ILS is a component of Win2K's Network Services and requires Microsoft IIS to run. Phone Dialer uses ILS to publish and locate conferences. Phone Dialer conferences don't require Active Directory (AD), but it can benefit Phone Dialer by automatically locating the ILS server if the ILS server and Win2K computer running Phone Dialer are in AD. To find published conferences, in the Phone Dialer window, which Figure 7 shows, select Internet Directories, My Network, Conferences, which is the default location. To change this location, you must manually configure the ILS server's location in Phone Dialer. To do so, right-click My Network, select Add Directory Server, and enter the ILS server's DNS name or IP address when the system prompts you for a directory name.
If you originate a conference, you can manually set up user access permissions, and you can modify the conference properties or delete the conference. By default, the conference owner has all permissions and everyone who has the necessary system configuration in your network can join the conference.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www .win2000mag.com/. TAO ZHOU "IP Multicast and Your Network," April 1999, InstantDoc ID 5052 "IP Multicast Resources," April 1999, InstantDoc ID 5051 "Be Prepared for IP Multicasting Applications," May 1997, InstantDoc ID 39 "How IP Multicasting Works," May 1997, InstantDoc ID 100 |
Joining a conference is easy. First, find the conference you want to view in the Conferences folder under the My Network or ILS server directories, then highlight it. Click the Join icon in Phone Dialer's toolbar, and Phone Dialer will display the conference if you have the necessary permissions. Even if you're the owner or originator of the conference, you use this process to join the conference.
Prime Time for IP Multicast
Win2K's IP multicasting components let you easily integrate Win2K into your corporate multicast network infrastructure. This functionality makes now the prime time to use IP multicast in your Win2K network.
