This article is the first of a series about IP multicast. Multicast is a great technology which you may come across as an network engineer. Unfortunately, it's still a frequently overlooked technology due to its alleged complexity. In fact, multicast addressing is no more complex than unicast. Multicast routing is only about understanding a few basic principles, but once you get them, you can easily design and implement very large and sparse multicast networks. Troubleshooting is certainly more difficult because of the stateful nature of multicast routing, but with proper use of tools and procedures, you can quickly figure out where problems lies and how to solve them. As these aspects are very different from each other, I will cover them in separate articles. Here's the first article; an overview of IP multicast.
IP multicast is a technology full of potential and benefits. Unfortunately, it is still widely undervalued because it is not well understood. In fact, the multicast forwarding paradigm is slightly different from unicast, even if it is not more complex, engineers and decision makers may be reluctant in deploying IP multicast in their networks, at least until they really need it.
Let's start by a strict definition of IP multicasting, as defined by RFC 1112.
IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address.
At the first read, multicast seem very similar to broadcast, in reality, the way it is forwarded and distributed differs significantly. IP multicast allows a host to send a unique copy of data to a group of host identified by a multicast group address. As we will see throughout the articles, multicast allows us to save resources like bandwidth, by avoiding us to send duplicate copies of the same content.
When we are talking about multicast, we are first and foremost talking about the addressing type. In IP networking, four addressing types currently exists:
The use of multicast bring a number of benefits compared to unicast. As previously mentioned, multicast allow for efficient use of resources, primarily bandwidth. In fact, a multicast network typically replicates the multicast traffic to the part of the network where the interested receivers are located. It do it only once, in contrast to unicast where a host typically send duplicate copies of the same unicast traffic to multiple destinations.
To better understand the benefits of multicast, let's take a typical use case. A service provider want to offer to its broadband subscribers, IPTV service. The latter allows the customers to receive High Definition (HD) television over the same packed-switched network they get internet connectivity and maybe also digital voice communication. The service provider is getting the TV channels from various national and international broadcasters by satellite feeds or by any other means. All customers will receive the same TV channels and therefore the same content. If the service provider use unicast as the delivery model, the network would have to potentially transport as many copies of the TV channels as there are watchers among the service providers customers. It can represent ten of thousands, if not millions of concurrent unicast flows at a given time.
Given the weight of a typical 720p HDTV channel, which is around 6 Mbps, if the service provider were to broadcast a popular live football event, we can easily figure out that the network would collapse rapidly due to the congestion. Someone could argue that if you deploy several application-layer relays at the edge of the network (close to the customers), the whole service would scale. If in fact you can limit the congestion in the core of your network, you are still duplicating the content at the application level with the added complexity of implementing and managing a numbers of relays. For service as resource hungry as video, it may not be a very wise decision. A better approach is to delegate this duplication task to the network in a application independent manner. Another issues with this model is the fact every relays must keep states information for every channels a customer is currently watching. This is particularly true if the transport protocol used is connection oriented like TCP or SCTP because the relays must keeps session states in memory. The relay would also have to handle a large numbers of concurrent video streams, which alone may severely impacts the performance and the scalability of your IPTV service.
This led us to the fact that most multicast applications use unreliable transport protocols like UDP, RTP or both. In fact, the source of a multicast traffic is unaware of the receivers. It doesn't know where the receivers are located, nor who they are, and if they received all or any of the multicast traffic. Like for unicast, multicast is delivered in best-effort, there is no guarantees the traffic will be delivered to the interested receivers. Multicast applications may also makes Quality of Service (QoS) harder, because queuing disciplines like Weighted Random Early Detection (WRED) don't work well with UDP traffic. In fact WRED drops traffic based on the weight or class of traffic the flows belongs to. If these flows uses TCP, they reduces their traffic rate by responding to the random packet drops. UDP based flows do not.
Another and more recent application of multicast, is its use as a transport protocol with virtual overlay network. Virtual overlay networks usually simulate a Layer-2 network over an IP fabric, for traffic separation purpose. The overlay network is built between several tunnel endpoints, mostly virtual switches or virtual routers sitting in a hypervisor. As the network must forwarding Broadcast, Multicast and Unknown Unicast (BUM) traffic, the underlying network protocol, here IP, must also support the same forwarding paradigms for an efficient use of the network's bandwidth. A multicast underlay network enable the forwarding of unique copies of BUM traffic to all interested endpoints, across IP boundaries and even across wide area networks.
IP Multicast comes with its own nomenclature and terminology. Here is a number of terms and common components you will certainly come across when working with multicast networks:
Two delivery models currently exists for IP multicast:
The next article will covers multicast addressing format, administrative scopes and standardized ranges.