Network Working Group
Internet Engineering Task Force (IETF) H. Bidgoli, Ed.
Internet-Draft
Request for Comments: 9739 Nokia
Intended status:
Category: Standards Track S. Venaas
Expires: 8 June 2025 Cisco System, Inc.
ISSN: 2070-1721 M. Mishra
Cisco System Systems, Inc.
Z. Zhang
Juniper Networks
M. McBride
Futurewei Technologies Inc.
5 December 2024
February 2025
Protocol Independent Multicast Light (PIM Light)
draft-ietf-pim-light-11
Abstract
This document specifies Protocol Independent Multicast Light (PIM
Light) and the PIM Light Interface (PLI) which (PLI). A PLI does not need a PIM
Hello message to accept PIM Join/Prune messages. PLI messages, and it can signal
multicast states over networks that can not cannot support full PIM neighbor
discovery, such as an example BIER Bit Index Explicit Replication (BIER) networks
that are connecting connect 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 an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 8 June 2025.
https://www.rfc-editor.org/info/rfc9739.
Copyright Notice
Copyright (c) 2024 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 Terminology
3. PIM Light Interface . . . . . . . . . . . . . . . . . . . . . 3
3.1. PLI supported Messages . . . . . . . . . . . . . . . . . 4 Message Types Supported by PIM Light
3.2. Considerations for the Absence of Hello Message consideration . . . . . . . . . 4
3.2.1. Join Attribute . . . . . . . . . . . . . . . . . . . 4
3.2.2. DR Election . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. PIM Assert . . . . . . . . . . . . . . . . . . . . . 5
3.3. PLI Configuration . . . . . . . . . . . . . . . . . . . . 6
3.4. Failures in PLR domain . . . . . . . . . . . . . . . . . 6 Domain
3.5. Reliable Transport Mechanism for PIM LIGHT . . . . . . . 7 Light
3.6. PIM Variants not supported . . . . . . . . . . . . . . . 7 Not Supported
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1.
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2.
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document specifies the procedures for Protocol Independent Multicast
Light (PIM Light) and the PIM Light Interface (PLI) procedures. (PLI). The PLI is a
new type of PIM interface that allows signaling of PIM Join/Prune
packets without full PIM neighbor discovery. A PLI is useful in
scenarios where multicast states needs need to be signalled signaled over networks or
media that cannot support full PIM neighborship between routers or
alternatively or,
alternatively, where full PIM neighborship is not desired. These type
types of networks or medias and media are addressed as a PIM called "PIM Light Domain domains" within
this document. Lack of full PIM neighborship will remove some PIM
functionality as explained in section Section 3.2 of this document. PIM
Light only supports Protocol Independent Multicast the PIM - Sparse Mode (PIM-
SM) protocol (PIM-SM) protocol,
including PIM Source-Specific Multicast (PIM-SSM) (PIM-SSM), as per [RFC7761]. The
This document details procedures and considerations needed for PIM
Light and the PLI to ensure efficient routing of multicast groups for
specific deployment environments.
2. Conventions used in this document Terminology
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 terminology from "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification [RFC7761] (Revised)" [RFC7761].
3. PIM Light Interface
RFC [RFC7761] section
Section 4.3.1 of [RFC7761] describes the PIM neighbor discovery via Hello
messages. In section Section 4.5 it describes of [RFC7761] notes 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 Join/
Prune message SHOULD be discarded without further processing.
In certain scenarios, it is desirable to establish multicast states
between two layer-3 adjacent Layer 3 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 that does not necessitate
PIM
Neighbor neighbor establishment. For example, in a Bit Index Explicit
Replication (BIER) [RFC8279] networks network connecting multiple PIM domains,
where PIM Join/Prune messages are tunneled via BIER as specified in [draft-ietf-bier-pim-signaling].
[BIER-PIM].
A PIM Light Interface (PLI) 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 capabilities or 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 where PIM-SM is not suitable. The applications or the
networks that on which PLIs are deployed on MUST ensure that there is no
multicast packet duplication, such as multiple upstream routers
sending the same multicast stream to a single downstream router. As For
example, an example
the implementation should ensure that DR election is done on
upstream
Redundant redundant PIM routers that are at the edge of the PIM Light Domain
domain to ensure a single Designated Router DR to forward the PIM Join message from
reviver to the Source. source.
3.1. PLI supported Messages
IANA [iana_pim-parameters_message-types], Message Types Supported by PIM Light
The "PIM Message Types" registry [IANA-PIM-Mess-Types] lists the PIM supported
message types. types supported by PIM. PIM Light only supports the
following message types
from the table "PIM Message Types"
1. in that registry:
* type 1 (Register)
* type 2 (Register Stop)
* type 3 (Join/Prune) (Note that this type is from the ALL-PIM-ROUTERS ALL-PIM-
ROUTERS message types listed in [RFC7761].
2. type 1 (Register)
3. type 2 (Register Stop)
4. [RFC7761].)
* type 8 (Candidate RP Advertisement)
5.
* type 13 (PIM Packed Null-Register)
6.
* type 13.1 (PIM Packed Register-Stop)
7.
* Any future PIM message types that use unicast destination IP. IP
No other message types are supported for by PIM Light and Light; other message
types MUST NOT be
process processed if received on a PLI.
3.2. Considerations for the Absence of Hello Message consideration
In
Because Hello messages are not processed in a PIM Light domain, the following
considerations in the subsections below should be taken into account due to the lack of processing Hello messages. account.
3.2.1. Join Attribute
Since a PLI does not process PIM Hello messages, it also does not
support the join attributes attribute option in PIM Hello as specified in
[RFC5384]. As such, PIM Light is unaware of its neighbor's
capability to process join attributes attributes, and it SHOULD NOT process a
join
Join message containing it.
For
There are two cases in which a PLI to can send and process a join attributes there can be two
cases:
1. It
attribute:
* The join attribute must be configured with an appropriate join
attribute type that the PLI is capable of processing as per
[iana_pim-parameters_join-attribute-types] table.
2. Separate IETF drafts or the
"PIM Join Attribute Types" registry [IANA-PIM-Attr-Types].
* Internet-Drafts and RFCs may dictate that certain join attributes
are allowed to be used without explicit configuration of the PLI
in certain scenarios. The details are left to those
drafts or Internet-
Drafts and RFCs.
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.
Bier edge router Bier edge router (BER)
|--PIM Domain--|--BIER domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host )--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 and transmit only PIM Join/Prune messages. If there
are redundant PIM routers at the edge of the BIER domain, to prevent
multicast stream duplication, they MUST establish PIM adjacency as
per [RFC7761] to ensure DR election at the edge of BIER domain. An
example DR election could be DR election between router D and F in
above figure.
the figure above. When the Join or Prune message arrives from a PIM
domain to the down stream downstream BIER edge router, it can be forwarded over
the BIER tunnel to the upstream BIER edge router only via the
designated router. DR.
3.2.3. PIM Assert
In scenarios where multiple PIM routers peer over a shared LAN or a
Point-to-Multipoint
point-to-multipoint medium, more than one upstream router may have
valid forwarding state for a packet, which can potentially causing cause
packet duplication. PIM Assert is used to select a single
transmitter when such duplication is detected. According to [RFC7761] section 4.6,
Section 4.6 of [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 multiple upstream PIM Light routers to a single
downstream PIM Light router. If network design constraints prevent
this, the implemented network architecture must take measures to
avoid traffic duplication. For example, in a scenario with PIM Light
over a BIER
domain scenario, domain, a downstream IBBR (Ingress BIER Border Router) in
a BIER domain can identify the nearest EBBRs (Egress BIER Border
Routers) to the source using the Shortest Path First (SPF) algorithm
with a post-processing as described in
[draft-ietf-bier-pim-signaling] Appendix A.1. A.1 of [BIER-PIM]. 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 PLIs on interfaces. If a router
supports PIM Light, arriving Join/Prune messages MUST be processed
only when a PLI is enabled on an interface,
arriving Join/Prune messages MUST be processed, otherwise interface; otherwise, they MUST be
dropped. While on some logical interfaces A PLI maybe may be enabled automatically or via an underlying mechanism, as an example
mechanism on some logical interfaces (for example, the logical
interface connecting two or more BIER edge routers in a BIER
subdomain [draft-ietf-bier-pim-signaling]. [BIER-PIM]).
3.4. Failures in PLR domain Domain
Because the Hello messages are not processed on the PLI, PIM Light
Interface PLI failures may
not be discovered in a PIM Light domain domain, and multicast routes will
not be pruned toward the source on the PIM Light domain, leaving domain. This
results in the upstream routers continuously sending multicast
streams until the outgoing interface (OIF) expires.
Other protocols can be used to detect these failures in the PIM Light
domain
domain, and they can be implementation specific. As an example, the
interface that on which PIM Light is configured on can be protected via
Bidirectional Forwarding Detection (BFD) or similar technology. If
BFD to the far-end PLI goes down, down and the PIM Light Router router is upstream
and has an OIF for a multicast route <S,G>, PIM must remove that PLI
from its OIF list.
UBER DBER
|--PIM Domain--|--BIER domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host )--Host
<--Prune <S,G> <failure on D>
In another example, where the PLI is configured automatically between the
BIER Edge Routers (BER), when (BERs). When the downstream Downstream BIER Edge Router
(DBER) is no longer reachable on the upstream Upstream BIER Edge Router
(UBER), the UBER which (which is also a PIM Light Router 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 Light
[RFC6559] defines a reliable transport mechanism for PIM transmission
of Join/Prune messages, using either TCP or SCTP as the transport
protocol. For TCP, PIM over reliable transport Over Reliable Transport (PORT) uses port 8471
8471, which is was assigned by IANA. SCTP is explained in [RFC9260], [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 SCTP; the router
must include the PIM-over-SCTP-Capable Hello Option in its Hello
messsage
message on that interface.
These Hello options contain a Connection ID ID, which is an IPv4 or IPv6
address used to establish the SCTP or TCP connection. For PORT using
TCP, the connection Connection ID is used for determining to determine which peer is doing an
active transport open to the neighbor and which peer is doing passive
transport open, as per section Section 4 of [RFC6559] [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.
Because PIM Light lacks 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 the TCP PORT option option,
each end of the PLI must be explicitly and correct correctly configured as
being either active transport open or passive transport open to
ensure handle that call collision is avoided.
3.6. PIM Variants not supported Not Supported
The following PIM variants are not supported with PIM Light and not
covered by this document:
1. Protocol Independent Multicast
* PIM - Dense Mode (PIM-DM)[RFC3973]
2. (PIM-DM) [RFC3973]
* Bidirectional Protocol Independent Multicast PIM (BIDIR-PIM) [RFC5015]
4. IANA Considerations
There are
This document has no new IANA considerations for this document. actions.
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, it is crucial that implementations ensure that the implementation ensures only
Join/Prune messages arriving at 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
Per Section 6.1.1 of [RFC7761], only forged join/prune message Join/Prune messages
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, 6.3 of [RFC7761], the authentication mechanisms described in
[RFC5796] can be applied to PIM Light via IPsec Encapsulating
Security Payload (ESP) or, optionally, the Authentication Header
(AH).
7.
6. References
7.1.
6.1. Normative References
[iana_pim-parameters_join-attribute-types]
"", January 2022, <https://www.iana.org/assignments/pim-
parameters/pim-parameters.xhtml#pim-parameters-2>.
[iana_pim-parameters_message-types]
"", January 2022, <https://www.iana.org/assignments/pim-
parameters/pim-parameters.xhtml#message-types>.
[IANA-PIM-Attr-Types]
IANA, "PIM Join Attribute Types",
<https://www.iana.org/assignments/pim-parameters>.
[IANA-PIM-Mess-Types]
IANA, "PIM Message Types",
<https://www.iana.org/assignments/pim-parameters>.
[RFC2119] "S. Brandner, Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels"", Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4607] "H. Holbrook, H. and B. Cain Cain, "Source-Specific Multicast for IP"".
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC5015] "M. Handley, I. M., Kouvelas, T. I., Speakman, T., and L. Vicisano Vicisano,
"Bidirectional Protocol Independent Multicast"". Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC5384] "A. Boers, I. A., Wijnands, I., and E. Rosen "PIM Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute
Format"", March 2016. Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>.
[RFC5796] "W. Atwood, S. W., Islam, S., and M. Siami Siami, "Authentication and
Confidentiality in PIM-SM"". Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796,
DOI 10.17487/RFC5796, March 2010,
<https://www.rfc-editor.org/info/rfc5796>.
[RFC6559] "D. Farinacci, I. D., Wijnands, S. IJ., Venaas, S., and M. Napierala
Napierala, "A
reliable Reliable Transport Mechanism for PIM"". PIM",
RFC 6559, DOI 10.17487/RFC6559, March 2012,
<https://www.rfc-editor.org/info/rfc6559>.
[RFC7761] "B.Fenner, M.Handley, H. Fenner, B., Handley, M., Holbrook, I. H., Kouvelas, R. I.,
Parekh,
Z.Zhang "PIM R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode"", Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016.
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8174] "B. Leiba, "ambiguity B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words"", Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] "Wijnands, Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T. T., and S. Aldrin, "Multicast using Using Bit Index
Explicit
Replication"", October 2016. Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC9260] "R. Stewart, M. Tuxen, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol"", Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022.
7.2. 2022, <https://www.rfc-editor.org/info/rfc9260>.
6.2. Informative References
[draft-ietf-bier-pim-signaling]
"H.Bidgoli, F.XU, J.
[BIER-PIM] Bidgoli, H., Ed., Xu, F., Kotalwar, I. J., Wijnands, M.Mishra, I.,
Mishra, M., and Z. Zhang, "PIM Signaling Through BIER Core"",
Core", Work in Progress, Internet-Draft, draft-ietf-bier-
pim-signaling-12, 25 July 2021. 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
pim-signaling-12>.
[RFC3973] "A. Adams, J. A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode"".
6. Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
Acknowledgments
Would
The authors would like to thank Sandy <Zhang Zheng> Zheng (Sandy) Zhang and Tanmoy Kundu
for their suggestions and contribution contributions to this document.
Authors' Addresses
Hooman Bidgoli (editor)
Nokia
March Road
Ottawa Ontario K2K 2T6
Canada
Email: hooman.bidgoli@nokia.com
Stig Venaas
Cisco System, Systems, Inc.
Tasman Drive
San Jose, California CA 95134
United States of America
Email: stig@cisco.com
Mankamana Mishra
Cisco System Systems, Inc.
Tasman Drive
San Jose, California CA 95134
United States of America
Email: mankamis@cisco.com
Zhaohui Zhang
Juniper Networks
Boston, MA
United States of America
Email: zzhang@juniper.com
Mike McBride
Futurewei Technologies Inc.
Santa Clara, CA
United States of America
Email: michael.mcbride@futurewei.com