PIM SSM is the most efficient deployment of PIM out there.
The most complicated part of source‑specific multicast
is the signaling from host to router.
Let's explore why that is in this module.
In this module, we'll discuss the following, the basic operation of PIM SSM.
We'll see a demonstration of source‑specific multicast in action.
Here's a hint,
it's going to look very similar to the source tree
join from PIM any‑source multicast.
The secret is in the signaling.
Next, we'll look at the packets that matter for source‑specific multicast,
IGMPv3 and the PIM Join/Prune.
The Globomantics multicast deployment has been so successful that
corporate has authorized creation of an application to allow users to
browse concerts recordings with the channel browser.
The servers will stream previously recorded concerts via
multicast to a dedicated multicast group.
Each concert has its own dedicated server streaming the media.
All the users must do is signal which one they want to receive.
To support this functionality, the channel browser application will use IGMPv3.
In previous implementations of multicast,
such as dense mode,
the receiver had no control over the stream they would receive.
In dense mode multicast,
any‑source sending to a multicast group would be flooded equally,
forcing all receivers to receive streams from every source.
The same is true of any‑source multicast.
With ASM,
any‑source that registers with an RP will be delivered to a
receiver if the multicast group is requested.
What that means is that the receiver application would either have to
discard or blend the stream depending on the use case.
Source‑specific multicast gives receivers the control
of what streams they will receive.
By using the newest version of signal protocols and some
method of knowing the available sources,
a receiver can signal for a particular source directly.
Not only does that optimize the flow of traffic by
ensuring only specific traffic is delivered,
it also obviates the need for a rendezvous point or a shared tree to be built.
In this example,
the receiver signals that it wants multicast group
232.3.2.1 delivered from source 10.99.1.100.
The same process we've understood through this entire course applies here
as well, the report is turned into a PIM join and the requested sources
used to determine the Unicast's best path.
That best path interface becomes the incoming interface for
this flow and the PIM join is forwarded on.
Once the first‑hop router adds an interface to its outgoing interface list,
the traffic flows down according to the outgoing
interface list built by those PIM joins,
and now comes the real scalable power of PIM SSM.
Because the receivers can request the stream they want directly,
we can reuse multicast groups.
This happens a lot in use cases like IPTV where a channel
browser and remote are used to switch between sources
sending to the same multicast group.
This works because each router tracks an S, G flow as a separate stream.
This freedom comes at a cost.
The requirements to support PIM SSM somewhat hefty.
First, the network equipment must support it.
This is probably the easiest requirement to fulfill these days.
The PIM SSM RFC reserves 232.0.0.0/8 as a special range for groups to run SSM.
This is a configurable setting,
but most people leave it as there's already reserved range.
The reason routers must know what range is acting as
the SSM group range is simple.
A multicast group in the SSM range must be requested with a source for the RFC,
sending in any‑source PIM join to a multicast group in the SSM range
is not supported and the router will ignore it.
Your receiver must support IGMPv3 or MLDv2.
These protocols are 20 years old now,
so there isn't much excuse for them not to be supported.
Having said that,
both protocols do still see low adoption rates for some reason; the
receiver simply needs to know what to ask for.
Finally, in the case of IPTV as an example,
a channel browser is applied to a set‑top box so that the
remote can browse through the feeds.
The set‑top box has a list of all sources,
and the remote chooses what source to request by flipping channels.
IGMPv3 and MLDv2 do work without requesting a source so long as
the requested group is not in the SSM range.
This simply becomes an any‑source join.
In this example, one receiver has correctly sent the PIM join to 232.3.2.1,
including a source.
This S, G source tree flow will be forwarded up to the first‑hop router.
The other receiver has sent a *, G any‑source join to 232.3.2.1,
which will be ignored by the router.
Before we get too much further, let's clear up a misconception,
PIM‑SSM uses the PIM sparse mode implementation to
accomplish its optimal delivery,
but source‑specific multicast is a completely different RFC and
implementation entirely than any‑source multicast,
which also uses PIM sparse mode.
What this means is that source‑specific multicast
requires its own commands that are not on by default and
that the SSM range is not defined.
The use of IGMPv3 and MLDv2 is pointless.
The PIM routers will treat every report as a *,
G any‑source join, even if sent to the reserved SSM range in requesting a source.
Every rule has exceptions.
Normally,
an any‑source reports sent to an SSM‑defined group is ignored by the PIM router,
but there does exist a way to tell the router not to
ignore that request and to map it directly.
The details are a bit beyond the scope of the course,
but at a high level,
a router can use DNS or a static access list to take a normal
any‑source report for an SSM group and automatically resolve the
source and then forward the PIM join on as if the source had been
requested directly by the receiver.
It's intended as a migration strategy and not as a full implementation,
but it can help to implement SSM in a network where older receivers that don't support IGMPv3 still need multicast.