Designing for Multicast Operation with IGMP: A TutorialManikantan Srinivasan, Net-O2 Technologies11/11/2004 6:00 AM ESTInternet protocol (IP) multicast technology has matured quite a bit since it was first deployed in the late 1990s. Multicast-enabled applications such as webinars, video/audio conferences, Internet radio/TV, and networked games are now being used widely over the Internet. These multi-user applications require data flow between a set of sources and a set of receivers in real time.
In multicast applications, Internet datagrams (IP packets) are normally sent as unicast packets i.e., from one source to one destination. However when multiple receivers require the same data, replicating the data from the source to all the receivers as individual unicast packets increases the network load, resulting in network congestion and loss of expected QoS. IP multicast enables efficient transfer of data from a set of sources to a dynamically formed set of receivers. But, IP multicast also has its challenges. these include:
Multicast routing protocols such as distance vector multicast routing protocol (DVMRP), protocol independent multicast (PIM), multicast border gateway protocol (MBGP) enabled in multicast routers ensure shortest path forwarding between the multicast source(s) and the multicast receivers/hosts. Group membership information is propagated in the network from the hosts towards to the routers that are directly attached to the sources in a bottom-up approach with the help of Internet group management protocol (IGMP) and other multicast protocols (PIM, MOSPF etc.,). These multicast protocols with improved hardware functionality ensure duplication free forwarding and quality of service. IGMP plays an important role in the maintenance of dynamic group membership information at the local networks. In this article, we'll take an in-depth look at the IGMP protocol and its impact in a multicast network design (Figure 1).
 IGMP Version 1 A host delays its report to a query by a random period (maximum of ten seconds) for each of its associated groups in order to check for a report sent by other members on the LAN. The report is delayed to avoid a burst of report messages from the hosts to the querier. When the host does not receive a report from other hosts during the delay period, it generates the report by itself. The host suppresses report generation when it receives reports from other hosts during the delay period. The generated report message contains the same IP group host address in the IP destination address field and in the IGMP group membership field. The querier starts a timer for the group membership information it receives in reports. If the group membership is not refreshed by subsequent reports (in response to general queries), the group information is removed. The waiting period, which is comprised of few (2 or 3) query intervals to determine membership validity, is typically large (2 or 3 minutes). During this waiting period, the multicast data continues to be forwarded over the interfaces, occupying unnecessary bandwidth. This delay limitation is removed in IGMP version 2, which we'll discuss. Version 2
An IGMPv2 querier generates two types of query messages: a general query message to obtain all possible multicast membership information and a group specific query to determine whether there are any members for a specific multicast group. An IGMPv2 host sends a report on joining a multicast group. It generates a report after a random delay when it receives a generic query message. A host that responds to a generic query message maintains information, as it is the last host to reply the query. A last host sends a leave group message when it is no longer a member of the multicast group. When an IGMPv2 querier receives a leave group message for multicast group, it generates a group specific query to check whether there are any other member hosts for that particular group. It retains the membership information when it receives a report message for the group specific query and discards the membership information when it does not receive a report message for its group specific queries (typically 2 queries are sent with an interval of 1 second). The support for leave and group specific query messages enables IGMPv2 queriers to quickly determine multicast groups without active members. Version 3
IGMPv3 hosts send v3 report messages to indicate their multicast reception states while responding to queries or when they need to indicate any change in their reception states. Reception state information associated with a group is placed as part of a group record (GR). An IGMPv3 report can contain multiple Group Records. Record Types and Filter Modes Two filter modes are used in IGMPv3: include mode and exclude mode. In the include mode, data from the specified sources are filtered and forwarded towards the hosts by the multicast router. In the exclude mode, data from the specified sources are filtered and not forwarded towards the hosts. The GR's record type value indicates whether the information is current or changed since the last state indication. IGMPv3 categorizes the group record information into three types:
Querier State Information The filter mode for a multicast group in a querier is known as router filter mode (RFM). It is determined after processing all the received state record information from the neighboring IGMPv3 hosts for the group. When the RFM is include, the source record list contains the list of sources whose data are to be forwarded on the attached network. When the RFM is exclude, the source record list contains two types of sources. The first set (type) contains sources whose data needs to be forwarded by some routers while the second set contains sources whose data are not to be forwarded. The group timer is used when the filter mode is exclude. When a CSR with record type MODE_IS_EXCLUDE is received, the RFM for the group becomes exclude. When the host that had reported a CSR with MODE_IS_EXCLUDE stops reporting and the group timer expires, the RFM changes to include. Figure 3 shows a sample sequence of current state records received at a router. The resulting router's state is described in Table 1.
 Querier Election The querier election algorithm elects the router which has the smallest IP address as the network's querier. The other routers assume a role of non-querier and do not generate any query messages, instead act on the received reports on the attached interfaces. A non-querier starts a timer and waits for query messages to detect the presence of the elected querier. When the non-querier does not receive query messages from the elected querier for the specified period (approximately 255 seconds) it assumes the role of the querier. Snooping One solution defined in 802.11D to overcome this limitation is to use the generic attribute registration protocol (GARP) and GARP mulitcast registration protocol (GMRP). While GMRP enables efficient multicast data forwarding at the switches, it also requires an implementation of the GARP. Secondly GMRP does not enable the multicast information to be propagated to the Multicast Routers attached to the LANs. In both GARP and GMRP, IGMP is required for distributing the multicast information. In recent years, the industry has seen vendors offering IGMP snooping (IGS) switches. These switch devices use the multicast information in the IGMP (v1/v2/v3) report messages exchanged between the hosts and the routers connected on the LAN to build their multicast forwarding / filtering database. An IGS switch typically learns (or is configured with) the ports on which the routers are reachable and the ports on which the hosts are reachable. When a report is received on a port, it is forwarded on the port attached to the router. The report is not forwarded on the other ports containing hosts since this could cause the other hosts to suppress their report generation for the multicast group. Whenever a new port's state moves to forwarding as a result of the spanning tree functionality, the switch forwards IGMP query message on the newly enabled port to detect the presence of IGMP hosts. This enables the switch to update its multicast filtering database with less latency. An IGS switch removes any invalid multicast information from its filtering database on received IGMP (v2 leave / v3 report) messages or using timeouts for group membership information. Currently there is no defined standard for IGMP snooping. However, the International Engineering Task Force's (IETF's) Multicast and Anycast Group is working towards a recommendation for IGMP snooping implementation. Wrap Up About the Author |
|
|
