IPv4 Multicast and IPv6: A Deployment Comparison

Having been involved in deploying interdomain IPv4 multicast on a Tier 1 ISP network, I see parallels between IPv4 multicast and the IPv6 deployment work that is keeping many in our industry busy these days. Let’s take a look at the similarities and one critical difference.

Feature Availability – In the late 1990s and early 2000s, the Tier 1 ISPs, with their high end routers that included strong support for multicast features, rolled out multicast in their core. Broadband providers had to consider many different types of equipment in their access infrastructure and the CPE. Their path to a multicast enabled network was considerably more challenging.

The same holds true today for IPv6 deployment. The Tier 1 ISPs have dual stack IPv4/IPv6 in their core, although some may not yet be ready to offer production IPv6 service to customers. The access piece is once again the more difficult portion of the network to enable for a new service. The Ciscos and Junipers of the industry may have a solid IPv6 story for mid-range and high-end routers; other vendors are still shipping products that are not ready for delivering a production-quality IPv6 service.

Motivation – Multicast offers bandwidth savings that benefit service providers and content providers. In this usage, a content provider may be a traditional one like Yahoo or an enterprise customer that wants to distribute live video of a company event. Rather than sending streams for every end user, the use of multicast results in one stream from the sender that is replicated by the network.

Were the large ISPs and broadband providers motivated to deploy multicast? I would argue that both were, although probably to different extents. National ISPs had better insight into the scaling challenges in moving huge amounts of traffic. Now looking at IPv6 deployment, the comparison in motivation is more complicated. All entities that operate networks need an IPv6 transition plan for business continuity’s sake. Tier 1 ISPs were pushed several years ago to offer IPv6 service for the federal government as part of the Office of Management and Budget’s mandate for agencies to adopt IPv6. Broadband providers do not face the same external pressures to deploy IPv6. The typical consumer doesn’t know or care how he or she is reaching a popular website.

Chicken and Egg Problem – Both IPv4 multicast and IPv6 had to face the “chicken and egg” problem. The big content providers had no strong business driver to deploy multicast while a majority of end users could not access multicast content. The broadband providers saw limited benefit in deploying multicast while little multicast content was available. Multicast proponents (myself included) believed a “killer app” would generate demand for multicast service but this never materialized. To the disappointment of many, IPv4 multicast was never available for a sufficient percentage of end users to contribute to a richer Internet experience.

Unlike with IPv4 multicast, failing to widely adopt IPv6 is not an option. A particular network can not continue to offer full Internet connectivity without a mechanism to access IPv6 content. There will soon be no addresses to obtain from the registries. Although the IPv4 to IPv6 transition may have bumps along the way, IPv6 will replace IPv4 as the dominant IP version. From a traffic perspective, this will happen much sooner than you may think. Today’s top content providers–Google, Facebook, and Yahoo–represent a huge portion of Internet traffic. Once these providers send AAAA DNS records for their main web pages to the entire Internet (i.e., no whitelisting or other restrictions), IPv6 enabled hosts with IPv6 service will switch to the new protocol for these large traffic flows. At that time, IPv6 deployment will have a significant success to highlight, a noteworthy accomplishment that IPv4 multicast deployment never had.


The Cultural Divide in Documentation Availability

Companies with strong IP heritages freely share their documentation on the web. Pick any one of the top router/switch vendors and you can find documentation on almost any piece of network gear. Now try to find documentation from any vendor that offers gear such as HLRs, RNCs, or ASN-GWs. Good luck in finding anything in that area unless you have a support account tied to a contract.

Why the difference? Do the traditional wireline/wireless telecom equipment vendors believe there is competitive advantage in not sharing documentation with the Internet community? I don’t believe that to be the case. The difference lies in culture. Consider the openness with which IP developed and matured. The IETF model of rough consensus on public email lists is about as open as protocol development can be. Compare this to closed and proprietary ways of the old guard vendors. Interoperability was very limited. If you had Vendor X for a DWDM terminal, you were almost guaranteed to have the same vendor’s equipment on the remote end. The same holds true in the wireless space for RAN. Without this need for interoperability, documentation become something shared only during an RFP process.

Market forces have dragged traditional telecom equipment vendors into the IP world. It is one that is not aligned with how they think and how they develop, market, and support their gear. This will gradually change. In meantime, I’m going to go check what VLAN a vendor’s picocell uses to download its initial config…oh wait. Damn.