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 sent by one node is replicated to every member of the group, including the node that sent the data. A multicast IP address is a class D IP address in the range 224.0.0.0 through 239.255.255.255. A number of these addresses are reserved for special purposes. For example, 224.0.0.0 is never used, 224.0.0.1 represents all systems on the subnet, and 224.0.0.2 represents all routers on the subnet. These last two special addresses are reserved for use by the IGMP protocol, which we will present shortly. For a comprehensive list of reserved addresses, take a look at RFC 1700, which is a list of network resources reserved for a particular use. The Internet Assigned Numbers Authority (IANA) maintains this list. Table 11-1 lists a few of the addresses currently marked as reserved. In actuality, you can use any address except for the first three reserved multicast addresses, as they are used by routers on the network. Refer to RFC 1700 for the exact multicast address assignments.

Table 11-1. Multicast addresses

Multicast Address	Use
224.0.0.0	Base address (reserved)
224.0.0.1	All systems on this subnet
224.0.0.2	All routers on this subnet
224.0.1.1	Network time protocol
224.0.0.9	RIP version 2 group address
224.0.1.24	WINS server group address

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, 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. The Internet Gateway Management Protocol (IGMP) was developed to signal routers that a machine on the network is interested in data destined for a given group.

Internet Gateway Management Protocol

Multicasting hosts use IGMP to notify routers that a computer on the router's subnet wants to join a particular multicast group. IGMP is the backbone of IP multicasting. For it to work correctly, all routers between two multicasting nodes must support IGMP. For example, if machines A and B join the multicast group 224.1.2.3, and there are three routers between the two, all three routers must be IGMP-enabled in order for successful communication to occur. Any non-IGMP-enabled router simply drops received multicast data. When an application joins a multicast group, an IGMP "join" command is sent to the all-routers address (224.0.0.2) on the subnet. 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 subnet with the multicast client.

Additionally, when an endpoint joins a multicast group it specifies a time-to-live (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 group (224.0.0.1) for each multicast address that it was notified of by a join command. If clients on that network are still using that multicast address, they respond with another IGMP message so that the router knows to keep forwarding data related to that address; otherwise, the router stops forwarding any data for that address. Even if the client explicitly leaves that multicast group using either of the Winsock methods for leaving a group, the filter set on the router is not immediately removed.

Unfortunately this can be disastrous: a client can drop membership to multicast group A and immediately join group B. Until the router performs a group query and receives no responses, the router will be forwarding data destined for both multicast groups A and B to the network. This is especially bad if the sum of the transmitted data associated with both groups is more than the network bandwidth will allow. This is where IGMP version 2 comes into play. The newest version allows for a client to explicitly send a "leave" message to the router to immediately stop forwarding data for the given multicast address. Of course, the router maintains a reference count of the number of clients for each particular address so that until all clients on the subnet release a particular address, data destined for that address continues to be propagated.

Windows 98 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, Service Pack 4 includes support for IGMP version 2. Previous Service Packs and the base OS itself supported only version 1. If you want to read the complete specifications on IGMP version 1 or version 2, consult RFC 1112 or RFC 2236, respectively.

IP Leaf Nodes

The process of joining an IP multicast group is simple, as every node is a leaf and therefore performs the same steps to join a group. Because IP multicasting was available in Winsock 1 as well as Winsock 2, two methods of API calls can be performed to accomplish the same thing. Here are the basic steps for IP multicasting in Winsock 1:

1. Use the socket function to create a socket with the AF_INET address family and the SOCK_DGRAM socket type. No special flags are required to indicate a multicast socket because the socket function has no flags parameter.
2. Bind the socket to a local port if you want to receive data from the group.
3. Call the setsockopt function with the IP_ADD_MEMBERSHIP option with the address structure of the group you want to join.

If you are using Winsock 2, steps 1 and 2 are the same, but step 3 is to call the WSAJoinLeaf function to add yourself to the group. These two functions and their differences are discussed in greater detail in the section on multicasting with Winsock later in this chapter.

One reminder: an application does not need to join an IP multicast group if it is only sending data. When sending data to a multicast group, the packet on the network is the same as a normal UDP packet except that the destination address is a special multicast address. If you need to receive multicast data, you are required to join the group. Other than the group membership requirements, however, IP multicasting behaves just like normal UDP protocol: it is connectionless, nonreliable, and so on.

IP Multicast Implementation

IP multicasting is supported by all the Windows platforms (with the exception of Windows CE prior to version 2.1). As a result, IP multicasting is implemented somewhat differently on each platform. We mentioned earlier that the network card in use must support multicasting. It does this by providing the ability to add multicast filters in hardware to the interface. Multicast IP addresses use a special MAC address that contains the encoded IP address so that network cards can easily determine whether an incoming packet is multicast and can also determine which multicast IP address the packet is destined for just by examining the MAC header. The exact encoding mechanism is discussed in RFC 1700. We will not cover it in this book, as it doesn't pertain to the Winsock API.

Windows 95 and Windows NT 4, however, implement multicasting by putting the network card in promiscuous mode. This means that the card is picking up all packets arriving on the wire and the network driver is examining the MAC headers, looking for multicast data destined for a group that a process on the workstation is a member of. Because this filtering is being performed by software, it is not as optimal as having the hardware filter packets for you. Windows 98 and Windows 2000 are implemented differently. Both take advantage of the card's ability to add filters, which is optimal because this is performed by the hardware. Most network cards can support 16 or 32 hardware filters. The only limitation on Windows 98 is that once all the hardware filters are set, no more multicast groups can be joined by a process on the machine. If the hardware limit is exceeded, the multicast join operation fails with WSAENOBUFS. Windows 2000 is more robust. Once all the hardware filters are exhausted, it puts the network card in promiscuous mode and operates in a manner similar to Windows 95 and Windows NT 4.