Multicast applications continue to proliferate. Supporting such applications is a complex task that requires carriers to monitor their networks closely.
Bill Kine
Spirent Communications
Multicast traffic over the Internet is increasing rapidly, and large service providers are extremely concerned about its effect on their networks. Applications such as data casting (news, stock tickers, etc.), video and audio transmissions, and training seminars (also called "webinars") all depend on multicast technology. Such multicast applications present complex network challenges because they are designed to deliver identical packets to a large number of receivers. The packets often must be replicated at an exponential rate, resulting in staggering bandwidth requirements and routing overhead.
Multicast fundamentals
Delivering multicast packets over a large network is a complex process. There are several steps involved 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 data must identify themselves to the network. This is called registration, and it is facilitated with a unique set of IP addresses (called Class D addresses) that are reserved specifically for multicast communications.
Once receivers join their respective multicast groups, the network must deliver the multicast traffic to the correct end stations using a routing protocol to determine the appropriate forwarding paths to all of the registered receivers. The source transmissions must be replicated at some point, so that the information can be received in multiple locations simultaneously.
Most multicast data transmissions are uni-directional. Typically, a single host will transmit information (such as stock ticker updates) to multiple end stations. Multicast data streams do not support reliable upper-layer protocols such as TCP. Instead, the network uses the "best-effort" User Datagram Protocol (UDP); therefore, whenever a packet is missed by a receiver, it is simply lost and not retransmitted.
Multicast registration process
The identification of multicast receivers is accomplished via the Internet Group Management Protocol (IGMP), which is invoked between hosts and their local router. When a workstation wants to participate in a particular multicast group, it sends an IGMP "join" message to its router (Figure 1). After the router receives a "join" for a specific group, it will forward any packets for that group to the appropriate interface(s). The router will only forward one copy of each data packet per interface; if there are multiple receivers on a single interface (for example, an Ethernet hub), they will all receive the information by monitoring a common Class D IP address.
IGMP is a stateful protocol. The router regularly verifies that the workstations want to continue to participate in the multicast groups by sending periodic "queries" to the receivers. If the receivers remain interested in that particular group, they will respond with a "membership report" message. IGMP also provides mechanisms for leaving multicast groups and for identifying specific data sources.
Multicast routing
After receivers register with various multicast groups, the network must replicate and deliver the information to all of the intended recipients. This requires the use of a routing protocol. There are several multicast routing protocols, and each has its unique strengths and weaknesses. The most popular protocol is known as Protocol Independent Multicast - Sparse Mode (PIM-SM).
PIM-SM is ideally suited for Internet communications. It is designed to reduce the routing protocol overhead, and also limit the overall bandwidth consumption of the multicast groups. PIM-SM has many of the characteristics of a traditional routing protocol: it allows nodes (routers) to automatically discover each other, it develops optimized forwarding paths (called trees) for each multicast group, and it gracefully responds to changes in the network's topology (Figure 2).
However, PIM-SM routers do not exchange topological or reachability information with each other. Instead, PIM-SM uses the unicast forwarding database of the routers to determine the optimal paths to a remote location. Since BGP, for example, will have already calculated a route to New York, PIM-SM uses that data instead of forcing the router to redundantly recalculate paths to known destinations. Databases of other protocols (such as RIP, OSPF, or IS-IS) also can be used -- this is the "protocol independent" portion of PIM-SM.
It would be extremely difficult for all routers to build and track all of the possible multicast trees within a large network. Therefore, the PIM-SM solution centralizes some of these activities by establishing routers known as Rendezvous Points (RPs) for each multicast group. The RP serves as the root of the multicast tree, so that the "leaf" or edge routers only need to locate the RP to join a new group. The forwarding tree calculations and stateful tracking for each group are handled exclusively by the RP.
Multicast network testing
The Internet already supports many large multicast applications such as news bureaus and financial services. Tens of thousands of smaller multicast groups exist at any given time for gaming or conferencing. As these applications further proliferate, so will multicast Internet traffic. Because service providers do not know the impact of increasing levels of multicast traffic, it is imperative that they monitor the performance of their networks and minimize through testing the risks of network failure.
Multicast communication represents a complex challenge for service providers. As such, it requires an equally complex solution. Multicast routing protocols provide the tools for optimizing network performance; however, these protocols tend to be rather intricate and require a substantial amount of router resources and technical expertise.
By extensively testing and modeling all of the possible permutations of multicast traffic and protocols in a lab environment before they proliferate throughout the live network, service providers can understand, anticipate, and resolve potential problems. This testing must include the performance and scalability aspects of multicast traffic, as well as the basic functional characteristics of the protocols.
Bill Kine is director of technical marketing for router testing at Spirent Communications (Calabasas, CA). He contributes to the development of advanced routing and switching test equipment and helps drive its strategic marketing programs. He has designed, implemented and optimized local and wide area networks of all sizes.