Introduction to Multicast for the Enterprise MPLS VPN

Multicast is a method of efficiently transmitting content one-way across a network from a source to multiple receivers. The primary use of multicast within Acme, Inc. is to deliver TV-quality broadcasts of live events, such as the CEO year-end results. This delivery model is called "one-to-many." It lets a global company such as Acme deliver important content consistently and accurately to everyone in the company. Companies may have studios located in major offices, such as Acme's head office in San Jose. There, content is recorded and converted into a format that can be delivered to the network using Internet Protocol TV (IPTV) servers that can send video, voice, and Microsoft PowerPoint presentations. Users can view the multicast content live by using the viewer software that pulls a program schedule from a central IPTV Content Manager, which contains all the relevant details for a workstation to request, receive, and display content sent over multicast from the IPTV server.

The primary reason for using multicast to deliver multimedia content for live events is its scalability. In large enterprise networks, a live event can be viewed by thousands of users, and only a single multicast stream is required to deliver the content. If the content were delivered using a unicast stream, the stream would increase proportionally to the number of users watching it, as shown in Figure 6-1. The single multicast stream compared with X unicast streams prevents networks from becoming saturated and source servers from becoming overloaded.

Figure 6-1. Unicast Versus MulticastBandwidth Consumption

Other applications that use IP multicast within the Acme global enterprise network include reliable multicast protocol Pragmatic General Multicast (PGM) for Application and Content Networking System (ACNS) 5.x, multicast voice over IP (VoIP) application Hoot and Holler, CallManager application Multicast Music-on-Hold (M-MOH), and the multicast messaging application InformaCast.

Wider applications beyond communication content exist in the financial services world. IP Multicast in the trading and market data services arena uses multicast for delivery efficiency. Application middleware messaging such as TIBCO leverages IP Multicast. As such, the requirement to extend multicast infrastructure support to critical market applications over the WAN is increasing.

Multicast Considerations

IP Unicast relies on Layer 4 protocols, such as TCP for reliability. IP Multicast uses User Datagram Protocol (UDP) to provide best-effort delivery of packets, which can result in packet loss. UDP does not request retransmission of lost packets. Applications such as IPTV viewer are designed to handle this problem. During transmission of a live event across the network, the impact of this packet loss is minimal. For example, a user watching the live event using IPTV viewer notices the video freezing, which is due to video frames or parts of the speech being lost. This is not a problem for the viewer if the packet loss is very small and happens only a couple of times during a broadcast. If the problem occurs continually during a broadcast, the viewer's experience will be very poor; therefore, it's critical that multicast be configured correctly on the network. Most streaming video applications allow for buffering, because they were originally designed for use over the public Internet, and therefore best-effort service. With the use for business purposes, the generous buffering allowances may be insufficient if the network has conditions causing loss leading that affect business services or key data systems.

Ideally, duplicate multicast packets should not be a problem. However, if workstations joining a specific group address receive duplicate packets, the application should be designed to handle this problem. Duplicate packets can be an issue over WAN links when you have limited bandwidth. The result could be saturated WAN links if a router sends more packets per multicast group address than the source originally sent.

Multicast traffic is delivered using UDP. Because of the nature of this connection, it does not react to congestion.

It is important that high bit rate content group addresses be blocked from traversing low-bandwidth WAN links; otherwise, the WAN link becomes congested. This congestion problem results in users at the remote site not being able to view the content sent using multicast due to the high number of dropped packets. Congestion caused by the high-quality (high quality equals high bandwidth demand) IPTV stream could also affect more critical traffic being transmitted over the WAN, such as VoIP calls. We will explore the mechanisms to properly control multicast over the WAN. You should ensure that quality of service (QoS), boundary access control list (ACL), and multicast rate limiting are configured on all WAN links to prevent congestion, as well as to ensure that bandwidth is conserved for more critical traffic, such as VoIP calls. The mechanisms that should be employed include administratively scoped multicast address ranges, assigning various bit-rate broadcasts to specific group addresses, boundary lists to give the various group addresses access to the network, and configuring group ranges on the broadcast server, such as IPTV Content Manager. The corresponding ACLs can be configured at the appropriate distribution switches connecting to the WAN gateways.

For on-demand content, rather than live streams, content can be distributed to localized caches or content engines for efficiency of access where bandwidth is limited. Operating under the "ships-in-the-night" concept of replicating offline content during the night or off-hours to the local content engines ensures that bandwidth-challenged locations can receive content that they would otherwise be unable to receive over their low-bandwidth WAN links. Multicast is often used to replicate efficiently to such local content engines.

When considering QoS for streaming video, the QoS baseline recommendation calls for streaming video (be it unicast video on demand or multicast) to be marked CS4 (DSCP 32). This can be set on IPTV servers themselves, and the servers can be trusted by their access layer switches.