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