idnits 2.17.1 draft-ietf-pce-stateful-pce-p2mp-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2016) is 2736 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: 'TBD' is mentioned on line 916, but not defined == Missing Reference: 'This I-D' is mentioned on line 1115, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-16 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-06 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-01) exists of draft-palleti-pce-rfc6006bis-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-07 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-10 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group U. Palle 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 2, 2017 Y. Tanaka 6 NTT Communications 7 Z. Ali 8 Cisco Systems 9 V. Beeram 10 Juniper Networks 11 October 29, 2016 13 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 14 usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 15 draft-ietf-pce-stateful-pce-p2mp-01 17 Abstract 19 The Path Computation Element (PCE) has been identified as an 20 appropriate technology for the determination of the paths of point- 21 to-multipoint (P2MP) TE LSPs. This document provides extensions 22 required for Path Computation Element communication Protocol (PCEP) 23 so as to enable the usage of a stateful PCE capability in supporting 24 P2MP TE LSPs. 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 http://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 May 2, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 (http://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 64 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 67 5. Architectural Overview of Protocol Extensions . . . . . . . . 6 68 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 69 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 70 5.3. IGP Extensions for Stateful PCE P2MP Capabilities 71 Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 72 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 73 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 74 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 75 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8 76 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 77 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 78 5.6.3.1. P2MP TE LSP Instantiation . . . . . . . . . . . . 9 79 5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9 80 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 9 81 5.6.3.4. P2MP TE LSP Delegation and Cleanup . . . . . . . 10 82 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10 83 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 10 84 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 12 85 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 13 86 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 14 87 6.5. The PCInitiate message . . . . . . . . . . . . . . . . . 15 88 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.6.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 17 90 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 91 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 18 92 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 18 93 7.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 19 94 7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 21 95 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 22 96 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 22 97 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23 98 8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 23 99 9. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 23 100 10. Manageability Considerations . . . . . . . . . . . . . . . . 24 101 10.1. Control of Function and Policy . . . . . . . . . . . . . 24 102 10.2. Information and Data Models . . . . . . . . . . . . . . 24 103 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 104 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 25 105 10.5. Requirements On Other Protocols . . . . . . . . . . . . 25 106 10.6. Impact On Network Operations . . . . . . . . . . . . . . 25 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 108 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 25 109 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26 110 11.3. Extension of LSP Object . . . . . . . . . . . . . . . . 26 111 11.4. Extension of PCEP-Error Object . . . . . . . . . . . . . 26 112 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 113 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 114 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 117 14.2. Informative References . . . . . . . . . . . . . . . . . 29 118 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 31 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 As per [RFC4655], the Path Computation Element (PCE) is an entity 124 that is capable of computing a network path or route based on a 125 network graph, and applying computational constraints. A Path 126 Computation Client (PCC) may make requests to a PCE for paths to be 127 computed. 129 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 130 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 131 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 132 PCE has been identified as a suitable application for the computation 133 of paths for P2MP TE LSPs ([RFC5671]). 135 The PCEP is designed as a communication protocol between PCCs and 136 PCEs for point-to-point (P2P) path computations and is defined in 137 [RFC5440]. The extensions of PCEP to request path computation for 138 P2MP TE LSPs are described in [I-D.palleti-pce-rfc6006bis]. 140 Stateful PCEs are shown to be helpful in many application scenarios, 141 in both MPLS and GMPLS networks, as illustrated in 142 [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to 143 P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the 144 fundamental extensions needed for stateful PCE to support general 145 functionality for P2P TE LSP. [I-D.ietf-pce-pce-initiated-lsp] 146 provides the an extensions needed for stateful PCE-initiated P2P TE 147 LSP. Complementarily, this document focuses on the extensions that 148 are necessary in order for the deployment of stateful PCEs to support 149 P2MP TE LSPs. This document describes the setup, maintenance and 150 teardown of PCE-initiated P2MP LSPs under the stateful PCE model. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Terminology 160 Terminology used in this document is same as terminology used in 161 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and 162 [I-D.palleti-pce-rfc6006bis]. 164 3. Supporting P2MP TE LSP for Stateful PCE 166 3.1. Motivation 168 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 169 demonstrating scenarios that benefit from the deployment of a 170 stateful PCE including optimization, recovery, etc which are equally 171 applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the 172 extensions to PCEP for P2P TE LSPs. Complementarily, this document 173 focuses on the extensions that are necessary in order for the 174 deployment of stateful PCEs to support P2MP TE LSPs. 176 In addition to that, the stateful nature of a PCE simplifies the 177 information conveyed in PCEP messages since it is possible to refer 178 to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this 179 is an added advantage, where the size of message is much larger. 180 Incase of stateless PCE, a modification of P2MP tree requires 181 encoding of all leaves along with the paths in PCReq message, but 182 using a stateful PCE with P2MP capability, the PCEP message can be 183 used to convey only the modifications (the other information can be 184 retrieved from the P2MP LSP identifier in the LSP database (LSPDB)). 186 In environments where the P2MP TE LSP placement needs to change in 187 response to application demands, it is useful to support dynamic 188 creation and tear down of P2MP TE LSPs. The ability for a PCE to 189 trigger the creation of P2MP TE LSPs on demand can be seamlessly 190 integrated into a controller-based network architecture, where 191 intelligence in the controller can determine when and where to set up 192 paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further 193 describes the motivation behind the PCE-Initiation capability, which 194 are equally applicable for P2MP TE LSPs. 196 3.2. Objectives 198 The objectives for the protocol extensions to support P2MP TE LSP for 199 stateful PCE are same as the objectives described in section 3.2 of 200 [I-D.ietf-pce-stateful-pce]. 202 4. Functions to Support P2MP TE LSPs for Stateful PCEs 204 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 205 stateful PCE. It also specifies that a function can be initiated 206 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 207 (E-C). 209 This document extends these functions to support P2MP TE LSPs. 211 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 212 announce during PCEP session establishment that they support PCEP 213 Stateful PCE extensions for P2MP using mechanisms defined in 214 Section 5.2. 216 LSP State Synchronization (C-E): after the session between the PCC 217 and a stateful PCE with P2MP capability is initialized, the PCE 218 must learn the state of a PCC's P2MP TE LSPs before it can perform 219 path computations or update LSP attributes in a PCC. 221 LSP Update Request (E-C): a stateful PCE with P2MP capability 222 requests modification of attributes on a PCC's P2MP TE LSP. 224 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 225 whenever the state of a P2MP TE LSP changes. 227 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 228 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 229 the authoritative source of the LSP's attributes as long as the 230 delegation is in effect (See Section 5.7 of 231 [I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation 232 or the PCE may give up the delegation at any time. 234 PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate 235 Message to a PCC to instantiate or delete a P2MP TE LSP. 237 5. Architectural Overview of Protocol Extensions 239 5.1. Extension of PCEP Messages 241 New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to 242 support stateful PCE for P2P TE LSPs. In this document these 243 messages are extended to support P2MP TE LSPs. 245 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 246 in a PCRpt message can contain actual P2MP TE LSP path attributes, 247 LSP status, etc. An LSP State Report carried on a PCRpt message 248 is also used in delegation or revocation of control of a P2MP TE 249 LSP to/from a PCE. The extension of PCRpt message is described in 250 Section 6.1. 252 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 253 Request in a PCUpd message MUST contain all LSP parameters that a 254 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 255 carried on a PCUpd message is also used to return LSP delegations 256 if at any point PCE no longer desires control of a P2MP TE LSP. 257 The PCUpd message is described in Section 6.2. 259 A new PCEP message is defined in [I-D.ietf-pce-pce-initiated-lsp] to 260 support stateful PCE instantiation of P2P TE LSPs. In this document 261 this message is extended to support P2MP TE LSPs. 263 Path Computation LSP Initiate Message (PCInitiate): is a PCEP 264 message sent by a PCE to a PCC to trigger P2MP TE LSP 265 instantiation or deletion. The PCInitiate message is described in 266 Section 6.5. 268 5.2. Capability Advertisement 270 During PCEP Initialization Phase, as per Section 7.1.1 of 271 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 272 capability via Stateful PCE Capability TLV in open message. Two new 273 flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 274 [I-D.ietf-pce-stateful-pce] and updated in 275 [I-D.ietf-pce-pce-initiated-lsp] and 276 [I-D.ietf-pce-stateful-sync-optimizations]. 278 Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), 279 and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: 281 N (P2MP-CAPABILITY - 1 bit): if set to 1 by a PCC, the N Flag 282 indicates that the PCC is willing to send P2MP LSP State Reports 283 whenever P2MP LSP parameters or operational status changes.; if 284 set to 1 by a PCE, the N Flag indicates that the PCE is interested 285 in receiving LSP State Reports whenever LSP parameters or 286 operational status changes. The P2MP-CAPABILITY Flag must be 287 advertised by both a PCC and a PCE for PCRpt messages P2MP 288 extension to be allowed on a PCEP session. 290 M (P2MP-LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the M 291 Flag indicates that the PCC allows modification of P2MP LSP 292 parameters; if set to 1 by a PCE, the M Flag indicates that the 293 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 294 UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE 295 for PCUpd messages P2MP extension to be allowed on a PCEP session. 297 P (P2MP-LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, 298 the P Flag indicates that the PCC allows instantiation of an P2MP 299 LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the 300 PCE supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION- 301 CAPABILITY flag must be set by both PCC and PCE in order to 302 support PCE-initiated P2MP LSP instantiation. 304 A PCEP speaker should continue to advertise the basic P2MP capability 305 via mechanisms as described in [I-D.palleti-pce-rfc6006bis]. 307 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 309 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 310 are either LSRs or servers also participating in the IGP, an 311 effective mechanism for PCE discovery within an IGP routing domain 312 consists of utilizing IGP advertisements. Extensions for the 313 advertisement of PCE Discovery Information are defined for OSPF and 314 for IS-IS in [RFC5088] and [RFC5089] respectively. 316 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 317 TLV used to advertise PCE capabilities. It MAY be present within the 318 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 319 provide the description and processing rules for this sub-TLV when 320 carried within OSPF and IS-IS, respectively. 322 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 323 reference: 325 Type: 5 327 Length: Multiple of 4. 329 Value: This contains an array of units of 32 bit flags with the most 330 significant bit as 0. Each bit represents one PCE capability. 332 PCE capability bits are defined in [RFC5088]. This document defines 333 new capability bits for the stateful PCE with P2MP as follows: 335 Bit Capability 336 TBD Active Stateful PCE with P2MP 337 TBD Passive Stateful PCE with P2MP 338 TBD PCE-Initiation with P2MP 340 Note that while active, passive or initiation stateful PCE with P2MP 341 capabilities may be advertised during discovery, PCEP Speakers that 342 wish to use stateful PCEP MUST advertise stateful PCEP capabilities 343 during PCEP session setup, as specified in the current document. A 344 PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP 345 session setup even if it did not receive any IGP PCE capability 346 advertisements. 348 5.4. State Synchronization 350 State Synchronization operations described in Section 5.6 of 351 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 353 5.5. LSP Delegation 355 LSP delegation operations described in Section 5.7 of 356 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 358 5.6. LSP Operations 360 5.6.1. Passive Stateful PCE 362 LSP operations for passive stateful PCE described in Section 5.8.1 of 363 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 365 The Path Computation Request and Response message format for P2MP TE 366 LSPs is described in Section 3.4 and Section 3.5 of 367 [I-D.palleti-pce-rfc6006bis] respectively. 369 The Request and Response message for P2MP TE LSPs are extended to 370 support encoding of LSP object, so that it is possible to refer to a 371 LSP with a unique identifier and simplify the PCEP message exchange. 372 For example, incase of modification of one leaf in a P2MP tree, there 373 should be no need to carry the full P2MP tree in PCReq message. 375 The extension for the Request and Response message for passive 376 stateful operations on P2MP TE LSPs are described in Section 6.3 and 377 Section 6.4. The extension for the Path Computation LSP State Report 378 (PCRpt) message is described in Section 6.1. 380 5.6.2. Active Stateful PCE 382 LSP operations for active stateful PCE described in Section 5.8.2 of 383 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 385 The extension for the Path Computation LSP Update (PCUpd) message for 386 active stateful operations on P2MP TE LSPs are described in 387 Section 6.2. 389 5.6.3. PCE-Initiated LSP 391 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 392 a Path Computation LSP Initiate Request (PCInitiate) message to the 393 PCC to suggest instantiation or deletion of a P2P TE LSP. This 394 document extends the PCInitiate message to support P2MP TE LSP (see 395 details in Section 6.5). 397 P2MP TE LSP suggested instantiation and deletion operations are same 398 as P2P LSP as described in section 5.3 and 5.4 of 399 [I-D.ietf-pce-pce-initiated-lsp]. 401 5.6.3.1. P2MP TE LSP Instantiation 403 The Instantiation operation of P2MP TE LSP is same as defined in 404 section 5.3 of [I-D.ietf-pce-pce-initiated-lsp] including handling of 405 PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error 406 codes remains unchanged. The N bit MUST be set in LSP object in 407 PCInitiate message by PCE to specify the instantiation is for P2MP TE 408 LSP. 410 Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV MUST 411 NOT be included in the LSP object in PCIntiitate message as it SHOULD 412 be generated by PCC and carried in PCRpt message. 414 5.6.3.2. P2MP TE LSP Deletion 416 The deletion operation of P2MP TE LSP is same as defined in section 417 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 418 Message with an LSP object carrying the PLSP-ID of the LSP to be 419 removed and an SRP object with the R flag set (LSP-REMOVE as per 420 section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of 421 processing and error codes remains unchanged. 423 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 425 Adding of new leaves and Pruning of old Leaves for the PCE initiated 426 P2MP TE LSP MUST be carried in PCUpd message and SHOULD refer 427 Section 6.2 for P2MP TE LSP extensions. As defined in 429 [I-D.palleti-pce-rfc6006bis], leaf type = 1 for adding of new leaves, 430 leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are 431 used in PCUpd message. 433 PCC MAY use the Incremental State Update mechanims as described in 434 [RFC4875] to signal adding and pruning of leaves. 436 5.6.3.4. P2MP TE LSP Delegation and Cleanup 438 P2MP TE LSP delegation and cleanup operations are same as defined in 439 section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing 440 and error codes remains unchanged. 442 6. PCEP Message Extensions 444 6.1. The PCRpt Message 446 As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is 447 used to report the current state of a P2P TE LSP. This document 448 extends the PCRpt message in reporting the status of P2MP TE LSP. 450 The format of PCRpt message is as follows: 452 ::= 453 454 Where: 456 ::= 457 [] 459 ::= [] 460 461 462 [ 463 ] 464 466 Where: 468 ::= 469 [] 470 [] 471 472 [] 474 ::= 475 [] 476 477 [] 479 ::= (|) 480 [] 482 ::= (|) 483 [] 485 is defined in [RFC5440] and 486 extended by PCEP extensions. 487 consists of the actual computed and 488 signaled values of the and 489 objects defined in [RFC5440]. 491 The P2MP END-POINTS object defined in [I-D.palleti-pce-rfc6006bis] is 492 mandatory for specifying address of P2MP leaves grouped based on leaf 493 types. 495 o New leaves to add (leaf type = 1) 497 o Old leaves to remove (leaf type = 2) 498 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 500 o Old leaves whose path must be left unchanged (leaf type = 4) 502 When reporting the status of a P2MP TE LSP, the destinations are 503 grouped in END-POINTS object based on the operational status (O field 504 in S2LS object) and leaf type (in END-POINTS). This way the leaves 505 that share the same operational status are grouped together. For 506 reporting the status of delegated P2MP TE LSP, leaf-type = 3, where 507 as for non-delegated P2MP TE LSP, leaf-type = 4 is used. 509 For delegated P2MP TE LSP configuration changes are reported via 510 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 511 type = 1) is used where as removing of old leaves (leaf-type = 2) is 512 used. 514 Note that we preserve compatibility with the 515 [I-D.ietf-pce-stateful-pce] definition of . At least 516 one instance of MUST be present in this message for P2MP 517 LSP. 519 During state synchronization, the PCRpt message must report the 520 status of the full P2MP TE LSP. 522 The S2LS object MUST be carried in PCRpt message along with END- 523 POINTS object when N bit is set in LSP object for P2MP TE LSP. If 524 the S2LS object is missing, the receiving PCE MUST send a PCErr 525 message with Error-type=6 (Mandatory Object missing) and Error- 526 value=TBD (S2LS object missing). If the END-POINTS object is 527 missing, the receiving PCE MUST send a PCErr message with Error- 528 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 529 object missing) (defined in [RFC5440]. 531 6.2. The PCUpd Message 533 As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is 534 used to update P2P TE LSP attributes. This document extends the 535 PCUpd message in updating the attributes of P2MP TE LSP. 537 The format of a PCUpd message is as follows: 539 ::= 540 542 Where: 544 ::= 545 [] 547 ::= 548 549 550 552 Where: 554 ::= 555 [] 556 557 [] 559 ::= (|) 560 [] 562 is defined in [RFC5440] and 563 extended by PCEP extensions. 565 Note that we preserve compatibility with the 566 [I-D.ietf-pce-stateful-pce] definition of . 568 The PCC MAY use the make-before-break or sub-group-based procedures 569 described in [RFC4875] based on a local policy decision. 571 The END-POINTS object MUST be carried in PCUpd message when N bit is 572 set in LSP object for P2MP TE LSP. If the END-POINTS object is 573 missing, the receiving PCC MUST send a PCErr message with Error- 574 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 575 object missing) (defined in [RFC5440]. 577 6.3. The PCReq Message 579 As per Section 3.4 of [I-D.palleti-pce-rfc6006bis], PCReq message is 580 used for a P2MP path computation request. This document extends the 581 PCReq message such that a PCC MAY include the LSP object in the PCReq 582 message if the stateful PCE P2MP capability has been negotiated on a 583 PCEP session between the PCC and a PCE. 585 The format of PCReq message is as follows: 587 ::= 588 [] 589 591 where: 593 ::= 594 [] 595 [] 596 [] 598 ::=[] 600 ::= 601 602 [] 603 [] 604 [] 605 [] 606 [] 607 [|] 608 [] 610 where: 612 ::= 613 [[]] 614 [] 615 ::=(|)[] 616 ::=[] 618 6.4. The PCRep Message 620 As per Section 3.5 of [I-D.palleti-pce-rfc6006bis], PCRep message is 621 used for a P2MP path computation reply. This document extends the 622 PCRep message such that a PCE MAY include the LSP object in the PCRep 623 message if the stateful PCE P2MP capability has been negotiated on a 624 PCEP session between the PCC and a PCE. 626 The format of PCRep message is as follows: 628 ::= 629 631 where: 633 ::=[] 635 ::= 636 [] 637 [] 638 [] 639 [] 640 [] 642 ::= 643 [][] 645 ::= (|) [] 647 where: 649 ::=[] 650 [] 651 [] 652 [] 653 [] 655 6.5. The PCInitiate message 657 As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE 658 sends a PCInitiate message to a PCC to recommend instantiation of a 659 P2P TE LSP, this document extends the format of PCInitiate message 660 for the creation of P2MP TE LSPs but the creation and deletion 661 operations of P2MP TE LSP are same to the P2P TE LSP. 663 The format of PCInitiate message is as follows: 665 ::= 666 667 Where: 669 ::= 670 [] 672 ::= 673 (|) 675 ::= 676 677 678 [] 680 ::= 681 683 Where: 685 ::= 686 [] 687 688 [] 690 ::= (|) 691 [] 693 is defined in [RFC5440] and extended 694 by PCEP extensions. 696 The PCInitiate message with an LSP object with N bit (P2MP) set is 697 used to convey operation on a P2MP TE LSP. The SRP object is used to 698 correlate between initiation requests sent by the PCE and the error 699 reports and state reports sent by the PCC as described in 700 [I-D.ietf-pce-stateful-pce]. 702 The END-POINTS object MUST be carried in PCInitiate message when N 703 bit is set in LSP object for P2MP TE LSP. If the END-POINTS object 704 is missing, the receiving PCC MUST send a PCErr message with Error- 705 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 706 object missing) (defined in [RFC5440]. 708 6.6. Example 710 6.6.1. P2MP TE LSP Update Request 712 LSP Update Request message is sent by an active stateful PCE to 713 update the P2MP TE LSP parameters or attributes. An example of a 714 PCUpd message for P2MP TE LSP is described below: 716 Common Header 717 SRP 718 LSP with P2MP flag set 719 END-POINTS for leaf type 3 720 ERO list 722 In this example, a stateful PCE request updation of path taken by 723 some of the leaves in a P2MP tree. The update request uses the END- 724 POINT type 3 (modified/reoptimized). The ERO list represents the 725 S2LS path after modification. The update message does not need to 726 encode the full P2MP tree in this case. 728 6.6.2. P2MP TE LSP Report 730 LSP State Report message is sent by a PCC to report or delegate the 731 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 732 LSP is described below to add new leaves to an existing P2MP TE LSP: 734 Common Header 735 LSP with P2MP flag set 736 END-POINTS for leaf type 1 737 S2LS (O=DOWN) 738 ERO list (empty) 740 An example of a PCRpt message for P2MP TE LSP is described below to 741 prune leaves from an existing P2MP TE LSP: 743 Common Header 744 LSP with P2MP flag set 745 END-POINTS for leaf type 2 746 S2LS (O=UP) 747 ERO list 749 An example of a PCRpt message for a delegated P2MP TE LSP is 750 described below to report status of leaves in an existing P2MP TE 751 LSP: 753 Common Header 754 LSP with P2MP flag set 755 END-POINTS for leaf type 3 756 S2LS (O=UP) 757 ERO list 758 END-POINTS for leaf type 3 759 S2LS (O=DOWN) 760 ERO list 762 An example of a PCRpt message for a non-delegated P2MP TE LSP is 763 described below to report status of leaves: 765 Common Header 766 LSP with P2MP flag set 767 END-POINTS for leaf type 4 768 S2LS (O=ACTIVE) 769 ERO list 770 END-POINTS for leaf type 4 771 S2LS (O=DOWN) 772 ERO list 774 7. PCEP Object Extensions 776 The PCEP TLV defined in this document is compliant with the PCEP TLV 777 format defined in [RFC5440]. 779 7.1. Extension of LSP Object 781 LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. 782 It specifies PLSP-ID to uniquely identify an LSP that is constant for 783 the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID 784 identify a P2MP TE LSP uniquely. This document adds the following 785 flags to the LSP Object: 787 N (P2MP bit): If the bit is set to 1, it specifies the message is 788 for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a 789 P2MP TE LSP. 791 F (Fragmentation bit): If the bit is set to 1, it specifies the 792 message is fragmented. 794 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 795 present in LSP object. 797 7.2. P2MP-LSP-IDENTIFIER TLV 799 The P2MP LSP Identifier TLV MUST be included in the LSP object in 800 PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is 801 missing, the PCE will generate an error with error-type 6 (mandatory 802 object missing) and error-value TBD (P2MP-LSP-IDENTIFIERS TLV 803 missing) and close the PCEP session. 805 The P2MP LSP Identifier TLV MAY be included in the LSP object in 806 PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value 807 of all zeros for this TLV is used to refer to all paths pertaining to 808 a particular PLSP-ID. 810 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 811 IPv6. 813 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 814 following figure: 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Type=[TBD] | Length=16 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | IPv4 Tunnel Sender Address | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | LSP ID | Tunnel ID | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Extended Tunnel ID | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | P2MP ID | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format 832 The type (16-bit) of the TLV is [TBD] to be assigned by IANA. The 833 length (16-bit) has a fixed value of 16 octets. The value contains 834 the following fields: 836 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 837 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 838 Sender Template Object. 840 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 841 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 842 Object. 844 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 845 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 847 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 848 identifier defined in [RFC3209], Section 4.6.1.1 for the 849 LSP_TUNNEL_IPv4 Session Object. 851 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 852 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 853 Object. 855 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 856 following figure: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Type=[TBD] | Length=40 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | | 864 + + 865 | IPv6 tunnel sender address | 866 + (16 octets) + 867 | | 868 + + 869 | | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | LSP ID | Tunnel ID | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 + + 875 | Extended Tunnel ID | 876 + (16 octets) + 877 | | 878 + + 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | P2MP ID | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format 886 The type of the TLV is [TBD] to be assigned by IANA. The length 887 (16-bit) has a fixed length of 40 octets. The value contains the 888 following fields: 890 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 891 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 892 Sender Template Object. 894 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 895 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 896 Object. 898 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 899 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 901 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 902 identifier defined in [RFC3209], Section 4.6.1.2 for the 903 LSP_TUNNEL_IPv6 Session Object. 905 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 907 Tunnel ID remains constant over the life time of a tunnel. 909 7.3. S2LS Object 911 The S2LS (Source-to-Leaves) Object is used to report RSVP-TE state of 912 one or more destinations (leaves) encoded within the END-POINTS 913 object for a P2MP TE LSP. It MUST be carried in PCRpt message along 914 with END-POINTS object when N bit is set in LSP object. 916 S2LS Object-Class is [TBD]. 918 S2LS Object-Types is 1. 920 The format of the S2LS object is shown in the following figure: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Flags | O| 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | | 928 // Optional TLVs // 929 | | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Figure 8: S2LS object format 934 Flags(32 bits): 936 O(Operational - 3 bits) the O Field represents the operational 937 status of the group of destinations. The values are as per 938 Operational field in LSP object defined in Section 7.3 of 939 [I-D.ietf-pce-stateful-pce]. 941 When N bit is set in LSP object then the O field in LSP object 942 represents the operational status of the full P2MP TE LSP and the O 943 field in S2LS object represents the operational status of a group of 944 destinations encoded within the END-POINTS object. 946 Future documents MAY define optional TLVs that MAY be included in the 947 S2LS Object. 949 8. Message Fragmentation 951 The total PCEP message length, including the common header, is 16 952 bytes. In certain scenarios the P2MP report and update request may 953 not fit into a single PCEP message (e.g. initial report or update). 954 The F-bit is used in the LSP object to signal that the initial 955 report, update, or initiate message was too large to fit into a 956 single message and will be fragmented into multiple messages. In 957 order to identify the single report or update each message will use 958 the same PLSP-ID. In order to identify that a series of PCInitiate 959 messages represents a single Initiate, each message will use the same 960 PLSP-ID (in this case 0) and SRP-ID-number. 962 Fragmentation procedure described below for report or update message 963 is similar to [I-D.palleti-pce-rfc6006bis] which describes request 964 and response message fragmentation. 966 8.1. Report Fragmentation Procedure 968 If the initial report is too large to fit into a single report 969 message, the PCC will split the report over multiple messages. Each 970 message sent to the PCE, except the last one, will have the F-bit set 971 in the LSP object to signify that the report has been fragmented into 972 multiple messages. In order to identify that a series of report 973 messages represents a single report, each message will use the same 974 PLSP-ID. 976 To indicate P2MP message fragmentation errors associated with a P2MP 977 Report, a Error-Type (18) and a new error-value TBD is used if a PCE 978 has not received the last piece of the fragmented message, it should 979 send an error message to the PCC to signal that it has received an 980 incomplete message (i.e., "Fragmented Report failure"). 982 8.2. Update Fragmentation Procedure 984 Once the PCE computes and updates a path for some or all leaves in a 985 P2MP TE LSP, an update message is sent to the PCC. If the update is 986 too large to fit into a single update message, the PCE will split the 987 update over multiple messages. Each update message sent by the PCE, 988 except the last one, will have the F-bit set in the LSP object to 989 signify that the update has been fragmented into multiple messages. 990 In order to identify that a series of update messages represents a 991 single update, each message will use the same PLSP-ID and SRP-ID- 992 number. 994 To indicate P2MP message fragmentation errors associated with a P2MP 995 Update request, a Error-Type (18) and a new error-value TBD is used 996 if a PCC has not received the last piece of the fragmented message, 997 it should send an error message to the PCE to signal that it has 998 received an incomplete message (i.e., "Fragmented Update failure"). 1000 8.3. PCIntiate Fragmentation Procedure 1002 Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate 1003 message is sent to the PCC. If the PCInitiate is too large to fit 1004 into a single PCInitiate message, the PCE will split the PCInitiate 1005 over multiple messages. Each PCInitiate message sent by the PCE, 1006 except the last one, will have the F-bit set in the LSP object to 1007 signify that the PCInitiate has been fragmented into multiple 1008 messages. In order to identify that a series of PCInitiate messages 1009 represents a single Initiate, each message will use the same PLSP-ID 1010 (in this case 0) and SRP-ID-number. 1012 To indicate P2MP message fragmentation errors associated with a P2MP 1013 PCInitiate, a Error-Type (18) and a new error-value TBD is used if a 1014 PCC has not received the last piece of the fragmented message, it 1015 should send an error message to the PCE to signal that it has 1016 received an incomplete message (i.e., "Fragmented Instantiation 1017 failure"). 1019 9. Non-Support of P2MP TE LSPs for Stateful PCE 1021 The PCEP protocol extensions described in this document for stateful 1022 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 1023 its stateful capability with P2MP as per Section 5.2. If the PCEP 1024 Speaker on the PCC supports the extensions of this draft (understands 1025 the P2MP flag in the LSP object) but did not advertise this 1026 capability, then upon receipt of PCUpd message from the PCE, it 1027 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1028 error-value TBD (Attempted LSP Update Request for P2MP if active 1029 stateful PCE capability for P2MP was not advertised). If the PCEP 1030 Speaker on the PCE supports the extensions of this draft (understands 1031 the P2MP flag in the LSP object) but did not advertise this 1032 capability, then upon receipt of a PCRpt message from the PCC, it 1033 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 1034 error-value TBD (Attempted LSP State Report for P2MP if stateful PCE 1035 capability for P2MP was not advertised) and it will terminate the 1036 PCEP session. 1038 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 1039 does not understand the P2MP flag in the LSP object, and therefore 1040 the PCEP extensions described in this document, then the Stateful PCE 1041 would act as per [I-D.ietf-pce-stateful-pce]. 1043 The PCEP protocol extensions described in this document for PCC or 1044 PCE with instantiation capability for P2MP TE LSPs MUST NOT be used 1045 if PCC or PCE has not advertised its stateful capability with 1046 Instantiation and P2MP capability as per Section 5.2. If the PCEP 1047 Speaker on the PCC supports the extensions of this draft (understands 1048 the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but 1049 did not advertise this capability, then upon receipt of PCInitiate 1050 message from the PCE, it SHOULD generate a PCErr with error-type 19 1051 (Invalid Operation), error-value TBD (Attempted LSP Instantiation 1052 Request for P2MP if stateful PCE instantiation capability for P2MP 1053 was not advertised). 1055 10. Manageability Considerations 1057 All manageability requirements and considerations listed in 1058 [RFC5440], [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], 1059 and [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol 1060 extensions defined in this document. In addition, requirements and 1061 considerations listed in this section apply. 1063 10.1. Control of Function and Policy 1065 A PCE or PCC implementation MUST allow configuring the stateful PCEP 1066 capability, the LSP Update capability, and the LSP Initiation 1067 capability for P2MP LSPs. 1069 10.2. Information and Data Models 1071 The PCEP MIB module SHOULD be extended to include advertised P2MP 1072 stateful capabilities, P2MP synchronization status, and P2MP 1073 delegation status etc. 1075 10.3. Liveness Detection and Monitoring 1077 Mechanisms defined in this document do not imply any new liveness 1078 detection and monitoring requirements in addition to those already 1079 listed in [RFC5440]. 1081 10.4. Verify Correct Operations 1083 Mechanisms defined in this document do not imply any new operation 1084 verification requirements in addition to those already listed in 1085 [RFC5440], [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], 1086 and [I-D.ietf-pce-pce-initiated-lsp]. 1088 10.5. Requirements On Other Protocols 1090 Mechanisms defined in this document do not imply any new requirements 1091 on other protocols. 1093 10.6. Impact On Network Operations 1095 Mechanisms defined in this document do not have any impact on network 1096 operations in addition to those already listed in [RFC5440], 1097 [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], and 1098 [I-D.ietf-pce-pce-initiated-lsp]. 1100 11. IANA Considerations 1102 This document requests IANA actions to allocate code points for the 1103 protocol elements defined in this document. 1105 11.1. PCE Capabilities in IGP Advertisements 1107 IANA is requested to allocate new bits in "PCE Capability Flags" 1108 registry for stateful PCE with P2MP capability as follows: 1110 Bit Meaning Reference 1111 TBD Active Stateful [This I-D] 1112 PCE with P2MP 1113 TBD Passive Stateful [This I-D] 1114 PCE with P2MP 1115 TBD Stateful PCE [This I-D] 1116 Initiation with P2MP 1118 11.2. STATEFUL-PCE-CAPABILITY TLV 1120 The following values are defined in this document for the Flags field 1121 in the STATEFUL-PCE-CAPABILITY-TLV (defined in 1122 [I-D.ietf-pce-stateful-pce]) in the OPEN object: 1124 Bit Description Reference 1126 TBD P2MP-CAPABILITY This.I-D 1127 TBD P2MP-LSP-UPDATE- This.I-D 1128 CAPABILITY 1129 TBD P2MP-LSP- This.I-D 1130 INSTANTIATION- 1131 CAPABILITY 1133 11.3. Extension of LSP Object 1135 This document requests that a registry is created to manage the Flags 1136 field of the LSP object (defined in [I-D.ietf-pce-stateful-pce]). 1137 New values are to be assigned by Standards Action [RFC5226]. Each 1138 bit should be tracked with the following qualities: 1140 o Bit number (counting from bit 0 as the most significant bit) 1142 o Capability description 1144 o Defining RFC 1146 The following values are defined in this document: 1148 Bit Description Reference 1150 TBD P2MP This.I-D 1151 TBD Fragmentation This.I-D 1153 11.4. Extension of PCEP-Error Object 1155 A new 19 (recommended values) defined in section 8.5 of 1156 [I-D.ietf-pce-stateful-pce]. The error-type 6 is defined in 1157 [RFC5440] and error-type 18 in [I-D.palleti-pce-rfc6006bis]. This 1158 document extend the new Error-Values for those error types for the 1159 following error conditions: 1161 Error-Type Meaning 1162 6 Mandatory Object missing 1163 Error-value=TBD: S2LS object missing 1164 Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing 1165 18 P2MP Fragmentation Error 1166 Error-value= TBD. Fragmented Report 1167 failure 1168 Error-value= TBD. Fragmented Update 1169 failure 1170 Error-value= TBD. Fragmented Instantiation 1171 failure 1172 19 Invalid Operation 1173 Error-value= TBD. Attempted LSP State Report 1174 for P2MP if stateful PCE capability 1175 for P2MP was not advertised 1176 Error-value= TBD. Attempted LSP Update Request 1177 for P2MP if active stateful PCE capability 1178 for P2MP was not advertised 1179 Error-value= TBD. Attempted LSP Instantiation 1180 Request for P2MP if stateful PCE 1181 instantiation capability for P2MP was not 1182 advertised 1184 Upon approval of this document, IANA is requested to make the 1185 assignment of a new error value for the existing "PCEP-ERROR Object 1186 Error Types and Values" registry located at 1187 http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object. 1189 11.5. PCEP TLV Type Indicators 1191 Upon approval of this document, IANA is requested to make the 1192 assignment of a new value for the existing "PCEP TLV Type Indicators" 1193 registry located at http://www.iana.org/assignments/pcep/ 1194 pcep.xhtml#pcep-tlv-type-indicators. This document defines the 1195 following new PCEP TLVs: 1197 Value Meaning Reference 1198 TBD P2MP-IPV4-LSP-IDENTIFIERS This.I-D 1199 TBD P2MP-IPV6-LSP-IDENTIFIERS This.I-D 1201 12. Security Considerations 1203 The stateful operations on P2MP TE LSP are more CPU-intensive and 1204 also utilize more link bandwidth. In the event of an unauthorized 1205 stateful P2MP operations, or a denial of service attack, the 1206 subsequent PCEP operations may be disruptive to the network. 1207 Consequently, it is important that implementations conform to the 1208 relevant security requirements of [RFC5440], 1209 [I-D.palleti-pce-rfc6006bis] and [I-D.ietf-pce-stateful-pce], and 1210 [I-D.ietf-pce-pce-initiated-lsp]. Further [I-D.ietf-pce-pceps] 1211 discusses an experimental approach to provide secure transport for 1212 PCEP. 1214 13. Acknowledgments 1216 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 1217 comments. 1219 14. References 1221 14.1. Normative References 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1229 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1230 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1231 . 1233 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1234 Zhang, "OSPF Protocol Extensions for Path Computation 1235 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1236 January 2008, . 1238 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1239 Zhang, "IS-IS Protocol Extensions for Path Computation 1240 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1241 January 2008, . 1243 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1244 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1245 DOI 10.17487/RFC5440, March 2009, 1246 . 1248 [I-D.ietf-pce-stateful-pce] 1249 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1250 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1251 pce-16 (work in progress), September 2016. 1253 [I-D.ietf-pce-stateful-sync-optimizations] 1254 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1255 and D. Dhody, "Optimizations of Label Switched Path State 1256 Synchronization Procedures for a Stateful PCE", draft- 1257 ietf-pce-stateful-sync-optimizations-06 (work in 1258 progress), October 2016. 1260 [I-D.ietf-pce-pce-initiated-lsp] 1261 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1262 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1263 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1264 progress), July 2016. 1266 [I-D.palleti-pce-rfc6006bis] 1267 Palleti, R. and D. Dhody, "Extensions to the Path 1268 Computation Element Communication Protocol (PCEP) for 1269 Point-to-Multipoint Traffic Engineering Label Switched 1270 Paths", draft-palleti-pce-rfc6006bis-00 (work in 1271 progress), October 2016. 1273 14.2. Informative References 1275 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1276 Element (PCE)-Based Architecture", RFC 4655, 1277 DOI 10.17487/RFC4655, August 2006, 1278 . 1280 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 1281 Regional Registration", RFC 4857, DOI 10.17487/RFC4857, 1282 June 2007, . 1284 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1285 Yasukawa, Ed., "Extensions to Resource Reservation 1286 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1287 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1288 DOI 10.17487/RFC4875, May 2007, 1289 . 1291 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1292 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1293 DOI 10.17487/RFC5226, May 2008, 1294 . 1296 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1297 Path Computation Element (PCE) to Point-to-Multipoint 1298 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 1299 DOI 10.17487/RFC5671, October 2009, 1300 . 1302 [I-D.ietf-pce-stateful-pce-app] 1303 Zhang, X. and I. Minei, "Applicability of a Stateful Path 1304 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 1305 app-07 (work in progress), September 2016. 1307 [I-D.ietf-pce-pceps] 1308 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1309 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 1310 progress), July 2016. 1312 Appendix A. Contributor Addresses 1314 Yuji Kamite 1315 NTT Communications Corporation 1316 Granpark Tower 1317 3-4-1 Shibaura, Minato-ku 1318 Tokyo 108-8118 1319 Japan 1321 EMail: y.kamite@ntt.com 1323 Authors' Addresses 1325 Udayasree Palle 1326 Huawei Technologies 1327 Divyashree Techno Park, Whitefield 1328 Bangalore, Karnataka 560066 1329 India 1331 EMail: udayasree.palle@huawei.com 1333 Dhruv Dhody 1334 Huawei Technologies 1335 Divyashree Techno Park, Whitefield 1336 Bangalore, Karnataka 560066 1337 India 1339 EMail: dhruv.ietf@gmail.com 1341 Yosuke Tanaka 1342 NTT Communications Corporation 1343 Granpark Tower 1344 3-4-1 Shibaura, Minato-ku 1345 Tokyo 108-8118 1346 Japan 1348 EMail: yosuke.tanaka@ntt.com 1350 Zafar Ali 1351 Cisco Systems 1353 EMail: zali@cisco.com 1354 Vishnu Pavan Beeram 1355 Juniper Networks 1357 EMail: vbeeram@juniper.net