idnits 2.17.1 draft-palle-pce-stateful-pce-p2mp-07.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 (June 29, 2015) is 3223 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 448, but not defined ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-11 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-02 -- 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-04 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-04 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-04 Summary: 1 error (**), 0 flaws (~~), 7 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: December 31, 2015 Y. Tanaka 6 NTT Communications 7 Z. Ali 8 Cisco Systems 9 V. Beeram 10 Juniper Networks 11 June 29, 2015 13 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 14 usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 15 draft-palle-pce-stateful-pce-p2mp-07 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 PCEP so as to enable the usage of a stateful PCE 23 capability in supporting point-to-multipoint (P2MP) TE LSPs. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 31, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 63 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 4 66 5. Architectural Overview of Protocol Extensions . . . . . . . . 5 67 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 5 68 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 69 5.3. State Synchronization . . . . . . . . . . . . . . . . . . 6 70 5.4. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 6 71 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6 72 5.5.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 7 73 5.5.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 7 74 6. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 7 75 6.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 7 76 6.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 8 77 6.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11 79 7.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11 80 7.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 81 7.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14 82 7.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 15 83 7.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.5.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 16 85 7.5.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 16 86 7.6. Report and Update Message Fragmentation . . . . . . . . . 17 87 7.6.1. Report Fragmentation Procedure . . . . . . . . . . . 18 88 7.6.2. Update Fragmentation Procedure . . . . . . . . . . . 18 89 8. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 18 90 9. Manageability Considerations . . . . . . . . . . . . . . . . 19 91 9.1. Control of Function and Policy . . . . . . . . . . . . . 19 92 9.2. Information and Data Models . . . . . . . . . . . . . . . 19 93 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 19 94 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 95 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 96 9.6. Impact On Network Operations . . . . . . . . . . . . . . 20 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 10.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 20 100 10.2. Extension of LSP Object . . . . . . . . . . . . . . . . 20 101 10.3. Extension of PCEP-Error Object . . . . . . . . . . . . . 21 102 10.4. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 21 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 104 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 107 13.2. Informative References . . . . . . . . . . . . . . . . . 23 108 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 25 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 111 1. Introduction 113 As per [RFC4655], the Path Computation Element (PCE) is an entity 114 that is capable of computing a network path or route based on a 115 network graph, and applying computational constraints. A Path 116 Computation Client (PCC) may make requests to a PCE for paths to be 117 computed. 119 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic 120 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 121 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The 122 PCE has been identified as a suitable application for the computation 123 of paths for P2MP TE LSPs ([RFC5671]). 125 The PCEP is designed as a communication protocol between PCCs and 126 PCEs for point-to-point (P2P) path computations and is defined in 127 [RFC5440]. The extensions of PCEP to request path computation for 128 P2MP TE LSPs are described in [RFC6006]. 130 Stateful PCEs are shown to be helpful in many application scenarios, 131 in both MPLS and GMPLS networks, as illustrated in 132 [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to 133 P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the 134 fundamental extensions needed for stateful PCE to support general 135 functionality for P2P TE LSP. Complementarily, this document focuses 136 on the extensions that are necessary in order for the deployment of 137 stateful PCEs to support P2MP TE LSPs. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2. Terminology 147 Terminology used in this document is same as terminology used in 148 [I-D.ietf-pce-stateful-pce] and [RFC6006]. 150 3. Supporting P2MP TE LSP for Stateful PCE 152 3.1. Motivation 154 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 155 demonstrating scenarios that benefit from the deployment of a 156 stateful PCE including optimization, recovery, etc which are equally 157 applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the 158 extensions to PCEP for P2P TE LSPs. Complementarily, this document 159 focuses on the extensions that are necessary in order for the 160 deployment of stateful PCEs to support P2MP TE LSPs. 162 In addition to that, the stateful nature of a PCE simplifies the 163 information conveyed in PCEP messages since it is possible to refer 164 to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this 165 is an added advantage, where the size of message is much larger. 166 Incase of stateless PCE, a modification of P2MP tree requires 167 encoding of all leaves along with the paths in PCReq message, but 168 using a stateful PCE with P2MP capability, the PCEP message can be 169 used to convey only the modifications (the other information can be 170 retrieved from the P2MP LSP identifier in the LSP database (LSPDB)). 172 3.2. Objectives 174 The objectives for the protocol extensions to support P2MP TE LSP for 175 stateful PCE are same as the objectives described in section 3.2 of 176 [I-D.ietf-pce-stateful-pce]. 178 4. Functions to Support P2MP TE LSPs for Stateful PCEs 180 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 181 stateful PCE. It also specifies that a function can be initiated 182 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 183 (E-C). 185 This document extends these functions to support P2MP TE LSPs. 187 Capability Advertisement (E-C,C-E): both the PCC and the PCE must 188 announce during PCEP session establishment that they support PCEP 189 Stateful PCE extensions for P2MP using mechanisms defined in 190 Section 5.2. 192 LSP State Synchronization (C-E): after the session between the PCC 193 and a stateful PCE with P2MP capability is initialized, the PCE 194 must learn the state of a PCC's P2MP TE LSPs before it can perform 195 path computations or update LSP attributes in a PCC. 197 LSP Update Request (E-C): a stateful PCE with P2MP capability 198 requests modification of attributes on a PCC's P2MP TE LSP. 200 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 201 whenever the state of a P2MP TE LSP changes. 203 LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to 204 update LSP attributes on one or more P2MP TE LSPs; the PCE becomes 205 the authoritative source of the LSP's attributes as long as the 206 delegation is in effect (See Section 5.5 of 207 [I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation 208 or the PCE may give up the delegation at any time. 210 [Editor's Note - An update to [I-D.sivabalan-pce-disco-stateful] is 211 needed to support autodiscovery of stateful PCEs with P2MP 212 capability. This will be undertaken after WG adoption.] 214 5. Architectural Overview of Protocol Extensions 216 5.1. Extension of PCEP Messages 218 New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to 219 support stateful PCE for P2P TE LSPs. In this document these 220 messages are extended to support P2MP TE LSPs. 222 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 223 in a PCRpt message can contain actual P2MP TE LSP path attributes, 224 LSP status, etc. An LSP State Report carried on a PCRpt message 225 is also used in delegation or revocation of control of a P2MP TE 226 LSP to/from a PCE. The extension of PCRpt message is described in 227 Section 7.1. 229 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 230 Request in a PCUpd message MUST contain all LSP parameters that a 231 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 232 carried on a PCUpd message is also used to return LSP delegations 233 if at any point PCE no longer desires control of a P2MP TE LSP. 234 The PCUpd message is described in Section 7.2. 236 5.2. Capability Advertisement 238 During PCEP Initialization Phase, as per Section 7.1.1 of 239 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 240 capability via Stateful PCE Capability TLV in open message. Two new 241 flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 242 [I-D.ietf-pce-stateful-pce] and updated in 243 [I-D.ietf-pce-pce-initiated-lsp] and 244 [I-D.ietf-pce-stateful-sync-optimizations]. 246 Two new bits N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) 247 are added in this document: 249 N (P2MP-CAPABILITY - 1 bit): if set to 1 by a PCC, the N Flag 250 indicates that the PCC is willing to send P2MP LSP State Reports 251 whenever P2MP LSP parameters or operational status changes.; if 252 set to 1 by a PCE, the N Flag indicates that the PCE is interested 253 in receiving LSP State Reports whenever LSP parameters or 254 operational status changes. The P2MP-CAPABILITY Flag must be 255 advertised by both a PCC and a PCE for PCRpt messages P2MP 256 extension to be allowed on a PCEP session. 258 M (P2MP-LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the M 259 Flag indicates that the PCC allows modification of P2MP LSP 260 parameters; if set to 1 by a PCE, the M Flag indicates that the 261 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 262 UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE 263 for PCUpd messages P2MP extension to be allowed on a PCEP session. 265 A PCEP speaker should continue to advertise the basic P2MP capability 266 via mechanisms as described in [RFC6006]. 268 5.3. State Synchronization 270 State Synchronization operations described in Section 5.4 of 271 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 273 5.4. LSP Delegation 275 LSP delegation operations described in Section 5.5 of 276 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 278 5.5. LSP Operations 279 5.5.1. Passive Stateful PCE 281 LSP operations for passive stateful PCE described in Section 5.6.1 of 282 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 284 The Path Computation Request and Response message format for P2MP TE 285 LSPs is described in Section 3.4 and Section 3.5 of [RFC6006] 286 respectively. 288 The Request and Response message for P2MP TE LSPs are extended to 289 support encoding of LSP object, so that it is possible to refer to a 290 LSP with a unique identifier and simplify the PCEP message exchange. 291 For example, incase of modification of one leaf in a P2MP tree, there 292 should be no need to carry the full P2MP tree in PCReq message. 294 The extension for the Request and Response message for passive 295 stateful operations on P2MP TE LSPs are described in Section 7.3 and 296 Section 7.4. The extension for the Path Computation LSP State Report 297 (PCRpt) message is described in Section 7.1. 299 5.5.2. Active Stateful PCE 301 LSP operations for active stateful PCE described in Section 5.6.2 of 302 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 304 The extension for the Path Computation LSP Update (PCUpd) message for 305 active stateful operations on P2MP TE LSPs are described in 306 Section 7.2. 308 6. PCEP Object Extensions 310 The PCEP TLV defined in this document is compliant with the PCEP TLV 311 format defined in [RFC5440]. 313 6.1. Extension of LSP Object 315 LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. 316 It specifies PLSP-ID to uniquely identify an LSP that is constant for 317 the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID 318 identify a P2MP TE LSP uniquely. This document adds the following 319 flags to the LSP Object: 321 N (P2MP bit): If the bit is set to 1, it specifies the message is 322 for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a 323 P2MP TE LSP. 325 F (Fragmentation bit): If the bit is set to 1, it specifies the 326 message is fragmented. 328 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 329 present in LSP object. 331 6.2. P2MP-LSP-IDENTIFIER TLV 333 The P2MP LSP Identifier TLV MUST be included in the LSP object in 334 PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is 335 missing, the PCE will generate an error with error-type 6 (mandatory 336 object missing) and error-value TBD (P2MP-LSP-IDENTIFIERS TLV 337 missing) and close the PCEP session. 339 The P2MP LSP Identifier TLV MAY be included in the LSP object in 340 PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value 341 of all zeros for this TLV is used to refer to all paths pertaining to 342 a particular PLSP-ID. 344 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 345 IPv6. 347 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 348 following figure: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type=[TBD] | Length=16 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | IPv4 Tunnel Sender Address | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | LSP ID | Tunnel ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Extended Tunnel ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | P2MP ID | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 1: IPV4-P2MP-LSP-IDENTIFIER TLV format 366 The type of the TLV is [TBD] and it has a fixed length of 16 octets. 367 The value contains the following fields: 369 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 370 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 371 Sender Template Object. 373 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 374 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 375 Object. 377 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 378 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 379 Tunnel ID remains constant over the life time of a tunnel. 381 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 382 identifier defined in [RFC3209], Section 4.6.1.1 for the 383 LSP_TUNNEL_IPv4 Session Object. 385 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 386 Section 19.1.1 of [RFC4875]for the P2MP LSP Tunnel IPv4 SESSION 387 Object. 389 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 390 following figure: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type=[TBD] | Length=40 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 + + 399 | IPv6 tunnel sender address | 400 + (16 octets) + 401 | | 402 + + 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | LSP ID | Tunnel ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 + + 409 | Extended Tunnel ID | 410 + (16 octets) + 411 | | 412 + + 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | P2MP ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 2: IPV6-P2MP-LSP-IDENTIFIER TLV format 420 The type of the TLV is [TBD] and it has a fixed length of 40 octets. 421 The value contains the following fields: 423 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 424 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 425 Sender Template Object. 427 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 428 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 429 Object. 431 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 432 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 433 Tunnel ID remains constant over the life time of a tunnel. 435 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 436 identifier defined in [RFC3209], Section 4.6.1.2 for the 437 LSP_TUNNEL_IPv6 Session Object. 439 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 441 6.3. S2LS Object 443 The S2LS (Source-to-Leaves) Object is used to report RSVP-TE state of 444 one or more destiantions (leaves) encoded within the END-POINTS 445 object for a P2MP TE LSP. It MUST be carried in PCRpt message along 446 with END-POINTS object when N bit is set in LSP object. 448 S2LS Object-Class is [TBD]. 450 S2LS Object-Types is 1. 452 The format of the S2LS object is shown in the following figure: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Flags | O| 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 // Optional TLVs // 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 3: S2LS object format 466 Flags(32 bits): 468 O(Operational - 3 bits) the O Field represents the operational 469 status of the group of destinations. The values are as per 470 Operational field in LSP object defined in Section 7.3 of 471 [I-D.ietf-pce-stateful-pce]. 473 When N bit is set in LSP object then the O field in LSP object 474 represents the operational status of the full P2MP TE LSP and the O 475 field in S2LS object represents the operational status of a group of 476 destinations encoded within the END-POINTS object. 478 Future documents MAY define optional TLVs that MAY be included in the 479 S2LS Object. 481 7. PCEP Message Extensions 483 7.1. The PCRpt Message 485 As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is 486 used to report the current state of a P2P TE LSP. This document 487 extends the PCRpt message in reporting the status of P2MP TE LSP. 489 The format of PCRpt message is as follows: 491 ::= 492 493 Where: 495 ::= 496 [] 498 ::= [] 499 500 501 502 Where: 504 ::= 505 [] 506 [] 507 508 [] 510 ::= (|) 511 [] 512 [] 514 is defined in [RFC5440] and 515 extended by PCEP extensions. 517 The P2MP END-POINTS object defined in [RFC6006]is mandatory for 518 specifying address of P2MP leaves grouped based on leaf types. 520 o New leaves to add (leaf type = 1) 522 o Old leaves to remove (leaf type = 2) 524 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 526 o Old leaves whose path must be left unchanged (leaf type = 4) 528 When reporting the status of a P2MP TE LSP, the destinations are 529 grouped in END-POINTS object based on the operational status (O field 530 in S2LS object) and leaf type (in END-POINTS). This way the leaves 531 that share the same operational status are grouped together. For 532 reporing the status of delegated P2MP TE LSP, leaf-type = 3, where as 533 for non-delegated P2MP TE LSP, leaf-type = 4 is used. 535 For delegated P2MP TE LSP configuration changes are reported via 536 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 537 type = 1) is used where as removing of old leaves (leaf-type = 2) is 538 used. 540 Note that we preserve compatibility with the 541 [I-D.ietf-pce-stateful-pce] definition of . At least 542 one instance of MUST be present in this message for P2MP 543 LSP. 545 During state synchronization, the PCRpt message must report the 546 status of the full P2MP TE LSP. 548 The S2LS object MUST be carried in PCRpt message along with END- 549 POINTS object when N bit is set in LSP object for P2MP TE LSP. If 550 the S2LS object is missing, the receiving PCE MUST send a PCErr 551 message with Error-type=6 (Mandatory Object missing) and Error- 552 value=TBD (S2LS object missing). If the END-POINTS object is 553 missing, the receiving PCE MUST send a PCErr message with Error- 554 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 555 object missing) (defined in [RFC5440]. 557 7.2. The PCUpd Message 559 As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is 560 used to update P2P TE LSP attributes. This document extends the 561 PCUpd message in updating the attributes of P2MP TE LSP. 563 The format of a PCUpd message is as follows: 565 ::= 566 568 Where: 570 ::= 571 [] 573 ::= 574 575 577 578 Where: 580 ::= 581 [] 582 583 [] 585 ::= (|) 586 [] 588 is defined in [RFC5440] and 589 extended by PCEP extensions. 591 Note that we preserve compatibility with the 592 [I-D.ietf-pce-stateful-pce] definition of . 594 The PCC MAY use the make-before-break or sub-group-based procedures 595 described in [RFC4875] based on a local policy decision. 597 The END-POINTS object MUST be carried in PCUpd message when N bit is 598 set in LSP object for P2MP TE LSP. If the END-POINTS object is 599 missing, the receiving PCC MUST send a PCErr message with Error- 600 type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS 601 object missing) (defined in [RFC5440]. 603 7.3. The PCReq Message 605 As per Section 3.4 of [RFC6006], PCReq message is used for a P2MP 606 path computation request. This document extends the PCReq message 607 such that a PCC MAY include the LSP object in the PCReq message if 608 the stateful PCE P2MP capability has been negotiated on a PCEP 609 session between the PCC and a PCE. 611 The format of PCReq message is as follows: 613 ::= 614 615 where: 616 ::= 617 618 [] 619 [] 620 [] 621 [] 622 [] 623 [] 624 [] 626 where: 627 ::=[][] 628 [] 630 ::=[][] 631 ::=[] 633 7.4. The PCRep Message 635 As per Section 3.5 of [RFC6006], PCRep message is used for a P2MP 636 path computation reply. This document extends the PCRep message such 637 that a PCE MAY include the LSP object in the PCRep message if the 638 stateful PCE P2MP capability has been negotiated on a PCEP session 639 between the PCC and a PCE. 641 The format of PCRep message is as follows: 643 ::= 644 646 ::= 647 [] 648 [] 649 [] 651 where: 653 ::= 654 [][] 656 ::= (|) [] 658 ::=[] 659 [] 660 [] 661 [] 662 [] 663 [] 665 7.5. Example 667 7.5.1. P2MP TE LSP Update Request 669 LSP Update Request message is sent by an active stateful PCE to 670 update the P2MP TE LSP parameters or attributes. An example of a 671 PCUpd message for P2MP TE LSP is described below: 673 Common Header 674 SRP 675 LSP with P2MP flag set 676 END-POINTS for leaf type 3 677 ERO list 679 In this example, a stateful PCE request updation of path taken by 680 some of the leaves in a P2MP tree. The update request uses the END- 681 POINT type 3 (modified/reoptimized). The ERO list represents the 682 S2LS path after modification. The update message does not need to 683 encode the full P2MP tree in this case. 685 7.5.2. P2MP TE LSP Report 687 LSP State Report message is sent by a PCC to report or delegate the 688 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 689 LSP is described below to add new leaves to an existing P2MP TE LSP: 691 Common Header 692 LSP with P2MP flag set 693 END-POINTS for leaf type 1 694 S2LS (O=DOWN) 695 ERO list (empty) 697 An example of a PCRpt message for P2MP TE LSP is described below to 698 prune leaves from an existing P2MP TE LSP: 700 Common Header 701 LSP with P2MP flag set 702 END-POINTS for leaf type 2 703 S2LS (O=UP) 704 ERO list 706 An example of a PCRpt message for a delegated P2MP TE LSP is 707 described below to report status of leaves in an existing P2MP TE 708 LSP: 710 Common Header 711 LSP with P2MP flag set 712 END-POINTS for leaf type 3 713 S2LS (O=UP) 714 ERO list 715 END-POINTS for leaf type 3 716 S2LS (O=DOWN) 717 ERO list 719 An example of a PCRpt message for a non-delegated P2MP TE LSP is 720 described below to report status of leaves: 722 Common Header 723 LSP with P2MP flag set 724 END-POINTS for leaf type 4 725 S2LS (O=ACTIVE) 726 ERO list 727 END-POINTS for leaf type 4 728 S2LS (O=DOWN) 729 ERO list 731 7.6. Report and Update Message Fragmentation 733 The total PCEP message length, including the common header, is 16 734 bytes. In certain scenarios the P2MP report and update request may 735 not fit into a single PCEP message (e.g. initial report or update). 737 The F-bit is used in the LSP object to signal that the initial report 738 or update was too large to fit into a single message and will be 739 fragmented into multiple messages. In order to identify the single 740 report or update, each message will use the same PLSP-ID. 742 Fragmentation procedure described below for report or update message 743 is similar to [RFC6006]which describes request and response message 744 fragmentation. 746 7.6.1. Report Fragmentation Procedure 748 If the initial report is too large to fit into a single report 749 message, the PCC will split the report over multiple messages. Each 750 message sent to the PCE, except the last one, will have the F-bit set 751 in the LSP object to signify that the report has been fragmented into 752 multiple messages. In order to identify that a series of report 753 messages represents a single report, each message will use the same 754 PLSP-ID. 756 To indicate P2MP message fragmentation errors associated with a P2MP 757 Report, a Error-Type (18) and a new error-value TBD is used if a PCE 758 has not received the last piece of the fragmented message, it should 759 send an error message to the PCC to signal that it has received an 760 incomplete message (i.e., "Fragmented Report failure"). 762 7.6.2. Update Fragmentation Procedure 764 Once the PCE computes and updates a path for some or all leaves in a 765 P2MP TE LSP, an update message is sent to the PCC. If the update is 766 too large to fit into a single update message, the PCE will split the 767 update over multiple messages. Each update message sent by the PCE, 768 except the last one, will have the F-bit set in the LSP object to 769 signify that the update has been fragmented into multiple messages. 770 In order to identify that a series of update messages represents a 771 single update, each message will use the same PLSP-ID and SRP-ID- 772 number. 774 To indicate P2MP message fragmentation errors associated with a P2MP 775 Update request, a Error-Type (18) and a new error-value TBD is used 776 if a PCC has not received the last piece of the fragmented message, 777 it should send an error message to the PCE to signal that it has 778 received an incomplete message (i.e., "Fragmented Update failure"). 780 8. Non-Support of P2MP TE LSPs for Stateful PCE 782 The PCEP protocol extensions described in this document for stateful 783 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 784 its stateful capability with P2MP as per Section 5.2. If the PCEP 785 Speaker on the PCC supports the extensions of this draft (understands 786 the P2MP flag in the LSP object) but did not advertise this 787 capability, then upon receipt of PCUpd message from the PCE, it 788 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 789 error-value TBD (Attempted LSP Update Request for P2MP if active 790 stateful PCE capability for P2MP was not advertised). If the PCEP 791 Speaker on the PCE supports the extensions of this draft (understands 792 the P2MP flag in the LSP object) but did not advertise this 793 capability, then upon receipt of a PCRpt message from the PCC, it 794 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 795 error-value TBD (Attempted LSP State Report for P2MP if stateful PCE 796 capability for P2MP was not advertised) and it will terminate the 797 PCEP session. 799 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 800 does not understand the P2MP flag in the LSP object, and therefore 801 the PCEP extensions described in this document, then the Stateful PCE 802 would act as per [I-D.ietf-pce-stateful-pce]. 804 9. Manageability Considerations 806 All manageability requirements and considerations listed in 807 [RFC5440], [RFC6006] and [I-D.ietf-pce-stateful-pce] apply to PCEP 808 protocol extensions defined in this document. In addition, 809 requirements and considerations listed in this section apply. 811 9.1. Control of Function and Policy 813 A PCE or PCC implementation MUST allow configuring the stateful PCEP 814 capability and the LSP Update capability for P2MP LSPs. 816 9.2. Information and Data Models 818 The PCEP MIB module SHOULD be extended to include advertised P2MP 819 stateful capabilities, P2MP synchronization status, and P2MP 820 delegation status etc. 822 9.3. Liveness Detection and Monitoring 824 Mechanisms defined in this document do not imply any new liveness 825 detection and monitoring requirements in addition to those already 826 listed in [RFC5440]. 828 9.4. Verify Correct Operations 830 Mechanisms defined in this document do not imply any new operation 831 verification requirements in addition to those already listed in 832 [RFC5440], [RFC6006] and [I-D.ietf-pce-stateful-pce]. 834 9.5. Requirements On Other Protocols 836 Mechanisms defined in this document do not imply any new requirements 837 on other protocols. 839 9.6. Impact On Network Operations 841 Mechanisms defined in this document do not have any impact on network 842 operations in addition to those already listed in [RFC5440], 843 [RFC6006] and [I-D.ietf-pce-stateful-pce]. 845 10. IANA Considerations 847 This document requests IANA actions to allocate code points for the 848 protocol elements defined in this document. 850 10.1. STATEFUL-PCE-CAPABILITY TLV 852 The following values are defined in this document for the Flags field 853 in the STATEFUL-PCE-CAPABILITY-TLV (defined in 854 [I-D.ietf-pce-stateful-pce]) in the OPEN object: 856 Bit Description Reference 858 TBD P2MP-CAPABILITY This.I-D 859 TBD P2MP-LSP-UPDATE- This.I-D 860 CAPABILITY 862 10.2. Extension of LSP Object 864 This document requests that a registry is created to manage the Flags 865 field of the LSP object (defined in [I-D.ietf-pce-stateful-pce]). 866 New values are to be assigned by Standards Action [RFC5226]. Each 867 bit should be tracked with the following qualities: 869 o Bit number (counting from bit 0 as the most significant bit) 871 o Capability description 873 o Defining RFC 875 The following values are defined in this document: 877 Bit Description Reference 879 TBD P2MP This.I-D 880 TBD Fragmentation This.I-D 882 10.3. Extension of PCEP-Error Object 884 A new 19 (recommended values) defined in section 8.4 of 885 [I-D.ietf-pce-stateful-pce]. The error-type 6 is defined in 886 [RFC5440] and error-type 18 in [RFC6006]. This document extend the 887 new Error-Values for those error types for the following error 888 conditions: 890 Error-Type Meaning 891 6 Mandatory Object missing 892 Error-value=TBD: S2LS object missing 893 Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing 894 18 P2MP Fragmentation Error 895 Error-value= TBD. Fragmented Report 896 failure 897 Error-value= TBD. Fragmented Update 898 failure 899 19 Invalid Operation 900 Error-value= TBD. Attempted LSP State Report 901 for P2MP if stateful PCE capability 902 for P2MP was not advertised 903 Error-value= TBD. Attempted LSP Update Request 904 for P2MP if active stateful PCE capability 905 for P2MP was not advertised 907 Upon approval of this document, IANA is requested to make the 908 assignment of a new error value for the existing "PCEP-ERROR Object 909 Error Types and Values" registry located at 910 http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object. 912 10.4. PCEP TLV Type Indicators 914 Upon approval of this document, IANA is requested to make the 915 assignment of a new value for the existing "PCEP TLV Type Indicators" 916 registry located at http://www.iana.org/assignments/pcep/ 917 pcep.xhtml#pcep-tlv-type-indicators. This document defines the 918 following new PCEP TLVs: 920 Value Meaning Reference 921 TBD P2MP-IPV4-LSP-IDENTIFIERS This.I-D 922 TBD P2MP-IPV6-LSP-IDENTIFIERS This.I-D 924 11. Security Considerations 926 The stateful operations on P2MP TE LSP are more CPU-intensive and 927 also utilize more link bandwidth. In the event of an unauthorized 928 stateful P2MP operations, or a denial of service attack, the 929 subsequent PCEP operations may be disruptive to the network. 930 Consequently, it is important that implementations conform to the 931 relevant security requirements of [RFC5440], [RFC6006] and 932 [I-D.ietf-pce-stateful-pce]. Further [I-D.ietf-pce-pceps] discusses 933 an experimental approach to provide secure transport for PCEP. 935 12. Acknowledgments 937 Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his 938 comments. 940 13. References 942 13.1. Normative References 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, March 1997. 947 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 948 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 949 Tunnels", RFC 3209, December 2001. 951 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 952 (PCE) Communication Protocol (PCEP)", RFC 5440, March 953 2009. 955 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 956 and J. Meuric, "Extensions to the Path Computation Element 957 Communication Protocol (PCEP) for Point-to-Multipoint 958 Traffic Engineering Label Switched Paths", RFC 6006, 959 September 2010. 961 [I-D.ietf-pce-stateful-pce] 962 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 963 Extensions for Stateful PCE", draft-ietf-pce-stateful- 964 pce-11 (work in progress), April 2015. 966 [I-D.ietf-pce-stateful-sync-optimizations] 967 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 968 and D. Dhody, "Optimizations of Label Switched Path State 969 Synchronization Procedures for a Stateful PCE", draft- 970 ietf-pce-stateful-sync-optimizations-02 (work in 971 progress), January 2015. 973 13.2. Informative References 975 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 976 Element (PCE)-Based Architecture", RFC 4655, August 2006. 978 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 979 Regional Registration", RFC 4857, June 2007. 981 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 982 "Extensions to Resource Reservation Protocol - Traffic 983 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 984 Switched Paths (LSPs)", RFC 4875, May 2007. 986 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 987 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 988 May 2008. 990 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path 991 Computation Element (PCE) to Point-to-Multipoint (P2MP) 992 MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 993 October 2009. 995 [I-D.ietf-pce-stateful-pce-app] 996 Zhang, X. and I. Minei, "Applicability of a Stateful Path 997 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 998 app-04 (work in progress), April 2015. 1000 [I-D.ietf-pce-pce-initiated-lsp] 1001 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1002 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1003 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 1004 progress), April 2015. 1006 [I-D.ietf-pce-pceps] 1007 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1008 Transport for PCEP", draft-ietf-pce-pceps-04 (work in 1009 progress), May 2015. 1011 [I-D.sivabalan-pce-disco-stateful] 1012 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 1013 for Stateful PCE Discovery", draft-sivabalan-pce-disco- 1014 stateful-03 (work in progress), January 2014. 1016 Appendix A. Contributor Addresses 1018 Yuji Kamite 1019 NTT Communications Corporation 1020 Granpark Tower 1021 3-4-1 Shibaura, Minato-ku 1022 Tokyo 108-8118 1023 Japan 1025 EMail: y.kamite@ntt.com 1027 Authors' Addresses 1029 Udayasree Palle 1030 Huawei Technologies 1031 Divyashree Techno Park, Whitefield 1032 Bangalore, Karnataka 560037 1033 India 1035 EMail: udayasree.palle@huawei.com 1037 Dhruv Dhody 1038 Huawei Technologies 1039 Divyashree Techno Park, Whitefield 1040 Bangalore, Karnataka 560037 1041 India 1043 EMail: dhruv.ietf@gmail.com 1045 Yosuke Tanaka 1046 NTT Communications Corporation 1047 Granpark Tower 1048 3-4-1 Shibaura, Minato-ku 1049 Tokyo 108-8118 1050 Japan 1052 EMail: yosuke.tanaka@ntt.com 1054 Zafar Ali 1055 Cisco Systems 1057 EMail: zali@cisco.com 1058 Vishnu Pavan Beeram 1059 Juniper Networks 1061 EMail: vbeeram@juniper.net