Protocol Independent Multicast Light (PIM Light)
Extracted elements (16)
A PLI may be enabled automatically via an underlying mechanism on a logical interface—for example, in a BIER domain a logical interface can connect two or more BIER edge routers, avoiding the need for manual PLI configuration on each such interface.
DR election is not supported on a PIM Light router because Hello messages are absent. The network design must ensure DR election occurs within the PIM domain; in BIER interconnect scenarios, redundant PIM routers at the BIER domain edge MUST establish PIM adjacency per RFC 7761 to prevent multicast stream duplication.
PIM Assert is not supported on PLIs because Assert messages are only accepted from known PIM neighbors (RFC 7761 Section 4.6), and PLIs do not establish PIM neighbor state. Network design or implementation-specific mechanisms (e.g., SPF-based EBBR selection with IP tie-breaking in BIER domains) must prevent duplicate streams instead.
PIM Light is designed specifically for scenarios where full PIM-SM neighborship is impossible or undesirable, such as BIER networks connecting multiple PIM domains where PIM Join/Prune messages are tunneled via BIER. The trade-off is loss of Hello-dependent features (DR election, Assert, Join Attribute negotiation) in exchange for simpler cross-domain multicast state signaling.
PIM Light only supports PIM-SM (including PIM-SSM per RFC 7761). PIM Dense Mode (RFC 3973) and Bidirectional PIM (RFC 5015) are explicitly not supported and not covered by this document.
PIM Light supports the PORT reliable transport mechanism (RFC 6559) over TCP or SCTP (destination port 8471). Because Hello messages are absent, the Connection ID must be configured on each PLI endpoint; for TCP, each end must be explicitly configured as active or passive transport open to avoid call collision.
Applications or networks on which PLIs are deployed MUST ensure there is no multicast packet duplication, such as multiple upstream routers sending the same multicast stream to a single downstream router.
Because a PLI does not use PIM Hello messages and therefore cannot discover neighbor capabilities for Join Attributes (RFC 5384), PIM Light SHOULD NOT send a Join message containing a Join Attribute unless neighbors are known via configuration to be capable or an RFC/Internet-Draft explicitly permits it.
If there are redundant PIM routers at the edge of a BIER domain using PLI, they MUST establish PIM adjacency as per RFC 7761 to prevent multicast stream duplication and to ensure DR election at the edge of the BIER domain.
Join/Prune messages not received from a PIM neighbor MUST be dropped unless PLI is enabled on the interface. This is the mechanism by which PLI operation is gated to explicitly configured interfaces.
PIM message types other than those explicitly listed as supported MUST NOT be processed if received on a PLI.
Because Hello messages are not processed on PLIs, PLI failures may not be discovered in a PIM Light domain, causing multicast routes to remain active until OIF expiry. External failure detection mechanisms such as BFD can be used; if BFD to the far-end PLI goes down, PIM must remove that PLI from its OIF list for affected (S,G) routes.
PIM Light supports only the following PIM message types: type 1 (Register), type 2 (Register Stop), type 3 (Join/Prune), type 8 (Candidate RP Advertisement), type 13.0 (PIM Packed Null-Register), type 13.1 (PIM Packed Register-Stop), and any future PIM message types where the destination is a unicast IP address.
The PIM Light Interface (PLI) is a new type of PIM interface that accepts Join/Prune messages from unknown PIM routers without requiring a PIM Hello message. It does not create general-purpose state for neighboring PIM routers and only processes Join/Prune messages from downstream routers in the multicast routing table.
Because PIM Light does not verify PIM neighbor adjacency for incoming Join/Prune messages, implementations MUST ensure only Join/Prune messages arriving at a configured PLI are processed; messages on non-PLI interfaces MUST be discarded. Route policies SHOULD additionally be implemented to accept only desired (S,G) pairs, discarding all others.
Only forged Join/Prune messages are considered a potential attack vector for PIM Light, as it does not process Hello or Assert messages. Authentication mechanisms from RFC 5796 can be applied via IPsec ESP or optionally AH, and security considerations from RFC 7761 and RFC 4607 SHOULD be considered where appropriate.