idnits 2.17.1 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5654], [Extended]), 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 (September 16, 2013) is 3874 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: 'Extended' is mentioned on line 535, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group F. Zhang, Ed. 3 Internet-Draft ZTE 4 Intended status: Standards Track R. Jing 5 Expires: March 20, 2014 China Telecom 6 R. Gandhi 7 Cisco Systems 8 September 16, 2013 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-07 13 Abstract 15 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], 16 describes that MPLS-TP MUST support associated bidirectional point- 17 to-point LSPs. 19 This document provides a method to bind two unidirectional Label 20 Switched Paths (LSPs) into an associated bidirectional LSP. The 21 association is achieved by defining the new Association Types in the 22 [Extended] ASSOCIATION object. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 20, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4 63 3.2.1. Single Sided Provisioning Model . . . . . . . . . . . 5 64 3.2.2. Double Sided Provisioning Model . . . . . . . . . . . 5 65 3.2.3. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . 5 66 3.2.4. Recovery Considerations . . . . . . . . . . . . . . . 6 67 3.2.5. Associated Bidirectional LSPs and LSP Recovery . . . . 6 68 3.2.6. Associated Bidirectional LSPs and TE Mesh-Groups . . . 7 69 3.2.7. MPLS-TP Associated Bidirectional LSP Identifiers . . . 7 70 3.2.8. Teardown of Associated Bidirectional LSPs . . . . . . 7 71 4. Association of LSPs . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8 73 4.1.1 Signaling of the ASSOCIATION Object . . . . . . . . . . 9 74 4.1.2 Compatibility . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.2.1.1. Subobjects . . . . . . . . . . . . . . . . . . . . 10 78 4.2.2. LSP Control . . . . . . . . . . . . . . . . . . . . . 10 79 4.2.3. Updated RSVP Message Formats . . . . . . . . . . . . . 11 80 4.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . 11 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. Association Type . . . . . . . . . . . . . . . . . . . . . 12 83 5.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 94 describes that MPLS-TP MUST support associated bidirectional point- 95 to-point LSPs. Furthermore, an associated bidirectional LSP is 96 useful for protection switching, for Operations, Administrations and 97 Maintenance (OAM) messages that require a reply path. 99 The requirements described in [RFC5654] are specifically mentioned in 100 Section 2.1. (General Requirements), and are repeated below: 102 7. MPLS-TP MUST support associated bidirectional point-to-point 103 LSPs. 105 11. The end points of an associated bidirectional LSP MUST be aware 106 of the pairing relationship of the forward and reverse LSPs used to 107 support the bidirectional service. 109 12. Nodes on the LSP of an associated bidirectional LSP where both 110 the forward and backward directions transit the same node in the same 111 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 112 the forward and the backward directions of the LSP. 114 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 115 bandwidth requirements, i.e., the amount of reserved bandwidth 116 differs between the forward and backward directions. 118 50. The MPLS-TP control plane MUST support establishing associated 119 bidirectional P2P LSP including configuration of protection functions 120 and any associated maintenance functions. 122 The above requirements are also repeated in [RFC6373]. 124 The notion of association, as well as the corresponding Resource 125 reSerVation Protocol (RSVP) ASSOCIATION object, is defined in 126 [RFC4872], [RFC4873] and [RFC6689]. In that context, the object is 127 used to associate recovery LSPs with the LSP they are protecting. 128 This object also has broader applicability as a mechanism to 129 associate RSVP state, and [RFC6780] defines the Extended ASSOCIATION 130 object that can be more generally applied. 132 This document provides a method to bind two reverse unidirectional 133 Label Switched Paths (LSPs) into an associated bidirectional LSP. The 134 association is achieved by defining the new Association Types in the 135 [Extended] ASSOCIATION object. 137 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Overview 144 3.1. Provisioning Model 146 The associated bidirectional LSP's forward and backward directions 147 are set up, monitored, and protected independently as required by 148 [RFC5654]. Configuration information regarding the LSPs can be sent 149 to one end or both ends of the LSP. Depending on the method chosen, 150 there are two models of signaling associated bidirectional LSP. The 151 first model is the single sided provisioning, the second model is the 152 double sided provisioning. 154 For the single sided provisioning, the configurations are sent to one 155 end. Firstly, a unidirectional tunnel is configured on this end, 156 then a LSP under this tunnel is initiated with the [Extended] 157 ASSOCIATION object carried in the Path message to trigger the peer 158 end to set up the corresponding reverse TE tunnel and LSP. 160 For the double sided provisioning, the two unidirectional TE tunnels 161 are configured independently, then the LSPs under the tunnels are 162 signaled with the [Extended] ASSOCIATION objects carried in the Path 163 message to indicate each other to associate the two LSPs together to 164 be an associated bidirectional LSP. 166 A number of scenarios exist for binding LSPs together to be an 167 associated bidirectional LSP. These include: (1) both of them do not 168 exist; (2) both of them exist; (3) one LSP exists, but the other one 169 need to be established. In all scenarios described, the provisioning 170 models discussed above are applicable. 172 3.2. Signaling Procedure 174 This section describes the signaling procedures for associating 175 bidirectional LSPs. 177 Consider the topology described in Figure 1. (An example of 178 associated bidirectional LSP). The LSP1 [via nodes A,D,B] (from A to 179 B) and LSP2 [via nodes B,D,C,A] (from B to A) are being established 180 or have been established, which can form an associated bidirectional 181 LSP between node A and node B. 183 LSP1 and LSP2 are referenced at the data plane level by the 184 identifiers: A-Node_ID::A-Tunnel_Num::A-LSP_Num::B-Node_ID and 185 B-Node_ID::B-Tunnel_Num::B-LSP_Num::A-Node_ID, respectively 186 [RFC6370]. 188 A-------D-------B 189 \ / 190 \ / 191 \ / 192 C 194 Figure 1: An example of associated bidirectional LSP 196 3.2.1. Single Sided Provisioning Model 198 For the single sided provisioning model, LSP1 is triggered by LSP2 or 199 LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, LSP1 is 200 initialized or refreshed (if LSP1 already exists) at node A with the 201 [Extended] ASSOCIATION object inserted in the Path message, the 202 Association Type must be set to "Single Sided Associated 203 Bidirectional LSPs". Terminating node B is triggered to set up LSP2 204 by the received [Extended] ASSOCIATION object with the Association 205 Type set to the value "Single Sided Associated Bidirectional LSPs", 206 the [Extended] ASSOCIATION object inserted in LSP2's Path message is 207 the same as in LSP1's Path message. 209 When LSP1 is triggered by LSP2, the same rules are applicable. Based 210 on the same values of the [Extended] ASSOCIATION objects in the two 211 LSPs' Path messages, the two LSPs can be bound together to be an 212 associated bidirectional LSP. 214 3.2.2. Double Sided Provisioning Model 216 For the double sided provisioning model, the Association Type must be 217 set to "Double Sided Associated Bidirectional LSPs". 219 Identification of the LSPs as being Associated Bidirectional LSPs 220 occurs based on the identical contents in the LSPs' [Extended] 221 ASSOCIATION objects. 223 3.2.3. Asymmetric Bandwidth LSPs 225 A variety of applications, such as Internet services and the return 226 paths of OAM messages, exist and which MAY have different bandwidth 227 requirements for each direction. Additional [RFC5654] also specifies 228 an asymmetric bandwidth requirement. This requirement is specifically 229 mentioned in Section 2.1. (General Requirements), and is repeated 230 below: 232 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 233 bandwidth requirements, i.e., the amount of reserved bandwidth 234 differs between the forward and backward directions. 236 The approach for supporting asymmetric bandwidth co-routed 237 bidirectional LSPs is defined in [RFC6387]. As to the asymmetric 238 bandwidth associated bidirectional LSPs, the existing SENDER_TSPEC 239 object must be carried in the REVERSE_LSP object [defined in Section 240 4.2 of this document] as a subobject in the initialized LSP's Path 241 message to specify the reverse LSP's traffic parameters in case where 242 single sided provisioning model is adopted. Consider the topology 243 described in Figure 1 in the context of asymmetric bandwidth 244 associated bidirectional LSPs, and take LSP2 triggered by LSP1 as an 245 example. Node B is triggered to set up the reverse LSP2 with the 246 corresponding asymmetric bandwidth by the [Extended] ASSOCIATION 247 object with Association Type "Single Sided Associated Bidirectional 248 LSPs" and the SENDER_TSPEC subobject in REVERSE_LSP object in LSP1's 249 Path message. 251 When double sided provisioning model is used, the two opposite LSPs 252 with asymmetric bandwidths are concurrently initialized, and this 253 requirement will be satisfied simultaneously. 255 3.2.4. Recovery Considerations 257 Consider the topology described in Figure 1, LSP1 and LSP2 form the 258 associated bidirectional LSP. Under the scenario of recovery, a 259 third LSP (LSP3) may be used to protect LSP1. LSP3 can be established 260 before or after the failure occurs, it can share the same TE tunnel 261 with LSP1. 263 When node A detects that LSP1 is broken or needs to be reoptimized, 264 LSP3 will be initialized or refreshed with the [Extended] ASSOCIATION 265 object inherited from LSP1's Path message. Furthermore, if LSP3 is 266 the protecting LSP [RFC4872], the [Extended] ASSOCIATION object and 267 PROTECTION object [RFC4872] need to be inherited from the LSP1 also. 268 In this way, based on the same [Extended] ASSOCIATION object, LSP2 269 and LSP3 will compose the new associated bidirectional LSPs. 271 3.2.5. Associated Bidirectional LSPs and LSP Recovery 273 LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not 274 impacted by this document. The recovery mechanisms defined in 275 [RFC4872] and [RFC4873] rely on the use of ASSOCIATION objects, but 276 use a different Association Type field value than defined in this 277 document so it is not be impacted. The mechanisms defined in 278 [RFC4090] does not rely on the use of ASSOCIATION objects and is 279 therefore also not impacted by the mechanisms defined in this 280 document. 282 3.2.6. Associated Bidirectional LSPs and TE Mesh-Groups 284 TE mesh-groups is defined in [RFC4972]. A node supporting both 285 Associated Bidirectional LSPs and TE mesh-groups, MAY include an 286 [Extended] ASSOCIATION object as defined in this document in Path 287 messages of LSPs used for the mesh-group. To enable unambiguous 288 identification of the mesh-group's associated bidirectional LSPs, the 289 information carried in the [Extended] ASSOCIATION object, including 290 the contents of the Association Source and Identifier fields MUST be 291 provisioned. 293 3.2.7. MPLS-TP Associated Bidirectional LSP Identifiers 295 [RFC6370] defines the MPLS-TP associated LSP identifiers based on the 296 signaling parameters of each unidirectional LSP. Using the mechanisms 297 defined in this document, any node that is along the path of both 298 unidirectional LSPs can identify which pair of unidirectional LSPs 299 support an Associated Bidirectional LSP as well as the signaling 300 parameters required by [RFC6370]. Note that the LSP end-points will 301 always be the path of both unidirectional LSPs. 303 3.2.8. Teardown of Associated Bidirectional LSPs 305 Associated bidirectional LSPs teardown also follows standard 306 procedures defined in [RFC3209] and [RFC3473] either without or with 307 the administrative status. Note that teardown procedures of the 308 associated bidirectional LSPs are independent of each other, so it is 309 possible that while one LSP1 follows graceful teardown with 310 administrative status, the other LSP2 is torn down without 311 administrative status (using PathTear/ResvTear/PathErr with state 312 removal). However, for the double sided associated bidirectional 313 LSPs, the teardown of LSP1 does not mean that LSP2 must be deleted, 314 which depends on the local policy. While for the single sided 315 associated bidirectional LSPs, the teardown of the initialized LSP 316 SHOULD induce the teardown of the trigger-established LSP, but the 317 teardown of the trigger-established LSP (using PathErr with state 318 removal) MAY not induce the teardown of the initialized LSP (which 319 depends on the local policy). 321 4. Association of LSPs 322 4.1. ASSOCIATION Object 324 The Extended ASSOCIATION object is defined in [RFC6780], which 325 enables MPLS-TP required LSP identification. The [Extended] 326 ASSOCIATION object is used as follows for associated bidirectional 327 LSPs. 329 Association Types: 331 In order to bind two reverse unidirectional LSPs to be an 332 associated bidirectional LSP, new Association Types are defined in 333 this document: 335 Value Type 336 ----- ----- 337 4 (TBD) Double Sided Associated Bidirectional LSPs (D) 338 5 (TBD) Single Sided Associated Bidirectional LSPs (A) 340 Association ID: 16 bits 342 For both double sided and single sided provisioning, Association 343 ID is a value assigned by the node that originates the 344 association. 346 Association Source: 4 or 16 bytes 348 Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. 350 For double sided provisioning, Association Source is set to an 351 address selected by the node that originates the association 352 (which may be a management entity.) 354 For single sided provisioning, Association Source is set to an 355 address assigned to the node that originates the LSP. 357 Global Association Source: 4 bytes 359 Same as for IPv4 and IPv6 [Extended] ASSOCIATION objects defined 360 in [RFC6780]. 362 For both double sided and single sided provisioning, Global 363 Association Source, when used, is set to the Global_ID [RFC6370] 364 of the node that originates association. 366 Extended Association ID: 4 or 16 bytes 368 This field contains data that is additional information to support 369 unique identification. 371 For both double sided and single sided provisioning, Extended 372 Association ID, when used, is selected by the node that originates 373 the association. 375 If either Global Association Source or Extended Association 376 Address is required, an Extended ASSOCIATION object [RFC6780] is 377 used. Otherwise an ASSOCIATION object [RFC4872] is used. 379 4.1.1 Signaling of the ASSOCIATION Object 381 As described in [RFC6780], association is always done based on 382 matching Path state or Resv state. Upstream initialized association 383 is represented in [Extended] ASSOCIATION objects carried in Path 384 message and downstream initialized association is represented in 385 [Extended] ASSOCIATION objects carried in Resv messages. The new 386 Association Types defined in this document are only used in upstream 387 initialized association. Thus they can only appear in [Extended] 388 ASSOCIATION objects signaled in Path message. 390 The rules associated with the processing of the [Extended] 391 ASSOCIATION objects in RSVP message are discussed in [RFC6780]. It 392 said that in the absence of Association Type-specific rules for 393 identifying association, the included [Extended] ASSOCIATION objects 394 MUST be identical. This document adds no specific rules, the 395 association will always operate based on the same [Extended] 396 ASSOCIATION objects. 398 4.1.2 Compatibility 400 The [Extended] ASSOCIATION object has been defined in [RFC6780] with 401 class numbers in the form 11bbbbbb, which ensures compatibility with 402 non-supporting nodes. Per [RFC2205], nodes not supporting this 403 extension will ignore the object but forward it, unexamined and 404 unmodified, in all messages resulting from this message. Especially, 405 this object received in PathTear, or PathErr messages should be 406 forwarded immediately in the same message, but should be saved with 407 the corresponding state and forwarded in any refresh message 408 resulting from that state when received in Path message. 410 4.2. REVERSE_LSP Object 412 Path Computation Element (PCE)-based approaches, see [RFC4655], may 413 be used for path computation of a GMPLS LSP, and consequently an 414 associated bidirectional LSP, across domains and in a single domain. 416 The ingress Label Switching Router (LSR), maybe serve as a PCE or 417 Path Computation Client (PCC), has more information about the reverse 418 LSP. 420 When the forward LSP is signaled, the reverse LSP's traffic 421 parameters, explicit route, LSP attributes, etc, can be carried in 422 the REVERSE_LSP object of the forward LSP's Path message. The egress 423 LSR can be triggered to establish the reverse LSP according to the 424 received control information. 426 4.2.1. Format 428 The information of the reverse LSP is specified via the REVERSE_LSP 429 object, which is optional with class numbers in the form 11bbbbbb has 430 the following format: 432 Class = TBD (of the form 11bbbbbb), C_Type = 1 (TBD) 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 // (Subobjects) // 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 This object MUST NOT be used when the [Extended] ASSOCIATION object 443 do not exist or exist but the Association Type is not "Single Sided 444 Associated Bidirectional LSPs". 446 4.2.1.1. Subobjects 448 The contents of a REVERSE_LSP object are a series of variable-length 449 data items called subobjects, which can be SENDER_TSPEC, 450 EXPLICIT_ROUTE object (ERO), Session Attribute object, Admin Status 451 object, LSP_ATTRIBUTES object, LSP_REQUIRED_ATTRIBUTES object, 452 PROTECTION object, ASSOCIATION object, Extended ASSOCIATION object, 453 etc. 455 4.2.2. LSP Control 457 The signaling procedure without the REVERSE_LSP object carried in the 458 LSP1's Path message is described in section 3.2.1, which is the 459 default option. A node includes a REVERSE_LSP object and [Extended] 460 ASSOCIATION object with an "Single Sided Associated Bidirectional 461 LSPs" Association Type in an outgoing Path message when it wishes to 462 control the reverse LSP, and the receiver node B MUST convert the 463 subobjects of the REVERSE_LSP object into the corresponding objects 464 that carried in LSP2's Path message. The case of a non-supporting 465 egress node is outside of this document. If node A want to tear down 466 the associated bidirectional LSP, a PathTear message will be sent out 467 and Node B is triggered to tear down LSP2. 469 4.2.3. Updated RSVP Message Formats 471 This section presents the RSVP message-related formats as modified by 472 this document. Unmodified RSVP message formats are not listed. 474 The format of a Path message is as follows: 476 ::= [ ] 477 [ [ | ] ... ] 478 [ ] 479 480 481 [ ] 482 483 [ ] 484 [ ... ] 485 [ ] 486 [ ... ] 487 [ ] 488 [ ... ] 489 [ ... ] 491 493 The format of the is not modified by the present 494 document. 496 4.2.4. Compatibility 498 The REVERSE_LSP object is defined with class numbers in the form 499 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 500 [RFC2205], nodes not supporting this extension will ignore the object 501 but forward it, unexamined and unmodified, in all messages resulting 502 from this message. Especially, this object received in PathTear, or 503 PathErr messages should be forwarded immediately in the same message, 504 but should be saved with the corresponding state and forwarded in any 505 refresh message resulting from that state when received in Path 506 message. 508 5. IANA Considerations 510 IANA is requested to administer assignment of new values for 511 namespace defined in this document and summarized in this section. 513 5.1. Association Type 515 Within the current document, two new Association Types are defined in 516 the [Extended] ASSOCIATION object. 518 Value Type 519 ----- ----- 520 4 (TBD) Double Sided Associated Bidirectional LSPs (D) 521 5 (TBD) Single Sided Associated Bidirectional LSPs (A) 523 5.2. REVERSE_LSP Object 525 A new class named REVERSE_LSP has been created in the 11bbbbbb range 526 (TBD) with the following definition: 528 Class Types or C-types (1, TBD): 530 There are no other IANA considerations introduced by this document. 532 6. Security Considerations 534 This document introduces two new Association Types, and except this, 535 there are no security issues about the [Extended] ASSOCIATION object 536 are introduced here. 538 The procedures defined in this document result in an increase in the 539 amount of state information carried in signaling messages since the 540 presence of the REVERSE_LSP object necessarily means that there is 541 more information about associated bidirectional LSPs. Thus, in the 542 event of the interception of a signaling message, slightly more could 543 be deduced about the state of the network than was previously the 544 case, but this is judged to be a very minor security risk as this 545 information is already available via routing. 547 Otherwise, this document introduces no additional security 548 considerations. For a general discussion on MPLS and GMPLS related 549 security issues, see the MPLS/GMPLS security framework [RFC5920]. 551 7. Acknowledgement 553 The authors would like to thank Lou Berger for his great guidance in 554 this work, George Swallow and Jie Dong for the discussion of 555 recovery, Lamberto Sterling for his valuable comments on the section 556 of asymmetric bandwidths, Daniel King for the review of the document, 557 Attila Takacs for the discussion of the provisioning model. At the 558 same time, the authors would also like to acknowledge the 559 contributions of Bo Wu, Xihua Fu, Lizhong Jin for the initial 560 discussions, and Wenjuan He for the prototype implementation. The 561 authors would also like to thank Siva Sivabalan, Eric Osborne and 562 Robert Sawaya for the discussion on the ASSOCIATION object. 564 8. References 566 8.1. Normative references 568 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 569 Association Object Extensions", RFC 6780, October 2012. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 575 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 576 Functional Specification", RFC 2205, September 1997. 578 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 579 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 580 Tunnels", RFC 3209, December 2001. 582 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 583 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 584 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 586 [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions 587 to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 589 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 590 Extensions in Support of End-to-End Generalized Multi- 591 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 592 2007. 594 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 595 "GMPLS Segment Recovery", RFC 4873, May 2007. 597 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., 598 Psenak, P., Mabbey, P., "Routing Extensions for Discovery 599 of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 600 Engineering (TE) Mesh Membership", RFC 4972, July 2007. 602 8.2. Informative References 604 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 605 Element (PCE)-Based Architecture", RFC 4655, August 2006. 607 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 608 and S. Ueno, "Requirements of an MPLS Transport Profile", 609 RFC 5654, September 2009. 611 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 612 Networks", RFC 5920, July 2010. 614 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 615 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 617 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 618 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 619 Framework", RFC 6373, September 2011. 621 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 622 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 623 Switched Paths (LSPs)", RFC 6387, September 2011. 625 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 626 6689, July 2012. 628 Authors' Addresses 630 Fei Zhang (editor) 631 ZTE 633 Email: zhang.fei3@zte.com.cn 635 Ruiquan Jing 636 China Telecom 638 Email: jingrq@ctbri.com.cn 640 Fan Yang 641 ZTE 643 Email: james-yang81@sohu.com 645 Weilian Jiang 646 ZTE 648 Email: jiang.weilian@gmail.com 650 Rakesh Gandhi (editor) 651 Cisco Systems 653 Email: rgandhi@cisco.com