idnits 2.17.1 draft-li-pce-multicast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '... pair, where the source address MAY be...' RFC 2119 keyword, line 166: '...aling/convergence problems MAY result....' RFC 2119 keyword, line 172: '...ion, many channels MAY need to be sent...' RFC 2119 keyword, line 229: '...e upstream and downstream nodes MAY be...' RFC 2119 keyword, line 257: '...and calculation constraints. This MAY...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2022) is 768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8408' is mentioned on line 437, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-pce-sr-p2mp-policy-00 ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-05) exists of draft-chen-pce-pcep-extension-pce-controller-bier-03 == Outdated reference: A later version (-12) exists of draft-dhody-pce-pcep-extension-pce-controller-p2mp-08 == Outdated reference: A later version (-12) exists of draft-ietf-bess-bgp-multicast-controller-07 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-04 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-07 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pce H. Li 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: September 21, 2022 Z. Zhang 6 Juniper Networks 7 H. Chen 8 Futurewei 9 R. Chen 10 ZTE Corporation 11 March 20, 2022 13 Multicast Tree Setup via PCEP 14 draft-li-pce-multicast-01 16 Abstract 18 Multicast forwarding requires per-tree state on certain nodes. Even 19 with BIER, per-tree state is needed on ingress/egress BIER routers 20 (though not needed on transit BIER routers). This documents 21 specifies PCEP protocol to collect tree information (e.g. root, leaf, 22 constraints) to allow a PCE to calculate a tree, and the procedures 23 to set up per-tree forwarding state on relevant nodes for various 24 multicast trees and various replication technologies. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 21, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Different Multicast Trees . . . . . . . . . . . . . . . . 4 63 2.1.1. IP Multicast . . . . . . . . . . . . . . . . . . . . 4 64 2.1.2. mLDP/RSVP-TE P2MP Tunnels . . . . . . . . . . . . . . 4 65 2.1.3. SR-P2MP Tunnels . . . . . . . . . . . . . . . . . . . 5 66 2.2. Different Replication Technologies . . . . . . . . . . . 5 67 2.3. Tree Information Discovery . . . . . . . . . . . . . . . 6 68 2.3.1. Root node Discovery . . . . . . . . . . . . . . . . . 6 69 2.3.2. Leaf node Discovery . . . . . . . . . . . . . . . . . 7 70 2.4. Multicast Tree . . . . . . . . . . . . . . . . . . . . . 7 71 2.4.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 8 72 2.4.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 8 73 2.5. Multicast Statistics . . . . . . . . . . . . . . . . . . 8 74 3. PCEP Object Formats . . . . . . . . . . . . . . . . . . . . . 9 75 3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . 9 77 3.1.2. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 78 3.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 79 3.3. Multicast Source Registration Object . . . . . . . . . . 10 80 3.3.1. Multicast Address TLV . . . . . . . . . . . . . . . . 11 81 3.3.2. mLDP FEC TLV . . . . . . . . . . . . . . . . . . . . 12 82 3.3.3. VPN Information TLV . . . . . . . . . . . . . . . . . 12 83 3.4. Multicast Receiver Information Object . . . . . . . . . . 12 84 3.4.1. BFR Information TLV . . . . . . . . . . . . . . . . . 13 85 3.5. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.5.1. Tree Label TLV . . . . . . . . . . . . . . . . . . . 14 87 3.5.2. VPN Forwarding Identifier TLV . . . . . . . . . . . . 14 88 3.6. Tree Forwarding State Synchronization Object . . . . . . 15 89 3.6.1. BIER Attribute TLV . . . . . . . . . . . . . . . . . 15 90 3.7. Multicast Receiver Statistics Object . . . . . . . . . . 16 91 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.1. PCRpt message . . . . . . . . . . . . . . . . . . . . . . 16 93 4.2. PCInitiate message . . . . . . . . . . . . . . . . . . . 17 94 4.3. PCUpd message . . . . . . . . . . . . . . . . . . . . . . 17 95 5. Example Workflow . . . . . . . . . . . . . . . . . . . . . . 18 96 5.1. Multicast Tree Discovery . . . . . . . . . . . . . . . . 18 97 5.2. Multicast Tree Path Establishment and Update . . . . . . 18 98 5.2.1. Labeled Tree . . . . . . . . . . . . . . . . . . . . 19 99 5.2.2. BIER Tree . . . . . . . . . . . . . . . . . . . . . . 19 100 5.3. Multicast Statistics Synchronization . . . . . . . . . . 21 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 7.1. MULTICAST-STATE-CAPABILITY . . . . . . . . . . . . . . . 22 104 7.2. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 22 105 7.3. New Objects . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.4. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 23 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 110 9.2. Informative References . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Introduction 115 Currently, multicast management information is mainly signaled by PIM 116 [RFC2362], mLDP [RFC6388] or BGP [RFC6514]. The trees/tunnels are 117 set up using the "receiver-initiated join" technique of PIM/mLDP, hop 118 by hop from downstream routers towards the root. The BGP messages 119 are either sent hop by hop between downstream routers and their 120 upstream neighbors, or can be reflected by Route Reflectors (RRs). 121 The signaling is the interaction between routers and cannot be 122 managed in a unified manner. 124 As an alternative to each hop independently determining its upstream 125 router and signaling upstream towards the root (following PIM/mLDP 126 model), the entire tree can be calculated by a centralized 127 controller, and the signaling can be entirely done from the 128 controller. 130 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 131 "strict synchronization between the PCE and not only the network 132 states (in term of topology and resource information), but also the 133 set of computed paths and reserved resources in use in the network." 134 [RFC8231] specifies a set of extensions to PCEP to support state 135 synchronization between PCCs and PCEs. 137 The controller can serve as a PCE to centrally manage multicast trees 138 and establish states on all tree nodes serving as PCC. This document 139 defines PCEP objects and TLVs to accomplish the multicast source 140 registration/revocation, receiver discovery, multicast tree state 141 update etc. functions. 143 2. Overview 145 2.1. Different Multicast Trees 147 This section discusses various multicast trees like IP, mLDP, SR-P2MP 148 - each with its own tree identification. 150 2.1.1. IP Multicast 152 As stated in [RFC1112], an IP multicast packet's destination address 153 is a Multicast Group Address and it follows either a source specific 154 tree rooted at the First Hop Router (FHR) or a shared tree rooted at 155 a Rendezvous Point (RP) [RFC7761]. Each tree is identified by a 156 (source address, group address) pair, where the source address MAY be 157 a wildcard in case of the shared tree. This identification, which is 158 often referred to as (s, g) or (*, g), is used in both forwarding 159 plane as well as in control plane that sets up the tree, e.g., using 160 Protocol Independ Multicast (PIM) [RFC7761] [RFC5015]. 162 Each node on the tree needs to have corresponding forwarding plane 163 state used to forward corresponding traffic and control plane state 164 that is used to set up a tree. Depending on the number of (s, g) 165 and/or (*, g) trees that a routing domain need to support, serious 166 scaling/convergence problems MAY result. 168 2.1.2. mLDP/RSVP-TE P2MP Tunnels 170 Quite often, some different multicast trees are used for similar 171 purposes and the tree structure are identical or very similar. For 172 example, in an IPTV application, many channels MAY need to be sent 173 from the same headend router to the same set of edge routers close to 174 receivers. 176 In that case, a set of IP multicast trees can be transported over a 177 fewer set of MPLS P2MP tunnels - either mLDP [RFC6388] or RSVP-TE 178 P2MP [RFC4875] tunnels - across an MPLS domain. Inside the MPLS 179 domain, there is no IP multicast tree state but only fewer state for 180 the P2MP tunnels. Outside the MPLS domain, those IP multicast trees 181 still have their per-tree state on each tree node. 183 An mLDP tree is identified by an mLDP FEC in the control plane. In 184 the context of PCEP signaling, part of or an entire mLDP tunnel can 185 be set up using PCEP from a PCE instead of using hop-by-hop mLDP 186 signaling. In this case the only relevance to mLDP is that mLDP FEC 187 is used to identify the tunnel. 189 A RSVP-TE P2MP tree is identified by a RSVP Session object in the 190 control plane. While in theory it can also be set up via PCEP 191 signaling from a PCE, it is outside the scope of this document. 193 In the forwarding plane, there is no difference between an mLDP 194 tunnel and a RSVP-TE P2MP tunnel. A tree is identified by a label - 195 incoming labeled traffic is replicated to a bunch of downstream nodes 196 with a label that identifies the tree to the downstream nodes. 198 2.1.3. SR-P2MP Tunnels 200 Segment Routing (SR) [RFC8402] has two principles: 202 1. No per-flow/tunnel state inside an SR domain 204 2. Optional but perferred use of controllers 206 When it comes to multicast, the only technologies that sticks to 207 principle #1 is BIER [RFC8279], which does not use per-tree state for 208 forwarding. 210 SR-P2MP [I-D.ietf-pim-sr-p2mp-policy] 211 [I-D.ietf-spring-sr-replication-segment] sticks to principle #2 only, 212 in that PCEs are used to calculate a multicast tree subject to 213 constraints and then direct signaling from PCEs are used to set up 214 the tree instead of using mLDP/RSVP signaling, but per-tree state is 215 still used. 217 In the control plane, an SR-P2MP is identified by a (root-id, tree- 218 id) tuple. In an SR-MPLS forwarding plane, an SR-P2MP tunnel is not 219 different from mLDP/RSVP-TE P2MP tunnel at all, though the tree- 220 identifying label is called a tree sid. 222 In an SRv6 forwarding plane, the tree sid is embedded as part of an 223 IPv6 address. 225 2.2. Different Replication Technologies 227 For any kind of multicast trees mentioned above, on a particular tree 228 node A, an incoming packet needs to replicated to a set of downstream 229 nodes B/C/D/E. Note that the upstream and downstream nodes MAY be 230 directly connected or they can be reached via a set of P2P/MP2P 231 tunnels, P2MP tunnels, or via BIER. In the latter case, intermediate 232 nodes do not maintain the per-tree state but they do need to maintain 233 state for the transporting tunnels or BIER. 235 Now on node A/B/C/D/E, per-tree replication state needs to be set up. 236 In particular on A, depending on the method used to replicate to 237 B/C/D/E, (a combination of) the following replication branches are 238 needed: 240 o A set of outgoing interfaces for native IP forwarding to directly 241 connected nodes from the B/C/D/E set in case of IP multicast tree, 242 and/or, 244 o A set of P2P/MP2P/P2MP tunnels to reach indirectly connected nodes 245 from the B/C/D/E set, and/or, 247 o A BIER bitstring and relevant BIER information to reach some nodes 248 from the B/C/D/E set 250 In the latter two cases, the replication branches also need relevant 251 information to identify to B/C/D/E which tree a packet is for (e.g., 252 a label for an mLDP or SR-P2MP tree). 254 2.3. Tree Information Discovery 256 When a PCE calculates a multicast tree, it needs to collect the tree 257 information like root, leaves and calculation constraints. This MAY 258 be provided to the PCE via a southbound (wrt the PCE) interface from 259 an orchestrator or via northbound PCEP signaling from some PCC nodes 260 (e.g. the root and leaf nodes of the tree). The PCE MAY also 261 participate overlay signaling protocols to collect the information 262 (e.g., [I-D.zzhang-mvpn-evpn-controller]). 264 This document only covers the northbound PCEP signaling. The two 265 other methods mentioned above are out of scope of this document. 267 Whether it is an IP Multicast or mLDP/SR-P2MP Tree, the root, leaves 268 and calculation constraints are encoded the same way but associated 269 with different tree identifications in the PCEP signaling. 270 Specifically, the root and leaves are encoded as IP addresses. 272 The leaf information can be encoded as a full set of leaves or as 273 addition/removal delta. 275 2.3.1. Root node Discovery 277 When a multicast source accesses to a First Hop Router (FHR), the FHR 278 originates a PCRpt message carrying the Multicast Source Registration 279 (MSR) object defined in Section 3.3, which provides FHR information. 280 FHR, as PCC, delegate the controller as PCE to calculate multicast 281 tree. In the sent PCRpt message, the D bit of LSP Object is set to 282 1. 284 2.3.2. Leaf node Discovery 286 For IP multicast, Last Hop Router (LHR) MAY convert the multicast 287 source and group address carried in the IGMP Join/Leave messages sent 288 by local hosts and VPN information corresponding to local hosts into 289 PCRpt messages and report these information to the controller. 290 Similar to IGMP messages, PIM messages from other domains can also be 291 used as receiver information and be converted into PCRpt messages to 292 be reported to the controller. 294 For mLDP and SR-P2MP multicast, The corresponding tree identifiers 295 can also be carried in PCRpt messages and reported to the controller. 297 When the first receiver accesses a Last Hop Router (LHR) to join a 298 multicast tree, or when the last receiver leaves the LHR, the LHR 299 originates a PCRpt message carrying the Multicast Receiver 300 Information (MRI) object defined in Section 3.4, which provides LHR 301 information. 303 If the receivers locate in different VPN domains, the VPN information 304 associated with the multicast source and multicast destination should 305 also be reported by the LHR and FHR. The VPN information reported by 306 LHRs SHOULD be consistent. 308 2.4. Multicast Tree 310 The multicast trees are established with the FHRs of the multicast 311 source as the root of the multicast trees. According to different 312 multicast technologies, the types of multicast trees include labeled 313 tree and BIER tree. Different multicast trees correspond to 314 different processing. This section describes the state update of 315 different multicast operations. 317 No matter which forwarding technology is used, there is a case that 318 local multicast receivers directly access to FHRs. In this case, 319 FHRs need to forward multicast data for local receivers in the way of 320 native IP without other control information. 322 In some scenarios, the egresses node needs a VPN forwarding 323 identifier to determine which VRF to forward the packet to. The 324 allocation of VPN forwarding identifier is performed by controller. 325 The scenario of egress assigning VPN tags has not been considered 326 yet. Controller sends the VPN forwarding identifier to ingress and 327 instructs ingress to encapsulate it. The VPN Forwarding Label may be 328 MPLS label or SRv6 segment. 330 2.4.1. Labeled Tree 332 For a Labeled multicast tree, whether the forwarding is based on 333 native IP, mLDP or SR-P2MP tunnel, each node needs a tree label to 334 identify a multicast tree. There are three options for tree label 335 assignment: 337 o From each router's SRLB that the controller learns 339 o From the common SRGB that the controller learns 341 o From the controller's local label space 343 The detailed instruction is as per 344 [I-D.ietf-bess-bgp-multicast-controller]. Section 3.5.1 defines two 345 new TLVs to extend the CCI Object-Type support the tree label and VPN 346 Label. 348 The operations for initiating multicast tree LSPs and 349 downloadinglabels are consistent with [I-D.ietf-pce-sr-p2mp-policy]. 351 2.4.2. BIER Tree 353 Different from other forwarding technologies, BIER does not need the 354 transit nodes to maintain the multicast state, and only needs to 355 forward and encapsulate the packets according to the BitString and 356 BIFT. BIFT information can be learned by IGP. For each node of a 357 sub-domain, the BIFT can be configured locally or allocated by BGP 358 controller or PCE. Allocation by PCE is as per 359 [I-D.chen-pce-pcep-extension-pce-controller-bier]. 361 After receiving the BFR information reported from LHRs, the 362 controller combine BFR information of LHRs into a BitString to guide 363 multicast data forwarding. 365 The controller (PCE) sends the BitString to the FHR via PCInitiate or 366 PCUpd message carrying Tree Forwarding State Synchronization (TFSS) 367 object defined in Section 3.6 to inform the FHR to forward multicast 368 data for a specific multicast tree according to the BitString, and 369 the tree identifier is (*, g) or (s, g) tuple. Controller also needs 370 to inform FHR to encapsulate VPN forwarding identifier so that LHRs 371 can forward multicast data to specific VRF accordingly. 373 2.5. Multicast Statistics 375 Multicast statistics are helpful for multicast service analysis and 376 business development. This section describes how to collect 377 statistics about multicast users. 379 For each LHR, the statistics consist of two parts, one is the number 380 of local users in the its managed domain, and the other is the number 381 of other managed domains. The sum of these two parts is the number 382 of multicast data that the one LHR needs to duplicate. 384 LHRs send this information to the controller via PCRpt message 385 carrying Multicast Receiver Statistics (MRS) object. LHRs need 386 report this information to the controller periodically. Once the 387 statistics information of a LHR change, the LHR also needs reports to 388 the controller. 390 Controller collects the statistics reported by LHRs and MAY 391 periodically informs the FHR of the statistics via PCRpt messages 392 carrying MRS object so that the FHR can feed the statistics back to 393 the multicast source. 395 3. PCEP Object Formats 397 3.1. OPEN Object 399 3.1.1. STATEFUL-PCE-CAPABILITY TLV 401 During the PCEP initialization phase, PCEP speakers advertise 402 stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN 403 object. Various flags are defined for the STATEFUL-PCE-CAPABILITY 404 TLV defined in [RFC8231] and updated in [RFC8232] and [RFC8281]. 406 A new flag is added in this document, whose code point is TBD1: 408 MULTICAST-STATE-CAPABILITY bit, if this bit is set to 1 by a PCEP 409 speaker, it indicates that the PCEP speaker supports the capability 410 of these new extensions as specified in this document. 412 To support the multicast tree state management capabilities described 413 in this document, both PCE and PCC need to set MULTICAST-STATE- 414 CAPABILITY bit. If a PCEP speaker receivers PECP message with the 415 newly defined object, but without the MULTICAST-STATE-CAPABILITY bit 416 set in STATEFUL-PCE-CAPABILITY TLV in the OPEN object, it MUST: 418 o Send a PCErr message with Error-Type=10(Reception of an invalid 419 object) and Error-Value TBD2(MULTICAST-STATE-CAPABILITY bit is not 420 set). 422 o Terminate the PCEP session. 424 3.1.2. PCECC Capability sub-TLV 426 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 427 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 428 CAPABILITY TLV as specified in [RFC9050]. 430 [I-D.dhody-pce-pcep-extension-pce-controller-p2mp] adds a new flag (M 431 Bit) in the PCECC-CAPABILITY sub-TLV to indicate the support for P2MP 432 in PCECC, which is applicable for multicast tree described in this 433 document as well. 435 3.2. PATH-SETUP-TYPE TLV 437 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; [RFC9050] defines a 438 PST value for PCECC as '2', which is applicable for multicast tree 439 described in this document as well. 441 3.3. Multicast Source Registration Object 443 The MSR object is optional and SHOULD contain multicast source 444 information and FHR information. The MSR object SHOULD be carried 445 within a PCRpt message sent by PCC to PCE for registration. The MSR 446 object SHOULD be carried within a PCUpd message sent by PCE to PCC in 447 response to registration. 449 MSR Object-Class is TBD3. MSR Object-Type is 1. The format of the 450 MSR object body is: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | flags |R|A| 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Auxiliary Length | Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ~ Auxiliary Data ~ 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 ~ Optional TLVs ~ 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 1: MSR Object Body Format 465 R (Register flag, 1 bit): The R flag set to 1 indicates that the PCC 466 is registering multicast information to the PCE. The R flag set to 0 467 indicates that the PCC revokes the registration. 469 A (Authentication flag, 1 bit): The A flag set to 1 indicates success 470 of registration. The A flag set to 0 indicates failure of 471 registration or revocation of registration. If there is no 472 authentication information, A flag SHOULD also be set to 0. 474 Auxiliary Length (1 Octet): indicates the length of Auxiliary Data. 476 Auxiliary Data (Variable length): contains functional data such as 477 authentication information. 479 MSR object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR 480 Policy Association Group Policy Identifiers TLV, and VPN Information 481 TLV. P2MP SR Policy Association Group Policy Identifiers TLV are 482 defined in [I-D.ietf-pce-sr-p2mp-policy]. MSR object carries 483 different TLVs depending on the multicast tree. 485 3.3.1. Multicast Address TLV 487 In IP multicast scenarios, Multicast Address TLV SHOULD be included. 489 The format of the Multicast Address TLV is: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type = TBD4 | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Prefix Length | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ Multicast Source Address ~ 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 ~ Multicast Group Address ~ 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 2: Multicast Address TLV Format 504 Prefix Length (2 Octets): indicates the length of multicast 505 addresses. the length MAY be 4 Octets, 8 Octets, 16 Octets, or 32 506 Octets. The multicast source address can be empty, but the multicast 507 group address must be filled. If both the multicast source address 508 and multicast group address exist, they must be both IPv4 and IPv6 509 addresses. 511 Multicast Source Address (Variable length): contains IPv4 or IPv6 512 address of the multicast source. 514 Multicast Group Address (Variable length): contains IPv4 or IPv6 515 address of the multicast group. 517 3.3.2. mLDP FEC TLV 519 In mLDP multicast scenarios, Multicast Address TLV SHOULD be 520 included. 522 The format of the mLDP FEC TLV is: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = TBD5 | Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 ~ mLDP FEC ~ 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 3: mLDP FEC TLV Format 533 mLDP FEC (Variable length): carries mLDP FEC. 535 3.3.3. VPN Information TLV 537 VPN Information TLV is used to report VPN information about multicast 538 sources and receivers. The format of the VPN Information TLV is: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type = TBD6 | Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | VPN Identifier | 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 4: VPN Information TLV Format 550 VPN Identifier (8 Octets): indicates the VPN which the receiver used. 552 3.4. Multicast Receiver Information Object 554 The MRI object is optional and SHOULD contain receivers' information 555 for matching the multicast registration information. The MRI object 556 SHOULD be carried within a PCRpt message sent by PCC to PCE for 557 multicast joining or leaving. 559 MRI Object-Class is TBD7. MRI Object-Type is 1. The format of the 560 MRI object body is: 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Reserved | flags |B|S| 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 ~ Optional TLVs ~ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 5: MRI Object Body Format 571 B(BIER multicast flag, 1 bit): The B flag set to 1 indicates that 572 multicast protocol is BIER. If the B flag set to 1, MRI object 573 SHOULD include BFR information TLV defined in Section 3.4.1. 575 S(Subscribe flag, 1 bit): The S flag set to 1 indicates that PCC 576 delivers the message requesting to join PCE. The S flag set to 0 577 indicates that PCC delivers the message requesting to leave to PCE. 579 MRI object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR 580 Policy Association Group Policy Identifiers TLV, VPN Information TLV, 581 and BFR information TLV. 583 3.4.1. BFR Information TLV 585 BFR Information TLV is used to report router location information in 586 the BIER domain. The format of the BFR Information TLV is: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = TBD8 | Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Subdomain-Id | BFR-ID | BSL |Padding| 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 6: BFR Information TLV Format 597 Subdomain-Id (1 Octet): Unique value identifying the BIER subdomain. 599 BFR-ID (2 Octets): Identification of BFR in a subdomain. 601 BSL (BitString Length, 4 bits): encodes the length in bits of the 602 BitString as per [RFC8296], the maximum length of the BitString is 7, 603 it indicates the length of BitString is 4096. It is used to refer to 604 the number of bits in the BitString. 606 3.5. CCI Object 608 The CCI object [RFC9050] is used by the PCE to specify the forwarding 609 instructions to the PCC and MAY be carried within a PCInitiate or 610 PCRpt message for control information download/report. 612 The CCI Object Type 1 for MPLS Label is defined in [RFC9050], which 613 is used for the P2MP LSPs as well. For mLDP multicast trees, in 614 addition to forwarding labels, corresponding tree labels or label 615 stacks are required. Therefore, a new TLV is needed to carry tree 616 labels or label stacks. In addition, in order to meet the needs of 617 VPN scenarios, a new TLV with VPN forwarding Identifier is also 618 defined. 620 3.5.1. Tree Label TLV 622 The format of Tree Label TLV is: 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type = TBD9 | Length | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 ~ Tree Label stack ~ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 7: Tree Label TLV Format 633 Tree Label stack (Variable length): contains tree labels used to 634 identify multicast trees. There are three application scenarios, as 635 per [I-D.ietf-bess-bgp-multicast-controller]. 637 3.5.2. VPN Forwarding Identifier TLV 639 The format of VPN Forwarding Identifier TLV is: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type = TBD10 | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 ~ VPN Forwarding Identifier ~ 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 8: VPN Forwarding Identifier TLV Format 650 VPN Forwarding Identifier (Variable length): contains MPLS label or 651 IPv6 Segment Identifier with 16 Octets. 653 3.6. Tree Forwarding State Synchronization Object 655 The TFSS object is optional and SHOULD contain the forwarding state 656 of control plane that the tree node needs to synchronize. The TFSS 657 object SHOULD be carried within a PCInitiate or PCUpd message sent by 658 PCE to PCC, or a PCRpt message sent by PCC to PCE for response. 660 TFSS Object-Class is TBD11. TFSS Object-Type is 1. The format of 661 the TFSS object body is: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Reserved | flags |F| 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 ~ Optional TLVs ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Figure 9: TFSS Object Body Format 672 F (Forwarding flag, 1 bit): The F flag set to 1 indicates that the 673 node MAY start forwarding multicast packets. The F flag set to 0 674 indicates that the node SHOULD stop forwarding multicast packets. 676 TFSS object MAY include Multicast Address TLV, VPN Forwarding 677 Identifier TLV, and BIER Attribute TLV. When TT=1, BIER Attribute 678 TLV SHOULD be included. 680 3.6.1. BIER Attribute TLV 682 BIER Attribute TLV is used to instruct the FHR to forward multicast 683 packets to the users according to the BitString specified by the 684 controller. The format of BIER Attribute TLV is: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type = TBD12 | Length | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Subdomain-id | SI | BSL ~ BitString ~ 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 10: BIER Attribute TLV Format 695 Subdomain-id (1 Octet): Unique value identifying the BIER subdomain. 697 SI (Set Identifier, 1 Octet): encoding the Set Identifier used in the 698 encapsulation for this BIER subdomain for this BitString length. 700 BSL (BitString Length, 4 bits): encodes the length in bits of the 701 BitString as per [RFC8296], the maximum length of the BitString is 7, 702 it indicates the length of BitString is 4096. It is used to refer to 703 the number of bits in the BitString. 705 BitString(Variable length): indicates the path of multicast data 706 packets forwarding for headend. 708 3.7. Multicast Receiver Statistics Object 710 The MRS object is optional and used to inform PCE of the number of 711 receivers. The MRS object SHOULD be carried within a PCRpt or a 712 PCUpd message for synchronize receiver information periodically, or 713 PCRpt message for the leaving of receivers. 715 MRS Object-Class is TBD13. MRS Object-Type is 1. The format of the 716 MRS object body is: 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Number Length | Reserved | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Multicast Statistics | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 ~ Optional TLVs ~ 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 11: MRS Object Body Format 729 Number Length (2 Octets): indicates the length of receiver number. 731 Multicast Statistics (4 Octets): indicates the statistics information 732 for a particular multicast tree of a controller or a LHR. 734 MRS object MAY include Multicast Address TLV, mLDP FEC TLV, P2MP SR 735 Policy Association Group Policy Identifiers TLV. 737 4. Message Formats 739 4.1. PCRpt message 741 The definition of the PCRpt message from [RFC8231] and [RFC9050] is 742 extended to optionally include MSR object, MRI object, TFSS object, 743 and MRS object after the path object. The encoding will become: 745 ::= 746 747 Where: 749 ::= [] 751 ::= [] 752 753 754 [] 755 [] 756 [] 757 [] 759 Where: 760 is as per [RFC8231] and the LSP and SRP object are 761 also defined in [RFC8231]. 763 4.2. PCInitiate message 765 The definition of the PCInitiate message from [RFC8281] is extended 766 to optionally include TFSS object after the path object. The 767 encoding will become: 769 ::= 770 771 Where: 773 ::= [] 775 ::= 776 777 [] 779 Where: 780 LSP and SRP object are defined in [RFC8231]. 782 4.3. PCUpd message 784 The definition of the PCUpd message from [RFC8231] is extended to 785 optionally include MSR object, TFSS object and MRS object after the 786 path object. The encoding will become: 788 ::= 789 790 Where: 792 ::= [] 794 ::= 795 796 797 [] 798 [] 799 [] 801 Where: 802 is as per [RFC8231] and the LSP and SRP object are 803 also defined in [RFC8231]. 805 5. Example Workflow 807 5.1. Multicast Tree Discovery 809 +-------+ +-------+ 810 |PCC | | PCE | 811 |ingress| +-------+ 812 +-----| | | 813 |PCC +-------+ | 814 |transit| | | 815 +------| | | | 816 |PCC +-------+ | | 817 |egress | | | | 818 +-------+ | | | 819 | | |-----PCRpt,PLSP-ID=1,D=1------>|Source Registration 820 | | | MSR Object(R=1) |(Root Discovery) 821 | | | | 822 | | |<----PCUpd,PLSP-ID=1-----------|Source Registration 823 | | | MSR Object(R=1) |Confirmation 824 | | | | 825 |------------------PCRpt,PLSP-ID=0---------->|Receiver Report 826 | | | MRI Object(S=1) |(Leaf Discovery) 827 | | | | 828 Figure 11: Workflow of Multicast Tree Discovery 830 5.2. Multicast Tree Path Establishment and Update 831 5.2.1. Labeled Tree 833 The workflow of Labeled Tree are as per 834 [I-D.ietf-pce-sr-p2mp-policy]. 836 5.2.2. BIER Tree 837 +-------+ +-------+ 838 |PCC | | PCE | 839 |ingress| +-------+ 840 +------| | | 841 | +-------+ | 842 | transit| | | 843 +------| | | | 844 | +--------+ | | 845 |egress | | | | 846 +--------+ | | | 847 |<-------------------PCInitiate,PLSP-ID=1-------|Tree State 848 | | | TFSS Object |Setup 849 | | | VPN Forwarding Identifier | 850 | | | | 851 |--------------------PCRpt,PLSP-ID=1----------->|Tree State 852 | | | |Confirmation 853 | | | | 854 | | |<-----PCInitiate,PLSP-ID=1-------|Tree State 855 | | | TFSS Object (F=1,TT=1) |Setup 856 | | | VPN Forwarding Identifier | 857 | | | | 858 | | |------PCRpt,PLSP-ID=1----------->|Tree State 859 | | | |Confirmation 860 | | | | 861 | | | | 862 | | | | 863 |--------------------PCRpt,PLSP-ID=0----------->|Receiver Report 864 | | | MRI Object(S=1/S=0) |(Leaf Discovery) 865 | | | | 866 |<-------------------PCInitiate,PLSP-ID=1-------|Tree State 867 | | | TFSS Object |Update 868 | | | VPN Forwarding Identifier | 869 | | | | 870 |--------------------PCRpt,PLSP-ID=1----------->|Tree State 871 | | | |Confirmation 872 | | | | 873 | | |<-----PCUpd,PLSP-ID=1------------|Tree State 874 | | | TFSS Object (F=1,TT=1) |Update 875 | | | | 876 | | |------PCRpt,PLSP-ID=1----------->|Tree State 877 | | | |Confirmation 878 | | | | 879 Figure 12: Workflow of BIER Tree Setup/Update 881 In the previous multicast tree discovery process, ingress has 882 delegated the PCE to calculate the multicast path. Therefore, during 883 the establishment of the multicast tree, PCE informs the ingress to 884 forward multicast data for (S,G)/(*,G) via PCInitiate message 885 carrying TFSS object according to the delegation. The PLSP-ID is the 886 value specified by the ingress. PCE also sends VPN forwarding 887 identifier to ingress and egresses, so that multicast packets can be 888 forwarded to specified VPN. 890 Ingress then updates the tree state and responds to the PCE. At this 891 point, the BIER tree is formally established and the ingress starts 892 forwarding for the multicast according to the BitString specified by 893 PCE. 895 If the topology of the BIER tree changes, the corresponding egresses 896 will send PCRpt messages carring MRI object to PCE to inform PCE of 897 their changes. PCE needs to send VPN forwarding identifier to these 898 egresses. 900 The PCE updates the BitStrig based on changes of the egresses and 901 informs the ingress to update. State update process is similar to 902 state setup process, except for the type of message sent by the PCE. 904 5.3. Multicast Statistics Synchronization 906 +-------+ +-------+ 907 |PCC | | PCE | 908 |ingress| +-------+ 909 +-----| | | 910 |PCC +-------+ | 911 |transit| | | 912 +------| | | | 913 |PCC +-------+ | | 914 |egress | | | | 915 +-------+ | | | 916 | | | | 917 |------------------PCRpt,PLSP-ID=0---------->| Statistics 918 | | | MRS Object | Report 919 | | |case1: Periodic Synchronization| 920 | | | case2: Change Synchronization | 921 | | | | 922 | | | | 923 | | |<----PCUpd,PLSP-ID=0-----------| Statistics 924 | | | MRS Object | Feedback 925 | | | Periodic Synchronization | 926 | | | | 927 Figure 13: Workflow of Multicast Statistics Synchronization 929 6. Security Considerations 931 To be added. 933 7. IANA Considerations 935 7.1. MULTICAST-STATE-CAPABILITY 937 IANA is requested to allocate a new code point within registry 938 "STATEFUL-PCE-CAPABILITY TLV Flag Field" under "Path Computation 939 Element Protocol (PCEP) Numbers" as follows: 941 Value Description Reference 942 ------------ ----------------------------- --------------- 943 TBD1 MULTICAST-STATE-CAPABILITY This document 945 7.2. PCEP-ERROR Object 947 IANA is requested to allocate code-points in the "PCEP-ERROR Object 948 Error Types and Values" sub-registry for the following new error-type 949 and error-value: 951 Error-Type Description Reference 952 ------------ ----------------------------- --------------- 953 10 Error-value = TBD2 This document 954 MULTICAST-STATE-CAPABILITY 955 bit is not set 957 7.3. New Objects 959 IANA is requested to allocate the following Object-Class Values in 960 the "PCEP Objects" sub-registry under the "Path Computation Element 961 Protocol (PCEP) Numbers" registry: 963 Object-Class Value Description Reference 964 ------------------ ------------------------------- --------------- 965 TBD3 Multicast Source Registration This document 966 TBD7 Multicast Receiver Information This document 967 TBD11 Tree Forwarding State Synchronization This document 968 TBD13 Multicast Receiver Statistics This document 970 IANA is requested to allocate the following Object-Type Value of CCI 971 object in the "PCEP Objects" sub-registry under the "Path Computation 972 Element Protocol (PCEP) Numbers" registry: 974 7.4. New TLVs 976 IANA is requested to allocate the following TLVs: 978 Type Description Reference 979 ------------------ ------------------------------- --------------- 980 TBD4 Multicast Source Address This document 981 TBD5 mLDP FEC This document 982 TBD6 VPN Information This document 983 TBD8 BFR Information This document 984 TBD9 Tree Label This document 985 TBD10 VPN Forwarding Identifier TLV This document 986 TBD12 BIER Attribute This document 988 8. Acknowledgements 990 The author thanks ... for their review and comments. 992 9. References 994 9.1. Normative References 996 [I-D.ietf-pce-sr-p2mp-policy] 997 Bidgoli, H., Voyer, D., Rajarathinam, S., Hemmati, E., 998 Saad, T., and S. Sivabalan, "PCEP extensions for p2mp sr 999 policy", draft-ietf-pce-sr-p2mp-policy-00 (work in 1000 progress), December 2021. 1002 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1003 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1004 . 1006 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 1007 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 1008 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 1009 Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, 1010 June 1998, . 1012 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1013 Element (PCE)-Based Architecture", RFC 4655, 1014 DOI 10.17487/RFC4655, August 2006, 1015 . 1017 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1018 Yasukawa, Ed., "Extensions to Resource Reservation 1019 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1020 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1021 DOI 10.17487/RFC4875, May 2007, 1022 . 1024 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1025 "Bidirectional Protocol Independent Multicast (BIDIR- 1026 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 1027 . 1029 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1030 Thomas, "Label Distribution Protocol Extensions for Point- 1031 to-Multipoint and Multipoint-to-Multipoint Label Switched 1032 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1033 . 1035 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1036 Encodings and Procedures for Multicast in MPLS/BGP IP 1037 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1038 . 1040 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1041 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1042 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1043 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1044 2016, . 1046 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1047 Computation Element Communication Protocol (PCEP) 1048 Extensions for Stateful PCE", RFC 8231, 1049 DOI 10.17487/RFC8231, September 2017, 1050 . 1052 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1053 and D. Dhody, "Optimizations of Label Switched Path State 1054 Synchronization Procedures for a Stateful PCE", RFC 8232, 1055 DOI 10.17487/RFC8232, September 2017, 1056 . 1058 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1059 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1060 Explicit Replication (BIER)", RFC 8279, 1061 DOI 10.17487/RFC8279, November 2017, 1062 . 1064 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1065 Computation Element Communication Protocol (PCEP) 1066 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1067 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1068 . 1070 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1071 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1072 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1073 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1074 2018, . 1076 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1077 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1078 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1079 July 2018, . 1081 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 1082 Computation Element Communication Protocol (PCEP) 1083 Procedures and Extensions for Using the PCE as a Central 1084 Controller (PCECC) of LSPs", RFC 9050, 1085 DOI 10.17487/RFC9050, July 2021, 1086 . 1088 9.2. Informative References 1090 [I-D.chen-pce-pcep-extension-pce-controller-bier] 1091 Chen, R., Xu, B., Chen, H., and A. Wang, "PCEP Procedures 1092 and Protocol Extensions for Using PCE as a Central 1093 Controller (PCECC) of BIER", draft-chen-pce-pcep- 1094 extension-pce-controller-bier-03 (work in progress), March 1095 2022. 1097 [I-D.dhody-pce-pcep-extension-pce-controller-p2mp] 1098 Li, Z., Peng, S., Geng, X., and M. S. Negi, "Path 1099 Computation Element Communication Protocol (PCEP) 1100 Procedures and Extensions for Using the PCE as a Central 1101 Controller (PCECC) of point-to-multipoint (P2MP) LSPs", 1102 draft-dhody-pce-pcep-extension-pce-controller-p2mp-08 1103 (work in progress), March 2022. 1105 [I-D.ietf-bess-bgp-multicast-controller] 1106 Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, 1107 "Controller Based BGP Multicast Signaling", draft-ietf- 1108 bess-bgp-multicast-controller-07 (work in progress), July 1109 2021. 1111 [I-D.ietf-pim-sr-p2mp-policy] 1112 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 1113 and Z. Zhang, "Segment Routing Point-to-Multipoint 1114 Policy", draft-ietf-pim-sr-p2mp-policy-04 (work in 1115 progress), March 2022. 1117 [I-D.ietf-spring-sr-replication-segment] 1118 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 1119 and Z. Zhang, "SR Replication Segment for Multi-point 1120 Service Delivery", draft-ietf-spring-sr-replication- 1121 segment-07 (work in progress), March 2022. 1123 [I-D.zzhang-mvpn-evpn-controller] 1124 Zhang, Z., Parekh, R., Zhang, Z., and H. Bidgoli, "MVPN 1125 and EVPN BUM Signaling with Controllers", draft-zzhang- 1126 mvpn-evpn-controller-01 (work in progress), October 2021. 1128 Authors' Addresses 1130 Huanan Li 1131 China Telecom 1133 Email: lihn6@foxmail.com 1135 Aijun Wang 1136 China Telecom 1138 Email: wangaj3@chinatelecom.cn 1140 Zhaohui Zhang 1141 Juniper Networks 1143 Email: zzhang@juniper.net 1145 Huaimo Chen 1146 Futurewei 1148 Email: Huaimo.chen@futurewei.com 1150 Ran Chen 1151 ZTE Corporation 1153 Email: chen.ran@zte.com.cn