Internet DRAFT - draft-li-pce-multicast
draft-li-pce-multicast
pce H. Li
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: 24 March 2023 Z. Zhang
Juniper Networks
H. Chen
Futurewei
R. Chen
ZTE Corporation
20 September 2022
Multicast Tree Setup via PCEP
draft-li-pce-multicast-02
Abstract
Multicast forwarding requires per-tree state on certain nodes. Even
with BIER, per-tree state is needed on ingress/egress BIER routers
(though not needed on transit BIER routers). This documents
specifies PCEP protocol to collect tree information (e.g. root, leaf,
constraints) to allow a PCE to calculate a tree, and the procedures
to set up per-tree forwarding state on relevant nodes for various
multicast trees and various replication technologies.
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 24 March 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 24 March 2023 [Page 1]
Internet-Draft Multicast Tree Setup via PCEP September 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Different Multicast Trees . . . . . . . . . . . . . . . . 4
2.1.1. IP Multicast . . . . . . . . . . . . . . . . . . . . 4
2.1.2. mLDP/RSVP-TE P2MP Tunnels . . . . . . . . . . . . . . 4
2.1.3. SR-P2MP Tunnels . . . . . . . . . . . . . . . . . . . 5
2.2. Different Replication Technologies . . . . . . . . . . . 5
2.3. Tree Information Discovery . . . . . . . . . . . . . . . 6
2.3.1. Root node Discovery . . . . . . . . . . . . . . . . . 6
2.3.2. Leaf node Discovery . . . . . . . . . . . . . . . . . 7
2.4. Multicast Tree . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 8
2.4.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Multicast Statistics . . . . . . . . . . . . . . . . . . 8
3. PCEP Object Formats . . . . . . . . . . . . . . . . . . . . . 9
3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . 9
3.1.2. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10
3.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Source Registration Object . . . . . . . . . . 10
3.3.1. Multicast Address TLV . . . . . . . . . . . . . . . . 11
3.3.2. mLDP FEC TLV . . . . . . . . . . . . . . . . . . . . 12
3.3.3. VPN Information TLV . . . . . . . . . . . . . . . . . 12
3.4. Multicast Receiver Information Object . . . . . . . . . . 12
3.4.1. BFR Information TLV . . . . . . . . . . . . . . . . . 13
3.5. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.1. Tree Label TLV . . . . . . . . . . . . . . . . . . . 14
3.5.2. VPN Forwarding Identifier TLV . . . . . . . . . . . . 14
3.6. Tree Forwarding State Synchronization Object . . . . . . 15
3.6.1. BIER Attribute TLV . . . . . . . . . . . . . . . . . 15
3.7. Multicast Receiver Statistics Object . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. PCRpt message . . . . . . . . . . . . . . . . . . . . . . 16
4.2. PCInitiate message . . . . . . . . . . . . . . . . . . . 17
4.3. PCUpd message . . . . . . . . . . . . . . . . . . . . . . 17
5. Example Workflow . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Multicast Tree Discovery . . . . . . . . . . . . . . . . 18
Li, et al. Expires 24 March 2023 [Page 2]
Internet-Draft Multicast Tree Setup via PCEP September 2022
5.2. Multicast Tree Path Establishment and Update . . . . . . 18
5.2.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 18
5.2.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Multicast Statistics Synchronization . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. MULTICAST-STATE-CAPABILITY . . . . . . . . . . . . . . . 21
7.2. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 21
7.3. New Objects . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Currently, during the establishment of multicast services, multicast
management information is mainly signaled by PIM [RFC2362], mLDP
[RFC6388] or BGP [RFC6514]. The trees/tunnels are set up using the
"receiver-initiated join" technique of PIM/mLDP, hop by hop from
downstream routers towards the root. The BGP messages are either
sent hop by hop between downstream routers and their upstream
neighbors, or can be reflected by Route Reflectors (RRs). The
control signaling interaction of multicast information is between
routers and cannot be managed in a unified manner.
As an alternative to each hop independently determining its upstream
router and signaling upstream towards the root (following PIM/mLDP
model), the entire tree can be calculated by a centralized
controller, and the signaling can be entirely done from the
controller.
[RFC4655] defines a stateful PCE to be one in which the PCE maintains
"strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network."
[RFC8231] specifies a set of extensions to PCEP to support state
synchronization between PCCs and PCEs.
The controller can serve as a PCE to centrally manage multicast trees
and establish states on all tree nodes serving as PCC. This document
defines PCEP objects and TLVs to accomplish the multicast source
registration/revocation, receiver discovery, multicast tree state
update etc. functions.
Li, et al. Expires 24 March 2023 [Page 3]
Internet-Draft Multicast Tree Setup via PCEP September 2022
2. Overview
2.1. Different Multicast Trees
This section discusses various multicast trees like IP, mLDP, SR-P2MP
- each with its own tree identification.
2.1.1. IP Multicast
As stated in [RFC1112], an IP multicast packet's destination address
is a Multicast Group Address and it follows either a source specific
tree rooted at the First Hop Router (FHR) or a shared tree rooted at
a Rendezvous Point (RP) [RFC7761]. Each tree is identified by a
(source address, group address) pair, where the source address MAY be
a wildcard in case of the shared tree. This identification, which is
often referred to as (s, g) or (*, g), is used in both forwarding
plane as well as in control plane that sets up the tree, e.g., using
Protocol Independ Multicast (PIM) [RFC7761] [RFC5015].
Each node on the tree needs to have corresponding forwarding plane
state used to forward corresponding traffic and control plane state
that is used to set up a tree. Depending on the number of (s, g)
and/or (*, g) trees that a routing domain need to support, serious
scaling/convergence problems MAY result.
2.1.2. mLDP/RSVP-TE P2MP Tunnels
Quite often, some different multicast trees are used for similar
purposes and the tree structure are identical or very similar. For
example, in an IPTV application, many channels MAY need to be sent
from the same headend router to the same set of edge routers close to
receivers.
In that case, a set of IP multicast trees can be transported over a
fewer set of MPLS P2MP tunnels - either mLDP [RFC6388] or RSVP-TE
P2MP [RFC4875] tunnels - across an MPLS domain. Inside the MPLS
domain, there is no IP multicast tree state but only fewer state for
the P2MP tunnels. Outside the MPLS domain, those IP multicast trees
still have their per-tree state on each tree node.
An mLDP tree is identified by an mLDP FEC in the control plane. In
the context of PCEP signaling, part of or an entire mLDP tunnel can
be set up using PCEP from a PCE instead of using hop-by-hop mLDP
signaling. In this case the only relevance to mLDP is that mLDP FEC
is used to identify the tunnel.
Li, et al. Expires 24 March 2023 [Page 4]
Internet-Draft Multicast Tree Setup via PCEP September 2022
A RSVP-TE P2MP tree is identified by a RSVP Session object in the
control plane. While in theory it can also be set up via PCEP
signaling from a PCE, it is outside the scope of this document.
In the forwarding plane, there is no difference between an mLDP
tunnel and a RSVP-TE P2MP tunnel. A tree is identified by a label -
incoming labeled traffic is replicated to a bunch of downstream nodes
with a label that identifies the tree to the downstream nodes.
2.1.3. SR-P2MP Tunnels
Segment Routing (SR) [RFC8402] has two principles:
1. No per-flow/tunnel state inside an SR domain
2. Optional but perferred use of controllers
When it comes to multicast, the only technologies that sticks to
principle #1 is BIER [RFC8279], which does not use per-tree state for
forwarding.
SR-P2MP [I-D.ietf-pim-sr-p2mp-policy]
[I-D.ietf-spring-sr-replication-segment] sticks to principle #2 only,
in that PCEs are used to calculate a multicast tree subject to
constraints and then direct signaling from PCEs are used to set up
the tree instead of using mLDP/RSVP signaling, but per-tree state is
still used.
In the control plane, an SR-P2MP is identified by a (root-id, tree-
id) tuple. In an SR-MPLS forwarding plane, an SR-P2MP tunnel is not
different from mLDP/RSVP-TE P2MP tunnel at all, though the tree-
identifying label is called a tree sid.
In an SRv6 forwarding plane, the tree sid is embedded as part of an
IPv6 address.
2.2. Different Replication Technologies
For any kind of multicast trees mentioned above, on a particular tree
node A, an incoming packet needs to replicated to a set of downstream
nodes B/C/D/E. Note that the upstream and downstream nodes MAY be
directly connected or they can be reached via a set of P2P/MP2P
tunnels, P2MP tunnels, or via BIER. In the latter case, intermediate
nodes do not maintain the per-tree state but they do need to maintain
state for the transporting tunnels or BIER.
Li, et al. Expires 24 March 2023 [Page 5]
Internet-Draft Multicast Tree Setup via PCEP September 2022
Now on node A/B/C/D/E, per-tree replication state needs to be set up.
In particular on A, depending on the method used to replicate to
B/C/D/E, (a combination of) the following replication branches are
needed:
* A set of outgoing interfaces for native IP forwarding to directly
connected nodes from the B/C/D/E set in case of IP multicast tree,
and/or,
* A set of P2P/MP2P/P2MP tunnels to reach indirectly connected nodes
from the B/C/D/E set, and/or,
* A BIER bitstring and relevant BIER information to reach some nodes
from the B/C/D/E set
In the latter two cases, the replication branches also need relevant
information to identify to B/C/D/E which tree a packet is for (e.g.,
a label for an mLDP or SR-P2MP tree).
2.3. Tree Information Discovery
When a PCE calculates a multicast tree, it needs to collect the tree
information like root, leaves and calculation constraints. This MAY
be provided to the PCE via a southbound (wrt the PCE) interface from
an orchestrator or via northbound PCEP signaling from some PCC nodes
(e.g. the root and leaf nodes of the tree). The PCE MAY also
participate overlay signaling protocols to collect the information
(e.g., [I-D.zzhang-mvpn-evpn-controller]).
This document only covers the northbound PCEP signaling. The two
other methods mentioned above are out of scope of this document.
Whether it is an IP Multicast or mLDP/SR-P2MP Tree, the root, leaves
and calculation constraints are encoded the same way but associated
with different tree identifications in the PCEP signaling.
Specifically, the root and leaves are encoded as IP addresses.
The leaf information can be encoded as a full set of leaves or as
addition/removal delta.
2.3.1. Root node Discovery
When a multicast source accesses to a First Hop Router (FHR), the FHR
originates a PCRpt message carrying the Multicast Source Registration
(MSR) object defined in Section 3.3, which provides FHR information.
FHR, as PCC, delegate the controller as PCE to calculate multicast
tree. In the sent PCRpt message, the D bit of LSP Object is set to
1.
Li, et al. Expires 24 March 2023 [Page 6]
Internet-Draft Multicast Tree Setup via PCEP September 2022
2.3.2. Leaf node Discovery
For IP multicast, Last Hop Router (LHR) MAY convert the multicast
source and group address carried in the IGMP Join/Leave messages sent
by local hosts and VPN information corresponding to local hosts into
PCRpt messages and report these information to the controller.
Similar to IGMP messages, PIM messages from other domains can also be
used as receiver information and be converted into PCRpt messages to
be reported to the controller.
For mLDP and SR-P2MP multicast, The corresponding tree identifiers
can also be carried in PCRpt messages and reported to the controller.
When the first receiver accesses a Last Hop Router (LHR) to join a
multicast tree, or when the last receiver leaves the LHR, the LHR
originates a PCRpt message carrying the Multicast Receiver
Information (MRI) object defined in Section 3.4, which provides LHR
information.
If the receivers locate in different VPN domains, the VPN information
associated with the multicast source and multicast destination should
also be reported by the LHR and FHR. The VPN information reported by
LHRs SHOULD be consistent.
2.4. Multicast Tree
The multicast trees are established with the FHRs of the multicast
source as the root of the multicast trees. According to different
multicast technologies, the types of multicast trees include labeled
tree and BIER tree. Different multicast trees correspond to
different processing. This section describes the state update of
different multicast operations.
No matter which forwarding technology is used, there is a case that
local multicast receivers directly access to FHRs. In this case,
FHRs need to forward multicast data for local receivers in the way of
native IP without other control information.
In some scenarios, the egresses node needs a VPN forwarding
identifier to determine which VRF to forward the packet to. The
allocation of VPN forwarding identifier is performed by controller.
The scenario of egress assigning VPN tags has not been considered
yet. Controller sends the VPN forwarding identifier to ingress and
instructs ingress to encapsulate it. The VPN Forwarding Label may be
MPLS label or SRv6 segment.
Li, et al. Expires 24 March 2023 [Page 7]
Internet-Draft Multicast Tree Setup via PCEP September 2022
2.4.1. Labeled Tree
For a Labeled multicast tree, whether the forwarding is based on
native IP, mLDP or SR-P2MP tunnel, each node needs a tree label to
identify a multicast tree. There are three options for tree label
assignment:
* From each router's SRLB that the controller learns
* From the common SRGB that the controller learns
* From the controller's local label space
The detailed instruction is as per
[I-D.ietf-bess-bgp-multicast-controller]. Section 3.5.1 defines two
new TLVs to extend the CCI Object-Type support the tree label and VPN
Label.
The operations for initiating multicast tree LSPs and
downloadinglabels are consistent with [I-D.ietf-pce-sr-p2mp-policy].
2.4.2. BIER Tree
Different from other forwarding technologies, BIER does not need the
transit nodes to maintain the multicast state, and only needs to
forward and encapsulate the packets according to the BitString and
BIFT. BIFT information can be learned by IGP. For each node of a
sub-domain, the BIFT can be configured locally or allocated by BGP
controller or PCE. Allocation by PCE is as per
[I-D.chen-pce-pcep-extension-pce-controller-bier].
After receiving the BFR information reported from LHRs, the
controller combine BFR information of LHRs into a BitString to guide
multicast data forwarding.
The controller (PCE) sends the BitString to the FHR via PCInitiate or
PCUpd message carrying Tree Forwarding State Synchronization (TFSS)
object defined in Section 3.6 to inform the FHR to forward multicast
data for a specific multicast tree according to the BitString, and
the tree identifier is (*, g) or (s, g) tuple. Controller also needs
to inform FHR to encapsulate VPN forwarding identifier so that LHRs
can forward multicast data to specific VRF accordingly.
2.5. Multicast Statistics
Multicast statistics are helpful for multicast service analysis and
business development. This section describes how to collect
statistics about multicast users.
Li, et al. Expires 24 March 2023 [Page 8]
Internet-Draft Multicast Tree Setup via PCEP September 2022
For each LHR, the statistics consist of two parts, one is the number
of local users in the its managed domain, and the other is the number
of other managed domains. The sum of these two parts is the number
of multicast data that the one LHR needs to duplicate.
LHRs send this information to the controller via PCRpt message
carrying Multicast Receiver Statistics (MRS) object. LHRs need
report this information to the controller periodically. Once the
statistics information of a LHR change, the LHR also needs reports to
the controller.
Controller collects the statistics reported by LHRs and MAY
periodically informs the FHR of the statistics via PCRpt messages
carrying MRS object so that the FHR can feed the statistics back to
the multicast source.
3. PCEP Object Formats
3.1. OPEN Object
3.1.1. STATEFUL-PCE-CAPABILITY TLV
During the PCEP initialization phase, PCEP speakers advertise
stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN
object. Various flags are defined for the STATEFUL-PCE-CAPABILITY
TLV defined in [RFC8231] and updated in [RFC8232] and [RFC8281].
A new flag is added in this document, whose code point is TBD1:
MULTICAST-STATE-CAPABILITY bit, if this bit is set to 1 by a PCEP
speaker, it indicates that the PCEP speaker supports the capability
of these new extensions as specified in this document.
To support the multicast tree state management capabilities described
in this document, both PCE and PCC need to set MULTICAST-STATE-
CAPABILITY bit. If a PCEP speaker receivers PECP message with the
newly defined object, but without the MULTICAST-STATE-CAPABILITY bit
set in STATEFUL-PCE-CAPABILITY TLV in the OPEN object, it MUST:
* Send a PCErr message with Error-Type=10(Reception of an invalid
object) and Error-Value TBD2(MULTICAST-STATE-CAPABILITY bit is not
set).
* Terminate the PCEP session.
Li, et al. Expires 24 March 2023 [Page 9]
Internet-Draft Multicast Tree Setup via PCEP September 2022
3.1.2. PCECC Capability sub-TLV
The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN
Object for PCECC capability advertisement in PATH-SETUP-TYPE-
CAPABILITY TLV as specified in [RFC9050].
[I-D.dhody-pce-pcep-extension-pce-controller-p2mp] adds a new flag (M
Bit) in the PCECC-CAPABILITY sub-TLV to indicate the support for P2MP
in PCECC, which is applicable for multicast tree described in this
document as well.
3.2. PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is defined in [RFC8408]; [RFC9050] defines a
PST value for PCECC as '2', which is applicable for multicast tree
described in this document as well.
3.3. Multicast Source Registration Object
The MSR object is optional and SHOULD contain multicast source
information and FHR information. The MSR object SHOULD be carried
within a PCRpt message sent by PCC to PCE for registration. The MSR
object SHOULD be carried within a PCUpd message sent by PCE to PCC in
response to registration.
MSR Object-Class is TBD3. MSR Object-Type is 1. The format of the
MSR object body is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |R|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auxiliary Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Auxiliary Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MSR Object Body Format
R (Register flag, 1 bit): The R flag set to 1 indicates that the PCC
is registering multicast information to the PCE. The R flag set to 0
indicates that the PCC revokes the registration.
Li, et al. Expires 24 March 2023 [Page 10]
Internet-Draft Multicast Tree Setup via PCEP September 2022
A (Authentication flag, 1 bit): The A flag set to 1 indicates success
of registration. The A flag set to 0 indicates failure of
registration or revocation of registration. If there is no
authentication information, A flag SHOULD also be set to 0.
Auxiliary Length (1 Octet): indicates the length of Auxiliary Data.
Auxiliary Data (Variable length): contains functional data such as
authentication information.
MSR object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
Policy Association Group Policy Identifiers TLV, and VPN Information
TLV. P2MP SR Policy Association Group Policy Identifiers TLV are
defined in [I-D.ietf-pce-sr-p2mp-policy]. MSR object carries
different TLVs depending on the multicast tree.
3.3.1. Multicast Address TLV
In IP multicast scenarios, Multicast Address TLV SHOULD be included.
The format of the Multicast Address TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast Group Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multicast Address TLV Format
Prefix Length (2 Octets): indicates the length of multicast
addresses. the length MAY be 4 Octets, 8 Octets, 16 Octets, or 32
Octets. The multicast source address can be empty, but the multicast
group address must be filled. If both the multicast source address
and multicast group address exist, they must be both IPv4 and IPv6
addresses.
Multicast Source Address (Variable length): contains IPv4 or IPv6
address of the multicast source.
Multicast Group Address (Variable length): contains IPv4 or IPv6
address of the multicast group.
Li, et al. Expires 24 March 2023 [Page 11]
Internet-Draft Multicast Tree Setup via PCEP September 2022
3.3.2. mLDP FEC TLV
In mLDP multicast scenarios, Multicast Address TLV SHOULD be
included.
The format of the mLDP FEC TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ mLDP FEC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: mLDP FEC TLV Format
mLDP FEC (Variable length): carries mLDP FEC.
3.3.3. VPN Information TLV
VPN Information TLV is used to report VPN information about multicast
sources and receivers. The format of the VPN Information TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VPN Information TLV Format
VPN Identifier (8 Octets): indicates the VPN which the receiver used.
3.4. Multicast Receiver Information Object
The MRI object is optional and SHOULD contain receivers' information
for matching the multicast registration information. The MRI object
SHOULD be carried within a PCRpt message sent by PCC to PCE for
multicast joining or leaving.
MRI Object-Class is TBD7. MRI Object-Type is 1. The format of the
MRI object body is:
Li, et al. Expires 24 March 2023 [Page 12]
Internet-Draft Multicast Tree Setup via PCEP September 2022
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | flags |B|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MRI Object Body Format
B(BIER multicast flag, 1 bit): The B flag set to 1 indicates that
multicast protocol is BIER. If the B flag set to 1, MRI object
SHOULD include BFR information TLV defined in Section 3.4.1.
S(Subscribe flag, 1 bit): The S flag set to 1 indicates that PCC
delivers the message requesting to join PCE. The S flag set to 0
indicates that PCC delivers the message requesting to leave to PCE.
MRI object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
Policy Association Group Policy Identifiers TLV, VPN Information TLV,
and BFR information TLV.
3.4.1. BFR Information TLV
BFR Information TLV is used to report router location information in
the BIER domain. The format of the BFR Information TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subdomain-Id | BFR-ID | BSL |Padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: BFR Information TLV Format
Subdomain-Id (1 Octet): Unique value identifying the BIER subdomain.
BFR-ID (2 Octets): Identification of BFR in a subdomain.
BSL (BitString Length, 4 bits): encodes the length in bits of the
BitString as per [RFC8296], the maximum length of the BitString is 7,
it indicates the length of BitString is 4096. It is used to refer to
the number of bits in the BitString.
Li, et al. Expires 24 March 2023 [Page 13]
Internet-Draft Multicast Tree Setup via PCEP September 2022
3.5. CCI Object
The CCI object [RFC9050] is used by the PCE to specify the forwarding
instructions to the PCC and MAY be carried within a PCInitiate or
PCRpt message for control information download/report.
The CCI Object Type 1 for MPLS Label is defined in [RFC9050], which
is used for the P2MP LSPs as well. For mLDP multicast trees, in
addition to forwarding labels, corresponding tree labels or label
stacks are required. Therefore, a new TLV is needed to carry tree
labels or label stacks. In addition, in order to meet the needs of
VPN scenarios, a new TLV with VPN forwarding Identifier is also
defined.
3.5.1. Tree Label TLV
The format of Tree Label TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tree Label stack ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Tree Label TLV Format
Tree Label stack (Variable length): contains tree labels used to
identify multicast trees. There are three application scenarios, as
per [I-D.ietf-bess-bgp-multicast-controller].
3.5.2. VPN Forwarding Identifier TLV
The format of VPN Forwarding Identifier TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VPN Forwarding Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: VPN Forwarding Identifier TLV Format
VPN Forwarding Identifier (Variable length): contains MPLS label or
IPv6 Segment Identifier with 16 Octets.
Li, et al. Expires 24 March 2023 [Page 14]
Internet-Draft Multicast Tree Setup via PCEP September 2022
3.6. Tree Forwarding State Synchronization Object
The TFSS object is optional and SHOULD contain the forwarding state
of control plane that the tree node needs to synchronize. The TFSS
object SHOULD be carried within a PCInitiate or PCUpd message sent by
PCE to PCC, or a PCRpt message sent by PCC to PCE for response.
TFSS Object-Class is TBD11. TFSS Object-Type is 1. The format of
the TFSS object body is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TFSS Object Body Format
F (Forwarding flag, 1 bit): The F flag set to 1 indicates that the
node MAY start forwarding multicast packets. The F flag set to 0
indicates that the node SHOULD stop forwarding multicast packets.
TFSS object MAY include Multicast Address TLV, VPN Forwarding
Identifier TLV, and BIER Attribute TLV. When TT=1, BIER Attribute
TLV SHOULD be included.
3.6.1. BIER Attribute TLV
BIER Attribute TLV is used to instruct the FHR to forward multicast
packets to the users according to the BitString specified by the
controller. The format of BIER Attribute TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subdomain-id | SI | BSL ~ BitString ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: BIER Attribute TLV Format
Subdomain-id (1 Octet): Unique value identifying the BIER subdomain.
SI (Set Identifier, 1 Octet): encoding the Set Identifier used in the
encapsulation for this BIER subdomain for this BitString length.
Li, et al. Expires 24 March 2023 [Page 15]
Internet-Draft Multicast Tree Setup via PCEP September 2022
BSL (BitString Length, 4 bits): encodes the length in bits of the
BitString as per [RFC8296], the maximum length of the BitString is 7,
it indicates the length of BitString is 4096. It is used to refer to
the number of bits in the BitString.
BitString(Variable length): indicates the path of multicast data
packets forwarding for headend.
3.7. Multicast Receiver Statistics Object
The MRS object is optional and used to inform PCE of the number of
receivers. The MRS object SHOULD be carried within a PCRpt or a
PCUpd message for synchronize receiver information periodically, or
PCRpt message for the leaving of receivers.
MRS Object-Class is TBD13. MRS Object-Type is 1. The format of the
MRS object body is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Statistics |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: MRS Object Body Format
Number Length (2 Octets): indicates the length of receiver number.
Multicast Statistics (4 Octets): indicates the statistics information
for a particular multicast tree of a controller or a LHR.
MRS object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR
Policy Association Group Policy Identifiers TLV.
4. Message Formats
4.1. PCRpt message
The definition of the PCRpt message from [RFC8231] and [RFC9050] is
extended to optionally include MSR object, MRI object, TFSS object,
and MRS object after the path object. The encoding will become:
Li, et al. Expires 24 March 2023 [Page 16]
Internet-Draft Multicast Tree Setup via PCEP September 2022
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
[<MSR>]
[<MRI>]
[<TFSS>]
[<MRS>]
Where:
<path> is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231].
4.2. PCInitiate message
The definition of the PCInitiate message from [RFC8281] is extended
to optionally include TFSS object after the path object. The
encoding will become:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
[<TFSS>]
Where:
LSP and SRP object are defined in [RFC8231].
4.3. PCUpd message
The definition of the PCUpd message from [RFC8231] is extended to
optionally include MSR object, TFSS object and MRS object after the
path object. The encoding will become:
Li, et al. Expires 24 March 2023 [Page 17]
Internet-Draft Multicast Tree Setup via PCEP September 2022
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
[<MSR>]
[<TFSS>]
[<MRS>]
Where:
<path> is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231].
5. Example Workflow
5.1. Multicast Tree Discovery
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+-----| | |
|PCC +-------+ |
|transit| | |
+------| | | |
|PCC +-------+ | |
|egress | | | |
+-------+ | | |
| | |-----PCRpt,PLSP-ID=1,D=1------>|Source Registration
| | | MSR Object(R=1) |(Root Discovery)
| | | |
| | |<----PCUpd,PLSP-ID=1-----------|Source Registration
| | | MSR Object(R=1) |Confirmation
| | | |
|------------------PCRpt,PLSP-ID=0---------->|Receiver Report
| | | MRI Object(S=1) |(Leaf Discovery)
| | | |
Figure 11: Workflow of Multicast Tree Discovery
5.2. Multicast Tree Path Establishment and Update
5.2.1. Labeled Tree
The workflow of Labeled Tree are as per
[I-D.ietf-pce-sr-p2mp-policy].
Li, et al. Expires 24 March 2023 [Page 18]
Internet-Draft Multicast Tree Setup via PCEP September 2022
5.2.2. BIER Tree
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| +-------+ |
| transit| | |
+------| | | |
| +--------+ | |
|egress | | | |
+--------+ | | |
|<-------------------PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Object |Setup
| | | VPN Forwarding Identifier |
| | | |
|--------------------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | |
| | |<-----PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Object (F=1,TT=1) |Setup
| | | VPN Forwarding Identifier |
| | | |
| | |------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | |
| | | |
| | | |
|--------------------PCRpt,PLSP-ID=0----------->|Receiver Report
| | | MRI Object(S=1/S=0) |(Leaf Discovery)
| | | |
|<-------------------PCInitiate,PLSP-ID=1-------|Tree State
| | | TFSS Object |Update
| | | VPN Forwarding Identifier |
| | | |
|--------------------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | |
| | |<-----PCUpd,PLSP-ID=1------------|Tree State
| | | TFSS Object (F=1,TT=1) |Update
| | | |
| | |------PCRpt,PLSP-ID=1----------->|Tree State
| | | |Confirmation
| | | |
Figure 12: Workflow of BIER Tree Setup/Update
Li, et al. Expires 24 March 2023 [Page 19]
Internet-Draft Multicast Tree Setup via PCEP September 2022
In the previous multicast tree discovery process, ingress has
delegated the PCE to calculate the multicast path. Therefore, during
the establishment of the multicast tree, PCE informs the ingress to
forward multicast data for (S,G)/(*,G) via PCInitiate message
carrying TFSS object according to the delegation. The PLSP-ID is the
value specified by the ingress. PCE also sends VPN forwarding
identifier to ingress and egresses, so that multicast packets can be
forwarded to specified VPN.
Ingress then updates the tree state and responds to the PCE. At this
point, the BIER tree is formally established and the ingress starts
forwarding for the multicast according to the BitString specified by
PCE.
If the topology of the BIER tree changes, the corresponding egresses
will send PCRpt messages carring MRI object to PCE to inform PCE of
their changes. PCE needs to send VPN forwarding identifier to these
egresses.
The PCE updates the BitStrig based on changes of the egresses and
informs the ingress to update. State update process is similar to
state setup process, except for the type of message sent by the PCE.
5.3. Multicast Statistics Synchronization
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+-----| | |
|PCC +-------+ |
|transit| | |
+------| | | |
|PCC +-------+ | |
|egress | | | |
+-------+ | | |
| | | |
|------------------PCRpt,PLSP-ID=0---------->| Statistics
| | | MRS Object | Report
| | |case1: Periodic Synchronization|
| | | case2: Change Synchronization |
| | | |
| | | |
| | |<----PCUpd,PLSP-ID=0-----------| Statistics
| | | MRS Object | Feedback
| | | Periodic Synchronization |
| | | |
Figure 13: Workflow of Multicast Statistics Synchronization
Li, et al. Expires 24 March 2023 [Page 20]
Internet-Draft Multicast Tree Setup via PCEP September 2022
6. Security Considerations
To be added.
7. IANA Considerations
7.1. MULTICAST-STATE-CAPABILITY
IANA is requested to allocate a new code point within registry
"STATEFUL-PCE-CAPABILITY TLV Flag Field" under "Path Computation
Element Protocol (PCEP) Numbers" as follows:
Value Description Reference
------------ ----------------------------- ---------------
TBD1 MULTICAST-STATE-CAPABILITY This document
7.2. PCEP-ERROR Object
IANA is requested to allocate code-points in the "PCEP-ERROR Object
Error Types and Values" sub-registry for the following new error-type
and error-value:
Error-Type Description Reference
------------ ----------------------------- ---------------
10 Error-value = TBD2 This document
MULTICAST-STATE-CAPABILITY
bit is not set
7.3. New Objects
IANA is requested to allocate the following Object-Class Values in
the "PCEP Objects" sub-registry under the "Path Computation Element
Protocol (PCEP) Numbers" registry:
Object-Class Value Description Reference
------------------ ------------------------------- ---------------
TBD3 Multicast Source Registration This document
TBD7 Multicast Receiver Information This document
TBD11 Tree Forwarding State Synchronization This document
TBD13 Multicast Receiver Statistics This document
IANA is requested to allocate the following Object-Type Value of CCI
object in the "PCEP Objects" sub-registry under the "Path Computation
Element Protocol (PCEP) Numbers" registry:
Li, et al. Expires 24 March 2023 [Page 21]
Internet-Draft Multicast Tree Setup via PCEP September 2022
7.4. New TLVs
IANA is requested to allocate the following TLVs:
Type Description Reference
------------------ ------------------------------- ---------------
TBD4 Multicast Source Address This document
TBD5 mLDP FEC This document
TBD6 VPN Information This document
TBD8 BFR Information This document
TBD9 Tree Label This document
TBD10 VPN Forwarding Identifier TLV This document
TBD12 BIER Attribute This document
8. Acknowledgements
The author thanks ... for their review and comments.
9. References
9.1. Normative References
[I-D.ietf-pce-sr-p2mp-policy]
Bidgoli, H., Voyer, D., Rajarathinam, S., Hemmati, E.,
Saad, T., and S. Sivabalan, "PCEP extensions for p2mp sr
policy", Work in Progress, Internet-Draft, draft-ietf-pce-
sr-p2mp-policy-01, 7 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-
policy-01.txt>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, DOI 10.17487/RFC2362,
June 1998, <https://www.rfc-editor.org/info/rfc2362>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Li, et al. Expires 24 March 2023 [Page 22]
Internet-Draft Multicast Tree Setup via PCEP September 2022
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
Li, et al. Expires 24 March 2023 [Page 23]
Internet-Draft Multicast Tree Setup via PCEP September 2022
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
9.2. Informative References
[I-D.chen-pce-pcep-extension-pce-controller-bier]
Chen, R., Xu, B., Chen, H., and A. Wang, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of BIER", Work in Progress, Internet-
Draft, draft-chen-pce-pcep-extension-pce-controller-bier-
03, 7 March 2022, <https://www.ietf.org/archive/id/draft-
chen-pce-pcep-extension-pce-controller-bier-03.txt>.
[I-D.dhody-pce-pcep-extension-pce-controller-p2mp]
Li, Z., Peng, S., Geng, X., and M. S. Negi, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Using the PCE as a Central Controller
(PCECC) of point-to-multipoint (P2MP) LSPs", Work in
Progress, Internet-Draft, draft-dhody-pce-pcep-extension-
pce-controller-p2mp-09, 10 July 2022,
<https://www.ietf.org/archive/id/draft-dhody-pce-pcep-
extension-pce-controller-p2mp-09.txt>.
[I-D.ietf-bess-bgp-multicast-controller]
Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko,
"Controller Based BGP Multicast Signaling", Work in
Progress, Internet-Draft, draft-ietf-bess-bgp-multicast-
Li, et al. Expires 24 March 2023 [Page 24]
Internet-Draft Multicast Tree Setup via PCEP September 2022
controller-09, 11 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-bess-bgp-
multicast-controller-09.txt>.
[I-D.ietf-pim-sr-p2mp-policy]
(editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
and Z. Zhang, "Segment Routing Point-to-Multipoint
Policy", Work in Progress, Internet-Draft, draft-ietf-pim-
sr-p2mp-policy-05, 2 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-
policy-05.txt>.
[I-D.ietf-spring-sr-replication-segment]
(editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
and Z. Zhang, "SR Replication Segment for Multi-point
Service Delivery", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-replication-segment-08, 1 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
replication-segment-08.txt>.
[I-D.zzhang-mvpn-evpn-controller]
Zhang, Z., Parekh, R., Zhang, Z., and H. Bidgoli, "MVPN
and EVPN BUM Signaling with Controllers", Work in
Progress, Internet-Draft, draft-zzhang-mvpn-evpn-
controller-01, 25 October 2021,
<https://www.ietf.org/archive/id/draft-zzhang-mvpn-evpn-
controller-01.txt>.
Authors' Addresses
Huanan Li
China Telecom
Email: lihn6@foxmail.com
Aijun Wang
China Telecom
Email: wangaj3@chinatelecom.cn
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Huaimo Chen
Futurewei
Email: Huaimo.chen@futurewei.com
Li, et al. Expires 24 March 2023 [Page 25]
Internet-Draft Multicast Tree Setup via PCEP September 2022
Ran Chen
ZTE Corporation
Email: chen.ran@zte.com.cn
Li, et al. Expires 24 March 2023 [Page 26]
