Group Membership IP Multicast Networks

233 that a switch connects to four devices that receive multicast data, as shown in Figure 10-1 . The device on Port 1 receives group 239.0.1.15 . The device on Port 2 receives 239.0.1.16 . The device on Port 3 receives both of these groups, and Port 4 has no multicast membership. Figure 10-1. A simple multicast network If the switch understands the IGMP packets as these devices join their respective multicast groups, then it can forward the multicast data selectively. If the switch doesnt understand IGMP, then all four devices will see all of the multicast traffic. This is not a problem for Port 3, which sees both groups anyway, but Port 4 doesnt require any of this traffic. Ports 1 and 2 only want to see the groups to which they belong. This is particularly useful in a VLAN environment, where there can be large numbers of devices sharing the same broadcast domain. Not all switches support IGMP, but it is an increasingly popular feature. It is most frequently seen on switches that have other Layer 3 functionality, such as Layer 3 switching.

10.1.4 Group Membership

Although IGMP does a good job of managing groups at the network layer, it does not include application- level functionality. That is, it allows individual devices to join existing groups only if they know the multicast IP address corresponding to that group. It does not provide a way for users to find out what multicast services are offered. It cannot determine the dynamically generated, multicast IP address for a particular application. Suppose, for example, that a user wants to join a multicast group that disseminates a news service. This service might be set up so that it always uses the same multicast IP address. In this case, the application can simply have this static address hardcoded into its configuration. If this application uses dynamically generated addresses or if the client application simply doesnt know the multicast address, then none of the protocols discussed so far provide a way for it to learn this information. This deficiency is well known, and a group within the IETF called the Multiparty Multimedia Session Control Working Group MMUSIC is currently working on solving it. The focus of this group is to develop protocols that are appropriate for large-scale multimedia applications. Small-scale applications do not have the same scaling problems as large-scale applications. If there are only three clients to a server, then it is much easier to build the application so that the server simply talks to the clients directly. The reason for the focus on multimedia applications is simply that the applications are the most likely areas where multicast transmission will be useful. MMUSIC currently has several higher-layer protocols in development used to manage groups and their members. The problems have been broken down into a number of key phases such as group creation and destruction, announcing new groups, and inviting members to join. To accomplish this task, they have 234 worked on protocols such as Session Initiation Protocol SIP, Session Description Protocol SDP, and Session Directory Announcement Protocol SDAP. As of the time of writing this book, these protocols were still not fully adopted as standards, and there were no available commercial products based on them. For the time being, multicast applications must rely on other methods for handling group membership. Thus, most applications currently work with static addressing, or the clients query a known server to find information about the multicast groups it currently uses.

10.1.5 Multicast Routing