idnits 2.17.1 draft-palle-pce-stateful-pce-p2mp-03.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 (June 6, 2014) is 3611 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 429, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-08 -- 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 (-11) exists of draft-ietf-pce-pce-initiated-lsp-00 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-00 Summary: 1 error (**), 0 flaws (~~), 6 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: December 8, 2014 Y. Tanaka 6 Y. Kamite 7 NTT Communications 8 Z. Ali 9 Cisco Systems 10 June 6, 2014 12 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 13 usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 14 draft-palle-pce-stateful-pce-p2mp-03 16 Abstract 18 The Path Computation Element (PCE) has been identified as an 19 appropriate technology for the determination of the paths of point- 20 to-multipoint (P2MP) TE LSPs. [I-D.ietf-pce-stateful-pce-app] 21 presents several use cases, demonstrating scenarios that benefit from 22 the deployment of a stateful PCE. [I-D.ietf-pce-stateful-pce] 23 provides the fundamental PCE communication Protocol (PCEP) extensions 24 needed to support stateful PCE functions. This memo provides 25 extensions required for PCEP so as to enable the usage of a stateful 26 PCE capability in supporting point-to-multipoint (P2MP) TE LSPs. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 8, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 66 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 4 69 5. Architectural Overview of Protocol Extensions . . . . . . . . 5 70 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 5 71 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 72 5.3. State Synchronization . . . . . . . . . . . . . . . . . . 7 73 5.4. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 7 74 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 75 5.5.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 7 76 5.5.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 7 77 6. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 7 78 6.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 7 79 6.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 8 80 6.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11 82 7.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11 83 7.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 84 7.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14 85 7.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 14 86 7.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.5.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 15 88 7.5.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 15 89 7.6. Report and Update Message Fragmentation . . . . . . . . . 16 90 7.6.1. Report Fragmentation Procedure . . . . . . . . . . . 17 91 7.6.2. Update Fragmentation Procedure . . . . . . . . . . . 17 92 8. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 17 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 10. Manageability Considerations . . . . . . . . . . . . . . . . 18 95 10.1. Control of Function and Policy . . . . . . . . . . . . . 18 96 10.2. Information and Data Models . . . . . . . . . . . . . . 18 97 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 18 98 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 18 99 10.5. Requirements On Other Protocols . . . . . . . . . . . . 18 100 10.6. Impact On Network Operations . . . . . . . . . . . . . . 18 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 11.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 18 103 11.2. Extension of LSP Object . . . . . . . . . . . . . . . . 19 104 11.3. Extension of PCEP-Error Object . . . . . . . . . . . . . 19 105 11.4. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 20 106 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 109 13.2. Informative References . . . . . . . . . . . . . . . . . 20 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. For P2MP this is an added advantage, where 165 the size of message is much larger. Incase of stateless PCE, a 166 modification of P2MP tree requires encoding of all leaves along with 167 the paths in PCReq message, but using a stateful PCE with P2MP 168 capability, the PCEP message can be used to convey only the 169 modifications (the other information can be retrieved from the P2MP 170 LSP identifier). 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 An update to [I-D.sivabalan-pce-disco-stateful] is needed to support 211 autodiscovery of stateful PCEs with P2MP capability. 213 5. Architectural Overview of Protocol Extensions 215 5.1. Extension of PCEP Messages 217 New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to 218 support stateful PCE for P2P TE LSPs. In this document these 219 messages are extended to support P2MP TE LSPs. 221 Path Computation State Report (PCRpt): Each P2MP TE LSP State Report 222 in a PCRpt message can contain actual P2MP TE LSP path attributes, 223 LSP status, etc. An LSP State Report carried on a PCRpt message 224 is also used in delegation or revocation of control of a P2MP TE 225 LSP to/from a PCE. The extension of PCRpt message is described in 226 Section 7.1. 228 Path Computation Update Request (PCUpd): Each P2MP TE LSP Update 229 Request in a PCUpd message MUST contain all LSP parameters that a 230 PCE wishes to set for a given P2MP TE LSP. An LSP Update Request 231 carried on a PCUpd message is also used to return LSP delegations 232 if at any point PCE no longer desires control of a P2MP TE LSP. 233 The PCUpd message is described in Section 7.2. 235 5.2. Capability Advertisement 237 During PCEP Initialization Phase, as per Section 7.1.1 of 238 [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful 239 capability via Stateful PCE Capability TLV in open message. A new 240 flag is defined for the STATEFUL-PCE-CAPABILITY TLV defined in 241 [I-D.ietf-pce-stateful-pce]. Its format is shown in the following 242 figure: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length=4 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Flags |M|N|D|T|I|S|U| 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 1: STATEFUL-PCE-CAPABILITY TLV Format 254 The U (LSP-UPDATE-CAPABILITY) bit is defined in 255 [I-D.ietf-pce-stateful-pce]. The I (LSP-INSTANTIATION-CAPABILITY) 256 bit is defined in [I-D.ietf-pce-pce-initiated-lsp]. The S (INCLUDE- 257 DB-VERSION), T (TRIGGERED-SYNC) and D (DELTA-LSP-SYNC-CAPABILITY) 258 bits are defined in [I-D.ietf-pce-stateful-sync-optimizations]. A 259 new bit N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) are 260 added in this document: 262 N (P2MP-CAPABILITY - 1 bit): if set to 1 by a PCC, the N Flag 263 indicates that the PCC is willing to send P2MP LSP State Reports 264 whenever P2MP LSP parameters or operational status changes.; if 265 set to 1 by a PCE, the N Flag indicates that the PCE is interested 266 in receiving LSP State Reports whenever LSP parameters or 267 operational status changes. The P2MP-CAPABILITY Flag must be 268 advertised by both a PCC and a PCE for PCRpt messages P2MP 269 extension to be allowed on a PCEP session. 271 M (P2MP-LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the M 272 Flag indicates that the PCC allows modification of P2MP LSP 273 parameters; if set to 1 by a PCE, the M Flag indicates that the 274 PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- 275 UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE 276 for PCUpd messages P2MP extension to be allowed on a PCEP session. 278 A PCEP speaker should continue to advertise the basic P2MP capability 279 via mechanisms as described in [RFC6006]. 281 5.3. State Synchronization 283 State Synchronization operations described in Section 5.4 of 284 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 286 5.4. LSP Delegation 288 LSP delegation operations described in Section 5.5 of 289 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 291 5.5. LSP Operations 293 5.5.1. Passive Stateful PCE 295 LSP operations for passive stateful PCE described in Section 5.6.1 of 296 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 298 The Path Computation Request and Response message format for P2MP TE 299 LSPs is described in Section 3.4 and Section 3.5 of [RFC6006] 300 respectively. 302 The Request and Response message for P2MP TE LSPs are extended to 303 support encoding of LSP object, so that it is possible to refer to a 304 LSP with a unique identifier and simplify the PCEP message exchange. 305 For example, incase of modification of one leaf in a P2MP tree, there 306 should be no need to carry the full P2MP tree in PCReq message. 308 The extension for the Request and Response message for passive 309 stateful operations on P2MP TE LSPs are described in Section 7.3 and 310 Section 7.4. 312 5.5.2. Active Stateful PCE 314 LSP operations for active stateful PCE described in Section 5.6.2 of 315 [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. 317 6. PCEP Object Extensions 319 The PCEP TLV defined in this document is compliant with the PCEP TLV 320 format defined in [RFC5440]. 322 6.1. Extension of LSP Object 324 LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. 325 It specifies PLSP-ID to uniquely identify an LSP that is constant for 326 the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID 327 identify a P2MP TE LSP uniquely. This document adds the following 328 flags to the LSP Object: 330 N (P2MP bit): If the bit is set to 1, it specifies the message is 331 for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a 332 P2MP TE LSP. 334 F (Fragmentation bit): If the bit is set to 1, it specifies the 335 message is fragmented. 337 If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be 338 present in LSP object. 340 6.2. P2MP-LSP-IDENTIFIER TLV 342 The P2MP LSP Identifier TLV MUST be included in the LSP object in 343 PCRpt message for RSVP-signaled P2MP TE LSPs. If the TLV is missing, 344 the PCE will generate an error with error-type 6 (mandatory object 345 missing) and error-value TBD (12) (P2MP-LSP-IDENTIFIERS TLV missing) 346 and close the PCEP session. 348 The P2MP LSP Identifier TLV MAY be included in the LSP object in 349 PCUpd message for RSVP-signaled P2MP TE LSPs. The special value of 350 all zeros for this TLV is used to refer to all paths pertaining to a 351 particular PLSP-ID. 353 There are two P2MP LSP Identifier TLVs, one for IPv4 and one for 354 IPv6. 356 The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the 357 following figure: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type=[TBD] | Length=16 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | IPv4 Tunnel Sender Address | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | LSP ID | Tunnel ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Extended Tunnel ID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | P2MP ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 2: IPV4-P2MP-LSP-IDENTIFIER TLV format 375 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 376 The value contains the following fields: 378 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 379 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 380 Sender Template Object. 382 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 383 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 384 Object. 386 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 387 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 388 Tunnel ID remains constant over the life time of a tunnel. 390 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 391 identifier defined in [RFC3209], Section 4.6.1.1 for the 392 LSP_TUNNEL_IPv4 Session Object. 394 P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in 395 Section 19.1.1 of [RFC4875]for the P2MP LSP Tunnel IPv4 SESSION 396 Object. 398 The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the 399 following figure: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type=[TBD] | Length=40 | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 + + 408 | IPv6 tunnel sender address | 409 + (16 octets) + 410 | | 411 + + 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | LSP ID | Tunnel ID | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 + + 418 | Extended Tunnel ID | 419 + (16 octets) + 420 | | 421 + + 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | P2MP ID | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 3: IPV6-P2MP-LSP-IDENTIFIER TLV format 429 The type of the TLV is [TBD] and it has a fixed length of 24 octets. 430 The value contains the following fields: 432 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 433 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 434 Sender Template Object. 436 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 437 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 438 Object. 440 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 441 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 442 Tunnel ID remains constant over the life time of a tunnel. 444 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 445 identifier defined in [RFC3209], Section 4.6.1.2 for the 446 LSP_TUNNEL_IPv6 Session Object. 448 P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. 450 6.3. S2LS Object 452 The S2LS (Source-to-Leaves) Object is used to report RSVP state of 453 one or more destiantions (leaves) encoded within the END-POINTS 454 object for a P2MP TE LSP. It MUST be carried in PCRpt message along 455 with END-POINTS object when N bit is set in LSP object. 457 The format of the S2LS object is shown in the following figure: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Flags | O| 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 // Optional TLVs // 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 4: S2LS object format 471 Flags(32 bits): 473 O(Operational - 3 bits) the O Field represents the operational 474 status of the group of destinations. The values are as per 475 Operational field in LSP object defined in Section 7.3 of 476 [I-D.ietf-pce-stateful-pce]. 478 When N bit is set in LSP object then the O field in LSP object 479 represents the operational status of the full P2MP TE LSP and the O 480 field in S2LS object represents the operational status of a group of 481 destinations encoded within the END-POINTS object. 483 Optional TLVs that may be included in the S2LS Object. 485 7. PCEP Message Extensions 487 7.1. The PCRpt Message 489 As per Section 6.1 of [I-D.ietf-pce-stateful-pce], PCRpt message is 490 used to report the current state of a P2P TE LSP. This document 491 extends the PCRpt message in reporting the status of P2MP TE LSP. 493 The format of PCRpt message is as follows: 495 ::= 496 497 Where: 499 ::= 500 [] 502 ::= [] 503 504 505 506 Where: 508 ::= 509 [] 510 511 512 [] 514 ::= (|) 515 [] 516 [] 518 is defined in [RFC5440] and 519 extended by PCEP extensions. 521 The P2MP END-POINTS object defined in [RFC6006]is mandatory for 522 specifying address of P2MP leaves grouped based on leaf types. 524 o New leaves to add (leaf type = 1) 526 o Old leaves to remove (leaf type = 2) 528 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 530 o Old leaves whose path must be left unchanged (leaf type = 4) 532 When reporting the status of a P2MP TE LSP, the destinations are 533 grouped in END-POINTS object based on the operational status (O field 534 in S2LS object) and leaf type (in END-POINTS). This way the leaves 535 that share the same operational status are grouped together. For 536 reporing the status of delegated P2MP TE LSP, leaf-type = 3, where as 537 for non-delegated P2MP TE LSP, leaf-type = 4 is used. 539 For delegated P2MP TE LSP configuration changes are reported via 540 PCRpt message. For example, adding of new leaves END-POINTS (leaf- 541 type = 1) is used where as removing of old leaves (leaf-type = 2) is 542 used. 544 Note that we preserve compatibility with the 545 [I-D.ietf-pce-stateful-pce] definition of . At least 546 one instance of MUST be present in this message. 548 [Editor Note: suggest to add object mandatory in 549 [I-D.ietf-pce-stateful-pce] document for ]. 551 During state synchronization, the PCRpt message must report the 552 status of the full P2MP TE LSP. 554 7.2. The PCUpd Message 556 As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is 557 used to update P2P TE LSP attributes. This document extends the 558 PCUpd message in updating the attributes of P2MP TE LSP. 560 The format of a PCUpd message is as follows: 562 ::= 563 565 Where: 567 ::= 568 [] 570 ::= 571 572 574 575 Where: 577 ::= 578 [] 579 580 [] 582 ::= (|) 583 [] 585 is defined in [RFC5440] and 586 extended by PCEP extensions. 588 Note that we preserve compatibility with the 589 [I-D.ietf-pce-stateful-pce] definition of . 591 The PCC MAY use the make-before-break or sub-group-based procedures 592 described in [RFC4875] based on a local policy decision. 594 7.3. The PCReq Message 596 As per Section 3.4 of [RFC6006], PCReq message is used for a P2MP 597 path computation request. This document extends the PCReq message 598 such that a PCC MAY include the LSP object in the PCReq message if 599 the stateful PCE P2MP capability has been negotiated on a PCEP 600 session between the PCC and a PCE. 602 The format of PCReq message is as follows: 604 ::= 605 606 where: 607 ::= 608 609 [] 610 [] 611 [] 612 [] 613 [] 614 [] 615 [] 617 where: 618 ::=[][] 619 [] 621 ::=[][] 622 ::=[] 624 7.4. The PCRep Message 626 As per Section 3.5 of [RFC6006], PCRep message is used for a P2MP 627 path computation reply. This document extends the PCRep message such 628 that a PCE MAY include the LSP object in the PCRep message if the 629 stateful PCE P2MP capability has been negotiated on a PCEP session 630 between the PCC and a PCE. 632 The format of PCRep message is as follows: 634 ::= 635 637 ::= 638 [] 639 [] 640 [] 642 where: 644 ::= 645 [][] 647 ::= (|) [] 649 ::=[] 650 [] 651 [] 652 [] 653 [] 654 [] 656 7.5. Example 658 7.5.1. P2MP TE LSP Update Request 660 LSP Update Request message is sent by an active stateful PCE to 661 update the P2MP TE LSP parameters or attributes. An example of a 662 PCUpd message for P2MP TE LSP is described below: 664 Common Header 665 SRP 666 LSP with P2MP flag set 667 END-POINTS for leaf type 3 668 ERO list 670 In this example, a stateful PCE request updation of path taken by 671 some of the leaves in a P2MP tree. The update request uses the END- 672 POINT type 3 (modified/reoptimized). The ERO list represents the 673 S2LS path after modification. The update message does not need to 674 encode the full P2MP tree in this case. 676 7.5.2. P2MP TE LSP Report 678 LSP State Report message is sent by a PCC to report or delegate the 679 P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE 680 LSP is described below to add new leaves to an existing P2MP TE LSP: 682 Common Header 683 LSP with P2MP flag set 684 END-POINTS for leaf type 1 685 S2LS (O=DOWN) 686 ERO list (empty) 688 An example of a PCRpt message for P2MP TE LSP is described below to 689 prune leaves from an existing P2MP TE LSP: 691 Common Header 692 LSP with P2MP flag set 693 END-POINTS for leaf type 2 694 S2LS (O=UP) 695 ERO list 697 An example of a PCRpt message for a delegated P2MP TE LSP is 698 described below to report status of leaves in an existing P2MP TE 699 LSP: 701 Common Header 702 LSP with P2MP flag set 703 END-POINTS for leaf type 3 704 S2LS (O=UP) 705 ERO list 706 END-POINTS for leaf type 3 707 S2LS (O=DOWN) 708 ERO list 710 An example of a PCRpt message for a non-delegated P2MP TE LSP is 711 described below to report status of leaves: 713 Common Header 714 LSP with P2MP flag set 715 END-POINTS for leaf type 4 716 S2LS (O=ACTIVE) 717 ERO list 718 END-POINTS for leaf type 4 719 S2LS (O=DOWN) 720 ERO list 722 7.6. Report and Update Message Fragmentation 724 The total PCEP message length, including the common header, is 16 725 bytes. In certain scenarios the P2MP report and update request may 726 not fit into a single PCEP message (initial report or update). The 727 F-bit is used in the LSP object to signal that the initial report or 728 update was too large to fit into a single message and will be 729 fragmented into multiple messages. In order to identify the single 730 report or update, each message will use the same PLSP-ID. 732 Fragmentation procedure described below for report or update message 733 is similar to [RFC6006]which describes request and response message 734 fragmentation. 736 7.6.1. Report Fragmentation Procedure 738 If the initial report is too large to fit into a single report 739 message, the PCC will split the report over multiple messages. Each 740 message sent to the PCE, except the last one, will have the F-bit set 741 in the LSP object to signify that the report has been fragmented into 742 multiple messages. In order to identify that a series of report 743 messages represents a single report, each message will use the same 744 PLSP-ID. 746 7.6.2. Update Fragmentation Procedure 748 Once the PCE computes and updates a path for some or all leaves in a 749 P2MP TE LSP, an update message is sent to the PCC. If the update is 750 too large to fit into a single update message, the PCE will split the 751 update over multiple messages. Each update message sent by the PCE, 752 except the last one, will have the F-bit set in the LSP object to 753 signify that the update has been fragmented into multiple messages. 754 In order to identify that a series of update messages represents a 755 single update, each message will use the same PLSP-ID and SRP-ID- 756 number. 758 [Editor Note: P2MP message fragmentation errors associated with a 759 P2MP path report and update will be defined in future version]. 761 8. Non-Support of P2MP TE LSPs for Stateful PCE 763 The PCEP protocol extensions described in this document for stateful 764 PCEs with P2MP capability MUST NOT be used if PCE has not advertised 765 its stateful capability with P2MP as per Section 5.2. If this is not 766 the case and Stateful operations on P2MP TE LSPs are attempted, then 767 a PCErr with error-type 19 (Invalid Operation) and error-value TBD 768 needs to be generated. 770 If a Stateful PCE receives a P2MP TE LSP report message and it 771 understands the P2MP flag in the LSP object, but the stateful PCE is 772 not capable of P2MP computation, the PCE MUST send a PCErr message 773 with error-type 19 (Invalid Operation) and error-value TBD. 775 If a Stateful PCE receives a P2MP TE LSP report message and the PCE 776 does not understand the P2MP flag in the LSP object, and therefore 777 the PCEP extensions described in this document, then the PCE SHOULD 778 reject the request. 780 [Editor Note: more information on exact error value is needed] 782 9. Security Considerations 784 TBD 786 10. Manageability Considerations 788 10.1. Control of Function and Policy 790 TBD. 792 10.2. Information and Data Models 794 TBD. 796 10.3. Liveness Detection and Monitoring 798 TBD. 800 10.4. Verify Correct Operations 802 TBD. 804 10.5. Requirements On Other Protocols 806 TBD. 808 10.6. Impact On Network Operations 810 TBD. 812 11. IANA Considerations 814 This document requests IANA actions to allocate code points for the 815 protocol elements defined in this document. Values shown here are 816 suggested for use by IANA. 818 11.1. STATEFUL-PCE-CAPABILITY TLV 820 The following values are defined in this document for the Flags field 821 in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object: 823 Bit Description Reference 825 27 P2MP-CAPABILITY This.I-D 826 26 P2MP-LSP-UPDATE- This.I-D 827 CAPABILITY 829 11.2. Extension of LSP Object 831 This document requests that a registry is created to manage the Flags 832 field of the LSP object. New values are to be assigned by Standards 833 Action [RFC5226]. Each bit should be tracked with the following 834 qualities: 836 o Bit number (counting from bit 0 as the most significant bit) 838 o Capability description 840 o Defining RFC 842 The following values are defined in this document: 844 Bit Description Reference 846 24 P2MP This.I-D 847 23 Fragmentation This.I-D 849 11.3. Extension of PCEP-Error Object 851 A new error types 6 and 19 defined in section 8.4 of 852 [I-D.ietf-pce-stateful-pce]. This document extend the new Error- 853 Values for those error types for the following error conditions: 855 Error-Type Meaning 856 6 Mandatory Object missing 857 Error-value=12: P2MP-LSP-IDENTIFIER TLV missing 858 19 Invalid Operation 859 Error-value= TBD. 861 11.4. PCEP TLV Type Indicators 863 This document defines the following new PCEP TLVs: 865 Value Meaning Reference 866 22 P2MP-IPV4-LSP-IDENTIFIERS This.I-D 867 23 P2MP-IPV6-LSP-IDENTIFIERS This.I-D 869 12. Acknowledgments 871 Thanks to Quintin Zhao and Venugopal Reddy for his comments. 873 13. References 875 13.1. Normative References 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 881 (PCE) Communication Protocol (PCEP)", RFC 5440, March 882 2009. 884 [I-D.ietf-pce-stateful-pce] 885 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 886 Extensions for Stateful PCE", draft-ietf-pce-stateful- 887 pce-08 (work in progress), February 2014. 889 13.2. Informative References 891 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 892 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 893 Tunnels", RFC 3209, December 2001. 895 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 896 Element (PCE)-Based Architecture", RFC 4655, August 2006. 898 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 899 Regional Registration", RFC 4857, June 2007. 901 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 902 "Extensions to Resource Reservation Protocol - Traffic 903 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 904 Switched Paths (LSPs)", RFC 4875, May 2007. 906 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 907 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 908 May 2008. 910 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path 911 Computation Element (PCE) to Point-to-Multipoint (P2MP) 912 MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 913 October 2009. 915 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 916 and J. Meuric, "Extensions to the Path Computation Element 917 Communication Protocol (PCEP) for Point-to-Multipoint 918 Traffic Engineering Label Switched Paths", RFC 6006, 919 September 2010. 921 [I-D.ietf-pce-stateful-pce-app] 922 Zhang, X. and I. Minei, "Applicability of Stateful Path 923 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 924 app-01 (work in progress), September 2013. 926 [I-D.ietf-pce-pce-initiated-lsp] 927 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 928 Extensions for PCE-initiated LSP Setup in a Stateful PCE 929 Model", draft-ietf-pce-pce-initiated-lsp-00 (work in 930 progress), December 2013. 932 [I-D.ietf-pce-stateful-sync-optimizations] 933 Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X., 934 and D. Dhody, "Optimizations of Label Switched Path State 935 Synchronization Procedures for a Stateful PCE", draft- 936 ietf-pce-stateful-sync-optimizations-00 (work in 937 progress), March 2014. 939 [I-D.sivabalan-pce-disco-stateful] 940 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 941 for Stateful PCE Discovery", draft-sivabalan-pce-disco- 942 stateful-03 (work in progress), January 2014. 944 Authors' Addresses 946 Udayasree Palle 947 Huawei Technologies 948 Leela Palace 949 Bangalore, Karnataka 560008 950 INDIA 952 EMail: udayasree.palle@huawei.com 953 Dhruv Dhody 954 Huawei Technologies 955 Leela Palace 956 Bangalore, Karnataka 560008 957 INDIA 959 EMail: dhruv.ietf@gmail.com 961 Yosuke Tanaka 962 NTT Communications Corporation 963 Granpark Tower 964 3-4-1 Shibaura, Minato-ku 965 Tokyo 108-8118 966 Japan 968 EMail: yosuke.tanaka@ntt.com 970 Yuji Kamite 971 NTT Communications Corporation 972 Granpark Tower 973 3-4-1 Shibaura, Minato-ku 974 Tokyo 108-8118 975 Japan 977 EMail: y.kamite@ntt.com 979 Zafar Ali 980 Cisco Systems 982 EMail: zali@cisco.com