idnits 2.17.1 draft-ali-pce-remote-initiated-gmpls-lsp-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 8) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** There are 28 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4208], [RFC3471], [RFC2119], [RFC3473], [RFC5520], [RFC6387], [RFC4872], [RFC3477], [RFC4873], [RFC6107], [RFC5623]), 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 (July 15, 2013) is 3938 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: 'RFC2119' is mentioned on line 79, but not defined == Missing Reference: 'RFC6107' is mentioned on line 692, but not defined == Missing Reference: 'RFC6387' is mentioned on line 465, but not defined == Unused Reference: 'RFC5440' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC 6107' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC 5467' is defined on line 750, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5623 -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Zafar Ali 3 Internet Draft Siva Sivabalan 4 Intended status: Standard Track Clarence Filsfils 5 Expires: January 14, 2014 Cisco Systems 7 Robert Varga 8 Pantheon Technologies 10 Victor Lopez 11 Oscar Gonzalez de Dios 12 Telefonica I+D 14 July 15, 2013 16 Path Computation Element Communication Protocol (PCEP) 17 Extensions for remote-initiated GMPLS LSP Setup 18 draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 13, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 54 Abstract 56 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 57 draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies 58 procedures that can be used for creation and deletion of PCE- 59 initiated LSPs under the active stateful PCE model. However, this 60 specification is focused on MPLS networks, and does not cover 61 remote instantiation of GMPLS paths. This document complements 62 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 63 draft by addressing the extensions required for GMPLS applications, 64 for example for OTN and WSON networks. 66 When active stateful PCE is used for managing PCE-initiated LSP, 67 PCC may not be aware of the intended usage of the LSP (e.g., in a 68 multi-layer network). PCEP Extensions for PCE-initiated LSP Setup 69 in a Stateful PCE Model draft does not address this requirement. 70 This draft also addresses the requirement to specify on how PCC 71 should use the PCEP initiated LSPs. 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in RFC 2119 78 [RFC2119]. 80 Table of Contents 82 1. Introduction...................................................3 83 2. Use Cases..................................................... 4 84 2.1. Single-layer provisioning from Active stateful PCE........ 4 85 2.2. Bandwidth-on-demand for multi-layer networks.............. 5 86 2.3. Higher-layer signaling trigger............................ 6 87 2.4. NMS-VNTM cooperation model (separated flavor)............. 8 88 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 90 3. GMPLS Requirements for Remote-Initiated LSPs.................. 9 91 4. Remote Initiated LSP Usage Requirement....................... 10 92 5. PCEP Extensions for Remote-Initiated GMPLS LSPs.............. 10 93 5.1. Generalized Endpoint in LSP Create Message............... 11 94 5.2. GENERALIZED-BANDWIDTH object in LSP Create Message....... 11 95 5.3. Protection Attributes in LSP Create Message.............. 12 96 5.4. ERO in LSP Create Object................................. 12 97 5.4.1. ERO with explicit label control.................... 12 98 5.4.2. ERO with Path Keys................................. 13 99 5.4.3. Switch Layer Object ................................13 100 6. PCEP extension for PCEP Initiated LSP Usage Specification.... 14 101 6.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Create Message..... 14 102 6.2. Communicating LSP usage to Egress node................... 15 103 6.3. LSP delegation and cleanup ...............................16 104 7. Security Considerations...................................... 16 105 8. IANA Considerations.......................................... 16 106 8.1. END-POINT Object......................................... 16 107 8.2. PCEP-Error Object........................................ 16 108 9. Acknowledgments.............................................. 16 109 10. References.................................................. 16 110 10.1. Normative References.................................... 16 111 10.2. Informative References.................................. 17 113 1. Introduction 115 The Path Computation Element communication Protocol (PCEP) 116 provides mechanisms for Path Computation Elements (PCEs) to 117 perform route computations in response to Path Computation 118 Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP 119 Setup in a Stateful PCE Model draft [I-D. draft-ietf-pce- 120 stateful-pce] describes a set of extensions to PCEP to enable 121 active control of MPLS-TE and GMPLS tunnels. 123 [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup 124 and teardown of PCE-initiated LSPs under the active stateful PCE 125 model, without the need for local configuration on the PCC, thus 126 allowing for a dynamic network that is centrally controlled and 127 deployed. However, this specification is focused on MPLS 128 networks, and does not cover the GMPLS networks (e.g., WSON, 129 OTN, SONET/ SDH, etc. technologies). GMPLS requirements for PCEP 130 initiated LSPs are outlined in Section 3. This document 131 complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by 132 addressing the requirements for remote-initiated GMPLS LSPs. The 133 PCEP extensions for PCEP initiated GMPLS LSPs are specified in 134 Section 5. The mechanism described in this document is 135 applicable not only to active PCEs initiating LSPs, but to any 136 entity that initiates LSPs remotely. 138 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 140 When an active stateful PCE is used for managing remote- 141 initiated LSP, the PCC may not be aware of the intended usage of 142 the remote-initiated LSP. For example, the PCC may not know the 143 target IGP instance in which the remote-initiated LSP is to be 144 used. These requirements are outlined in Section 4. [RFC6107] 145 defines LSP_TUNNEL_INTERFACE_ID Object for communicating target 146 IGP instance and usage of the forwarding and/ or routing 147 adjacency from the ingress node to the egress node. However, 148 current PCEP specifications do not include signaling of the 149 LSP_TUNNEL_INTERFACE_ID TLV in the PCEP message. Furthermore, 150 [I-D. draft-crabbe-pce-pce-initiated-lsp] does not address this 151 requirement. This draft also addresses the requirement to 152 specify on how PCC should use the PCEP initiated LSPs. This is 153 achieved by using LSP_TUNNEL_INTERFACE_ID Object defined in 154 [RFC6107] in PCEP, as detailed in Section 6. 156 2. Use Cases 158 2.1. Single-layer provisioning from active stateful PCE 160 Figure 1 shows a single-layer topology with optical nodes with a 161 GMPLS control plane. In this scenario, the active PCE can 162 dynamically create or delete L0 services between client 163 interfaces. This process can be triggered by the deployment of a 164 new network configuration or a re-optimization process. This 165 operation can be human-driven (e.g. through an NMS) or an 166 automatic process. 168 [Please refer to pdf version for the Figure] 170 Figure 1. Single-layer provisioning from active stateful PCE. 172 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 174 L0 PCE obtains resources information via control plane 175 collecting LSAs messages. The request contains, at least, two 176 optical transport interfaces (OT i/f), so PCE computes the path 177 and sends a message to the optical equipment with ERO path 178 information. 180 2.2. Bandwidth-on-demand for multi-layer networks 182 This use case assumes there is a multi-layer network composed by 183 routers and optical equipment. In this scenario, there is an 184 entity, which decides it needs extra bandwidth between two 185 routers. This certain moment a GMPLS LSP connecting both routers 186 via the optical network can be established on-the-fly. This 187 entity can be a router, an active stateful PCE or even the NMS 188 (with or without human intervention). 190 It is important to note that the bandwidth-on-demand interfaces 191 and spare bandwidth in the optical network could be shared to 192 cover many under capacity scenarios in the L3 network. For 193 example, in this use-case, if we assume all interfaces are 10G 194 and there is 10G of spare bandwidth available in the optical 195 network, the spare bandwidth in the optical network can be used 196 to connect any router, depending on bandwidth demand of the 197 router network. For example, if there are three routers, it is 198 not known a priori if the demand will make bandwidth-on-demand 199 interface at R1 to be connected to bandwidth-on-demand interface 200 at R2 or R3. For this reason, bandwidth-on-demand interfaces 201 cannot be pre-provisioned with the IP services that are expected 202 to carry. 204 According to [RFC5623], there are four options of Inter-Layer 205 Path Computation and Inter-Layer Path Control Models: (1) PCE- 206 VNTM cooperation, (2) Higher-layer signaling trigger, (3) NMS- 207 VNTM cooperation model (integrated flavor) and (4) NMS-VNTM 208 cooperation model (separated flavor). In all scenarios there is 209 a certain moment when entities are using an interface to request 210 for a path provisioning. In this document we have selected two 211 use cases in a scenario with routers and optical equipment to 212 obtain the requirements for this draft, but it is applicable to 213 the four options. 215 [Please refer to pdf version for the Figure] 217 Figure 2. Use case higher-layer signaling trigger 218 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 220 2.3. Higher-layer signaling trigger 222 Figure 2 depicts a multi-layer network scenario similar to the 223 presented in section 4.2.2. [RFC5623], with the difference that 224 PCE is an active stateful PCE [I-D. draft-ietf-pce-stateful- 225 pce]. 227 In this example, O1, O2 and O3 are optical nodes that are 228 connected with router nodes R1, R2 and R3, respectively. The 229 network is designed such that the interface between R1-O1, R2-O2 230 and R3-O3 are setup to provide bandwidth-on-demand via the 231 optical network. 233 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 235 The example assumes that an active stateful PCE is used for 236 setting and tearing down bandwidth-on-demand connectivity. 237 Although the simple use-case assumes a single PCE server (PCE1), 238 the proposed technique is generalized to cover multiple co- 239 operating PCE case. Similarly, although the use case assumes 240 PCE1 only has knowledge of the L3 topology, the proposed 241 technique is generalized to cover multi-layer PCE case. 243 The PCE server (PCE1) is assumed to be receiving L3 topology 244 data. It is also assumed that PCE learns L0 (optical) addresses 245 associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and 246 R3-O3. These addresses are referred by OTE-IP-R1 (optical TE 247 link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2 248 address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at 249 R3), respectively. How PCE learns the optical addresses 250 associated with the bandwidth-on-demand interfaces is beyond the 251 scope of this document. 253 How knowledge of the bandwidth-on-demand interfaces is utilized 254 by the PCE is exemplified in the following. Suppose an 255 application requests 8 Gbps from R1 to R2 (recall all interfaces 256 in Figure 1 are assumed to be 10G). PCE1 satisfies this by 257 establishing a tunnel using R1-R4-R2 path. PCEP initiated LSP 258 using techniques specified in [I-D. draft-crabbe-pce-pce- 259 initiated-lsp] can be used to establish a PSC tunnel using the 260 R1-R4-R2 path. Now assume another application requests 7 Gbps 261 service between R1 and R2. This request cannot be satisfied 262 without establishing a GMPLS tunnel via optical network using 263 bandwidth-on-demand interfaces. In this case, PCE1 initiates a 264 GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS 265 tunnel1 in the following). The PCEP initiated LSP using 266 techniques specified in document are used for this purpose. 268 As mentioned earlier, the GMPLS tunnel created on-the-fly to 269 satisfy bandwidth demand of L3 applications cannot be pre- 270 provisioned in IP network, as bandwidth-on-demand interfaces and 271 spare bandwidth in the optical network are shared. Furthermore, 272 in this example, as active stateful PCE is used for managing 273 PCE-initiated LSP, PCC may not be aware of the intended usage of 274 the PCE-initiated LSP. Specifically, when the PCE1 initiated 275 GMPLS tunnel1, PCC does not know the IGP instance whose demand 276 leads to establishment of the GMPLS tunnel1 and hence does not 277 know the IGP instance in which the GMPLS tunnel1 needs to be 278 advertised. Similarly, the PCC does not know IP address that 279 should be assigned to the GMPLS tunnel1. In the above example, 280 this IP address is labeled as TUN-IP-R1 (tunnel IP address at 281 R1). The PCC also does not know if the tunnel needs to be 282 advertised as forwarding and/ or routing adjacency and/or to be 283 locally used by the target IGP instance. Similarly, egress node 284 for GMPLS signaling (R2 node in this example) may not know the 285 intended usage of the tunnel (tunnel1 in this example). For 286 example, the R2 node does not know IP address that should be 287 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 289 assigned to the GMPLS tunnel1. In the above example, this IP 290 address is labeled as TUN-IP-R2 (tunnel IP address at R2). 291 Section 6 of this draft addresses the requirement to specify on 292 how PCC and egress node for signaling should use the PCEP 293 initiated LSPs. 295 2.4. NMS-VNTM cooperation model (separated flavor) 297 Figure 3 depicts NMS-VNTM cooperation model. This is the 298 separated flavor, because NMS and VNTM are not in the same 299 location. 301 A new L3 path is requested from NMS, because there is an 302 automated process in the NMS or after human intervention. NMS 303 does not have information about all network information, so it 304 consults L3 PCE. For shake of simplicity L3-PCE is used, but any 305 other multi-layer cooperating PCE model is applicable. In case 306 that there are enough resources in the L3 layer, L3-PCE returns 307 a L3 only path. On the other hand, if there is a lack of 308 resources at the L3 layer, the response does not have any path 309 or may contain a multilayer path with L3 and L0 (optical) 310 information in case of a ML-PCE. In case of there is not a path 311 in L3; NMS sends a message to the VNTM to create a GMPLS LSP in 312 the lower layer. When the VNTM receives this message, based on 313 the local policies, accepts the suggestion and sends a similar 314 message to the router, which can create the lower layer LSP via 315 UNI signaling in the routers, like in use case in section 2.3.1. 316 Similarly, VNTM may talk with L0-PCE to set-up the path in the 317 optical domain (section 2.2). This second option looks more 318 complex, because it requires VNTM configuring inter-layer TE- 319 links. 321 Requirements for the message from VNTM to the router are the 322 same than in the previous use case (section 2.3.1). Regarding 323 NMS to VNTM message, the requirements here depends on who has 324 all the information. Three different addresses are required in 325 this use case: (1) L3, (2) L0 and (3) inter-layer addressing. In 326 case there is a non-cooperating L3-PCE, information about inter- 327 layer connections have to be stored (or discovered) by VNTM. If 328 there is a ML-PCE and this information is obtained from the 329 network, the message would be the same than in section 2.3.1. 331 [Please refer to pdf version for the Figure] 333 Figure 3. Use case NMS-VNTM cooperation model 334 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 336 3. GMPLS Requirements for Remote-Initiated LSPs 338 [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures 339 that can be used for creation and deletion of PCE-initiated LSPs 340 under the active stateful PCE model. However, this specification 341 does not address GMPLS requirements outlined in the following: 343 - GMPLS support multiple switching capabilities on per TE link 344 basis. GMPLS LSP creation requires knowledge of LSP switching 345 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 346 [RFC3471], [RFC3473]. 348 - GMPLS LSP creation requires knowledge of the encoding type 349 (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) 350 to be used by the LSP [RFC3471], [RFC3473]. 352 - GMPLS LSP creation requires information of the generalized 353 payload (G-PID) to be carried by the LSP [RFC3471], 354 [RFC3473]. 356 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 358 - GMPLS LSP creation requires specification of data flow 359 specific traffic parameters (also known as Tspec), which are 360 technology specific. 362 - GMPLS also specifics support for asymmetric bandwidth 363 requests [RFC6387]. 365 - GMPLS extends the addressing to include unnumbered interface 366 identifiers, as defined in [RFC3477]. 368 - In some technologies path calculation is tightly coupled with 369 label selection along the route. For example, path 370 calculation in a WDM network may include lambda continuity 371 and/ or lambda feasibility constraints and hence a path 372 computed by the PCE is associated with a specific lambda 373 (label). Hence, in such networks, the label information needs 374 to be provided to a PCC in order for a PCE to initiate GMPLS 375 LSPs under the active stateful PCE model. I.e., explicit 376 label control may be required. 378 - GMPLS specifics protection context for the LSP, as defined in 379 [RFC4872] and [RFC4873]. 381 4. Remote Initiated LSP Usage Requirement 383 The requirement to specify usage of the LSP to the PCC includes 384 but not limited to specification of the following information. 386 - The target IGP instance for the Remote-initiated LSP needs to 387 be specified. 389 - In the target IGP instance, should the PCE-initiated LSP be 390 advertised as a forwarding adjacency and/ or routing 391 adjacency and/ or to be used locally by the PCC? 393 - Should the as Remote-initiated LSP be advertised an IPv4 FA/ 394 RA, IPv6 FA/ RA or as unnumbered FA/ RA. 396 - If Remote-initiated LSP is to be advertised an IPv4 FA/ RA, 397 IPv6 FA/ RA, what is the local and remote IP address is to be 398 used for the advertisement. 400 5. PCEP Extensions for Remote-Initiated GMPLS LSPs 402 Section 3 outlines GMPLS and application requirements that need 403 to be satisfied in order for a PCE to initiate GMPLS LSPs under 404 the active stateful PCE model. The section provides PCEP 405 protocol extensions required to meet these requirements. 407 Expires January 2014 [Page 408 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 410 LSP create message defined in [I-D. draft-crabbe-pce-pce- 411 initiated-lsp] needs to be extended to include GMPLS specific 412 PCEP objects as follows: 414 5.1. Generalized Endpoint in LSP Create Message 416 This document does not modify the usage of END-POINTS object for 417 PCE initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 418 initiated-lsp]. It augments the usage as specified below. 420 END-POINTS object has been extended by [I-D. draft-ietf-pcep- 421 gmpls-ext] to include a new object type called ''Generalized 422 Endpoint''. PCCreate message sent by a PCE to a PCC to trigger a 423 GMPLS LSP instantiation SHOULD include the END-POINTS with 424 Generalized Endpoint object type. Furthermore, the END-POINTS 425 object MUST contain ''label request'' TLV. The label request TLV 426 is used to specify the switching type, encoding type and GPID of 427 the LSP being instantiated by the PCE. 429 As mentioned earlier, the PCE server is assumed to be receiving 430 topology data. In the use case of higher-layer signaling 431 trigger, the addresses associated with bandwidth-on-demand 432 interfaces are included, e.g., OTE-IP-R1, OTE-IP-R2 and OTE-IP- 433 R3, in the use case example. These addresses and R1, R2 and R3 434 router IDs are used to derive source and destination address of 435 the END-POINT object. As previously mentioned, in the case of 436 NMS-VNMT cooperation model with L3 PCE, VNTM must receive such 437 inter-layer interface association to configure the whole path. 439 The unnumbered endpoint TLV can be used to specify unnumbered 440 endpoint addresses for the LSP being instantiated by the PCE. 441 The END-POINTS MAY contain other TLVs defined in [I-D. draft- 442 ietf-pcep-gmpls-ext]. 444 If the END-POINTS Object of type Generalized Endpoint is missing 445 the label request TLV, the PCC MUST send a PCErr message with 446 Error-type=6 (Mandatory Object missing) and Error-value= TBA 447 (LSP request TLV missing). 449 If the PCC does not support the END-POINTS Object of type 450 Generalized Endpoint, the PCC MUST send a PCErr message with 451 Error-type= ???? and Error-value= ???. [??? = already defined 452 values to be looked up]. 454 5.2. GENERALIZED-BANDWIDTH object in LSP Create Message 456 LSP create message defined in [I-D. draft-crabbe-pce-pce- 457 initiated-lsp] can optionally include the BANDWIDTH object. 458 However, the following possibilities cannot be represented in 459 the BANDWIDTH object: 461 Expires January 2014 [Page 462 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 464 - Asymmetric bandwidth (different bandwidth in forward and 465 reverse direction), as described in [RFC6387]. 467 - Technology specific GMPLS parameters (e.g., Tspec for 468 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 470 GENERALIZED-BANDWIDTH object has been defined in [I-D. draft- 471 ietf-pcep-gmpls-ext] to address the above-mentioned limitation 472 of the BANDWIDTH object. 474 This document specifies the use of GENERALIZED-BANDWIDTH object 475 in PCCreate message. Specifically, GENERALIZED-BANDWIDTH object 476 MAY be included in the PCCreate message. The GENERALIZED- 477 BANDWIDTH object in PCCreate message is used to specify 478 technology specific Tspec and asymmetrical bandwidth values for 479 the LSP being instantiated by the PCE. 481 5.3. Protection Attributes in LSP Create Message 483 This document does not modify the usage of LSPA object for PCE 484 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 485 initiated-lsp]. It augments the usage of LSPA object in LSP 486 Create Message to carry the end-to-end protection context this 487 also includes the protection state information. 489 The LSP Protection Information TLV of LSPA in the PCCreate 490 message can be used to specify protection attributes of the LSP 491 being instantiated by the PCE. 493 5.4. ERO in LSP Create Object 495 This document does not modify the usage of ERO object for PCE 496 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 497 initiated-lsp]. It augments the usage as specified in the 498 following sections. 500 5.4.1. ERO with explicit label control 502 As mentioned earlier, there are technologies and scenarios where 503 active stateful PCE requires explicit label control in order to 504 instantiate an LSP. 506 Explicit label control (ELC) is a procedure supported by RSVP- 507 TE, where the outgoing label(s) is (are) encoded in the ERO. [I- 508 D. draft-ietf-pcep-gmpls-ext] extends the object of PCEP 509 to include explicit label control. The ELC procedure enables the 510 PCE to provide such label(s) directly in the path ERO. 512 The extended ERO object in PCCreate message can be used to 513 specify label along with ERO to PCC for the LSP being 514 instantiated by the active stateful PCE. 515 Expires January 2014 [Page 516 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 518 5.4.2. ERO with Path Keys 520 There are many scenarios in packet and optical networks where 521 the route information of an LSP may not be provided to the PCC 522 for confidentiality reasons. A multi-domain or multi-layer 523 network is an example of such networks. Similarly, a GMPLS User- 524 Network Interface (UNI) [RFC4208] is also an example of such 525 networks. 527 In such scenarios, ERO containing the entire route cannot be 528 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 529 Keys to the PCC. For example, in the case UNI interface between 530 the router and the optical nodes, the ERO in the LSP Create 531 Message may be constructed as follows: 533 - The first hop is a strict hop that provides the egress 534 interface information at PCC. This interface information is 535 used to get to a network node that can extend the rest of the 536 ERO. (Please note that in the cases where the network node is 537 not directly connected with the PCC, this part of ERO may 538 consist of multiple hops and may be loose). 539 - The following(s) hop in the ERO may provide the network node 540 with the path key [RFC5520] that can be resolved to get the 541 contents of the route towards the destination. 542 - There may be further hops but these hops may also be encoded 543 with the path keys (if needed). 545 This document does not change encoding or processing roles for 546 the path keys, which are defined in [RFC5520]. 548 5.4.3. Switch Layer Object 550 [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER 551 object which defines and specifies the switching layer (or 552 layers) in which a path MUST or MUST NOT be established. A 553 switching layer is expressed as a switching type and encoding 554 type. [I-D. draft-ietf-pcep-gmpls-ext], which defines the GMPLS 555 extensions for PCEP, suggests using the SWITCH-LAYER object. 556 Thus, SWITCH-LAYER object can be used in the PCCreate message to 557 specify the switching layer (or layers) of the LSP being 558 remotely initiated. 560 Expires January 2014 [Page 561 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 563 6. PCEP extension for PCEP Initiated LSP Usage Specification 565 The requirement to specify on how PCC should use the PCEP 566 initiated LSPs in outlined in Section 4. This subsection 567 specifies PCEP extension used to satisfy this requirement. 569 PCEP extensions specified in this section are equally applicable 570 to PCEP initiated MPLS as well as GMPLS LSPs. 572 6.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Create Message 574 [RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for 575 communicating usage of the forwarding or routing adjacency from 576 the ingress node to the egress node. This document extends the 577 LSP Create Message to include LSP_TUNNEL_INTERFACE_ID object 578 defined in [RFC6107]. Object class and type for the 579 LSP_TUNNEL_INTERFACE_ID object are as follows: 581 Object Name: LSP_TUNNEL_INTERFACE_ID 583 Object-Class Value: TBA by Iana (suggested value: 40) 585 Object-type: 1 587 The contents of this object are identical in encoding to the 588 contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined 589 in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE 590 LSP_TUNNEL_INTERFACE_ID object are acceptable in this object. 591 The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond 592 to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please 593 note that use of TLV type 1 defined in [RFC3477] is not 594 specified by this document. 596 TLV TLV 597 Type Description Reference 598 -- ------------------------------------------------- ---------- 599 2 IPv4 interface identifier with target IGP instance [RFC6107] 601 3 IPv6 interface identifier with target IGP instance [RFC6107] 603 4 Unnumbered interface with target IGP instance 604 [RFC6107] 606 The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID 607 object are identical to those defined for the RSVP-TE 608 LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the 609 fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV 610 are identical to those defined for the corresponding RSVP-TE 611 LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have 612 slightly different usage. 614 Expires January 2014 [Page 615 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 617 - IPv4 Interface Address field in IPv4 interface identifier with 618 target IGP instance TLV: This field indicates the local IPv4 619 address to be assigned to the tunnel at the PCC (ingress node 620 for RSVP-TE signaling). In the example use case of Section 2, 621 IP address TUN-IP-R1 (tunnel IP address at R1) is carried in 622 this field (if TUN-IP-R1 is a v4 address). 624 - IPv6 Interface Address field in IPv4 interface identifier with 625 target IGP instance TLV: This field indicates the local IPv6 626 address to be assigned to the tunnel at the PCC (ingress node 627 for RSVP-TE signaling). In the example use case of Section 2, 628 IP address TUN-IP-R1 (tunnel IP address at R1) is carried in 629 this field (if TUN-IP-R1 is a v6 address). 631 - LSR's Router ID field in Unnumbered interface with target IGP 632 instance: The PCC SHOULD use the LSR's Router ID in Unnumbered 633 interface with target IGP instance in advertising the LSP 634 being initiated by the PCE. In the example use case of Section 635 2, this field carries router-id of R1 in the target IGP 636 instance. 638 - Interface ID (32 bits) field in unnumbered interface with 639 target IGP instance: All bits of this field MUST be set to 0 640 by the PCE server and MUST be ignored by PCC. PCC SHOULD 641 allocate an Interface ID that fulfills Interface ID 642 requirements specified in [RFC3477]. 644 When the Ingress PCC receives an LPS Request Message with 645 LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained 646 in the TLV to drive the IGP instance, treatment of the LSP being 647 initiated in the target IGP instance (e.g., FA, RA or local 648 usage), the local IPv4 or IPv6 address or router-id for 649 unnumbered case to be used for advertisement of the LSP being 650 instantiated. 652 6.2. Communicating LSP usage to Egress node 654 PCE does not need to send LSP Create message to egress node 655 (node R2 in the example of section 2) to communicate LSP usage 656 information. Instead PCC (Ingres signaling node) uses RSVP-TE 657 signaling mechanism specified in [RFC6107] to send the LSP usage 658 to Egress node. Specifically, when the Ingress PCC receives an 659 LPS Request Message with LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD 660 add LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For 661 this purpose, it is RECOMMENDED that the ingress PCC uses 662 content of the LSP_TUNNEL_INTERFACE_ID TLV in LSP Create Message 663 in PCEP to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This 664 document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object 665 in RSVP-TE signaling as specified in [RFC6107]. 667 Expires January 2014 [Page 668 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 670 The egress node uses information contained in the 671 LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive 672 the IGP instance, treatment of the LSP being initiated in the 673 target IGP instance (e.g., FA, RA or local usage), the local 674 IPv4 or IPv6 address or router-id for unnumbered case to be used 675 for advertisement of the LSP being instantiated. 677 6.3. LSP delegation and cleanup 679 LSP delegation and cleanup procedure specified in [I-D. draft- 680 ietf-pcep-gmpls-ext] are equally applicable to GMPLS LSPs and 681 this document does not modify the associated usage. 683 7. Security Considerations 685 To be added in future revision of this document. 687 8. IANA Considerations 689 8.1. END-POINT Object 691 This document extends the LSP Create Message to include 692 LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object 693 class and type for the LSP_TUNNEL_INTERFACE_ID object are as 694 follows: 696 Name Class value Type 697 ---- ----------- ---- 698 LSP_TUNNEL_INTERFACE_ID TBA by Iana (Suggested:40) 1 700 8.2. PCEP-Error Object 702 This document defines the following new Error-Value: 704 Error-Type Error Value 706 6 Error-value=TBA: LSP Request TLV missing 708 9. Acknowledgments 710 The authors would like to thank George Swallow and Jan Medved 711 for their comments. 713 10. References 715 10.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 Expires January 2014 [Page 720 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 722 [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, 723 I., Sivabalan, S., Varga, R., ''PCEP Extensions for 724 PCE-initiated LSP Setup in a Stateful PCE Model'', 725 draft-crabbe-pce-pce-initiated-lsp, work in progress. 727 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 728 Computation Element (PCE) Communication Protocol 729 (PCEP)", RFC 5440, March 2009. 731 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 732 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 733 Traffic Engineering", RFC 5623, September 2009. 735 [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 736 for Dynamically Signaled Hierarchical Label Switched 737 Paths", RFC 6107, February 2011. 739 10.2. Informative References 741 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 742 Switching (GMPLS) Signaling Functional Description", 743 RFC 3471, January 2003. 745 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 746 Switching (GMPLS) Signaling Resource ReserVation 747 Protocol-Traffic Engineering (RSVP-TE) Extensions", 748 RFC 3473, January 2003. 750 [RFC 5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and 751 J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional 752 Label Switched Paths (LSPs)", RFC 5467, March 2009. 754 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 755 Links in Resource ReSerVation Protocol - Traffic 756 Engineering (RSVP-TE)", RFC 3477, January 2003. 758 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 759 Ed., "RSVP-TE Extensions in Support of End-to-End 760 Generalized Multi-Protocol Label Switching (GMPLS) 761 Recovery", RFC 4872, May 2007. 763 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 764 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 766 Expires January 2014 [Page 767 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-01.txt 769 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 770 "Generalized Multiprotocol Label Switching (GMPLS) 771 User-Network Interface (UNI): Resource ReserVation 772 Protocol-Traffic Engineering (RSVP-TE) Support for the 773 Overlay Model", RFC 4208, October 2005. 775 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 776 "Preserving Topology Confidentiality in Inter-Domain 777 Path Computation Using a Path-Key-Based Mechanism", 778 RFC 5520, April 2009. 780 Authors' Addresses 782 Zafar Ali 783 Cisco Systems 784 Email: zali@cisco.com 786 Siva Sivabalan 787 Cisco Systems 788 Email: msiva@cisco.com 790 Clarence Filsfils 791 Cisco Systems 792 Email: cfilsfil@cisco.com 794 Robert Varga 795 Pantheon Technologies 797 Victor Lopez 798 Telefonica I+D 799 Email: vlopez@tid.es 801 Oscar Gonzalez de Dios 802 Telefonica I+D 803 Email: ogondio@tid.es 805 Expires January 2014 [Page