DRAG DROP
Answer: 
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 SwitchoverSource Specific
Multicast – Uses (*,G) joins as well as (S,G) Joins , Requires IGMPV3 Support, Hosts learn the multicast source address via out-of-banf mechanismi) 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 networkand 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 throughoutthe network to support the building of trees.
Dense mode protocols are undesirable because every tree built in some part of the network will always causeresource 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 networkunless a receiver has sent an explicit IGMP/MLD membership report (or “join”) for a group.
This variant of ASMis known to scale well and is the multicast paradigm we will mainly be discussing. This is the basis for PIMSparseMode, 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 C creating control plane state only on routers in the path between sources andreceivers, and in PIM-SM/BiDir, the Rendezvous Point (RP). They never create state in other parts of thenetwork. 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 toa receiver. The forwarding state on a shared tree is referred to as (*,G) forwarding state, where the * is a wildcard for ANY SOURCE. Additionally, PIM-SM supports the creation of forwarding state that relates to trafficfrom a specific source. These are known as SOURCE TREES, and the associated state is referred to as (S,G)forwarding stateSSM is the model used when the receiver (or some proxy) sends (S,G) “joins” to indicate that it wants toreceive traffic sent by source S to group G. This is possible with IGMPv3/MLDv2 “INCLUDE” modemembership reports. We therefore refer to this model as the Source-Specific Multicast (SSM) model.
SSMmandates 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 inSSM.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) flowin the text, implying that the flow could be an ASM group or an SSM channel