Diff: draft-ietf-pim-light-08.txt - draft-ietf-pim-light-09.txt
 draft-ietf-pim-light-08.txt   draft-ietf-pim-light-09.txt 
Network Working Group H. Bidgoli, Ed. Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track S. Venaas Intended status: Standards Track S. Venaas
Expires: 28 March 2025 Cisco System, Inc. Expires: 23 May 2025 Cisco System, Inc.
M. Mishra M. Mishra
Cisco System Cisco System
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
M. McBride M. McBride
Futurewei Technologies Inc. Futurewei Technologies Inc.
24 September 2024 19 November 2024
PIM Light PIM Light
draft-ietf-pim-light-08 draft-ietf-pim-light-09
Abstract Abstract
This document specifies Protocol Independent Multicast Light (PIM This document specifies Protocol Independent Multicast Light (PIM
Light) and PIM Light Interface (PLI) which does not need PIM Hello Light) and PIM Light Interface (PLI) which does not need PIM Hello
message to accept PIM Join/Prune messages. PLI can signal multicast message to accept PIM Join/Prune messages. PLI can signal multicast
states over networks that can not support full PIM neighbor states over networks that can not support full PIM neighbor
discovery, as an example BIER networks that are connecting two or discovery, as an example BIER networks that are connecting two or
more PIM domains. This document outlines the PIM Light protocol and more PIM domains. This document outlines the PIM Light protocol and
procedures to ensure loop-free multicast traffic between two or more procedures to ensure loop-free multicast traffic between two or more
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2025. This Internet-Draft will expire on 23 May 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.2.3. PIM Assert . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. PIM Assert . . . . . . . . . . . . . . . . . . . . . 5
3.3. PLI Configuration . . . . . . . . . . . . . . . . . . . . 5 3.3. PLI Configuration . . . . . . . . . . . . . . . . . . . . 5
3.4. Failures in PLR domain . . . . . . . . . . . . . . . . . 6 3.4. Failures in PLR domain . . . . . . . . . . . . . . . . . 6
3.5. Reliable Transport Mechanism for PIM LIGHT . . . . . . . 6 3.5. Reliable Transport Mechanism for PIM LIGHT . . . . . . . 6
3.6. PIM Variants not supported . . . . . . . . . . . . . . . 7 3.6. PIM Variants not supported . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document specifies the Protocol Independent Multicast Light (PIM This document specifies the Protocol Independent Multicast Light (PIM
Light) and PIM Light Interface (PLI) procedures. PLI is a new type Light) and PIM Light Interface (PLI) procedures. PLI is a new type
of PIM interface that allows signaling of PIM Join/Prune packets of PIM interface that allows signaling of PIM Join/Prune packets
without full PIM neighbor discovery. PLI is useful in scenarios without full PIM neighbor discovery. PLI is useful in scenarios
where multicast state needs to be signaled over networks or media where multicast state needs to be signaled over networks or media
that cannot support full PIM neighborship between routers or that cannot support full PIM neighborship between routers or
alternatively full PIM neighborship is not desired. Lack of full PIM alternatively full PIM neighborship is not desired. Lack of full PIM
neighborship will remove some PIM functionality as explained further neighborship will remove some PIM functionality as explained in
in this document. PIM Light only supports PIM-SM protocol including section 3.2 of this document. PIM Light only supports Protocol
PIM-SSM as per [RFC7761]. The document details procedures and Independent Multicast Sparse Mode (PIM-SM) protocol including PIM
considerations needed for PIM Light and PLI to ensure efficient Source-Specific Multicast (PIM-SSM) as per [RFC7761]. The document
routing of multicast groups for specific deployment environments. 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 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Definitions 2.1. Definitions
skipping to change at page 3, line 49 skipping to change at page 3, line 49
router. The absence of Hello messages on a PLI means there is no router. The absence of Hello messages on a PLI means there is no
mechanism to discover neighboring PIM routers or their capabilities, mechanism to discover neighboring PIM routers or their capabilities,
nor to execute basic algorithms such as Designated Router (DR) nor to execute basic algorithms such as Designated Router (DR)
election [RFC7761]. Consequently, the PIM Light router does not election [RFC7761]. Consequently, the PIM Light router does not
create any general-purpose state for neighboring PIM routers and only create any general-purpose state for neighboring PIM routers and only
processes Join/Prune messages from downstream routers in its processes Join/Prune messages from downstream routers in its
multicast routing table. Processing these Join/Prune messages will multicast routing table. Processing these Join/Prune messages will
introduce multicast states in a PIM Light router. introduce multicast states in a PIM Light router.
Due to these constraints, a PLI should be deployed in very specific Due to these constraints, a PLI should be deployed in very specific
scenarios. The application using these PLIs MUST ensure there is no scenarios where PIM-SM is not suitable. The application using these
multicast packet duplication, such as multiple upstream routers PLIs MUST ensure there is no multicast packet duplication, such as
sending the same multicast stream to a single downstream router. multiple upstream routers sending the same multicast stream to a
single downstream router.
3.1. PLI supported Messages 3.1. PLI supported Messages
As per IANA [iana_pim-parameters_message-types], PIM supports As per IANA [iana_pim-parameters_message-types], PIM supports
numerous message types. However, PIM Light only supports message numerous message types. However, PIM Light only supports message
type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed in type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed in
[RFC7761]. Unicast destination type messages, like Register [RFC7761]. Unicast destination type messages, like Register
messages, Register-Stop and Candidate-RP-Advertisement, are supported messages, Register-Stop and Candidate-RP-Advertisement, are supported
by PIM Light. No other message types are supported for PIM Light and by PIM Light. No other message types are supported for PIM Light and
SHOULD NOT be process if received on a PLI. SHOULD NOT be process if received on a PLI.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
BBR BBR BBR BBR
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
| PIM Adj| | | |PIM Adj | | PIM Adj| | | |PIM Adj |
|------------( E )-------| |-------( F )------------| |------------( E )-------| |-------( F )------------|
(DR Election) (DR Election)
For instance, in a BIER domain connecting two PIM networks, a PLI can For instance, in a BIER domain connecting two PIM networks, a PLI can
be used between BIER edge routers solely for multicast state be used between BIER edge routers solely for multicast state
communication, transmitting only PIM Join/Prune messages. To prevent communication and transmit only PIM Join/Prune messages. To prevent
multicast stream duplication, PIM routers on either side of the BIER multicast stream duplication, PIM routers on either side of the BIER
domain should establish PIM adjacency as per [RFC7761] to ensure DR domain should establish PIM adjacency as per [RFC7761] to ensure DR
election at the edge of BIER domain, as an example DR election election at the edge of BIER domain. An example DR election could be
between router D and F in above figure. When the Join or Prune DR election between router D and F in above figure. When the Join or
message arrives from a PIM domain to the down stream BIER edge 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, it can be send over the BIER tunnel to the upstream BIER edge
router only via the designated router. router only via the designated router.
3.2.3. PIM Assert 3.2.3. PIM Assert
In scenarios where multiple PIM routers peer over a shared LAN or a In scenarios where multiple PIM routers peer over a shared LAN or a
Point-to-Multipoint medium, more than one upstream router may have Point-to-Multipoint medium, more than one upstream router may have
valid forwarding state for a packet, potentially causing packet valid forwarding state for a packet, potentially causing packet
duplication. PIM Assert is used to select a single transmitter when duplication. PIM Assert is used to select a single transmitter when
such duplication is detected. According to [RFC7761], PIM Assert such duplication is detected. According to [RFC7761], PIM Assert
should only be accepted from a known PIM neighbor. should only be accepted from a known PIM neighbor.
In PIM Light implementations, care must be taken to avoid duplicate In PIM Light implementations, care must be taken to avoid duplicate
streams arriving from upstream PIM Light routers to a single streams arriving from upstream PIM Light routers to a single
downstream PIM Light router. If network design constraints prevent downstream PIM Light router. If network design constraints prevent
this, the implemented network architecture should take measures to this, the implemented network architecture should take measures to
avoid traffic duplication. For example, in a PIM Light over a BIER avoid traffic duplication. For example, in a PIM Light over a BIER
domain scenario, downstream IBBR (Ingress BIER Border Router) in a domain scenario, downstream IBBR (Ingress BIER Border Router) in a
BIER domain can identify the nearest EBBRs (Egress BIER Border BIER domain can identify the nearest EBBRs (Egress BIER Border
Routers) to the source using SPF with post-processing as described in 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. If the downstream IBBR [draft-ietf-bier-pim-signaling] Appendix A.1. If the downstream IBBR
identifies two EBBRs, it can select one using a unique IP selection identifies two EBBRs, it can select one using a unique IP selection
algorithm, such as choosing the EBBR with the lowest or highest IP algorithm, such as choosing the EBBR with the lowest or highest IP
address. If the selected EBBR goes offline, the downstream router address. If the selected EBBR goes offline, the downstream router
can use the next EBBR based on the IP selection algorithm, which is can use the next EBBR based on the IP selection algorithm, which is
beyond the scope of this document. beyond the scope of this document.
3.3. PLI Configuration 3.3. PLI Configuration
Since a PLI doesn't require PIM Hello Messages and PIM neighbor Since a PLI doesn't require PIM Hello Messages and PIM neighbor
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3.4. Failures in PLR domain 3.4. Failures in PLR domain
Because the Hello messages are not processed on the PLI, PIM Light Because the Hello messages are not processed on the PLI, PIM Light
Interface failures may not be discovered in a PIM Light domain and Interface failures may not be discovered in a PIM Light domain and
multicast routes will not be pruned toward the source on the PIM multicast routes will not be pruned toward the source on the PIM
Light domain, leaving the upstream routers continuously sending Light domain, leaving the upstream routers continuously sending
multicast streams until the out going interface (OIF) expires. multicast streams until the out going interface (OIF) expires.
Other protocols can be used to detect these failures in the PIM Light Other protocols can be used to detect these failures in the PIM Light
domain and they can be implementation specific. As an example, the domain and they can be implementation specific. As an example, the
interface that PIM Light is configured on can be protected via BFD or interface that PIM Light is configured on can be protected via
similar technology. If BFD to the far-end PLI goes down, and the PIM Bidirectional Forwarding Detection (BFD) or similar technology. If
Light Router is upstream and has an OIF for a multicast route <S,G>, BFD to the far-end PLI goes down, and the PIM Light Router is
PIM should remove that PLI from its OIF list. upstream and has an OIF for a multicast route <S,G>, PIM should
remove that PLI from its OIF list.
UBER DBER UBER DBER
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
<--Prune <S,G> <failure on D> <--Prune <S,G> <failure on D>
In another example, if PLI is configured automatically, as an example In another example, where the PLI is configured automatically between
in BIER case, when the downstream BIER Edge Router (DBER) is no the BIER Edge Routers (BER), when the downstream BIER Edge Router
longer reachable, the upstream BIER Edge Router (UBER) which is also (DBER) is no longer reachable on the upstream BIER Edge Router
a PIM Light Router can prune the <S,G> advertised toward the source (UBER), the UBER which is also a PIM Light Router can prune the <S,G>
on the PIM domain to stop the transmission of the multicast stream. advertised toward the source on the PIM domain to stop the
transmission of the multicast stream.
3.5. Reliable Transport Mechanism for PIM LIGHT 3.5. Reliable Transport Mechanism for PIM LIGHT
[RFC6559] defines a reliable transport mechanism for PIM transmission [RFC6559] defines a reliable transport mechanism for PIM transmission
of Join/Prune messages, using either TCP or SCTP as transport of Join/Prune messages, using either TCP or SCTP as transport
protocol. For TCP, PIM over reliable transport (PORT) uses port 8471 protocol. For TCP, PIM over reliable transport (PORT) uses port 8471
which is assigned by IANA. SCTP is explained in [RFC9260], and it is 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 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 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 MUST include the PIM-over-TCP-Capable Hello Option in its Hello
skipping to change at page 6, line 49 skipping to change at page 7, line 4
MUST include the PIM-over-TCP-Capable Hello Option in its Hello MUST include the PIM-over-TCP-Capable Hello Option in its Hello
messages for that interface. The same is true for SCTP and the messages for that interface. The same is true for SCTP and the
router must include PIM-over-SCTP-Capable Hello Option in its Hello router must include PIM-over-SCTP-Capable Hello Option in its Hello
messsage on that interface. messsage on that interface.
These Hello options contain a Connection ID which is an IPv4 or IPv6 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 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 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 active transport open to the neighbor and which peer is doing passive
transport open, as per section 4 of [RFC6559] transport open, as per section 4 of [RFC6559]
When the router is using SCTP, the Connection ID IP address When the router is using SCTP, the Connection ID IP address
comparison need not be done since the SCTP protocol can handle call comparison need not be done since the SCTP protocol can handle call
collision. collision.
PIM Light lacking Hello messages, the PLI can be configured with the PIM Light lacks Hello messages, the PLI can be configured with the
Connection ID IPv4 or IPv6 addresses used to establish the SCTP or 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 TCP connection. For PIM Light using TCP PORT option each end of the
PLI must be explicitly and correct configured as being active PLI must be explicitly and correct configured as being active
transport open or passive transport open to ensure handle call transport open or passive transport open to ensure handle call
collision is avoided. collision is avoided.
3.6. PIM Variants not supported 3.6. PIM Variants not supported
The following PIM variants are not supported with PIM Light and not The following PIM variants are not supported with PIM Light and not
covered by this document: covered by this document:
 End of changes. 14 change blocks. 
29 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/