idnits 2.17.1 draft-ali-pce-remote-initiated-gmpls-lsp-02.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 8 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2013) is 3840 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: 'RFC6387' is mentioned on line 353, but not defined == Unused Reference: 'RFC5440' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC 6107' is defined on line 497, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5623 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: April 20, 2014 Cisco Systems 6 Robert Varga 7 Pantheon Technologies 8 Victor Lopez 9 Oscar Gonzalez de Dios 10 Telefonica I+D 11 Xian Zhang 12 Huawei 14 October 21, 2013 16 Path Computation Element Communication Protocol (PCEP) 17 Extensions for remote-initiated GMPLS LSP Setup 18 draft-ali-pce-remote-initiated-gmpls-lsp-02.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 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on April 20, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) 61 controlling the copyright in such materials, this document may not 62 be modified outside the IETF Standards Process, and derivative 63 works of it may not be created outside the IETF Standards Process, 64 except to format it for publication as an RFC or to translate it 65 into languages other than English. 67 Abstract 69 Draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies 70 procedures that can be used for creation and deletion of PCE- 71 initiated LSPs in the active stateful PCE model. However, this 72 specification focuses on MPLS networks, and does not cover remote 73 instantiation of paths in GMPLS-controlled networks. This document 74 complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by addressing 75 the requirements for remote-initiated GMPLS LSPs. 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 81 this document are to be interpreted as described in RFC 2119 82 [RFC2119]. 84 Table of Contents 86 1. Introduction.................................................. 3 87 2. Use Cases .....................................................3 88 2.1. Single-layer provisioning from active stateful PCE ........3 89 2.2. Multi-layer networks ......................................4 90 2.2.1. Higher-layer signaling trigger ......................4 91 2.3. NMS-VNTM cooperation model (separated flavor) .............6 92 3. Requirements for Remote-Initiated GMPLS LSPs ..................7 93 4. PCEP Extensions for Remote-Initiated GMPLS LSPs ...............7 94 4.1. Generalized Endpoint in LSP Initiate Message ..............8 95 4.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message ......8 96 4.3. Protection Attributes in LSP Initiate Message .............9 97 4.4. ERO in LSP Initiate Object ................................9 98 4.4.1. ERO with explicit label control .....................9 99 4.4.2. ERO with Path Keys ..................................9 100 4.4.3. Switch Layer Object ................................10 101 4.5. LSP delegation and cleanup ...............................10 102 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 104 5. Security Considerations ......................................10 105 6. IANA Considerations ..........................................11 106 6.1. PCEP-Error Object ........................................11 107 7. Acknowledgments ..............................................11 108 8. References ...................................................11 109 8.1. Normative References .....................................11 110 8.2. Informative References ...................................11 112 1. Introduction 114 The Path Computation Element communication Protocol (PCEP) 115 provides mechanisms for Path Computation Elements (PCEs) to 116 perform route computations in response to Path Computation 117 Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP 118 Setup in a Stateful PCE Model draft [I-D. draft-ietf-pce- 119 stateful-pce] describes a set of extensions to PCEP to enable 120 active control of MPLS-TE and GMPLS network. 122 [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup 123 and teardown of PCE-initiated LSPs under the active stateful PCE 124 model, without the need for local configuration on the PCC. This 125 enables realization of a dynamic network that is centrally 126 controlled and deployed. However, this specification is focused 127 on MPLS networks, and does not cover the GMPLS networks (e.g., 128 WSON, OTN, SONET/ SDH, etc. technologies). This document 129 complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by 130 addressing the requirements for remote-initiated GMPLS LSPs. 131 These requirements are covered in Section 3 of this draft. The 132 PCEP extensions for remote initiated GMPLS LSPs are specified in 133 Section 4. 135 2. Use Cases 137 2.1. Single-layer provisioning from active stateful PCE 139 Figure 1 shows a single-layer topology with optical nodes with a 140 GMPLS control plane. In this scenario, the active PCE can 141 dynamically instantiate or delete L0 services between client 142 interfaces. This process can be triggered by the deployment of a 143 new network configuration or a re-optimization process. This 144 operation can be human-driven (e.g. through an NMS) or an 145 automatic process. 147 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 149 [See PDF version of the document for Figures] 151 Figure 1. Single-layer provisioning from active stateful PCE. 153 L0 PCE obtains resources information via control plane 154 collecting LSAs messages. The PCE computes the path and sends a 155 message to the optical equipment with Explicate Route Object 156 (ERO) information. 158 2.2. Multi-layer networks 160 This use case assumes there is a multi-layer network composed by 161 routers and optical equipment. According to [RFC5623], there are 162 four inter-layer path control models: (1) PCE-VNTM cooperation, 163 (2) Higher-layer signaling trigger, (3) NMS-VNTM cooperation 164 model (integrated flavor) and (4) NMS-VNTM cooperation model 165 (separated flavor). In the following we have selected two use 166 cases to explain the requirements considered in this draft, but 167 the document is applicable to all four options. 169 2.2.1. Higher-layer signaling trigger 171 Figure 2 depicts a multi-layer network scenario similar to the 172 one presented in section 4.2.2. [RFC5623], with the difference 173 that PCE is an active stateful PCE [I-D. draft-ietf-pce- 174 stateful-pce]. 176 In this example, O1, O2 and O3 are optical nodes that are 177 connected with router nodes R1, R2 and R3, respectively. The 178 network is designed such that the interface between R1-O1, R2-O2 179 and R3-O3 are setup to provide bandwidth-on-demand via the 180 optical network. 182 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 184 [See PDF version of the document for Figures] 186 Figure 2. Use case higher-layer signaling trigger 188 The example assumes that an active stateful PCE is used for 189 setting and tearing down bandwidth-on-demand connectivity. 190 Although the simple use-case assumes a single PCE server (PCE1), 191 the proposed technique is generalized to cover multiple co- 192 operating PCE case. Similarly, although the use case assumes 193 PCE1 only has knowledge of the L3 topology, the proposed 194 technique is generalized to cover multi-layer PCE case. 196 The PCE server (PCE1) is assumed to be receiving L3 topology 197 data. It is also assumed that PCE learns L0 (optical) addresses 198 associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and 199 R3-O3. These addresses are referred by OTE-IP-R1 (optical TE 200 link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2 201 address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at 202 R3), respectively. How PCE learns the optical addresses 203 associated with the bandwidth-on-demand interfaces is beyond the 204 scope of this document. 206 How knowledge of the bandwidth-on-demand interfaces is utilized 207 by the PCE is exemplified in the following. Suppose an 208 application requests 8 Gbps from R1 to R2 (recall all interfaces 209 in Figure 1 are assumed to be 10G). PCE1 satisfies this by 210 establishing a tunnel using R1-R4-R2 path. Remote initiated LSP 211 using techniques specified in [I-D. draft-crabbe-pce-pce- 212 initiated-lsp] can be used to establish a PSC tunnel using the 213 R1-R4-R2 path. Now assume another application requests 7 Gbps 214 service between R1 and R2. This request cannot be satisfied 215 without establishing a GMPLS tunnel via optical network using 216 bandwidth-on-demand interfaces. In this case, PCE1 initiates a 217 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 219 GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS 220 tunnel1 in the following). The remote initiated LSP using 221 techniques specified in document is used for this purpose. 223 2.3. NMS-VNTM cooperation model (separated flavor) 225 Figure 3 depicts NMS-VNTM cooperation model. This is the 226 separated flavor, because NMS and VNTM are not in the same 227 location. 229 [See PDF version of the document for Figures] 231 Figure 3. Use case NMS-VNTM cooperation model 233 A new L3 path is requested from NMS (e.g., via an automated 234 process in the NMS or after human intervention). NMS does not 235 have information about all network information, so it consults 236 L3 PCE. For shake of simplicity L3-PCE is used, but any other 237 multi-layer cooperating PCE model is applicable. In case that 238 there are enough resources in the L3 layer, L3-PCE returns a L3 239 only path. On the other hand, if there is a lack of resources at 240 the L3 layer, L3 PCE does not return a Path. Consequently, NMS 241 sends a message to the VNTM to initiate a GMPLS LSP in the lower 242 layer. When the VNTM receives this message, based on the local 243 policies, accepts the suggestion and sends a similar message to 244 the router, which can initiate the lower layer LSP via UNI 245 signaling in the routers. Similarly, VNTM may talk with L0-PCE 246 to set-up the path in the optical domain. 248 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 250 Requirements for the remote initiated GMPLS LSP from VNTM to the 251 router are the same as discussed in the previous use case. The 252 remote initiated LSP using techniques specified in document is 253 used for this purpose. 255 3. Requirements for Remote-Initiated GMPLS LSPs 257 [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures 258 that can be used for creation and deletion of PCE-initiated LSPs 259 under the active stateful PCE model. However, this specification 260 does not address GMPLS requirements outlined in the following: 262 - GMPLS support multiple switching capabilities on per TE link 263 basis. GMPLS LSP creation requires knowledge of LSP switching 264 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 265 [RFC3471], [RFC3473]. 267 - GMPLS LSP creation requires knowledge of the encoding type 268 (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) 269 to be used by the LSP [RFC3471], [RFC3473]. 271 - GMPLS LSP creation requires information of the generalized 272 payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473]. 274 - GMPLS LSP creation requires specification of data flow 275 specific traffic parameters (also known as Tspec), which are 276 technology specific. 278 - GMPLS also specifics support for asymmetric bandwidth 279 requests [RFC6387]. 281 - GMPLS extends the addressing to include unnumbered interface 282 identifiers, as defined in [RFC3477]. 284 - In some technologies path calculation is tightly coupled with 285 label selection along the route. For example, path calculation 286 in a WDM network may include lambda continuity and/ or lambda 287 feasibility constraints and hence a path computed by the PCE 288 is associated with a specific lambda (label). Hence, in such 289 networks, the label information needs to be provided to a PCC 290 in order for a PCE to initiate GMPLS LSPs under the active 291 stateful PCE model. I.e., explicit label control may be 292 required. 294 - GMPLS specifics protection context for the LSP, as defined in 295 [RFC4872] and [RFC4873]. 297 4. PCEP Extensions for Remote-Initiated GMPLS LSPs 299 LSP initiate (PCInitiate) message defined in [I-D. draft-crabbe- 300 pce-pce-initiated-lsp] needs to be extended to include GMPLS 301 specific PCEP objects as follows: 303 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 305 4.1. Generalized Endpoint in LSP Initiate Message 307 This document does not modify the usage of END-POINTS object for 308 PCE initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 309 initiated-lsp]. It augments the usage as specified below. 311 END-POINTS object has been extended by [I-D. draft-ietf-pcep- 312 gmpls-ext] to include a new object type called "Generalized 313 Endpoint". PCInitiate message sent by a PCE to a PCC to trigger 314 a GMPLS LSP instantiation SHOULD include the END-POINTS with 315 Generalized Endpoint object type. Furthermore, the END-POINTS 316 object MUST contain "label request" TLV. The label request TLV 317 is used to specify the switching type, encoding type and GPID of 318 the LSP being instantiated by the PCE. 320 As mentioned earlier, the PCE server is assumed to be receiving 321 topology data. In the use case of higher-layer signaling 322 trigger, the addresses associated with bandwidth-on-demand 323 interfaces are included, e.g., OTE-IP-R1, OTE-IP-R2 and OTE-IP- 324 R3, in the use case example. These addresses and R1, R2 and R3 325 router IDs are used to derive source and destination address of 326 the END-POINT object. As previously mentioned, in the case of 327 NMS-VNMT cooperation model with L3 PCE, VNTM must receive such 328 inter-layer interface association to configure the whole path. 330 The unnumbered endpoint TLV can be used to specify unnumbered 331 endpoint addresses for the LSP being instantiated by the PCE. 332 The END-POINTS MAY contain other TLVs defined in [I-D. draft- 333 ietf-pcep-gmpls-ext]. 335 If the END-POINTS Object of type Generalized Endpoint is missing 336 the label request TLV, the PCC MUST send a PCErr message with 337 Error-type=6 (Mandatory Object missing) and Error-value= TBA 338 (LSP request TLV missing). 340 If the PCC does not support the END-POINTS Object of type 341 Generalized Endpoint, the PCC MUST send a PCErr message with 342 Error-type = 3 (Unknown Object), Error-value = 2(unknown object 343 type). 345 4.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 347 LSP initiate message defined in [I-D. draft-crabbe-pce-pce- 348 initiated-lsp] can optionally include the BANDWIDTH object. 349 However, the following possibilities cannot be represented in 350 the BANDWIDTH object: 352 - Asymmetric bandwidth (different bandwidth in forward and 353 reverse direction), as described in [RFC6387]. 355 - Technology specific GMPLS parameters (e.g., Tspec for 356 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 358 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 360 GENERALIZED-BANDWIDTH object has been defined in [I-D. draft- 361 ietf-pcep-gmpls-ext] to address the above-mentioned limitation 362 of the BANDWIDTH object. 364 This document specifies the use of GENERALIZED-BANDWIDTH object 365 in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH 366 object MAY be included in the PCInitiate message. The 367 GENERALIZED-BANDWIDTH object in PCInitiate message is used to 368 specify technology specific Tspec and asymmetrical bandwidth 369 values for the LSP being instantiated by the PCE. 371 4.3. Protection Attributes in LSP Initiate Message 373 This document does not modify the usage of LSPA object for PCE 374 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 375 initiated-lsp]. It augments the usage of LSPA object in LSP 376 Initiate Message to carry the end-to-end protection context this 377 also includes the protection state information. 379 The LSP Protection Information TLV of LSPA in the PCInitiate 380 message can be used to specify protection attributes of the LSP 381 being instantiated by the PCE. 383 4.4. ERO in LSP Initiate Object 385 This document does not modify the usage of ERO object for PCE 386 initiated LSPs as specified in [I-D. draft-crabbe-pce-pce- 387 initiated-lsp]. It augments the usage as specified in the 388 following sections. 390 4.4.1. ERO with explicit label control 392 As mentioned earlier, there are technologies and scenarios where 393 active stateful PCE requires explicit label control in order to 394 instantiate an LSP. 396 Explicit label control (ELC) is a procedure supported by RSVP- 397 TE, where the outgoing label(s) is (are) encoded in the ERO. [I- 398 D. draft-ietf-pcep-gmpls-ext] extends the object of PCEP 399 to include explicit label control. The ELC procedure enables the 400 PCE to provide such label(s) directly in the path ERO. 402 The extended ERO object in PCInitiate message can be used to 403 specify label along with ERO to PCC for the LSP being 404 instantiated by the active stateful PCE. 406 4.4.2. ERO with Path Keys 408 There are many scenarios in packet and optical networks where 409 the route information of an LSP may not be provided to the PCC 410 for confidentiality reasons. A multi-domain or multi-layer 411 network is an example of such networks. Similarly, a GMPLS User- 412 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 414 Network Interface (UNI) [RFC4208] is also an example of such 415 networks. 417 In such scenarios, ERO containing the entire route cannot be 418 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 419 Keys to the PCC. For example, in the case UNI interface between 420 the router and the optical nodes, the ERO in the LSP Initiate 421 Message may be constructed as follows: 423 - The first hop is a strict hop that provides the egress 424 interface information at PCC. This interface information is 425 used to get to a network node that can extend the rest of the 426 ERO. (Please note that in the cases where the network node is 427 not directly connected with the PCC, this part of ERO may 428 consist of multiple hops and may be loose). 429 - The following(s) hop in the ERO may provide the network node 430 with the path key [RFC5520] that can be resolved to get the 431 contents of the route towards the destination. 432 - There may be further hops but these hops may also be encoded 433 with the path keys (if needed). 435 This document does not change encoding or processing roles for 436 the path keys, which are defined in [RFC5520]. 438 4.4.3. Switch Layer Object 440 [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER 441 object which defines and specifies the switching layer (or 442 layers) in which a path MUST or MUST NOT be established. A 443 switching layer is expressed as a switching type and encoding 444 type. [I-D. draft-ietf-pcep-gmpls-ext], which defines the GMPLS 445 extensions for PCEP, suggests using the SWITCH-LAYER object. 446 Thus, SWITCH-LAYER object can be used in the PCInitiate message 447 to specify the switching layer (or layers) of the LSP being 448 remotely initiated. 450 4.5. LSP delegation and cleanup 452 LSP delegation and cleanup procedure specified in [I-D. draft- 453 ietf-pcep-gmpls-ext] are equally applicable to GMPLS LSPs and 454 this document does not modify the associated usage. 456 5. Security Considerations 458 To be added in future revision of this document. 460 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 462 6. IANA Considerations 464 6.1. PCEP-Error Object 466 This document defines the following new Error-Value: 468 Error-Type Error Value 470 6 Error-value=TBA: LSP Request TLV missing 472 7. Acknowledgments 474 The authors would like to thank George Swallow and Jan Medved 475 for their comments. 477 8. References 479 8.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, 485 I., Sivabalan, S., Varga, R., "PCEP Extensions for 486 PCE-initiated LSP Setup in a Stateful PCE Model", 487 draft-crabbe-pce-pce-initiated-lsp, work in progress. 489 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 490 Computation Element (PCE) Communication Protocol 491 (PCEP)", RFC 5440, March 2009. 493 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 494 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 495 Traffic Engineering", RFC 5623, September 2009. 497 [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 498 for Dynamically Signaled Hierarchical Label Switched 499 Paths", RFC 6107, February 2011. 501 8.2. Informative References 503 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 504 Switching (GMPLS) Signaling Functional Description", 505 RFC 3471, January 2003. 507 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 508 Switching (GMPLS) Signaling Resource ReserVation 509 Protocol-Traffic Engineering (RSVP-TE) Extensions", 510 RFC 3473, January 2003. 512 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 514 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 515 Links in Resource ReSerVation Protocol - Traffic 516 Engineering (RSVP-TE)", RFC 3477, January 2003. 518 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 519 Ed., "RSVP-TE Extensions in Support of End-to-End 520 Generalized Multi-Protocol Label Switching (GMPLS) 521 Recovery", RFC 4872, May 2007. 523 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 524 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 526 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 527 "Generalized Multiprotocol Label Switching (GMPLS) 528 User-Network Interface (UNI): Resource ReserVation 529 Protocol-Traffic Engineering (RSVP-TE) Support for the 530 Overlay Model", RFC 4208, October 2005. 532 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 533 "Preserving Topology Confidentiality in Inter-Domain 534 Path Computation Using a Path-Key-Based Mechanism", 535 RFC 5520, April 2009. 537 Author's Addresses 539 Zafar Ali 540 Cisco Systems 541 Email: zali@cisco.com 543 Siva Sivabalan 544 Cisco Systems 545 Email: msiva@cisco.com 547 Clarence Filsfils 548 Cisco Systems 549 Email: cfilsfil@cisco.com 551 Robert Varga 552 Pantheon Technologies 554 Victor Lopez 555 Telefonica I+D 556 Email: vlopez@tid.es 558 Oscar Gonzalez de Dios 559 Telefonica I+D 560 Email: ogondio@tid.es 561 Internet-Draft draft-ali-pce-remote-initiated-gmpls-lsp-02.txt 563 Xian Zhang 564 Huawei Technologies 565 Email: zhang.xian@huawei.com