IP Multicast - Overview (Part 1)

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.

Definition of 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.

RFC 1112 - Host Extensions for IP Multicasting

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:

Unicast addressing
You are certainly already familiar with this one. Unicast addresses are used to communicate or send traffic to a single host or destination. Each host is identified by a unique IP address.
Anycast addressing
The anycast addresses are used to send traffic to the nearest member of a group of anycast hosts or destinations. All members of a group share the same destination IP address. Unicast and anycast addresses cannot be differentiated from each other on both network and data-link layers; the anycast traffic is treated in the same manner as for unicast.
Broadcast addressing
Broadcast addresses are used to send traffic to all hosts of a given subnet. Different types of broadcast addresses exists, however they are outside of the scope of this article.
Multicast addressing
Multicast addresses are used to send traffic to a group of hosts interested in receiving that traffic, the group being identified by a single destination address. Multicast allow for one-to-many communication, that is traffic is sent from one host, called a source, to a group of interested hosts, called receivers. As we will see throughout this article, multicast forwarding allows for efficient use of resources, like network bandwidth, session states and servers' CPUs.

Multicast Applications

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.

Terminology and Components

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:

Source
A host that sends multicast IP packets. When a source originates multicast packets, it always use its unicast address as the source address and a multicast group as the destination address.
Receiver
A host interested in receiving multicast traffic for a given group address. A receiver uses a group membership protocol like IGMP or the IPv6 equivalent MLD, to advertise its desire to receive multicast traffic.
Group address
A multicast IP address in the 224/4 (Class D) range.
Designated Router (DR)
A router who is responsible for forwarding multicast packets into the network.
Designated Forwarder (DF)
A router who is responsible for forwarding multicast traffic to the receivers on a given subnet.
Multicast Distribution Tree (MDT)
Multicast traffic always flows over what is called a Multicast Distribution Tree (MDT). The MDT connects the source, at the root, with the receivers for a given multicast group, at the leaf.
Rendezvous Point (RP)
A Rendezvous Point is a multicast router whose purpose is to discover multicast sources and to connect them with the potential receivers. The rendezvous point is always the root of a shared multicast distribution tree in Protocol Independent Multicast - Sparse Mode (PIM-SM).
Multicast Routing Protocol
Protocol whose task is to build and establish a loop-free distribution tree. Typical multicast routing protocols are DVMRP and PIM, we will cover both of them later in this article series.
Upstream Interface
A multicast enabled interface that points toward a multicast source or RP.
Downstream Interface:
A multicast enabled interface that leads toward one or several multicast receivers.

Delivery Models

Two delivery models currently exists for IP multicast:

Any-Source Multicast (ASM)
The ASM delivery model has been originally defined in RFC 1112. As the name implies, this model allow to connect any multicast sources, which enable one-to-many applications like IPTV but also many-to-many applications like video conferencing.
Source-Specific Multicast (SSM)
With the SSM delivery model, a multicast receivers always specifies from which source(s) it want to receive multicast traffic. Obviously, for SSM to works, the receiver must previously know the source of the multicast traffic, which is generally known from the client application. In contrast to ASM, the SSM delivery model only provides support for one-to-many applications. The SSM model comes with a number of benefits, such as:
  • Multicast Traffic always flows on the Shortest Path Tree (SPT), which usually allow for better performance because of the least number of hops. It also makes SSM well-suited for delay-sensitive applications like Voice.
  • Avoid the usage of complex protocols and algorithms. A good example is the avoidance of the Rendezvous Point (RP) to connect sources and receivers together, as it is done in the ASM model.

The next article will covers multicast addressing format, administrative scopes and standardized ranges.

About the author Nicolas Chabbey

Nicolas Chabbey is a Network Engineer certified with Cisco Systems and Juniper Networks. He has begun his career in 2003, and has designed, implemented and maintained networks for enterprises and service providers. When he is not behind a computer, he is riding his mountain bike across the Swiss alps.

Previous Home Next

Comments

blog comments powered by Disqus