In this article I'm going to discuss the basics of IPv4 Multicast, and a few of the protocols which

make the magic happen. This is meant for a crash course introduction for people who are new to
networking or just haven't had the exposure to multicast before. For those of you already
acquainted with multicast, I will provide a few links at the bottom for some great resources for
further reading. I highly recommend after this article taking a look; for anyone really interested
in the detailed operations of multicast they are tough to beat.

Multicast can seem like a lot of voodoo for those who are not familiar with how the theory is
actually implemented in Cisco gear. It is indeed a departure from our normal thinking when it
comes to how routing works, what it's supposed to accomplish, and how it operates to achieves
these goals.  At the very basic premise, multicast enables a one to many, or many to many,
communication methodology.  A source - or sources - can send traffic to a designated "group
address", which is within the Multicast IP range of 224.0.0.0 through 239.255.255.255. This
traffic is then forwarded to the destinations as described below. Keep in mind – group addresses
are always the destination – and never the source, of traffic.

As an example - when you send an email to a group email address, you only enter one address in
the TO field.  However, the email server knows this group address represents many recipients,
and automagically delivers a copy of that email to each one individually.  You only needed to
send one email and it reached 200 people!  Multicast is a lot like that, you only need to originate
the traffic once, and it will be replicated throughout the network as your design dictates to reach
each intended recipient.  Pretty neat huh?

Before we start in on the routing mechanics, I'd like to introduce a few foundational concepts
that you will need to know to really grasp multicast.

RPF Check

The RPF check is the basic premise that ensures a loop free multicast forwarding path.  RPF
relies largely on the unicast routing table for its functionality, leveraging the information already
compiled there.  The router will run an RPF check on each multicast packet that comes in an
interface. The RPF check verifies that the interface the packet is received on, is the same
interface the router would forward traffic which is destined for that multicast source.  A quick
example where the unicast routing table is the only source for the RPF check....

 
 

RouterA receives a packet a on Fa0/1, from HostC.  RouterA takes the source IP and then does a
route lookup on how to get back to HostC.  If the route points out Fa0/1, then the RPF check
passes.  If for some reason, it pointed out another interface, then the RPF check would fail.

There are other methods to ensure the RPF check passes, such as tweaking unicast routing,
utilizing static mroutes, or mBGP, but those are outside the scope of this discussion.  I highly
recommend Marko Milivojevic's series of blogs over at IPExpert that discuss overcoming RPF
Check failures if you want to dive further into this topic.

IGMP

IGMP allows hosts to communicate with network entities such as routers, to make known their
desire to receive multicast traffic on specific groups.  IGMPv1, IGMPv2, and IGMPv3 all exist,
and support various features between them; IGMPv2 is the popularly deployed revision right
now.  IGMPv3 requires a lot of application support to operate effectively, which hasn't really
been seen so far.

There are some mechanisms in place that allow routers and switches to optimize the process of
further refining the forwarding path of multicast traffic.  One is Cisco’s CGMP – Cisco Group
Management Protocol – which defines a method for switches and routers to communicate with
one another so that way the switches can maintain a host table for who has joined a group. The
other is IGMP snooping, which allows switches to peek into IGMP join messages and then
builds a host table based on the information it gleans. This allows switches to forward multicast
feeds only on ports it knows interested hosts are connected to.

Short and sweet: IGMP lets hosts join the group to receive traffic. Routers will take IGMP
requests and tranlsate those into PIM-JOIN messages...which brings us to our next topic -
Protocol Independant Multicast.

PIM
PIM is a protocol that communicates multicast source and destination information between
routers within a network, allowing them to forward or not forward traffic, based on that
information. How they accomplish that depends on the mode of operation, which can be one of
three modes: Sparse Mode, Dense Mode, or Sparse-Dense Mode.  Each mode has it's own
benefits and drawbacks, which I'll discuss next. PIM operates in such a way that it is agnostic to
which unicast routing protocol you are running, so long as reachability is provided and the
unicast routing table is made available for RPF checks. This avoids the need to deploy a new
routing protocol in your network just to support multicast, easing the implementation and
adoption.  This is simply another service that takes advantage of your core connectivity.

Sparse Mode

Sparse Mode is the best-case scenario in many ways, it looks to forward traffic only when
requested. Sparse mode initially leverages the Shared Tree in distributing multicast feeds to hosts
that elect to receive them. This implies that something must keep track of each group and
whether it has been requested - this role falls to the Rendezvous Point, aka the RP.  The RP is
administratively designated, and is often placed in a centralized position within the network to
ensure it has the best opportunity to control traffic.  The RP will receive source advertisements
(which is actually a leaf PIM router saying they have an active source) and will record that info. 
If the RP knows of a destination - which in this case would be another PIM-enabled router - that
wishes to receive that traffic, it will forward the traffic from the source on to that destination,
forming what is known as the shared tree.  This "shared tree" keeps the RP in the path and allows
it to distribute the traffic only out interfaces which it has received a PIM-JOIN message from. 
Each PIM router in the path between the RP and the destination will have already seen the PIM-
Join and will know to forward the traffic.  With this design, traffic will not be replicated and
forwarded unless someone requests it, which keeps bandwidth utilization down to a minimum.

Dense Mode

There are cases when Sparse Mode may not be the best choice - albeit those times are rare these
days.  If you have lots of receivers across your network, and only a few people wish not to
receive it, then Sparse Mode may seem like an awful lot of work just to save the bandwidth on
those few links.  If you want to push data to everyone in a given network, dense mode may be
your ticket.  Dense mode assumes from the beginning that EVERYONE wants this data, and
pushes it to every leaf node out every interface.  Eventually PIM prunes these nodes which have
no interested destinations, but for a time the traffic will be replicated until that process
completes.  I've not seen dense mode used often, quite frankly, and even in the few cases where
it was deployed, Sparse-Dense mode could have been used.

Sparse-Dense Mode
This brings us to the hybrid - Sparse-Dense mode. Sparse-Dense mode operates in both modes -
on a per-group basis.  If an RP exists for a given group, it will operate in Sparse Mode. If no RP
is set for a group, then it operates in Dense Mode, for that group. Pretty simple, right? Right.

The main caveat to multicast which makes this mode of operation useful is Auto-RP.  Auto-RP is
a method of dynamically advertising the RP for a given group within sparse mode, so that you do
not have to configure every PIM router in the environment each time you deploy a new group. 
Auto-RP speaks on 224.0.1.39, and 224.0.1.40, and does so in a dense fashion - talking to every
PIM router in the domain as it is an advertisement.  There is indeed a work-around to this which
you can implement in Sparse Mode, but that requires making a change on each PIM router, albeit
only once.  By deploying PIM in a sparse-dense mode from the beginning, not only will Auto-RP
work without a workaround, but you will support sparse mode operation and also allowing
groups to fall back into dense mode if necessary.

Now that we’ve discussed IGMP, PIM, RPF checks, you should be better prepared to tackle
multicast!  As I said at the beginning of the article, this was merely an introduction – a brief one
at that – and should just whet your appetite!  Here are a few links and books you can take a look
at to further your understanding of what is a really elegant solution to intelligently multiplexing
traffic.

Cisco DocCD for 12.4T IOS Train ::

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/12_4t/imc_12_4t_book.html

Cisco IP Multicast Home ::

http://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html

 
Cisco Press Interdomain Multicast Solutions Guide ::
http://www.ciscopress.com/bookstore/product.asp?isbn=1587050838