A municipal hospital wants multicast clinical imaging to follow PIM sparse-mode concepts at ENCOR describe depth. What is PIM-SM’s core role in that design?

A municipal hospital wanting multicast clinical imaging at ENCOR describe depth should map PIM sparse-mode’s core role correctly. PIM-SM routes multicast by building shared trees via a Rendezvous Point (RP) and source trees as needed, rather than flooding every group everywhere. Imaging viewers register interest; traffic is pulled toward those receivers through the RP-anchored shared tree and can switch to a shortest-path source tree when appropriate. That model fits clinical wings where not every VLAN needs every modality feed, preserving bandwidth for charting and EHR traffic instead of dense-mode flood behavior.

First-hop gateway redundancy with a virtual IP for nurse-station PCs fails because that is HSRP/VRRP territory, not PIM-SM’s multicast tree role. Translating inside SCADA addresses to a public PAT pool fails because NAT/PAT solves address sharing for remote access, not sparse-mode multicast distribution of imaging. Mirroring all VLAN traffic to a packet analyzer with SPAN fails because SPAN is local traffic copy for troubleshooting, not a multicast routing paradigm.

Exam caveat: dense mode floods then prunes; sparse mode assumes sparse interest and uses an RP. When the stem emphasizes “not flooding every group everywhere” or RP/shared-tree language, PIM-SM is the intended concept. Do not pick FHRP, NAT, or SPAN distractors that share campus vocabulary but answer a different problem.

Operational check: confirm RP mapping (static, Auto-RP, or BSR as designed), verify show ip pim rp mapping and mroute state for an imaging group, and ensure interested clinic segments show (*,G)/(S,G) state while uninterested segments do not carry the stream.