A museums and culture department needs many sensors to talk to many collectors on the same groups without building a separate (S,G) tree per sender. Which PIM variant is designed for that many-to-many pattern?
Select an answer to reveal the explanation.
Short Explanation
When dozens of sensors all jabber on one group, building a shortest-path tree for every source turns into a state avalanche. Bidirectional PIM keeps traffic on shared trees both ways toward the RP, so you skip that per-source tree tax. It’s the many-to-many specialist.
Full Explanation
Museums and culture sensor meshes often present many senders and many collectors on shared groups. Bidirectional PIM is designed for that many-to-many pattern: traffic stays on shared trees rooted at an RP (with designated-forwarder election per link) and does not create a separate (S,G) shortest-path tree per sensor. That avoids mroute-state explosion when dozens of civic sensors jabber on the same groups.
PIM Dense Mode with graft messages only toward first-hop routers remains a flood/graft dense model. It does not provide the shared-tree-only many-to-many efficiency Bidir-PIM targets.
Source-Specific Multicast limited to 232/8 is optimized for one-to-many channels with explicit (S,G) interest, which increases per-source channelization rather than eliminating per-source tree state for many talkers on one group.
IGMPv3 INCLUDE lists that pin every sensor as an SSM source push the design further into per-source SSM channels, amplifying the state problem the stem wants to avoid.
Exam caveat: Bidir-PIM still needs a reachable RP/phantom RP plan and DF election understanding; verify platform support rather than assuming it is simply “PIM-SM with SPT disabled.”
Operational check: enable bidir for the sensor group range, confirm DF election on shared segments, and verify mroute state remains shared-tree oriented as sensors join. Capture state scale before/after in the museum network notes for capacity planning.