| IP multicast extends the unicast service of the Internet Protocol to the capability of sending IP packets to a group of Internet computers. This is realized more effectively than sending single unicast packets to the members of a group. The sender addresses the members of a group by a group address, the so-called IP multicast address. (See Section 17.2.1.) Normally, the sender doesn't know who is currently a member of a group, how many members are subscribed to a group, or where these members are located. IP multicast is one of the few implementations of the principle of group communication. Another network technology that also supports group communication is ATM. Figure 17-3 shows the IP multicast scenario in the Internet. Figure 17-3. IP multicast scenario in the Internet. 
addresses for multicast groups: We basically have to distinguish between multicast communication on the MAC layer and those on the network layer (Internet Protocol). In local area networks, multicast is normally supported by the underlying technology. In this case, multicast packets are transmitted over a broadcast-enabled network, and the connected computers use the group address to decide whether they want to receive the data. Section 17.4.1 describes in detail how multicast is supported in local area networks. In contrast, multicast communication on the IP layer (i.e., between the routers in the Internet) is much harder to implement. One of the most important functions is provided by multicast routing protocols, which organize the efficient distribution of data. The separation between multicast in the local domain and in the routed network domain can be seen not only in how data are forwarded (data path), but also in how groups are managed. Joining and leaving groups is handled by the Internet Group Management Protocol (IGMP); routers distribute their group information over multicast routing protocols. An end system tells its local multicast router only the IP address of the group it wants to join. The router will then have to find out how it can get the multicast data from the Internet. Joining and leaving of groups for computers in a local area network are handled by the Internet Group Management Protocol, which will be introduced in Section 17.3. So-called multicast distribution trees are built to distribute multicast packets between routers across the entire network. The data packets are then distributed along these trees to the individual receivers and local area networks. These distribution trees are built by multicast routing protocols (e.g., the Distance Vector Routing Protocol (DVMRP) and Multicast OSPF (MOSPF)). As in routing in the Internet, the control path and the data path are also separated here, as can be clearly seen in the implementation under Linux. The data path (i.e., forwarding and replicating of multicast packets) is defined by the information in the multicast routing table. The information in the routing table is procured over the control path, by the multicast routing protocols and IGMP. In addition to better structuring, another benefit of keeping the two mechanisms separate is that we can use different routing protocols. In fact, several protocols are currently available in Linux. Section 17.5.2 uses the DVMRP protocol and its implementation in the mrouted daemon as a representative example. Before we take a closer look at the data and control paths of IP multicast, we will discuss important elements multicast groups and their addresses in the next section. 17.2.1 Addresses for Multicast Groups The address range of the Internet Protocol (Version 4) was introduced in Section 14.1.5. (See Figure 14-3.) The classes A, B, and C are reserved for unicast communication; class E is reserved for future use. The address range of class D is reserved for multicast communication. This means that it is characterized so that the upper four bits of the 32-bit IP address begin with 1110 and take the range from 224.0.0.0 to 239.255.255.255 in the address space. The remaining 28 bits make available 228 multicast groups. One particularity of group communication is that the sender does normally not know who it is sending its packets to. The group address merely denotes a specific group and does not give information about the current members of this group. It could well be that there are no members at all in the multicast group, or that it has thousand or even millions of receivers. Each multicast-capable participant can join a group. A host that is not wanted in a group cannot be prevented from joining. The only barrier is to cipher the packet contents and to distribute the deciphering key to desired members only. Multicast group addresses should generally be unique on a worldwide level, because nobody knows which computers join what groups. However, there is a way to limit the reach of a multicast packet, which normally is useful and is actually used by many programs. For this purpose, the TTL field in the IP packet is set to a specific value, which means that it will be discarded after the specified number of hops. (See also Section 17.2.3.) Reserved Multicast Groups In addition to user-specific multicast groups, a special range of group addresses is reserved for special applications. It is in the range between the addresses from 224.0.0.0 to 224.0.0.255 and from 239.0.0.0 to 239.255.255.255. Only some of these addresses are actually used at present. The following list shows some examples: All hosts (224.0.0.1): This group automatically includes each multicast-capable IP computer. It is also possible to leave this group. It is used, among other purposes, to determine the number of active groups within a local area network. (See Section 17.3.) All routers (244.0.0.2): Each multicast router has to belong to the all-routers group. It is used for multicast routing purposes. DVMRP routing (224.0.0.4): This group is used by the Distance Vector Multicast Routing Protocol (DVMRP) to exchange routing information. RIP V2 routing (224.0.0.9): This group is used by the Routing Information Protocol, Version 2, to exchange routing information.
The ping command can be used to find the computers belonging to a specific group within the local area network. For example, the command ping 224.0.0.1 shows all multicast-capable hosts. (See Figure 17-4.) Figure 17-4. Pinging all multicast-capable computers in the same LAN. klaus@tux # ping 224.0.0.1 PING 224.0.0.1 (224.0.0.1): 56 data bytes 64 bytes from 129.13.42.117: icmp_seq=0 ttl=255 time=0.184 ms 64 bytes from 129.13.42.28: icmp_seq=0 ttl=255 time=0.769 ms (DUP!) 64 bytes from 129.13.42.152: icmp_seq=0 ttl=255 time=1.427 ms (DUP!) 64 bytes from 129.13.42.11: icmp_seq=0 ttl=255 time=1.803 ms (DUP!) 64 bytes from 129.13.42.230: icmp_seq=0 ttl=64 time=2.111 ms (DUP!) 64 bytes from 129.13.42.64: icmp_seq=0 ttl=255 time=2.458 ms (DUP!)
17.2.2 Configuring IP Multicast in Linux To support IP multicast, we have to activate the option "IP: multicasting" when configuring the kernel. This integrates the IGMP protocol, and the computer is now capable of joining a multicast group and receiving its packets. If we want our Linux computer to additionally act as multicast router, we also have to select the options "IP: multicast routing" and "IP: tunneling" (if IP tunneling is used to connect to a multicast-capable network). Once we have created and started the new kernel, the computer is able to receive multicast packets. To send packets to multicast groups (which capability, by the way, doesn't require multicast support in the kernel), we need a default route to be able to route multicast packets. In computers not acting as multicast routers, we normally add one route for all multicast groups namely, to the complete 224.0.0.0 network. The command used for this purpose looks as follows, if eth0 is the computer's network card: route add 224.0.0.0 netmask 240.0.0.0 dev eth0
In multicast routers, the routing daemon (e.g., mrouted) is responsible for setting the routes. If the computer supports the proc file system, we can check the virtual file /proc/net/igmp to see the groups in which the computer is currently a member. 17.2.3 Multicast Programming This section describes how you can integrate multicast communication into applications that you develop yourself. Berkeley sockets (see Chapter 27) are normally used to program applications with network functionality. Berkeley sockets let the programmer access network protocols to run the desired communication over these protocols. Also, socket options can be used to influence the properties of some protocols. IP multicast is an extension of the Internet Protocol, which is the reason why the multicast options are accommodated in the options of the IP layer. Linux offers the following socket options for multicast: IP_MULTICAST_IF defines the network device you want to use to send multicast packets over the socket. IP_MULTICAST_TTL sets the TTL (Time To Live) value for multicast packets you send. IP_MULTICAST_LOOP defines whether multicast packets you send should be received over the loopback device. IP_ADD_MEMBERSHIP is used to join an IP multicast group. IP_DROP_MEMBERSHIP is used to leave an IP multicast group.
The socket options for IP multicast listed above will be described in the following subsections. In general, we need the following getsockopt() and setsockopt() functions to set and get socket options: int getsockopt(int socket, int opt_level, int opt_name, void* opt_val, int* opt_len) int setsockopt(int socket, int opt_level, int opt_name, const void* opt_val, int opt_len)
The two functions we use to set and get socket options have the following parameters: socket is the descriptor of the socket for which we change or get options. For IP multicasting, the socket has to belong to the AF_INET family. Because we can only use either UDP or Raw-IP for multicast communication, the socket will be of the type SOCK_DGRAM or SOCK_RAW. opt_level identifies the network layer that will handle the option: SOL_SOCKET (socket layer), IPPROTO_UDP (UDP), or IPPROTO_IP for the IP layer. For IP multicasting options, level should always be set to IPPROTO_IP. opt_len specifies the size of the data structure to which the opt_val pointer refers. Both getsockopt() and setsockopt() return 0 if successful, but -1 in case an error occurs.
The IP_MULTICAST_IF Socket Option The kernel normally uses the default network device to send multicast data packets. A programmer can overwrite this behavior and define a specific output network device. The network device is identified by its IP address (if_addr): struct in_addr if_addr; setsockopt(socket, IPPROTO_IP, IP_MULTICAST_IF, &if_addr, sizeof(if_addr));
From now on, the entire multicast traffic created in this socket is transported over the specified network device. To undo this behavior (i.e., to use the network device selected by the system administrator again), we have only to call setsockopt() once more and set the device address to INADDR_ANY. The IP_MULTICAST_TTL Socket Option In the multicasting context, the TTL (Time To Live) field in the IP packet header has a dual meaning. First, it controls the lifetime of a packet, to keep the packet from traveling infinitely across the network. Each router decrements the TTL value by one and eventually discards it. Second, the TTL field has the meaning of a threshold value. We have to avoid multicast packets from being routed out of the local area network or routing range. Otherwise, parts of the Internet could be loaded with undesired multicast packets. This is why we split the potential reach of a multicast packet into different zones. These zones are controlled by the TTL value specified in the packets. If a multicast packet exceeds a zone, it has to have a sufficient residual lifetime to overcome this hurdle. 0: limits the reach to the local system. The packet is not output on a physical network device. 1: The packet can spread only within the subnetwork. It is not forwarded by any router. <32: Local domain, organization, or department. <64: Region, country, national corporate intranet. <128: Continent. <255: Worldwide.
If a router's threshold value is larger than or equal to the TTL value of a multicast packet, then this packet is discarded. The default value of the TTL field in a multicast packet is one. This means that an application programmer has to set the TTL value explicitly to make it possible for a multicast packet to be transported beyond the local subnetwork. Notice that the TTL value of nonmulticast packets is larger than one for IP. The socket option IP_MULTICAST_TTL can be used to change the default value: int ttl = NEW_TTL; setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
The IP_MULTICAST_LOOP Socket Option There is a special network device, called the loopback device, to enable applications in the local computer to communicate. This device works at minimal cost and behaves like a physical network device. This is the reason it is often used to test network applications locally or to design them so that there will be no difference between situations where the communication partner is reachable locally or remotely over the network. One example is the X-Windows system. The loopback device in Linux is denoted lo and has the reserved IP address 127.0.0.1. The socket option IP_MULTICAST_LOOP can now be used to define whether multicast packets to be sent should be replicated over the loopback device to local sockets. For example, this could be useful for the video part in a videoconference, so that the users can receive their own images for control purposes. In contrast, this is not desirable for audio data, because it would cause interferences. When setting the IP_MULTICAST_LOOP, we have to make sure that opt_val is a pointer to a variable specifying the Boolean value for enabled (1) or disabled (0). For example, the compiler would not accept the following call: setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, 0, 1)
The correct call looks like this: int loop = 1; setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
The IP_ADD_MEMBERSHIP Socket Option The socket option (IP_ADD_MEMBERSHIP) is available on application level to join an IP multicast group. In the kernel, the call results in the function ip_mc_join_group(). The kernel is instructed to use IGMP, unless it is already used, to join the desired group, and to forward the data to the application. Notice that more than one application in one single computer can be members of a group. For example, the code sequence to join group 233.25.10.72 looks like this: /* struct ip_mreq { * struct in_addr imr_multiaddr; // multicast group to join * struct in_addr imr_interface; // interface to join on */ struct ip_mreq imr; imr.imr_multiaddr.s_addr = inet_addr("233.25.10.72"); imr.imr_interface.s_addr = htonl("129.13.42.110"); setsockopt(socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *) &imr, sizeof(struct ip_mreq));
The IP_LEAVE_MEMBERSHIP Socket Option This option is invoked to denote that a socket or application is no longer interested in receiving data from that multicast group. Internally, the option is implemented by ip_mc_leave_group(). However, this does not automatically mean that the computer won't receive any more packets for the multicast group. The computer's membership in the group is terminated only when no application is any longer interested in the group. Packets for groups that the computer is no longer interested in are simply ignored by the kernel. The computer in the above example could leave the group as follows: setsockopt(socket, IPPROTO_IP, IP_DROP_MEMBERSHIP, &imr, sizeof(imr));
| 