Multicast Communications
Supporting Shared Applications
Bill Kine
Product Manager
Spirent Communications

There are three fundamental methods for transmitting data over an IP network: unicast, broadcast and multicast. Unicast traffic is sent to a particular destination such as a host computer, web server or a particular end user. Broadcast traffic is forwarded to all users of the network. Multicast traffic is delivered to a specific subset of the network’s users. For example, an entire department, workgroup or site may share information by using multicast data transmissions.

Both unicast and broadcast traffic types are easy for networks to implement; data packets will either be delivered to a single unique destination, or they will be propagated throughout the entire network for all end users. Supporting multicast traffic is considerably more complex because the participants must first be identified, and then traffic must be sent to their specific locations. The network must also refrain from sending traffic to any unnecessary destinations in order to avoid wasting valuable bandwidth.

Large network operators are extremely concerned about the effects of multicast traffic on their networks. Network operators do not typically support broadcast traffic (no messages need to be delivered to all users). However, multicast traffic is increasing over the Internet. Applications such as data casting (news, stock tickers, etc.), video and audio transmissions, and training seminars (also called webinars) all depend upon multicast technology. These applications require the network to successfully deliver identical packets to a large number of receivers. These data packets often must be replicated at an exponential rate – the resulting bandwidth requirements and routing overhead associated with these applications can be quite daunting.

Multicast communications exist for one sole purpose – to conserve bandwidth. To prove this point, simply consider the other alternatives. On one hand, sending unicast traffic to a large group of receivers is quite wasteful since the same packet will need to be transmitted over and over again by its source. Broadcast traffic, on the other hand, transmits the same packet to all network users regardless of their locations, departments, affiliations, etc.; this method is even more inefficient. Multicast solutions reduce the unnecessary replication of data and focus the delivery process on the appropriate users. However, multicast traffic only actually conserves precious bandwidth if it is meticulously implemented and optimized.

Multicast Fundamentals

Delivering multicast packets over a large network is a complex process. There are several components of this process that must take place to successfully establish multicast communications. The first step is the identification of the receivers. All hosts that want to receive a particular stream of multicast information must identify themselves to the network. This is called the registration process, and it is facilitated with a unique set of IP addresses (called Class D addresses) that are reserved specifically for multicast communications.

The receivers register with a particular multicast group (for example, to attend an individual webinar) by using the Internet Group Management Protocol (IGMP). This protocol is currently in its third iteration (known as IGMPv3) and takes place exclusively between the receiver and its local router.

Once receivers join their respective groups (and it is possible that a single receiver will join several groups), the network must deliver the multicast traffic to the correct end stations. Therefore, a routing protocol must be used to determine the appropriate forwarding paths to all of the registered receivers. Furthermore, the transmissions from the data source must be replicated at some point, so that the information can be received in multiple locations simultaneously. This process is also facilitated by the multicast routing protocol.

There are several different options for multicast routing protocols. The most commonly used protocols are in the family known as Protocol Independent Multicast (PIM). These multicast forwarding protocols are not dependent upon a specific underlying unicast routing protocol. Instead, they are able to take advantage of the router’s topology database, regardless of how it was derived. PIM works equally well when running in conjunction with BGP, OSPF, ISIS, RIP or any other protocol. PIM, unlike IGMP, is used exclusively for router-to-router communications; end user workstations do not participate in this process.

The two most prevalent types of PIM are PIM-Sparse Mode (PIM-SM) and PIM-Source Specific Mode (PIM-SSM). The differences between these two forms of PIM are significant. PIM-SSM is the simpler protocol; it builds a multicast distribution tree using the source router as the root of the tree. All of the routers that are adjacent to the registered receivers (known as Last Hop Routers (LHRs)) send PIM “joins” (not to be confused with IGMP “joins”) directly to the source router, known as the First Hop Router (FHR). The FHR keeps track of the tree structure and the state of the various router interconnections. It then forwards the data packets via the interfaces that are connected to that particular multicast group’s distribution tree. These packets are then replicated as needed as they traverse the tree structure toward all of the receivers. This is a distributed solution that is ideal for a highly dispersed user community.

PIM-Sparse Mode, in contrast to PIM-SSM, allows network operators to centralize the management and processing of their multicast groups and distribution trees. A high-powered router known as a Rendezvous Point (RP) will become the root of all of the multicast trees. Receivers (LHRs) join the RP when they want to be added to a multicast group. Multicast source routers (FHRs) will send their data directly to the RP, which is then responsible for forwarding the information along the tree to all of the registered receivers.

Multicast and IPv6

Multicast support was built into IPv6 at its inception. The first three bits of an IPv6 address identify the format prefix (FP) of the overall 128-bit address. If the format prefix is set to binary 111, then it refers to a multicast address (similar to an IPv4 class D address).

IGMP has been superseded by the Multicast Listener Discovery (MLD) protocol for IPv6, but MLD’s operation and principles are identical to those of IGMP. MLD is now in its second version, as specified by the recently adopted RFC 3810.

PIM-SM and PIM-SSM are the most progressive routing protocols ever developed – they were built at the outset to support both versions of the Internet Protocol. These protocols truly are agnostic regarding their support for IPv4 or IPv6. The functionality of LHRs, FHRs and RPs will remain the same regardless of the IP version number. In fact, these protocols could serve as admirable examples for future IETF routing protocol developments.

Conclusion

Multicast applications are catching on. The Internet already supports many large multicast applications such as news bureaus and financial services. Tens of thousands of small multicast groups exist at any given time to support two or three users participating in small impromptu conferences. As these applications further proliferate, multicast traffic will significantly increase.

Multicast protocols and IPv6 can be easily married; both represent the future of public and private internet communications. Multicast traffic will be present (and growing) in all future IPv6 networks. The original IPv6 architects understood this reality years ago when they designed the new protocol. The fundamental tools are available to enable networks to support multicast traffic, now it is up to network engineers to plan, build, test and optimize their networks to efficiently support their users’ multicast applications.