idnits 2.17.1 draft-ietf-ccamp-rsvp-te-srlg-collect-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3472 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: April 26, 2015 Telefonica Global CTO 6 D. Li 7 Huawei 8 C. Margaria 10 M. Hartley 11 Z. Ali 12 Cisco 13 October 23, 2014 15 RSVP-TE Extensions for Collecting SRLG Information 16 draft-ietf-ccamp-rsvp-te-srlg-collect-08 18 Abstract 20 This document provides extensions for the Resource ReserVation 21 Protocol-Traffic Engineering (RSVP-TE) to support automatic 22 collection of Shared Risk Link Group (SRLG) information for the TE 23 link formed by a Label Switched Path (LSP). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 26, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Applicability Example: Dual Homing . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 5 63 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . 5 64 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 5 68 4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 6 69 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7 70 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Manageability Considerations . . . . . . . . . . . . . . . . 9 74 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9 75 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10 79 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 10 80 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 It is important to understand which TE links in the network might be 90 at risk from the same failures. In this sense, a set of links can 91 constitute a 'shared risk link group' (SRLG) if they share a resource 92 whose failure can affect all links in the set [RFC4202]. 94 On the other hand, as described in [RFC4206] and [RFC6107], H-LSP 95 (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying 96 one or more other LSPs. Both of the H-LSP and S-LSP can be formed as 97 a TE link. In such cases, it is important to know the SRLG 98 information of the LSPs that will be used to carry further LSPs. 100 This document provides a mechanism to collect the SRLGs used by a 101 LSP, which can then be advertized as properties of the TE-link formed 102 by that LSP. Note that specification of the the use of the collected 103 SRLGs is outside the scope of this document. 105 1.1. Applicability Example: Dual Homing 107 An interesting use case for the SRLG collection procedures defined in 108 this document is achieving LSP diversity in a dual homing scenario. 109 The use case is illustrated in Figure 1, when the overlay model is 110 applied as defined in RFC 4208 [RFC4208] . In this example, the 111 exchange of routing information over the User-Network Interface (UNI) 112 is prohibited by operator policy. 114 +---+ +---+ 115 | P |....| P | 116 +---+ +---+ 117 / \ 118 +-----+ +-----+ 119 +---+ | PE1 | | PE3 | +---+ 120 |CE1|----| | | |----|CE2| 121 +---+\ +-----+ +-----+ /+---+ 122 \ | | / 123 \ +-----+ +-----+ / 124 \| PE2 | | PE4 |/ 125 | | | | 126 +-----+ +-----+ 127 \ / 128 +---+ +---+ 129 | P |....| P | 130 +---+ +---+ 132 Figure 1: Dual Homing Configuration 134 Single-homed customer edge (CE) devices are connected to a single 135 provider edge (PE) device via a single UNI link (which could be a 136 bundle of parallel links, typically using the same fiber cable). 137 This single UNI link can constitute a single point of failure. Such 138 a single point of failure can be avoided if the CE device is 139 connected to two PE devices via two UNI interfaces as depicted in 140 Figure 1 above for CE1 and CE2, respectively. 142 For the dual-homing case, it is possible to establish two connections 143 (LSPs) from the source CE device to the same destination CE device 144 where one connection is using one UNI link to PE1, for example, and 145 the other connection is using the UNI link to PE2. In order to avoid 146 single points of failure within the provider network, it is necessary 147 to also ensure path (LSP) diversity within the provider network in 148 order to achieve end-to-end diversity for the two LSPs between the 149 two CE devices CE1 and CE2. This use case describes how it is 150 possible to achieve path diversity within the provider network based 151 on collected SRLG information. As the two connections (LSPs) enter 152 the provider network at different PE devices, the PE device that 153 receives the connection request for the second connection needs to 154 know the additional path computation constraints such that the path 155 of the second LSP is disjoint with respect to the already established 156 first connection. 158 As SRLG information is normally not shared between the provider 159 network and the client network, i.e., between PE and CE devices, the 160 challenge is how to solve the diversity problem when a CE is dual- 161 homed. For example, CE1 in Figure 1 may have requested an LSP1 to 162 CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently 163 request an LSP2 to CE2 via PE2 with the constraint that it needs to 164 be maximally SRLG disjoint with respect to LSP1. PE2, however, does 165 not have any SRLG information associated with LSP1, which is needed 166 as input for its constrained-based path computation function. If CE1 167 is capable of retrieving the SRLG information associated with LSP1 168 from PE1, it can pass this information to PE2 as part of the LSP2 169 setup request (RSVP PATH message), and PE2 can now calculate a path 170 for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG 171 information associated with LSP1 can already be retrieved when LSP1 172 is setup or at any time before LSP2 is setup. 174 The RSVP extensions for collecting SRLG information defined in this 175 document make it possible to retrieve SRLG information for an LSP and 176 hence solve the dual-homing LSP diversity problem. When CE1 sends 177 the setup request for LSP2 to PE2, it can also request the collection 178 of SRLG information for LSP2 and send that information to PE1. This 179 will ensure that the two paths for the two LSPs remain mutually 180 diverse, which is important, when the provider network is capable to 181 restore connections that failed due to a network failure (fiber cut) 182 in the provider network. 184 It shall be noted that the knowledge of SRLG information even for 185 multiple LSPs does not allow a CE devices to derive the provider 186 network topology based on the collected SRLG information. 188 2. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 3. RSVP-TE Requirements 196 3.1. SRLG Collection Indication 198 The ingress node of the LSP SHOULD be capable of indicating whether 199 the SRLG information of the LSP is to be collected during the 200 signaling procedure of setting up an LSP. SRLG information SHOULD 201 NOT be collected without an explicit request for it being made by the 202 ingress node. 204 3.2. SRLG Collection 206 If requested, the SRLG information SHOULD be collected during the 207 setup of an LSP. The endpoints of the LSP can use the collected SRLG 208 information, for example, for routing, sharing and TE link 209 configuration purposes. 211 3.3. SRLG Update 213 When the SRLG information of an existing LSP for which SRLG 214 information was collected during signaling changes, the relevant 215 nodes of the LSP SHOULD be capable of updating the SRLG information 216 of the LSP. This means that that the signaling procedure SHOULD be 217 capable of updating the new SRLG information. 219 4. Encodings 221 4.1. SRLG Collection Flag 223 In order to indicate nodes that SRLG collection is desired, this 224 document defines a new flag in the Attribute Flags TLV (see RFC 5420 225 [RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or 226 LSP_ATTRIBUTES Object: 228 o Bit Number (temporarily 12, an early allocation has been made by 229 IANA, see Section 8.1 for more details): SRLG Collection flag 231 The SRLG Collection flag is meaningful on a Path message. If the 232 SRLG Collection flag is set to 1, it means that the SRLG information 233 SHOULD be reported to the ingress and egress node along the setup of 234 the LSP. 236 The rules of the processing of the Attribute Flags TLV are not 237 changed. 239 4.2. SRLG sub-object 241 This document defines a new RRO sub-object (ROUTE_RECORD sub-object) 242 to record the SRLG information of the LSP. Its format is modeled on 243 the RRO sub-objects defined in RFC 3209 [RFC3209]. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | SRLG ID 1 (4 bytes) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ~ ...... ~ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | SRLG ID n (4 bytes) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Type 259 The type of the sub-object. The value is temporarily 34. An early 260 allocation has been made by IANA (see Section 8.2 for more details). 262 Length 264 The Length field contains the total length of the sub-object in 265 bytes, including the Type and Length fields. The Length depends on 266 the number of SRLG IDs. 268 Reserved 270 This 2 byte field is reserved. It SHOULD be set to zero on 271 transmission and MUST be ignored on receipt. 273 SRLG ID 275 This 4 byte field contains one SRLG ID. There is one SRLG ID field 276 per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG 277 sub-object 279 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 280 managed as a stack. The SRLG sub-object SHOULD be pushed by the node 281 before the node IP address or link identifier. The SRLG-sub-object 282 SHOULD be pushed after the Attribute subobject, if present, and after 283 the LABEL subobject, if requested. 285 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- 286 object) in the RRO so as to facilitate confidentiality in the 287 signaling of inter-domain TE LSPs, and allows the path segment that 288 needs to be hidden (that is, a Confidential Path Segment (CPS)) to be 289 replaced in the RRO with a PKS. If the CPS contains SRLG Sub- 290 objects, these MAY be retained in the RRO by adding them again after 291 the PKS Sub-object in the RRO. 293 A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without 294 also pushing either a IPv4 sub-object, a IPv6 sub-object, a 295 Unnumbered Interface ID sub-object or a Path Key sub-object. 297 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 298 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 300 5. Signaling Procedures 302 5.1. SRLG Collection 304 Per RFC 3209 [RFC3209], an ingress node initiates the recording of 305 the route information of an LSP by adding a RRO to a Path message. 306 If an ingress node also desires SRLG recording, it MUST set the SRLG 307 Collection Flag in the Attribute Flags TLV which MAY be carried 308 either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 309 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 310 desired, but not mandatory 312 When a node receives a Path message which carries an 313 LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if 314 local policy determines that the SRLG information is not to be 315 provided to the endpoints, it MUST return a PathErr message with 316 Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" 317 (value 31, an early allocation of the value has been done by IANA, 318 see Section 8.3 for more details) to reject the Path message. 320 When a node receives a Path message which carries an LSP_ATTRIBUTES 321 Object and the SRLG Collection Flag set, if local policy determines 322 that the SRLG information is not to be provided to the endpoints, the 323 Path message SHOULD NOT be rejected due to SRLG recording restriction 324 and the Path message SHOULD be forwarded without any SRLG sub- 325 object(s) in the RRO of the corresponding outgoing Path message. 327 If local policy permits the recording of the SRLG information, the 328 processing node SHOULD add local SRLG information, as defined below, 329 to the RRO of the corresponding outgoing Path message. It then 330 forwards the Path message to the next node in the downstream 331 direction. 333 Following the steps described above, the intermediate nodes of the 334 LSP can collect the SRLG information in the RRO during the processing 335 of the Path message hop by hop. When the Path message arrives at the 336 egress node, the egress node receives SRLG information in the RRO. 338 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 339 message which contains an RRO, an egress node initiates the RRO 340 process by adding an RRO to the outgoing Resv message. The 341 processing for RROs contained in Resv messages then mirrors that of 342 the Path messages. 344 When a node receives a Resv message for an LSP for which SRLG 345 Collection is specified, if local policy determines that the SRLG 346 information is not to be provided to the endpoints, if the SRLG- 347 recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a 348 ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording 349 Rejected" (temporary value 21, an early allocation of the value has 350 been made by IANA, see Section 8.3 for more details) MUST be sent. 351 If the request was in a LSP_ATTRIBUTES object, then a ResvErr SHOULD 352 NOT be generated, but SRLG information MUST NOT be added in the RRO. 353 When local policy allows recording SRLG information, the node SHOULD 354 add SRLG information, as defined below, to the RRO of the 355 corresponding outgoing Resv message. When the Resv message arrives 356 at the ingress node, the ingress node can get the SRLG information 357 from the RRO in the same way as the egress node. 359 Note that a link's SRLG information for the upstream direction cannot 360 be assumed to be the same as that in the downstream. 362 o For Path and Resv messages for a unidirectional LSP, a node SHOULD 363 include SRLG sub-objects in the RRO for the downstream data link 364 only. 366 o For Path and Resv messages for a bidirectional LSP, a node SHOULD 367 include SRLG sub-objects in the RRO for both the upstream data 368 link and the downstream data link from the local node. In this 369 case, the node MUST include the information in the same order for 370 both Path messages and Resv messages. That is, the SRLG sub- 371 object for the upstream link is added to the RRO before the SRLG 372 sub-object for the downstream link. 374 Based on the above procedure, the endpoints can get the SRLG 375 information automatically. Then the endpoints can for instance 376 advertise it as a TE link to the routing instance based on the 377 procedure described in [RFC6107] and configure the SRLG information 378 of the FA automatically. 380 5.2. SRLG Update 382 When the SRLG information of a link is changed, the LSPs using that 383 link need to be aware of the changes. The procedures defined in 384 Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG 385 information if the SRLG change is to be communicated to other nodes 386 according to the local node's policy. If local policy is that the 387 SRLG change SHOULD be suppressed or would result in no change to the 388 previously signaled SRLG-list, the node SHOULD NOT send an update. 390 5.3. Compatibility 392 A node that does not recognize the SRLG Collection Flag in the 393 Attribute Flags TLV is expected to proceed as specified in RFC 5420 394 [RFC5420]. It is expected to pass the TLV on unaltered if it appears 395 in a LSP_ATTRIBUTES object, or reject the Path message with the 396 appropriate Error Code and Value if it appears in a 397 LSP_REQUIRED_ATTRIBUTES object. 399 A node that does not recognize the SRLG RRO sub-object is expected to 400 behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects 401 are to be ignored and passed on unchanged. 403 6. Manageability Considerations 405 6.1. Policy Configuration 407 In a border node of inter-domain or inter-layer network, the 408 following SRLG processing policy SHOULD be capable of being 409 configured: 411 o Whether the SRLG IDs of the domain or specific layer network can 412 be exposed to the nodes outside the domain or layer network, or 413 whether they SHOULD be summarized, mapped to values that are 414 comprehensible to nodes outside the domain or layer network, or 415 removed entirely. 417 A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. 419 6.2. Coherent SRLG IDs 421 In a multi-layer multi-domain scenario, SRLG ids can be configured by 422 different management entities in each layer/domain. In such 423 scenarios, maintaining a coherent set of SRLG IDs is a key 424 requirement in order to be able to use the SRLG information properly. 425 Thus, SRLG IDs SHOULD be unique. Note that current procedure is 426 targeted towards a scenario where the different layers and domains 427 belong to the same operator, or to several coordinated administrative 428 groups. Ensuring the aforementioned coherence of SRLG IDs is beyond 429 the scope of this document. 431 Further scenarios, where coherence in the SRLG IDs cannot be 432 guaranteed are out of the scope of the present document and are left 433 for further study. 435 7. Security Considerations 437 This document builds on the mechanisms defined in [RFC3473], which 438 also discusses related security measures. In addition, [RFC5920] 439 provides an overview of security vulnerabilities and protection 440 mechanisms for the GMPLS control plane. The procedures defined in 441 this document permit the transfer of SRLG data between layers or 442 domains during the signaling of LSPs, subject to policy at the layer 443 or domain boundary. It is recommended that domain/layer boundary 444 policies take the implications of releasing SRLG information into 445 consideration and behave accordingly during LSP signaling. 447 8. IANA Considerations 449 8.1. RSVP Attribute Bit Flags 451 IANA has created a registry and manages the space of the Attribute 452 bit flags of the Attribute Flags TLV, as described in section 11.3 of 453 RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource 454 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 455 registry located in http://www.iana.org/assignments/rsvp-te- 456 parameters". IANA has made an early allocation in the "Attribute 457 Flags" section of the mentioned registry that expires on 2015-09-11. 459 This document introduces a new Attribute Bit Flag: 461 Bit No Name Attribute Attribute RRO Reference 462 Flags Path Flags Resv 463 ----------- ---------- ---------- ----------- --- --------- 464 12 (tempo- SRLG Yes Yes Yes This I-D 465 rary expires collection 466 2015-09-11) Flag 468 8.2. ROUTE_RECORD Object 470 IANA manages the "RSVP PARAMETERS" registry located at 471 http://www.iana.org/assignments/rsvp-parameters. IANA has made an 472 early allocation in the Sub-object type 21 ROUTE_RECORD - Type 1 473 Route Record registry. The early allocation expires on 2015-09-11. 475 This document introduces a new RRO sub-object: 477 Value Description Reference 478 --------------------- ------------------- --------- 479 34 (temporary, SRLG sub-object This I-D 480 expires 2015-09-11) 482 8.3. Policy Control Failure Error subcodes 484 IANA manages the assignments in the "Error Codes and Globally-Defined 485 Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry 486 located at http://www.iana.org/assignments/rsvp-parameters. IANA has 487 made an early allocation in the "Sub-Codes - 2 Policy Control 488 Failure" subsection of the the "Error Codes and Globally-Defined 489 Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. 490 The early allocation expires on 2015-09-11. 492 This document introduces a new Policy Control Failure Error sub-code: 494 Value Description Reference 495 --------------------- ----------------------- --------- 496 21 (temporary, SRLG Recording Rejected This I-D 497 expires 2015-09-11) 499 9. Acknowledgements 501 The authors would like to thank Igor Bryskin, Ramon Casellas, Lou 502 Berger, Alan Davey, Dhruv Dhody and Dieter Beller for their useful 503 comments and improvements to the document. 505 10. References 507 10.1. Normative References 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 513 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 514 Tunnels", RFC 3209, December 2001. 516 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 517 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 518 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 520 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 521 Ayyangarps, "Encoding of Attributes for MPLS LSP 522 Establishment Using Resource Reservation Protocol Traffic 523 Engineering (RSVP-TE)", RFC 5420, February 2009. 525 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 526 Reservation Protocol (RSVP) Extensions for Path Key 527 Support", RFC 5553, May 2009. 529 10.2. Informative References 531 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 532 Support of Generalized Multi-Protocol Label Switching 533 (GMPLS)", RFC 4202, October 2005. 535 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 536 Hierarchy with Generalized Multi-Protocol Label Switching 537 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 539 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 540 "Generalized Multiprotocol Label Switching (GMPLS) User- 541 Network Interface (UNI): Resource ReserVation Protocol- 542 Traffic Engineering (RSVP-TE) Support for the Overlay 543 Model", RFC 4208, October 2005. 545 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 546 Networks", RFC 5920, July 2010. 548 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 549 Signaled Hierarchical Label Switched Paths", RFC 6107, 550 February 2011. 552 Authors' Addresses 554 Fatai Zhang (editor) 555 Huawei 556 F3-5-B RD Center 557 Bantian, Longgang District, Shenzhen 518129 558 P.R.China 560 Email: zhangfatai@huawei.com 562 Oscar Gonzalez de Dios (editor) 563 Telefonica Global CTO 564 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 565 Madrid 28050 566 Spain 568 Phone: +34 913129647 569 Email: oscar.gonzalezdedios@telefonica.com 570 Dan Li 571 Huawei 572 F3-5-B RD Center 573 Bantian, Longgang District, Shenzhen 518129 574 P.R.China 576 Email: danli@huawei.com 578 Cyril Margaria 579 Suite 4001, 200 Somerset Corporate Blvd. 580 Bridgewater, NJ 08807 581 US 583 Email: cyril.margaria@gmail.com 585 Matt Hartley 586 Cisco 588 Email: mhartley@cisco.com 590 Zafar Ali 591 Cisco 593 Email: zali@cisco.com