< Chap 9: Index | Winsock2 Main | Multicasting & IPv4 >



Multicasting 9 Part 1



What do we have in this chapter 9 part 1?

  1. Multicast Semantics

  2. Finding Multicast Properties

  3. IP Multicasting

  4. Support Protocols

  5. Multicasting with Setsockopt


Multicasting technology (or point-to-multipoint as it's sometimes called) allows data to be sent from one group member and then replicated to many others without creating a network traffic nightmare. This technology was developed as an alternative to broadcasting, which can negatively impact network bandwidth if used extensively. Multicast data is replicated to a network only if processes running on workstations in that network are interested in that data. Not all protocols support the notion of multicasting, on Windows platforms, only two protocols are multicast capable: IP and ATM. IP multicasting includes both IPv4 and IPv6. In addition, there are different types of IP multicasting. For example, Windows XP supports source multicasting for IPv4 as well as a reliable multicast provider that uses IP multicasting but adds reliability and session-oriented semantics. This chapter presents the information necessary to understand multicasting in general as well as how multicasting applies specifically to these protocols.

First, we will cover the basic semantics of multipoint networking, which includes the various possible types of multicasting as well as basic characteristics of IP and ATM multicasting. Then we will present the specifics of IP and ATM in their own sections. In each section, we will discuss how the Winsock API is used to access each protocol's multicast features.

All Windows platforms support one or more multicasting protocols. IPv4 multicasting is available on all Windows platforms (Windows CE requires version 2.1 or greater). IPv6 multicasting is available in Windows XP as well as in Windows 2000 with the IPv6 technology preview and in Windows NT 4.0 with the Microsoft Research IPv6 stack. Reliable multicasting is available in Windows XP if the Microsoft Message Queue (MSMQ) component is installed. Finally, native ATM multicasting is available in Windows 98, Windows Me, Windows 2000, and Windows XP.


Multicast Semantics


Multicasting has two important properties: the control plane and the data plane. The control plane defines the way that group membership is organized. The data plane refers to the way that data is propagated among the members. Either one of these properties can be rooted or non-rooted. In a rooted control plane, there is a special member of the multicast group known as the c_root. Each of the remaining group members is known as a c_leaf. In most cases, the c_root establishes the multipoint group by initiating connections to any number of c_leafs. In some cases, a c_leaf might request membership to a given multipoint group at a later time. Note that there can be only one root node for a given group. The ATM protocol is an example of a rooted control plane. A non-rooted control plane allows anyone to join a group without exception. In this situation, all group members are c_leaf nodes. Each member has the power to join a multipoint group. You can impose your own group membership scheme in a non-rooted control plane (this will in effect make one node a c_root) by implementing your own group membership protocol. However, your group membership scheme is still built upon a non-rooted control plane. All forms of IP multicasting and reliable multicasting are examples of a non-rooted control plane. Figure 9-1 illustrates the difference between rooted and non-rooted control planes. In the rooted control plane on the left side of the figure, the c_root must explicitly ask each c_leaf to join the group, while in the non-rooted scheme on the right anyone can join the group.


Winsock and Multicasting: Rooted and non-rooted control planes


Figure 9-1 Rooted and non-rooted control planes


The data plane also can be rooted or non-rooted. A rooted data plane has a participant called the d_root. The transfer of data occurs only between d_root and all other members of the multipoint session, who are each referred to as a d_leaf. The traffic can be either unidirectional or bidirectional, but a rooted data plane implies that data sent from one d_leaf will be received by only the d_root, and data sent from the d_root will be received by each d_leaf. ATM and reliable multicasting are examples of a rooted data plane. Figure 9-2 illustrates the difference between rooted and non-rooted data planes. In the rooted data plane on the left of the figure, data abc from the d_root is propagated to every d_leaf. Data xyz sent from a d_leaf is received by only the d_root. This contrasts with the non-rooted example on the right, in which data abc and xyz are propagated to every member, no matter who sent the data.

Winsock and Multicasting: Rooted and non-rooted data planes


Figure 9-2 Rooted and non-rooted data planes


Finally, in a non-rooted data plane all group members can send data to all other members of the group. A block of data sent from a group member is delivered to all other members, and all recipients can send data back. There are no restrictions on who can receive or send data. Again, IP multicasting is non-rooted in the data plane.

So we see that ATM multicasting is rooted in the control and data planes, and IP multicasting is non-rooted in both planes. Reliable multicasting is an example of a non-rooted control plane but a rooted data plane.


Finding Multicast Properties


In Chapter 2, we discussed how to enumerate protocol entries and determine their properties. All of the pertinent multipoint information about a protocol is also available from the protocol's entry in the catalog. The dwServiceFlags1 entry in the WSAPROTOCOL_INFO structure returned by WSAEnumProtocols() contains several bits we're interested in. If the XP1_SUPPORT_MULTIPOINT bit is set, the protocol entry supports multicasting. Then, if the XP1_MULTIPOINT_CONTROL_PLANE bit is set, the protocol supports a rooted control plane; otherwise, it is non-rooted. If the XP1_MULTIPOINT_DATA_PLANE bit is set, the protocol supports a rooted data plane. Likewise, if the bit is 0, the protocol supports only a non-rooted data plane.





IP Multicasting


IP multicasting relies on a special group of addresses known as multicast addresses. It is this group address that names a given group. For example, if five nodes all want to communicate with one another via IP multicast, they all join the same group address. Once they are joined, any data that one node sends is replicated to every member of the group, including the node that sent the data. A multicast IPv4 address is a class D IP address in the range through and IPv6 multicast addresses begin with the prefix FF (1111 1111), as we discussed in Chapter 3. A number of these addresses are reserved for special purposes. For a comprehensive list of reserved addresses, take a look at RFCs 1700 and 2375. The IANA maintains this list. Table 9-1 lists a few of the IPv4 addresses currently marked as reserved. Actually, you can use any address except for the first three reserved multicast addresses because they are used by routers on the network. Refer to RFC 1700 for the exact multicast address assignments.


Table 9-1 Reserved IPv4 Multicast Addresses


Multicast Address


Base address (reserved)

All nodes on this subnet

All routers on this subnet

Network time protocol

RIP version 2 group address

WINS server group address


IPv6 multicasting also sets aside certain multicast addresses for specific purposes, some of which are listed in Table 9-2. One difference between IPv4- and IPv6-reserved multicast addresses is that IPv6 offers different addresses depending on the desired scope, such as link-local and site-local.


Table 9-2 IPv6 Multicast Addresses



Multicast Address




All nodes address



All routers address



All nodes address



All routers address



RIP routers



All routers address



All DHCP servers



All DHCP relays


Because multicasting had not been envisioned when TCP/IP was developed, a number of accommodations had to be made to allow IP to support it. For example, we have already discovered that IP requires a set of special addresses to be set aside for multicast traffic. In addition, for IPv4, a special protocol was introduced to manage multicast clients and their membership in a group. Imagine if two workstations on separate subnets want to join a single multicast group. How is this implemented over IP? You can't simply broadcast the data to the multicast address everywhere because the network would become flooded with broadcast data in no time. IGMP was developed to signal routers that a machine on the network is interested in data destined for a given group. The latest revision of IGMP (version 3) adds support for limiting what sources data is accepted from. Note that the reliable multicast provider still relies on IGMP to communicate group membership to network elements.

For IPv6, the ICMPv6 protocol rolls up the various support protocols, such as ICMP, ARP, and IGMP, into one. Multicast membership is managed by MLD messages, which are a type of message sent over the ICMPv6 protocol.

In the meantime, you may want to configure your Windows XP Pro for multicasting in the registry. The multicasting enabled through the IGMPLevel setting and was defined as:



Key: Tcpip\Parameters

Value Type: REG_DWORD - Number

Valid Range: 0,1,2

Default: 2


Description: This parameter determines how well the computer supports IP multicasting and participates in the Internet Group Management Protocol. At level 0, the computer provides no multicast support. At level 1, the computer can only send IP multicast packets. At level 2, the computer can send IP multicast packets and fully participate in IGMP to receive multicast packets.


The following screenshot shows the registry setting for IGMP.



Winsock and Multicasting: The registry setting for IGMP


Support Protocols


Multicasting hosts use IGMP and MLD to notify routers that a computer on the router's subnet wants to join a particular multicast group. IGMP is the backbone of IPv4 multicasting and MLD is its counterpart for IPv6. For multicasting to work correctly, all routers between two multicasting nodes must support the appropriate multicast support protocol. For example, in the case of IPv4, if machines A and B join the multicast group, and there are three routers between the two, all three routers must be IGMP-enabled for successful communication to occur. Any non-multicast-enabled router simply drops received multicast data. When an application joins a multicast group, a “join” (or report) message is sent to the all-routers address on the interface the group was joined. This command notifies the router that it has clients interested in a particular multicast address. Thus, if the router receives data destined for that multicast address, it forwards it to the network with the multicast client.

In addition, when an endpoint joins a multicast group, it specifies a TTL parameter that indicates how many routers the endpoint's multicast application is willing to traverse to send and receive data. For example, if you write an IP multicast application that joins group X with a TTL of 2, a join command is sent to the all-routers group on the local subnet. The routers on that subnet pick up the command, indicating that it should forward multicast data destined for that address. The router decrements the TTL by 1 and passes the join command on to its neighboring networks. The routers on those networks do the same upon receipt of the command. At this point, those routers decrement the TTL again, which now makes the TTL value 0 and the command is no longer propagated. Because of this, TTL limits how far multicast data will be replicated.

Once a router has one or more multicast groups registered by workstations, it periodically sends a “group query” message to the all-hosts address for each multicast address that a join command notified it of. If clients on that network are still using that multicast address, they respond with another message so that the router knows to keep forwarding data related to that address; otherwise, the router stops forwarding any data for that address. Also, both IGMP (version 2 and greater) and MLD support the notion of a host explicitly leaving a group. That is, each interface maintains a reference count of how many applications are joined to a particular multicast group. When the count goes to zero, a leave (or “done”) message is sent. This notifies the routers to stop forwarding data for that group. Note that for IGMPv1, there is no explicit leave message, so the router will continue forwarding data even after the interested application(s) have exited, which can have undesired results. Only when the IGMPv1 router sends a group query will it discover that no one is listening to that particular group.

Windows XP introduces support for IGMP version 3 for IPv4 multicasting, which allows applications to join an IPv4 multicast group and list one or more sources from which to accept or deny data from. If group X is joined, which specifies sources A and B as the only valid sources, then only data originating from A or B will be propagated to the application. Likewise, if group X was joined and sources A and B were excluded, then data sent to the multicast group from everyone except A and B will be propagated to the application. For IGMPv3 to work properly, the routers on the network must also support IGMPv3. If they don't, there is no real gain because the routers will propagate all data for the joined multicast groups, not just from the source list specified. If a Windows XP host is on a network that is not IGMPv3-enabled, it will fall back to the version of IGMP present.

Windows 98, Windows Me, and Windows 2000 natively support IGMP version 2. For Windows 95, the latest Winsock 2 update also includes IGMP version 2. In Windows NT 4.0, Service Pack 4 includes support for IGMP version 2. Previous Service Packs and the base OS supported only version 1. Windows XP supports IGMPv3. If you want to read the complete specifications on IGMP version 1 or version 2, consult RFC 1112 or RFC 2236, respectively. Currently, IGMP version 3 is an IETF draft: draft-ietf-idmr-igmp-v3-07.txt.


Multicasting with setsockopt()


Originally, the only way to join or leave a multicast group was via the setsockopt API. Winsock 2 introduces a protocol-independent method of multicasting with the WSAJoinLeaf() API (discussed in the next section), but as we will soon see, the setsockopt() method is much more flexible even though it is more closely tied to the protocol being used.




Useful References:


1.      IPv4 Multicasting Tools and Settings.

2.      Windows Server 2003 Resource Kit Tools.

3.      TCP/IP and NBT configuration parameters for Windows XP.


< Chap 9: Index | Winsock2 Main | Multicasting & IPv4 >