Internet-Draft PIM Light September 2024
Bidgoli, et al. Expires 7 March 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-pim-light-07
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Bidgoli, Ed.
Nokia
S. Venaas
Cisco System, Inc.
M. Mishra
Cisco System
Z. Zhang
Juniper Networks
M. McBride
Futurewei Technologies Inc.

PIM Light

Abstract

This document specifies Protocol Independent Multicast Light (PIM Light) and PIM Light Interface (PLI) which does not need PIM Hello message to accept PIM Join/Prune messages. PLI can signal multicast states over networks that can not support full PIM neighbor discovery, as an example BIER networks that are connecting two or more PIM domains. This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 March 2025.

Table of Contents

1. Introduction

This document specifies the Protocol Independent Multicast Light (PIM Light) and PIM Light Interface (PLI) procedures. PLI is a new type of PIM interface that allows signaling of PIM Join/Prune packets without full PIM neighbor discovery. PLI is useful in scenarios where multicast state needs to be signaled over networks or media that do not support or require full PIM neighborship between routers. The document details procedures and considerations needed for PIM Light and PLI to ensure efficient routing of multicast groups for specific deployment environments.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.1. Definitions

This document uses definitions used in Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification [RFC7761]

3. PIM Light Interface

RFC [RFC7761] section 4.3.1 describes the PIM neighbor discovery via Hello messages. In section 4.5 it describes that If a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing.

In certain scenarios, it is desirable to establish multicast states between two Layer 3 adjacent routers without forming a PIM neighborship. This can be necessary for various reasons, such as signaling multicast states upstream between multiple PIM domains over a network that is not optimized for PIM or does not necessitate PIM Neighbor establishment. For example, in a Bit Index Explicit Replication (BIER) [RFC8279] networks connecting multiple PIM domains, where PIM Join/Prune messages are tunneled via BIER as specified in [draft-ietf-bier-pim-signaling].

A PIM Light Interface (PLI) accepts Join/Prune messages from an unknown PIM router without requiring a PIM Hello message from the router. The absence of Hello messages on a PLI means there is no mechanism to discover neighboring PIM routers or their capabilities, nor to execute basic algorithms such as Designated Router (DR) election [RFC7761]. Consequently, the PIM Light router does not create any general-purpose state for neighboring PIM routers and only processes Join/Prune messages from downstream routers in its multicast routing table. Processing these Join/Prune messages will introduce multicast states in a PIM Light router.

Due to these constraints, a PLI should be deployed in very specific scenarios. The application using these PLIs MUST ensure there is no multicast packet duplication, such as multiple upstream routers sending the same multicast stream to a single downstream router.

3.1. PLI supported Messages

As per IANA [iana_pim-parameters], PIM supports numerous message types. However, PIM Light only supports message type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed in [RFC7761]. Other unicast destination type message like Register messages, Register-Stop message and Candidate-RP-Advertisement message are supported by PIM light. No other message types are supported for PIM Light and SHOULD NOT be process if received on a PLI.

3.2. Absence of Hello Message consideration

In a PIM Light domain, the following considerations should be taken into account due to the lack of processing Hello messages

3.2.1. Join Attribute

Since a PLI does not process PIM Hello messages, it also does not support the join attributes option in PIM Hello as specified in [RFC5384]. As such, PIM Light is unaware of its neighbor's capability to process join attributes. A PIM Light router that does not recognize the type 1 Encoded-source Address, as per [RFC7761], SHOULD NOT process a join message containing it. Otherwise, the PLI SHOULD process the join attribute accordingly.

3.2.2. DR Election

Due to the absence of Hello messages, DR Election is not supported on a PIM Light router. The network design must ensure DR Election occurs within the PIM domain, assuming the PIM Light domain interconnects PIM domains.

                         BBR                   BBR
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
           |       PIM Adj|         | |         |PIM Adj       |
           |------------( E )-------| |-------( F )------------|
                                          (DR Election)

For instance, in a BIER domain connecting two PIM networks, a PLI can be used between BIER edge routers solely for multicast state communication, transmitting only PIM Join/Prune messages. To prevent multicast stream duplication, PIM routers on either side of the BIER domain should establish PIM adjacency as per [RFC7761] to ensure DR election at the edge of BIER domain, as an example DR election between router D and F in above figure. When the Join or Prune message arrives from a PIM domain to the down stream BIER edge router, it can be send over the BIER tunnel to the upstream BIER edge router only via the designated router.

3.2.3. PIM Assert

In scenarios where multiple PIM routers peer over a shared LAN or a Point-to-Multipoint medium, more than one upstream router may have valid forwarding state for a packet, potentially causing packet duplication. PIM Assert is used to select a single transmitter when such duplication is detected. According to [RFC7761], PIM Assert should only be accepted from a known PIM neighbor.

In PIM Light implementations, care must be taken to avoid duplicate streams arriving from upstream PIM Light routers to a single downstream PIM Light router. If network design constraints prevent this, the implemented network architecture should take measures to avoid traffic duplication. For example, in a PIM Light over a BIER domain scenario, downstream IBBR (Ingress BIER Border Router) in a BIER domain can identify the nearest EBBRs (Egress BIER Border Routers) to the source using SPF with post-processing as described in [draft-ietf-bier-pim-signaling] Appendix A.1. If the downstream IBBR identifies two EBBRs, it can select one using a unique IP selection algorithm, such as choosing the EBBR with the lowest or highest IP address. If the selected EBBR goes offline, the downstream router can use the next EBBR based on the IP selection algorithm, which is beyond the scope of this document.

3.3. PLI Configuration

Since a PLI doesn't require PIM Hello Messages and PIM neighbor adjacency is not checked for arriving Join/Prune messages, there needs to be a mechanism to enable PLI on interfaces. Only when PLI is enabled on an interface, arriving Join/Prune messages should be processed, otherwise they should be dropped. While on some logical interfaces PLI maybe enabled automatically or via an underlying mechanism, as an example the logical interface connecting two or more BIER edge routers in a BIER sub-domain [draft-ietf-bier-pim-signaling].

3.4. Failures in PLR domain

Because the Hello messages are not processed on the PLI, PIM Light Interface failures may not be discovered in a PIM Light domain and multicast routes will not be pruned toward the source on the PIM Light domain, leaving the upstream routers continuously sending multicast streams until the out going interface (OIF) expires.

Other protocols can be used to detect these failures in the PIM Light domain and they can be implementation specific. As an example, the interface that PIM Light is configured on can be protected via BFD or similar technology. If BFD to the far-end PLI goes down, and the PIM Light Router is upstream and has an OIF for a multicast route <S,G>, PIM should remove that PLI from its OIF list.

                         UBER                 DBER
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
                  <--Prune <S,G>          <failure on D>

In another example, if PLI is configured automatically, as an example in BIER case, when the downstream BIER Edge Router (DBER) is no longer reachable, the upstream BIER Edge Router (UBER) which is also a PIM Light Router can prune the <S,G> advertised toward the source on the PIM domain to stop the transmission of the multicast stream.

3.5. Reliable Transport Mechanism for PIM LIGHT

[RFC6559] defines a reliable transport mechanism for PIM transmission of Join/Prune messages, using either TCP or SCTP as transport protocol. For TCP, PIM over reliable transport (PORT) uses port 8471 which is assigned by IANA. SCTP is explained in [RFC9260], and it is used as a second option for PORT. [RFC6559] mentions that when a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. The same is true for SCTP and the router must include PIM-over-SCTP-Capable Hello Option in its Hello messsage on that interface.

These Hello options contain a Connection ID which is an IPv4 or IPv6 address used to establish the SCTP or TCP connection. For PORT using TCP, the connection ID is used for determining which peer is doing a active transport open to the neighbor and which peer is doing passive transport open, as per section 4 of [RFC6559]

When the router is using SCTP, the Connection ID IP address comparison need not be done since the SCTP protocol can handle call collision.

PIM Light lacking Hello messages, the PLI can be configured with the Connection ID IPv4 or IPv6 addresses used to establish the SCTP or TCP connection. For PIM Light using TCP PORT option each end of the PLI must be explicitly and correct configured as being active transport open or passive transport open to ensure handle call collision is avoided.

3.6. PIM Variants not supported

The following PIM variants are not supported with PIM Light and not covered by this document:

  1. Protocol Independent Multicast - Dense Mode (PIM-DM)[RFC3973]

  2. Bidirectional Protocol Independent Multicast (BIDIR-PIM) [RFC5015]

4. IANA Considerations

There are no new IANA considerations for this document.

5. Security Considerations

Since PIM Light does not require PIM Hello messages and does not verify PIM neighbor adjacency for incoming Join/Prune messages, it is crucial for security reasons, that the implementation ensures only Join/Prune messages arriving on a configured PLI are processed. Any Join/Prune messages received on an interface that is not configured as a PLI MUST be discarded and not processed. Additionally, as a secondary line of defense, route policies SHOULD be implemented to process only the Join/Prune messages associated with the desired (S,G) pairs, while all other (S,G) pairs MUST be discarded and not processed.

Furthermore, because PIM Light can be used for signaling Source-Specific and Sparse Mode Join/Prune messages, the security considerations outlined in [RFC7761] and [RFC4607] SHOULD be considered where appropriate.

In section 6.1.1 of [RFC7761], only forged join/prune message should be considered as a potential attack vector, as PIM Light does not process Hello or Assert messages. In addition, as detailed in Section 6.3, the authentication mechanisms described in [RFC5796] can be applied to PIM Light via IPsec Encapsulating Security Payload (ESP) or, optionally, the Authentication Header (AH).

6. Acknowledgments

Would like to thank Sandy <Zhang Zheng> and Tanmoy Kundu for their suggestions and contribution to this document.

7. References

7.1. Normative References

[iana_pim-parameters]
"", , <https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#message-types>.
[RFC2119]
"S. Brandner, "Key words for use in RFCs to Indicate Requirement Levels"", .
[RFC4607]
"H. Holbrook, B. Cain "Source-Specific Multicast for IP"".
[RFC5015]
"M. Handley, I. Kouvelas, T. Speakman, L. Vicisano "Bidirectional Protocol Independent Multicast"".
[RFC5384]
"A. Boers, I. Wijnands, E. Rosen "PIM Join Attribute Format"", .
[RFC5796]
"W. Atwood, S. Islam, M. Siami "Authentication and Confidentiality in PIM-SM"".
[RFC6559]
"D. Farinacci, I. Wijnands, S. Venaas, M. Napierala "A reliable Transport Mechanism for PIM"".
[RFC7761]
"B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z.Zhang "PIM Sparse Mode"", .
[RFC8174]
"B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"", .
[RFC8279]
"Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. Aldrin, "Multicast using Bit Index Explicit Replication"", .
[RFC9260]
"R. Stewart, M. Tuxen, K. Nielsen, "Stream Control Transmission Protocol"", .

7.2. Informative References

[draft-ietf-bier-pim-signaling]
"H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z. Zhang, "PIM Signaling Through BIER Core"", .
[RFC3973]
"A. Adams, J. Nicholas, W. Siadak, "Protocol Independent Multicast - Dense Mode"".

Authors' Addresses

Hooman Bidgoli (editor)
Nokia
March Road
Ottawa Ontario K2K 2T6
Canada
Stig Venaas
Cisco System, Inc.
Tasman Drive
San Jose, California 95134
United States of America
Mankamana Mishra
Cisco System
Tasman Drive
San Jose, California 95134
United States of America
Zhaohui Zhang
Juniper Networks
Boston,
United States of America
Mike McBride
Futurewei Technologies Inc.
Santa Clara,
United States of America