idnits 2.17.1 draft-palle-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce-app], [I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2014) is 3745 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 358, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-01 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-07 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-disco-stateful-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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: July 29, 2014 January 25, 2014 7 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 8 usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 9 draft-palle-pce-stateful-pce-p2mp-01 11 Abstract 13 The Path Computation Element (PCE) has been identified as an 14 appropriate technology for the determination of the paths of point- 15 to-multipoint (P2MP) TE LSPs. [I-D.ietf-pce-stateful-pce-app] 16 presents several use cases, demonstrating scenarios that benefit from 17 the deployment of a stateful PCE. [I-D.ietf-pce-stateful-pce] 18 provides the fundamental PCE communication Protocol (PCEP) extensions 19 needed to support stateful PCE functions. This memo provides 20 extensions required for PCEP so as to enable the usage of a stateful 21 PCE capability in supporting point-to-multipoint (P2MP) TE LSPs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 29, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 61 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 4 64 5. Architectural Overview of Protocol Extensions . . . . . . . . 5 65 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 5 66 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 5 67 5.3. State Synchronization . . . . . . . . . . . . . . . . . . 6 68 5.4. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 6 69 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 70 5.5.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 6 71 5.5.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 6 72 6. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 6 73 6.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 6 74 6.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 7 75 7. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 8 76 7.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 8 77 7.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 9 78 7.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.3.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 10 80 7.3.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 11 81 7.4. Report and Update Message Fragmentation . . . . . . . . . 11 82 7.4.1. Report Fragmentation Procedure . . . . . . . . . . . 11 83 7.4.2. Update Fragmentation Procedure . . . . . . . . . . . 12 84 8. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. Manageability Considerations . . . . . . . . . . . . . . . . 12 87 10.1. Control of Function and Policy . . . . . . . . . . . . . 13 88 10.2. Information and Data Models . . . . . . . . . . . . . . 13 89 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 13 90 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 13 91 10.5. Requirements On Other Protocols . . . . . . . . . . . . 13 92 10.6. Impact On Network Operations . . . . . . . . . . . . . . 13 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 11.1. Extension of LSP Object . . . . . . . . . . . . . . . . 13 95 11.2. Extension of PCEP-Error Object . . . . . . . . . . . . . 14 96 11.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 14 98 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 101 13.2. Informative References . . . . . . . . . . . . . . . . . 14 103 1. Introduction 105 As per [RFC4655], the Path Computation Element (PCE) is an entity 106 that is capable of computing a network path or route based on a 107 network graph, and applying computational constraints. A Path 108 Computation Client (PCC) may make requests to a PCE for paths to be 109 computed. 111 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 112 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 113 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 114 PCE has been identified as a suitable application for the computation 115 of paths for P2MP TE LSPs ([RFC5671]). 117 The PCEP is designed as a communication protocol between PCCs and 118 PCEs for point-to-point (P2P) path computations and is defined in 119 [RFC5440]. The extensions of PCEP to request path computation for 120 P2MP TE LSPs are described in [RFC6006]. 122 Stateful PCEs are shown to be helpful in many application scenarios, 123 in both MPLS and GMPLS networks, as illustrated in 124 [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to 125 P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the 126 fundamental extensions needed for stateful PCE to support general 127 functionality for P2P TE LSP. Complementarily, this document focuses 128 on the extensions that are necessary in order for the deployment of 129 stateful PCEs to support P2MP TE LSPs. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Terminology 139 Terminology used in this document is same as terminology used in 140 [I-D.ietf-pce-stateful-pce] and [RFC6006]. 142 3. Supporting P2MP TE LSP for Stateful PCE 144 3.1. Motivation 146 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 147 demonstrating scenarios that benefit from the deployment of a 148 stateful PCE including optimization, recovery, etc. 149 [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE 150 LSPs in applying these scenarios. But these scenarios apply equally 151 to P2MP TE LSPs as well. 153 In addition to that, the stateful nature of a PCE simplifies the 154 information conveyed in PCEP messages since it is possible to refer 155 to the LSPs via PLSP-ID. For P2MP this is an added advantage, where 156 the size of message is much larger. Incase of stateless PCE, a 157 modification of P2MP tree requires encoding of all leaves along with 158 the paths in PCReq message, but using a stateful PCE with P2MP 159 capability, the PCEP message can be used to convey only the 160 modifications (the other information can be retrieved from the LSP 161 identifier). 163 3.2. Objectives 165 The objectives for the protocol extensions to support P2MP TE LSP for 166 stateful PCE are same as the objectives described in section 3.2 of 167 [I-D.ietf-pce-stateful-pce]. 169 4. Functions to Support P2MP TE LSPs for Stateful PCEs 171 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 172 stateful PCE. It also specifies that a function can be initiated 173 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 174 (E-C). 176 This document extends these functions to support P2MP TE LSPs. 178 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 179 announce during PCEP session establishment that they support PCEP 180 Stateful PCE extensions for P2MP using mechanisms defined in 181 [I-D.ietf-pce-stateful-pce] and [RFC6006]. 183 LSP State Synchronization (C-E): after the session between the PCC 184 and a stateful PCE with P2MP capability is initialized, the PCE 185 must learn the state of a PCC's P2MP TE LSPs before it can perform 186 path computations or update LSP attributes in a PCC. 188 LSP Update Request (E-C): a stateful PCE with P2MP capability 189 requests modification of attributes on a PCC's P2MP TE LSP. 191 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 192 whenever the state of a P2MP TE LSP changes. 194 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 195 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 196 the authoritative source of the LSP's attributes as long as the 197 delegation is in effect (See Section 5.5 of 198 [I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation 199 or the PCE may give up the delegation at any time. 201 [I-D.sivabalan-pce-disco-stateful] and [RFC6006] defines the IGP 202 extensions needed to support autodiscovery of stateful PCEs with P2MP 203 capability. 205 5. Architectural Overview of Protocol Extensions 207 5.1. Extension of PCEP Messages 209 New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to 210 support stateful PCE for P2P TE LSPs. In this document these 211 messages are extended to support P2MP TE LSPs. 213 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 214 in a PCRpt message can contain actual P2MP TE LSP path attributes, 215 LSP status, etc. An LSP State Report carried on a PCRpt message 216 is also used in delegation or revocation of control of a P2MP TE 217 LSP to/from a PCE. The extension of PCRpt message is described in 218 Section 7.1. 220 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 221 Request in a PCUpd message MUST contain all LSP parameters that a 222 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 223 carried on a PCUpd message is also used to return LSP delegations 224 if at any point PCE no longer desires control of a P2MP TE LSP. 225 The PCUpd message is described in Section 7.2. 227 5.2. Capability Advertisement 229 During PCEP Initialization Phase, as per Section 7.1.1 of 230 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 231 capability via Stateful PCE Capability TLV in open message and as per 232 Section 3.1 of [RFC6006], PCE advertises P2MP capability via IGP 233 discovery or a P2MP capable TLV in open message. These mechanism 234 when used together indicates a stateful PCE with P2MP capability. 236 5.3. State Synchronization 238 State Synchronization operations described in Section 5.4 of 239 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 241 5.4. LSP Delegation 243 LSP delegation operations described in Section 5.5 of 244 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 246 5.5. LSP Operations 248 5.5.1. Passive Stateful PCE 250 LSP operations for passive stateful PCE described in Section 5.6.1 of 251 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 253 The Path Computation Request and Response message format for P2MP TE 254 LSPs is as per Section 3.4 and Section 3.5 of [RFC6006] respectively. 256 [Editor's Note: The Request and Response message should support LSP 257 object, so that it is possible to refer to a LSP with a unique 258 identifier and simplify the PCEP message exchange. for example, 259 incase of modification of one leaf in a P2MP tree, there should be no 260 need to carry the full P2MP tree in PCReq message.] 262 5.5.2. Active Stateful PCE 264 LSP operations for active stateful PCE described in Section 5.6.2 of 265 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 267 6. PCEP Object Extensions 269 The PCEP TLV defined in this document is compliant with the PCEP TLV 270 format defined in [RFC5440]. 272 6.1. Extension of LSP Object 274 LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. 275 This document adds the following flags to the LSP Object: 277 N (P2MP bit): If the bit is set to 1, it specifies the message is 278 for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a 279 P2MP TE LSP. 281 F (Fragmentation bit): If the bit is set to 1, it specifies the 282 message is fragmented. 284 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 285 present in LSP object. 287 6.2. P2MP-LSP-IDENTIFIER TLV 289 The P2MP LSP Identifier TLV MUST be included in the LSP object in 290 PCRpt message for RSVP-signaled P2MP TE LSPs. If the TLV is missing, 291 the PCE will generate an error with error-type 6 (mandatory object 292 missing) and error-value TBD (12) (P2MP-LSP-IDENTIFIERS TLV missing) 293 and close the PCEP session. 295 The P2MP LSP Identifier TLV MAY be included in the LSP object in 296 PCUpd message for RSVP-signaled P2MP TE LSPs. The special value of 297 all zeros for this TLV is used to refer to all paths pertaining to a 298 particular PLSP-ID. 300 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 301 IPv6. 303 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 304 following figure: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type=[TBD] | Length=12 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | P2MP ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sub-Group Originator ID | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Reserved | Sub-Group ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 1: IPV4-P2MP-LSP-IDENTIFIER TLV format 320 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 321 The value contains the following fields: 323 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 324 Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION 325 Object. 327 Sub-Group Originator ID: contains the 32-bit 'Sub-Group Originator 328 ID' identifier defined in Section 19.2.1 of [RFC4875] for the P2MP 329 LSP Tunnel IPv4 SENDER_TEMPLATE Object. 331 Sub-Group ID: contains the 16-bit 'Sub-Group ID' identifier defined 332 in Section 19.2.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 333 SENDER_TEMPLATE Object. 335 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 336 following figure: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type=[TBD] | Length=24 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | P2MP ID | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 | | 347 | Sub-Group Originator ID | 348 | | 349 | (16 bytes) | 350 | | 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Reserved | Sub-Group ID | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 2: IPV6-P2MP-LSP-IDENTIFIER TLV format 358 The type of the TLV is [TBD] and it has a fixed length of 24 octets. 359 The value contains the following fields: 361 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 363 Sub-Group Originator ID: contains the 128-bit 'Sub-Group Originator 364 ID' defined in Section 19.2.2 of [RFC4875] for the P2MP LSP Tunnel 365 IPv6 SENDER_TEMPLATE Object. 367 Sub-Group ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 369 7. PCEP Message Extensions 371 7.1. The PCRpt Message 373 As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is 374 used to report the current state of a P2P TE LSP. This document 375 extends the PCRpt message in reporting the status of P2MP TE LSP. 377 The format of PCRpt message is as follows: 379 ::= 380 381 Where: 383 ::= 384 [] 386 ::= [] 387 388 389 390 Where: 392 ::= 393 [] 394 395 [] 397 ::= (|) 398 [] 399 [] 401 is defined in [RFC5440] and extended 402 by PCEP extensions. 404 The END-POINTS object defined in [RFC6006] is mandatory for 405 specifying address of P2MP leaves. 407 Note that we preserve compatibility with the 408 [I-D.ietf-pce-stateful-pce] definition of . At least 409 one instance of MUST be present in this message. 411 [Editor Note: suggest to add object mandatory in 412 [I-D.ietf-pce-stateful-pce] document for ]. 414 7.2. The PCUpd Message 416 As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is 417 used to update P2P TE LSP attributes. This document extends the 418 PCUpd message in updating the attributes of P2MP TE LSP. 420 The format of a PCUpd message is as follows: 422 ::= 423 425 Where: 427 ::= 428 [] 430 ::= 431 432 433 434 Where: 436 ::= 437 [] 438 439 [] 441 ::= (|) 442 [] 444 is defined in [RFC5440] and extended 445 by PCEP extensions. 447 Note that we preserve compatibility with the 448 [I-D.ietf-pce-stateful-pce] definition of . 450 7.3. Example 452 7.3.1. P2MP TE LSP Update Request 454 LSP Update Request message is sent by an active stateful PCE to 455 update the P2MP TE LSP parameters or attributes. An example of a 456 PCUpd message for P2MP TE LSP is described below: 458 Common Header 459 SRP 460 LSP with P2MP flag set 461 END-POINTS for leaf type 3 462 ERO list 464 In this example, a stateful PCE request updation of path taken by 465 some of the leaves in a P2MP tree. The update request uses the END- 466 POINT type 3 (modified/reoptimized). The ERO list represents the S2L 467 path after modification. The update message does not need to encode 468 the full P2MP tree in this case. 470 7.3.2. P2MP TE LSP Report 472 LSP State Report message is sent by a PCC to report or delegate the 473 P2MP TE LSP. An example of a PCRpt message for P2MP TE LSP is 474 described below to add new leaves to an existing P2MP TE LSP: 476 Common Header 477 LSP with P2MP flag set 478 END-POINTS for leaf type 1 479 ERO list 481 An example of a PCRpt message for P2MP TE LSP is described below to 482 prune leaves from an existing P2MP TE LSP: 484 Common Header 485 LSP with P2MP flag set 486 END-POINTS for leaf type 2 487 ERO list (empty) 489 An example of a PCRpt message for P2MP TE LSP is described below to 490 report status of modified leaves in an existing P2MP TE LSP: 492 Common Header 493 LSP with P2MP flag set 494 END-POINTS for leaf type 3 495 ERO list 497 7.4. Report and Update Message Fragmentation 499 The total PCEP message length, including the common header, is 16 500 bytes. In certain scenarios the P2MP report and update request may 501 not fit into a single PCEP message (initial report or update). The 502 F-bit is used in the LSP object to signal that the initial report or 503 update was too large to fit into a single message and will be 504 fragmented into multiple messages. In order to identify the single 505 report or update, each message will use the same PLSP-ID. 507 Fragmentation procedure described below for report or update message 508 is similar to [RFC6006] which describes request and response message 509 fragmentation. 511 7.4.1. Report Fragmentation Procedure 513 If the initial report is too large to fit into a single report 514 message, the PCC will split the report over multiple messages. Each 515 message sent to the PCE, except the last one, will have the F-bit set 516 in the LSP object to signify that the report has been fragmented into 517 multiple messages. In order to identify that a series of report 518 messages represents a single report, each message will use the same 519 PLSP-ID. 521 7.4.2. Update Fragmentation Procedure 523 Once the PCE computes and updates a path for some or all leaves in a 524 P2MP TE LSP, an update message is sent to the PCC. If the update is 525 too large to fit into a single update message, the PCE will split the 526 update over multiple messages. Each update message sent by the PCE, 527 except the last one, will have the F-bit set in the LSP object to 528 signify that the update has been fragmented into multiple messages. 529 In order to identify that a series of update messages represents a 530 single update, each message will use the same PLSP-ID and SRP-ID- 531 number. 533 [Editor Note: P2MP message fragmentation errors associated with a 534 P2MP path report and update will be defined in future version]. 536 8. Non-Support of P2MP TE LSPs for Stateful PCE 538 The PCEP protocol extensions described in this document for stateful 539 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 540 its stateful capability with P2MP as per Section 5.2. If this is not 541 the case and Stateful operations on P2MP TE LSPs are attempted, then 542 a PCErr with error-type 19 (Invalid Operation) and error-value TBD 543 needs to be generated. 545 If a Stateful PCE receives a P2MP TE LSP report message and it 546 understands the P2MP flag in the LSP object, but the stateful PCE is 547 not capable of P2MP computation, the PCE MUST send a PCErr message 548 with error-type 19 (Invalid Operation) and error-value TBD. 550 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 551 does not understand the P2MP flag in the LSP object, and therefore 552 the PCEP extensions described in this document, then the PCE SHOULD 553 reject the request. 555 [Editor Note: more information on exact error value is needed] 557 9. Security Considerations 559 TBD 561 10. Manageability Considerations 562 10.1. Control of Function and Policy 564 TBD. 566 10.2. Information and Data Models 568 TBD. 570 10.3. Liveness Detection and Monitoring 572 TBD. 574 10.4. Verify Correct Operations 576 TBD. 578 10.5. Requirements On Other Protocols 580 TBD. 582 10.6. Impact On Network Operations 584 TBD. 586 11. IANA Considerations 588 This document requests IANA actions to allocate code points for the 589 protocol elements defined in this document. Values shown here are 590 suggested for use by IANA. 592 11.1. Extension of LSP Object 594 This document requests that a registry is created to manage the Flags 595 field of the LSP object. New values are to be assigned by Standards 596 Action [RFC5226]. Each bit should be tracked with the following 597 qualities: 599 o Bit number (counting from bit 0 as the most significant bit) 601 o Capability description 603 o Defining RFC 605 The following values are defined in this document: 607 Bit Description Reference 609 24 P2MP This.I-D 610 23 Fragmentation This.I-D 612 11.2. Extension of PCEP-Error Object 614 A new error types 6 and 19 defined in section 8.4 of 615 [I-D.ietf-pce-stateful-pce]. This document extend the new Error- 616 Values for those error types for the following error conditions: 618 Error-Type Meaning 619 6 Mandatory Object missing 620 Error-value=12: P2MP-LSP-IDENTIFIER TLV missing 621 19 Invalid Operation 622 Error-value= TBD. 624 11.3. PCEP TLV Type Indicators 626 This document defines the following new PCEP TLVs: 628 Value Meaning Reference 629 22 P2MP-IPV4-LSP-IDENTIFIERS This.I-D 630 23 P2MP-IPV6-LSP-IDENTIFIERS This.I-D 632 12. Acknowledgments 634 Thanks to Quintin Zhao for his comments. 636 13. References 638 13.1. Normative References 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 13.2. Informative References 645 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 646 Element (PCE)-Based Architecture", RFC 4655, August 2006. 648 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 649 Regional Registration", RFC 4857, June 2007. 651 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 652 "Extensions to Resource Reservation Protocol - Traffic 653 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 654 Switched Paths (LSPs)", RFC 4875, May 2007. 656 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 657 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 658 May 2008. 660 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 661 (PCE) Communication Protocol (PCEP)", RFC 5440, March 662 2009. 664 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path 665 Computation Element (PCE) to Point-to-Multipoint (P2MP) 666 MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 667 October 2009. 669 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 670 and J. Meuric, "Extensions to the Path Computation Element 671 Communication Protocol (PCEP) for Point-to-Multipoint 672 Traffic Engineering Label Switched Paths", RFC 6006, 673 September 2010. 675 [I-D.ietf-pce-stateful-pce-app] 676 Zhang, X. and I. Minei, "Applicability of Stateful Path 677 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 678 app-01 (work in progress), September 2013. 680 [I-D.ietf-pce-stateful-pce] 681 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 682 Extensions for Stateful PCE", draft-ietf-pce-stateful- 683 pce-07 (work in progress), October 2013. 685 [I-D.sivabalan-pce-disco-stateful] 686 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 687 for Stateful PCE Discovery", draft-sivabalan-pce-disco- 688 stateful-02 (work in progress), July 2013. 690 Authors' Addresses 692 Udayasree Palle 693 Huawei Technologies 694 Leela Palace 695 Bangalore, Karnataka 560008 696 INDIA 698 EMail: udayasree.palle@huawei.com 699 Dhruv Dhody 700 Huawei Technologies 701 Leela Palace 702 Bangalore, Karnataka 560008 703 INDIA 705 EMail: dhruv.ietf@gmail.com