Network Programming with Perl

By Lincoln  D.  Stein

Slots : 1

Multicast Basics

Multicasting relies on a series of reserved IP addresses in the upper end of the IP address space between addresses 224.0.0.0 and 239.255.255.255. When a packet is sent to one of these addresses, it is not routed in the normal way to a single machine, but instead is distributed through the network to all machines that have registered their interest in receiving transmissions on that address. These IP addresses are known in the multicasting world as "groups" because each address refers to a group of machines.

In effect, multicast groups act much like mailing lists. A process joins one or more groups, and the multicasting system makes sure that copies of the messages directed to the group are routed to each member of the group. Later, the process can drop its membership, and the incoming messages will cease .

Like all other TCP/IP applications, multicasting uses the combination of port number and address to find the correct program to deliver a packet to. Before a socket can receive a multicast message, it must bind to a port just as a socket in a conventional unicast server application must do. This means that the same multicast group can be used for different applications (or different components of the same application) so long as everyone agrees in advance on which ports to use. For example, multicast address 226.0.1.8 can be used to receive a video stream on port 1908 and simultaneously to run an interactive whiteboard application on port 2455.

There are more than 26 million multicast addresses in the reserved range and 65,536 port numbers , which gives the Internet about 17 trillion channels to use in multicasting. However, the number of multicast groups that a single socket can join simultaneously is usually limited by the operating systems to about 20.

A variety of applications that require one-to-many connectivity use multicasting. Examples of multicast applications for which source code is available include VIC, a videoconferencing system from Lawrence Berkeley National Laboratory; RAT, an audio streaming system from University College London; and WB, a networked whiteboard system also from Lawrence Berkeley. In addition, the network time protocol daemon, xntpd , can be configured to multicast the current time throughout the LAN. Used in conjunction with LAN-wide multicast routing, this allows one to synchronize all the machines in an organization to a single network time signal. You can find these and a large number of other Open Source multicast- related tools at http://www-mice.cs.ucl.ac.uk/multimedia/software/.

Like broadcasting, current implementation of TCP/IP multicasting is compatible with only the UDP protocol. A number of active research projects are addressing the need for a reliable connection-oriented multicasting facility. Multicasting is discussed in RFCs 1112, 2236, 1458, and others listed among the references of Appendix D.

Reserved Multicast Addresses

Multicast space isn't quite the untramelled wilderness that the last section might imply. Some address ranges are reserved for special purposes or for well-known applications. These addresses are not available for general use (Table 21.1). If you are designing a new multicast application rather than writing a client or server for an existing one, you should avoid these addresses in order to prevent potential conflicts.

The 255 addresses in the range 224.0.0.0 through 224.0.0.255 are reserved for local administrative tasks , specifically the exchange of router messages. Messages sent to these addresses are never routed beyond the local area network.

Table 21.1. Reserved Multicast Ranges

224.0.0.1 is the "all-hosts" group. A message sent to this address is transmitted to all the hosts on the local area network, but is not forwarded by any multicast routers. Thus the all- hosts group is the multicast equivalent of the broadcast address.

224.0.0.2 is the "all-routers" group. All multicast-capable routers are required to join this group at startup time.

Other addresses in this range are reserved for the use of specific router types. For example, 224.0.0.4 is the "all DVMRP routers" group, joined by routers using the DVMRP protocol. 224.0.0.5 is reserved for OSPF routers, 224.0.0.9 for RIP2 routers, and so on.

Other addresses in multicast space are reserved for well-known applications, and although some of them are not much used, you're advised to avoid them. You'll find a more comprehensive list of well-known addresses at http://www.isi.cdn/in-notes/iana/assignments/mnln-castaddresses. Three large blocks of multicast addresses are unassigned and are safe for you to use for development:

• 224.3.0.0 “224.251.255.255 (16,318,464 addresses)

• 225.0.0.0 “231.255.255.255 (117,440,512 addresses)

• 233.0.0.0 “238.255.255.255 (100,663,296 addresses)

Multicast Addresses and Hardware Filtering

Recall from the last chapter that one of the limitations of broadcasting is that it forces every host on the LAN to process each packet. Multicasting is more efficient than this. When an application joins a multicast group, the host's network interface card is configured to receive multicast packets bound for that group, a process called "imperfect hardware filtering." The interface hands off received packets to the operating system, which then delivers them to the correct application (Figure 21.1).

The filtering performed by the interface card is "imperfect" because it uses a hashing scheme to choose which packets to accept. This scheme occasionally allows some irrelevant packets (those bound for groups the host has not joined) through as well. However, any irrelevant packets are discarded by the operating system in a second "perfect software filtering" step. Hence, multicasting is not as efficient as unicasting , in which the network card perfectly filters out packets bound for irrelevant IP addresses; but it is much more efficient than broadcasting, in which the card exercises no discrimination.

From the application programming standpoint, you do not have to worry about multicast hardware filtering, except to know that heavy use of multicasting would not have the same impact on your network that a similar level of broadcasting would.

Multicasting Across WANs

Unlike broadcasts, multicasts were designed to be routed. Multicast packets can be routed between subnets or across wide area networks (WANs). A specialized multicast routing protocol supervises this process.

When an application joins a multicast group, its host sends a message to the local router to inform it of that fact. The router then forwards that group's multicast messages from the WAN to the host's subnet. As additional hosts in the subnet join the same group, the router keeps track of them, both passively by receiving join messages and actively by periodically polling the subnet for each host's membership list. When an application departs from a multicast group, its host sends a depart message to the local router. When the last host has departed from a multicast group, the router stops forwarding the corresponding packets.

Multicast routers periodically exchange information about the groups that the adjacent routers wish to receive, collaboratively building a tree that describes how multicast messages on a particular group should be distributed. This allows messages transmitted to a multicast group to be distributed in an efficient manner to just those networks and hosts that are interested in receiving them.

In order for any of this to work, however, you must be equipped with multicast-capable routers. Many newer routers, such as those from Cisco systems, are multicast capable, but some are not. Another option is to build a router from a UNIX host that is capable of multicast routing. For example, recent versions of the Linux operating system have built-in multicast routing capabilities, although this feature must usually be enabled by recompiling the kernel. You would also need the mrouted router daemon to take advantage of this functionality.

It is also possible to work around a nonmulticast-capable router by tunneling through it using ordinary unicast packets. The mrouted daemon can do this, provided that it is running on hosts on each subnet that you wish to share multicast packets.

To send or receive multicasts across the Internet, you may create a private multicast network by tunneling between LANs using mrouted or the equivalent. Alternatively, you can participate in the public multicast network, MBONE, which is used by a loose coalition of public and private organizations for Internet-based broadcasting services. In addition to providing an Internet-wide multicasting backbone, MBONE provides a simple session-announcement service that notifies you when certain public activities, such as a video conference, are scheduled to occur. Session announcements also provide information about the multicast addresses and ports on which the session will be transmitted so that client software can be configured properly to receive the information.

Joining the MBONE requires the cooperation of your Internet Service Provider and possibly the network provider as well. Appendix D contains more sources of information on setting up multicast routing and connecting with the MBONE.

Multicast TTLs

Since multicast messages can be routed, you need a way to control how far they can go. You wouldn't want a whiteboard application intended for interdepartmental conferences in your organization to be multicast across the Internet.

Multicasting uses a simple but effective technique to control the scope of messages. Each packet contains a time-to-live (TTL) field that is set to an arbitrary positive integer between 1 and 255. Every time the packet crosses a router, its TTL is decremented by 1. When the TTL reaches 0, the packet is discarded.

By default, multicast packets have a TTL of 1, meaning that they won't be routed across subnets. As soon as they hit the first router, their TTL reaches 0 and they expire. To arrange for a packet to be forwarded, set its TTL to a higher value. In general, a packet can cross TTL-1 routers.

To provide finer control over routing of multicast packets, an organization can assign "threshold" values to each outgoing interface of a multicast router. The router will forward the packet only if its TTL matches or exceeds the threshold. To illustrate this, consider the hypothetical company in Figure 21.2. It has three departments, each of which is large enough to contain several subnets. Each department's subnets are connected with a departmental router (labeled A, B, and C), and the departments are interconnected via the central interdepartmental router "D." Router D also acts as the gateway to the Internet. Each departmental router uses the default threshold of 1 on the subnet interfaces, but a threshold of 3 on the interface that connects it to the central router. Similarly, the central router has a threshold of 31 on the interface that connects it to the Internet. This setup allows the scope of a packet to be precisely controlled by its TTL. Packets with TTLs between 1 and 3 are forwarded within a department's subnets, but can't travel to other departments because they don't meet the threshold criterion of 3 required to be forwarded beyond the departmental router. Packets with TTLs between 4 and 32 can travel among the departments, but won't be forwarded to the Internet. The router threshold values control the scope of multicast applications, preventing applications intended for use only within a subnet, department, or organization from spilling over into places they're not wanted.

Table 21.2 lists common TTL thresholds and their associated scopes. These values are conventions, and the exact definitions of "site," "organization," and "department" are up to you to determine.

Table 21.2. Conventional TTL Thresholds