Get started Bring yourself up to speed with our introductory content.

Introduction to IP multicast

A look at the basics of multicasting.

I'm sure most of you have heard the terms multicast or multicasting before. Sometimes we hear these terms in routing conversations when talking about OSPF or EIGRP. Other times they are used to describe communication in video teleconferencing or Webcasting. As newer multicast capable applications are developed it becomes increasingly important to understand how multicasting works and how we can efficiently use various networking protocols to control multicast traffic in our environment. This week's tip will focus on the basic fundamentals of IP multicast. We will save the multicast routing protocol conversation for later.

What is multicasting?
Simply put, multicasting is the process of sending data to a group of hosts, also known as receivers. In contrast, "broadcasting" or "unicasting" sends data to all or one host(s) respectively. Think of multicasting in terms of listening to the radio. Somewhere out there a radio station is playing music over a certain frequency, say 101.1FM. Because you like rock music, you tune in your radio to 101.1FM and listen to the music. Keep in mind you're not the only one listening to that station and the person next to you may in fact be listening to a different station altogether! Ok, so let's look at the components of our listening experience and compare our example to multicasting terminology:

1) Radio Station --------------> Multicast Source (S)
2) Music ------------------------> Multicast Data Stream
3) Frequency (101.1FM)----> Multicast Group Address (G)
4) Listener (You)-------------> Multicast Receiver

I will add one more thing about the multicast stream itself. There are "multicast" applications out there which actually send multiple unicast streams to receivers. One of the advantages to multicasting certain data is that only one copy has to be sent from the source, which in a very large environment cuts down on the risk that the source could be overloaded or slow points in a network could become potential bottlenecks for all data.

Sparse vs. Dense
One of the key elements in IP Multicast design is determining the number of multicast receivers within your network. Just like in our example it's important to remember that not every receiver will want or be able to join all multicast data streams or groups. The terms sparse and dense refer to the relationship of multicast receivers and the total number of hosts in a network. If the number of receivers is high in comparison to the total number of hosts, then the domain (network) is densely populated. In contrast if the number of receivers is low relative to the number of total hosts then the domain is sparsely populated. These terms are important when planning for the mechanisms you will use to route multicast traffic through your network.

In a lot of cases it is important to prevent traffic from reaching certain boundaries either inside or outside your network. Scope refers to the "distance" a packet can travel before it is dropped. This is usually accomplished with the TTL value in the IP packet. When a TTL value equals 1, the receiving router does not forward the packet. Packets with a TTL=1 are referred to as local or this subnet. An example would be the OSPF multicast packet addressed to – its TTL is set to 1 so the hello packet will not go outside a subnet. This concept is important when talking about the Multicast Backbone or MBone, which I will talk about in future articles.

What's to come
So now hopefully you have an idea of what multicasting is and how it can be used for certain data streams within your network. Next week I am going to introduce you to the mechanisms and protocols surrounding multicast group membership.

Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, INC, a wholly owned subsidiary of SBC Communications. Doug has over 7 years in the industry and currently provides high level business and technology consulting for various federal clients in the Washington D.C. area. He can be reached at [email protected].

This was last published in January 2005

Dig Deeper on Network protocols and standards