Taming IP Video

Video over Internet Protocol (VIP) networks have been called “killer” applications that allow for more efficient and less costly mass communication on university networks. Sometimes that’s not a compliment, however, especially when some university network administrators see it as a potential network “killer.”

VIP can be difficult to manage because of high-bandwidth demands associated with IP video: overtaxed network equipment, extra requirements to install or upgrade net­work devices and the amount of recon­figuration required. Multiple high- definition (HD) streams can also consume large chunks of bandwidth, bringing everything on the campus network to a halt.

It doesn’t have to be that way. Video — even HDTV streams — can coexist quite nicely on a campus network with other applications such as Voice over Internet Protocol, e-mail and Web browsing. It all depends on how the network is designed, deployed and implemented for real-time data services, such as video. It also depends on how well you plan for, and handle, video.

IP Video Basics

There are three forms of video distribution over networks: unicast, broadcast and multicast. All three start out pretty much the same. The video equipment digitizes the image and the associated audio, converts it into sequential IP packets and hands it off to the network. From that point on, things are a bit different.

Unicast is what we are most familiar with when we talk about network services. Video unicast is the network equivalent of a phone call, a one-to-one session between two nodes. Only the intended recipient receives the packets. The network doesn’t need to do anything special to accomplish this, handling unicast video as any other network communication would be handled. The routers simply see the source and destination addresses in the packet headers and forward them accordingly.

Broadcast is useful when there is a need to reach more than one destination with a transmission, such as a state-of-the-university presentation from the chancellor. Faculty, students and staff all need to see the presentation. Broadcast is a lot like television: The video gear drops the packets on the network and, just like a TV transmission antenna, the network broadcasts to everyone in the community. Packets go to every node on your campus net. This is not particularly efficient because every device on the network receives the video packets whether it wants them or not. These devices have no choice but to process the unwanted video packets, consuming precious central processing unit or network interface card cycles and degrading network performance in the process.

What if you don’t want to broadcast a video feed? What if you want more than a one-to-one unicast video session? What if, for security or for performance reasons, you want to limit which devices on the network receive the video traffic? Then you need the video equivalent of a conference call, in which more than two participants are included but the distribution doesn’t go all over the network. This is where IP multicast comes in.

Video Distribution, the IP Multicast Way

IP multicast provides widespread distribution of the video session, but with restricted access. That’s not a contradiction in terms. Multicast not only provides a modicum of security (only those who should receive the broadcast are sent the packets) but also is inherently more efficient and dramatically lowers video’s impact on the campus network (packets aren’t sent to every node, only to those that are intended to participate in the multicast).

To support multicast on the campus network, you need multicast-aware and -enabled routers or Layer 3 switches.

If you try to establish a multicast session on a network that isn’t multicast-capable or -enabled, the network devices won’t know what to do with the multicast packets. As a result, they will ask themselves if they recognize the packet’s IP header address. The answer will be no because, according to RFC 3171, IP Class D addresses ranging from 224.0.0.0 to 239.255.255.255 are reserved for IP multicast (see http://tools.ietf.org/html/rfc3171). These addresses are probably not within your campus network’s IP assigned range. Since legacy devices know only two forms of transmission — unicast or broadcast — they will quickly decide that because the address is not recognized, the packet should be flooded to every node on your network. In other words, the multicast packets become a broadcast. Clearly this isn’t what you want, as it completely defeats the purpose of implementing IP multicast in the first place.

Now the question becomes, what is needed to deploy multicast video on your network?

The Seven Steps to Successful Multicast Deployment

Step 1. Purchase and implement multicast-enabled network equipment. To better understand how multicast works, visualize a tree: The tree itself is the multicast group, with the roots being the source of the multicast and the branches reaching out to each and every network node designated to receive the video transmission. A multicast-enabled router or L3 switch occupies each point at which the tree trunk joins a branch. It’s the job of this device to replicate each multicast packet appropriately so it travels across the appropriate interfaces (or branches) on its way to the group members. Therefore, be sure to turn on the multicast feature in your multicast- enabled network device. The commands to do this will vary from vendor to vendor, so check your documentation for further details.

Step 2. Enable Internet Group Management Protocol. Routers or L3 switches need to know where to deliver multicast packets. Therefore, the routers must first know the locations of group members. This is the job of the Internet Group Management Protocol (IGMP). IGMP specifies how a host registers in order to receive specific multicast traffic. To add an extra bit of confusion to the mix, there are three versions of IGMP: IGMP version 3 adds source awareness to the protocol that allows the inclusion or exclusion of specific sources (don’t worry too much about this since versions 2 and 3 are backward-compatible with previous versions). Just make sure that you enable IGMP globally in your campus routers and L3 switches.

Step 3. Select the appropriate multicast routing protocol for your environment. There are several flavors of multicast, and they don’t interoperate. This means that you have to decide which protocol you are going to deploy on your campus network and then do so consistently in all devices. There is a veritable smorgasbord of protocols. Among your choices are: Distance Vector Multicast Routing Protocol (DVMRP), Core Based Trees (CBT), Multicast BGP (MBGP), Multicast Source Discovery Protocol (MSDP), Multicast Extensions to OSPF (MOSPF), Multicast Listener Discovery (MLD), Protocol Independent Multicast (PIM), GARP Multicast Registration Protocol (GMRP) and Multicast DNS (mDNS).

The choice is ultimately yours, but you probably will want to select the multicast routing protocol that has the most widespread deployment, which is PIM. This protocol’s support is better, more network vendors implement it and it is probably a safe bet that it is generally a superior protocol.

Step 4. Select PIM Dense Mode or PIM Sparse Mode. There are two flavors of PIM: Dense Mode (PIM-DM) and Sparse Mode (PIM-SM). Returning to our tree metaphor, think of PIM-DM as growing a new tree and PIM-SM as pruning back an existing tree. PIM-SM is generally preferred because it cuts out nodes that do not need to be included in the multicast. PIM-DM floods the nodes, using far more network resources. This makes PIM-SM inherently more efficient and more popular than PIM-DM.

Step 5. Tune up your routers. This is probably the most overlooked step in the entire multicast process, but it is one of the most important. PIM relies on standard routing tables to build its multicast forwarding paths. If your routing tables aren’t as they should be, multicast won’t behave properly. Make sure your unicast traffic is behaving exactly as you’d expect and that all unicast routes are present and correct. Don’t think about running multicast on your network until you are sure of your unicast routing because if your unicast traffic isn’t right, there is very little hope for a multicast to operate as it should.

Step 6. Implement reverse path forwarding. IP multicast uses reverse path forwarding (RPF) to assure that the routers or L3 switches receive a multicast packet on the correct interface. In the unicast world this is pretty much automatic. However, unlike unicast routing that forwards packets toward their destination, multicast routing actually forwards packets away from the source. Therefore, a multicast-enabled router or L3 switch has to determine which direction is upstream (toward the source) and which direction is downstream (away from the source, toward the possible node destinations). In other words, rather than sending data toward a receiving node, the router actually sends it away from the source, hence the need for RPF. It’s complex, so you can spend time trying to figure it out, or you can implement RPF in your network devices and forget about it.

Step 7. Routing multicast over the Internet / Internet 2. You may decide to keep your multicast traffic confined to your campus network. If so, you can safely ignore this step. However, if you do want to run multicast over your service provider’s WAN, be prepared to face a series of potential issues. For example, if the service provider doesn’t offer multicast-enabled service, you will have to tunnel the multi­cast traffic through their network. If the service provider supports multicast, doing so adds overhead and management complexity for them — and cost for you. Sit down with your service provider to determine what they do — or don’t — support, what it will cost you and what will best accommodate your multicast needs in their network.

As you can see, IP multicast is a robust protocol that can effectively route video traffic across the campus network or across the world. It can deliver video packets efficiently to only those network nodes that need the transmission. Multicast and its various intricacies are complex topics that can fill entire books. But don’t hesitate — the benefits of implementing multicast are well worth the pain. It will make your network more efficient and your campus customers more productive.