Drag the IP multicast characteristic on the left to match the correct multicast service model on the right.

DRAG DROP
Drag the IP multicast characteristic on the left to match the correct multicast service model on the right.

Answer: See the explanation

Explanation:
Any Source Multicast – Uses RP’s as the root of the shared tree for a multicast group, ONly
(S,G) state is build between the source and the recevier, Spport SPT Switchover Source
Specific Multicast – Uses (*,G) joins as well as (S,G) Joins , Requires IGMPV3 Support,
Hosts learn the multicast source address via out-of-banf mechanism

i) Dense Mode Flood-and-Prune Protocols (DVMRP / MOSPF / PIM-DM)
In dense mode protocols, all routers in the network are aware of all trees, their sources and
receivers.
Protocols such as DVMRP and PIM dense mode flood “active source” information across the
whole network and build trees by creating “Prune State” in parts of the topology where traffic
for a specific tree is unwanted.
They are also called flood-and-prune protocols. In MOSPF, information about receivers is
flooded throughout the network to support the building of trees.
Dense mode protocols are undesirable because every tree built in some part of the network
will always cause resource utilization (with convergence impact) on all routers in the network
(or within the administrative scope, if configured). We will not be discussing these protocols
in the rest of this paper.
ii) Sparse Mode Explicit Join Protocols (PIM-SM/PIM-BiDir)
With sparse mode explicit join protocols we do not create a group-specific forwarding state in
the network unless a receiver has sent an explicit IGMP/MLD membership report (or “join”)
for a group. This variant of ASM is known to scale well and is the multicast paradigm we
will mainly be discussing. This is the basis for PIMSparse Mode, which most multicast
deployments have used to this point. This is also the basis for PIM-BiDir, which will be
increasingly deployed for MANY (sources) TO MANY (receivers) applications.
These protocols are called sparse mode because they efficiently support IP multicast delivery
trees with a “sparse” receiver population – creating control plane state only on routers in the
path between sources and receivers, and in PIM-SM/BiDir, the Rendezvous Point (RP). They
never create state in other parts of the network. State in a router is only built explicitly when
it receives a join from a downstream router or receiver, hence the name “explicit join
protocols”.

Both PIM-SM and PIM-BiDir employ “SHARED TREES”, which allow traffic from any
source to be forwarded to a receiver. The forwarding state on a shared tree is referred to as
(*,G) forwarding state, where the * is a wild card for ANY SOURCE. Additionally, PIM-SM
supports the creation of forwarding state that relates to traffic from a specific source. These
are known as SOURCE TREES, and the associated state is referred to as (S, G) forwarding
state SSM is the model used when the receiver (or some proxy) sends (S,G) “joins” to
indicate that it wants to receive traffic sent by source S to group G. This is possible with
IGMPv3/MLDv2 “INCLUDE” mode membership reports. We therefore refer to this model
as the Source-Specific Multicast (SSM) model. SSM mandates the use of an explicit-join
protocol between routers. The standard protocol for this is PIM-SSM, which is simply the
subset of PIM-SM used to create (S,G) trees. There are no shared trees (*,G) state in SSM.
Multicast receivers can thus “join” an ASM group G, or “join” (or more accurately
“subscribe” to) an SSM (S, G) channel. To avoid having to repeat the term “ASM group or
SSM channel”, we will use the term (multicast) flow in the text, implying that the flow could
be an ASM group or an SSM channel