idnits 2.17.1 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06.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]), 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 (March 18, 2013) is 4057 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 19, 2013 China Telecom 6 R. Gandhi 7 Cisco Systems 8 March 18, 2013 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06 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 September 19, 2013. 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 . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . . 8 73 4.1.1 Signaling of the Extended Association Object . . . . . 9 74 4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1.1. Subobjects . . . . . . . . . . . . . . . . . . . . 10 77 4.2.2. LSP Control . . . . . . . . . . . . . . . . . . . . . 10 78 4.2.3. Updated RSVP Message Formats . . . . . . . . . . . . . 10 79 4.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . 11 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Association Type . . . . . . . . . . . . . . . . . . . . . 11 82 5.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 93 describes that MPLS-TP MUST support associated bidirectional point- 94 to-point LSPs. Furthermore, an associated bidirectional LSP is 95 useful for protection switching, for Operations, Administrations and 96 Maintenance (OAM) messages that require a reply path. 98 The requirements described in [RFC5654] are specifically mentioned in 99 Section 2.1. (General Requirements), and are repeated below: 101 7. MPLS-TP MUST support associated bidirectional point-to-point 102 LSPs. 104 11. The end points of an associated bidirectional LSP MUST be aware 105 of the pairing relationship of the forward and reverse LSPs used to 106 support the bidirectional service. 108 12. Nodes on the LSP of an associated bidirectional LSP where both 109 the forward and backward directions transit the same node in the same 110 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 111 the forward and the backward directions of the LSP. 113 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 114 bandwidth requirements, i.e., the amount of reserved bandwidth 115 differs between the forward and backward directions. 117 50. The MPLS-TP control plane MUST support establishing associated 118 bidirectional P2P LSP including configuration of protection functions 119 and any associated maintenance functions. 121 The above requirements are also repeated in [RFC6373]. 123 The notion of association, as well as the corresponding Resource 124 reSerVation Protocol (RSVP) ASSOCIATION object, is defined in 125 [RFC4872], [RFC4873] and [RFC6689]. In that context, the object is 126 used to associate recovery LSPs with the LSP they are protecting. 127 This object also has broader applicability as a mechanism to 128 associate RSVP state, and [RFC6780] defines the Extended ASSOCIATION 129 object that can be more generally applied. 131 This document provides a method to bind two reverse unidirectional 132 Label Switched Paths (LSPs) into an associated bidirectional LSP. The 133 association is achieved by defining the new Association Types in the 134 Extended ASSOCIATION object. 136 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Overview 143 3.1. Provisioning Model 145 The associated bidirectional LSP's forward and backward directions 146 are set up, monitored, and protected independently as required by 147 [RFC5654]. Configuration information regarding the LSPs can be sent 148 to one end or both ends of the LSP. Depending on the method chosen, 149 there are two models of signaling associated bidirectional LSP. The 150 first model is the single sided provisioning, the second model is the 151 double sided provisioning. 153 For the single sided provisioning, the configurations are sent to one 154 end. Firstly, a unidirectional tunnel is configured on this end, 155 then a LSP under this tunnel is initiated with the Extended 156 ASSOCIATION object carried in the Path message to trigger the peer 157 end to set up the corresponding reverse TE tunnel and LSP. 159 For the double sided provisioning, the two unidirectional TE tunnels 160 are configured independently, then the LSPs under the tunnels are 161 signaled with the Extended ASSOCIATION objects carried in the Path 162 message to indicate each other to associate the two LSPs together to 163 be an associated bidirectional LSP. 165 A number of scenarios exist for binding LSPs together to be an 166 associated bidirectional LSP. These include: (1) both of them do not 167 exist; (2) both of them exist; (3) one LSP exists, but the other one 168 need to be established. In all scenarios described, the provisioning 169 models discussed above are applicable. 171 3.2. Signaling Procedure 173 This section describes the signaling procedures for associating 174 bidirectional LSPs. 176 Consider the topology described in Figure 1. (An example of 177 associated bidirectional LSP). The LSP1 [via nodes A,D,B] (from A to 178 B) and LSP2 [via nodes B,D,C,A] (from B to A) are being established 179 or have been established, which can form an associated bidirectional 180 LSP between node A and node B. 182 LSP1 and LSP2 are referenced at the data plane level by the 183 identifiers: A-Node_ID::A-Tunnel_Num::A-LSP_Num::B-Node_ID and 184 B-Node_ID::B-Tunnel_Num::B-LSP_Num::A-Node_ID, respectively 185 [RFC6370]. 187 A-------D-------B 188 \ / 189 \ / 190 \ / 191 C 193 Figure 1: An example of associated bidirectional LSP 195 3.2.1. Single Sided Provisioning Model 197 For the single sided provisioning model, LSP1 is triggered by LSP2 or 198 LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, LSP1 is 199 initialized or refreshed (if LSP1 already exists) at node A with the 200 Extended ASSOCIATION object inserted in the Path message, the 201 Association Type must be set to "Single Sided Associated 202 Bidirectional LSPs". Terminating node B is triggered to set up LSP2 203 by the received Extended ASSOCIATION object with the Association Type 204 set to the value "Single Sided Associated Bidirectional LSPs", the 205 Extended ASSOCIATION object inserted in LSP2's Path message is the 206 same as in LSP1's Path message. 208 When LSP1 is triggered by LSP2, the same rules are applicable. Based 209 on the same values of the Extended ASSOCIATION objects in the two 210 LSPs' Path messages, the two LSPs can be bound together to be an 211 associated bidirectional LSP. 213 3.2.2. Double Sided Provisioning Model 215 For the double sided provisioning model, the Association Type must be 216 set to "Double Sided Associated Bidirectional LSPs". 218 Identification of the LSPs as being Associated Bidirectional LSPs 219 occurs based on the identical contents in the LSPs' Extended 220 ASSOCIATION objects. 222 3.2.3. Asymmetric Bandwidth LSPs 224 A variety of applications, such as Internet services and the return 225 paths of OAM messages, exist and which MAY have different bandwidth 226 requirements for each direction. Additional [RFC5654] also specifies 227 an asymmetric bandwidth requirement. This requirement is 228 specifically mentioned in Section 2.1. (General Requirements), and 229 is repeated below: 231 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 232 bandwidth requirements, i.e., the amount of reserved bandwidth 233 differs between the forward and backward directions. 235 The approach for supporting asymmetric bandwidth co-routed 236 bidirectional LSPs is defined in [RFC6387]. As to the asymmetric 237 bandwidth associated bidirectional LSPs, the existing SENDER_TSPEC 238 object must be carried in the REVERSE_LSP object as a sub-object in 239 the initialized LSP's Path message to specify the reverse LSP's 240 traffic parameters in case that single sided provisioning model is 241 adopted. Consider the topology described in Figure 1 in the context 242 of asymmetric associated bidirectional LSP, and take LSP2 triggered 243 by LSP1 as an example. Node B is triggered to set up the reverse 244 LSP2 with the corresponding asymmetric bandwidth by the Extended 245 ASSOCIATION object with Association Type "Single Sided Associated 246 Bidirectional LSPs" and the SENDER_TSPEC sub-object in LSP1's Path 247 message, and the SENDER_TSPEC object in the LSP2' Path message is the 248 same as the the SENDER_TSPEC sub-object in LSP1's Path message. When 249 double sided provisioning model is used, the two opposite LSPs with 250 asymmetric bandwidths are concurrently initialized, and this 251 requirement will be satisfied simultaneously. 253 3.2.4. Recovery Considerations 255 Consider the topology described in Figure 1, LSP1 and LSP2 form the 256 associated bidirectional LSP. Under the scenario of recovery, a 257 third LSP (LSP3) may be used to protect LSP1. LSP3 can be 258 established before or after the failure occurs, it can share the same 259 TE tunnel with LSP1. 261 When node A detects that LSP1 is broken or needs to be reoptimized, 262 LSP3 will be initialized or refreshed with the Extended ASSOCIATION 263 object inherited from LSP1's Path message. Furthermore, if LSP3 is 264 the protecting LSP [RFC4872], the ASSOCIATION object and PROTECTION 265 object [RFC4872] need to be inherited from the LSP1 also. In this 266 way, based on the same Extended ASSOCIATION object, LSP2 and LSP3 267 will compose the new associated bidirectional LSPs. 269 3.2.5. Associated Bidirectional LSPs and LSP Recovery 271 LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not 272 impacted by this document. The recovery mechanisms defined in 273 [RFC4872] and [RFC4873] rely on the use of ASSOCIATION Objects, but 274 use a different Association Type field value than defined in this 275 document so should not be impacted. The mechanisms defined in 276 [RFC4090] does not rely on the use of ASSOCIATION Objects and is 277 therefore also not impacted by the mechanisms defined in this 278 document. 280 3.2.6. Associated Bidirectional LSPs and TE Mesh-Groups 282 TE mesh-groups is defined in [RFC4972]. A node supporting both 283 Associated Bidirectional LSPs and TE mesh-groups, MAY include an 284 ASSOCIATION object as defined in this document in Path messages of 285 LSPs used to support the mesh-group. To enable unambiguous 286 identification of the mesh-group's associated bidirectional LSPs, the 287 information carried in the ASSOCIATION object, including the contents 288 of the Association Source and Identifier fields MUST be provisioned. 290 3.2.7. MPLS-TP Associated Bidirectional LSP Identifiers 292 [RFC6370] defines the LSP associated identifiers based on the 293 signaling parameters of each unidirectional LSP. The combination 294 of each unidirectional LSP's parameters is used to identify the 295 Associated Bidirectional LSP. Using the mechanisms defined in 296 this document, any node that is along the path of both 297 unidirectional LSPs can identify which pair of unidirectional LSPs 298 support an Associated Bidirectional LSP as well as the signaling 299 parameters required by [RFC6370]. Note that the LSP end-points 300 will always be the path of both unidirectional LSPs. 302 3.2.8. Teardown of Associated Bidirectional LSPs 304 Associated bidirectional LSPs teardown also follows standard 305 procedures defined in [RFC3209] and [RFC3473] either without or with 306 the administrative status. Note that teardown procedures of the 307 associated bidirectional LSPs are independent of each other, so it is 308 possible that while one LSP1 follows graceful teardown with 309 administrative status, the other LSP2 is torn down without 310 administrative status (using PathTear/ResvTear/PathErr with state 311 removal). However, for the double sided associated bidirectional 312 LSPs, the teardown of LSP1 does not mean that LSP2 must be deleted, 313 which depends on the local policy. While for the single sided 314 associated bidirectional LSPs, the teardown of the initialized LSP 315 should induce the teardown of the trigger-established LSP, but the 316 teardown of the trigger-established LSP (using PathErr with state 317 removal) should not induce the teardown of the initialized LSP (which 318 depends on the local policy). 320 4. Association of LSPs 322 4.1. Extended ASSOCIATION Object 324 The Extended ASSOCIATION object is defined in [RFC6780], which 325 enables MPLS-TP required LSP identification. The Extended ASSOCIATION 326 object is used as follows for associated bidirectional LSPs. 328 Association Types: 330 In order to bind two reverse unidirectional LSPs to be an 331 associated bidirectional LSP, new Association Types are defined in 332 this document: 334 Value Type 335 ----- ----- 336 4 (TBD) Double Sided Associated Bidirectional LSPs (D) 337 5 (TBD) Single Sided Associated Bidirectional LSPs (A) 339 Association ID: 16 bits 341 For both double sided and single sided provisioning, Association 342 ID is a value assigned by the node that originates the 343 association. 345 Association Source: 4 or 16 bytes 347 Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. 349 For double sided provisioning, Association Source is set to an 350 address selected by the node that originates the association 351 (which may be a management entity.) 353 For single sided provisioning, Association Source is set to an 354 address assigned to the node that originates the LSP. 356 Global Association Source: 4 bytes 358 Same as for IPv4 and IPv6 Extended ASSOCIATION objects defined in 359 [RFC6780]. 361 For both double sided and single sided provisioning, Global 362 Association Source, when used, is set to the Global_ID [RFC6370] 363 of the node that originates association. 365 Extended Association ID: 4 or 16 bytes 367 This field contains data that is additional information to support 368 unique identification. 370 For both double sided and single sided provisioning, Extended 371 Association ID, when used, is selected by the node that originates 372 the association. 374 If either Global Association Source or Extended Association 375 Address is required, an Extended ASSOCIATION object [RFC6780] is 376 used. Otherwise an ASSOCIATION object [RFC4872] is used. 378 4.1.1 Signaling of the Extended Association Object 380 As described in [RFC6780], association is always done based on 381 matching Path state or Resv state. Upstream initialized association 382 is represented in Extended ASSOCIATION objects carried in Path 383 message and downstream initialized association is represented in 384 Extended ASSOCIATION objects carried in Resv messages. The new 385 Association Types defined in this document are only used in upstream 386 initialized association. Thus they can only appear in Extended 387 ASSOCIATION objects signaled in Path message. 389 The rules associated with the processing of the Extended ASSOCIATION 390 objects in RSVP message are discussed in [RFC6780]. It said that in 391 the absence of Association Type-specific rules for identifying 392 association, the included Extended ASSOCIATION objects MUST be 393 identical. This document adds no specific rules, the association 394 will always operate based on the same Extended ASSOCIATION objects. 396 4.2. REVERSE_LSP Object 398 Path Computation Element (PCE)-based approaches, see [RFC4655], may 399 be used for path computation of a GMPLS LSP, and consequently an 400 associated bidirectional LSP, across domains and in a single domain. 401 The ingress Label Switching Router (LSR), maybe serve as a PCE or 402 Path Computation Client (PCC), has more information about the reverse 403 LSP. When the forward LSP is signaled, the reverse LSP's traffic 404 parameters, explicit route, LSP attributes, etc, can be carried in 405 the REVERSE_LSP object of the forward LSP's Path message. The egress 406 LSR can be triggered to establish the reverse LSP according to the 407 control information. 409 4.2.1. Format 411 The information of the reverse LSP is specified via the REVERSE_LSP 412 object, which is optional with class numbers in the form 11bbbbbb has 413 the following format: 415 Class = TBD (of the form 11bbbbbb), C_Type = 1 (TBD) 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 // (Subobjects) // 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 This object MUST NOT be used when the Extended ASSOCIATION object do 426 not exist or exist but the Association Type is not "Single Sided 427 Associated Bidirectional LSPs". 429 4.2.1.1. Subobjects 431 The contents of a REVERSE_LSP object are a series of variable-length 432 data items called subobjects, which can be SENDER_TSPCE, 433 EXPLICIT_ROUTE object (ERO), Session Attribute Object, Admin Status 434 Object, LSP_ATTRIBUTES Object, LSP_REQUIRED_ATTRIBUTES Object, 435 PROTECTION Object, ASSOCIATION Object, Extended ASSOCIATION Objects, 436 etc. 438 4.2.2. LSP Control 440 The signaling procedure without the REVERSE_LSP object carried in the 441 LSP1's Path message is described in section 3.2.1, which is the 442 default option. A node includes a REVERSE_LSP object and Extended 443 ASSOCIATION object with an "Single Sided Associated Bidirectional 444 LSPs" Association Type in an outgoing Path message when it wishes to 445 control the reverse LSP, and the receiver node B MUST convert the 446 subobjects of the REVERSE_LSP object into the corresponding objects 447 that carried in LSP2's Path message. The case of a non-supporting 448 egress node is outside of this document. If node A want to tear down 449 the associated bidirectional LSP, a PathTear message will be sent out 450 and Node B is triggered to tear down LSP2. 452 4.2.3. Updated RSVP Message Formats 454 This section presents the RSVP message-related formats as modified by 455 this document. Unmodified RSVP message formats are not listed. 457 The format of a Path message is as follows: 459 ::= [ ] 461 [ [ | ] ... ] 462 [ ] 463 464 465 [ ] 466 467 [ ] 468 [ ... ] 469 [ ] 470 [ ... ] 471 [ ] 472 [ ... ] 473 [ ... ] 475 477 The format of the is not modified by the present 478 document. 480 4.2.4. Compatibility 482 The REVERSE_LSP object is defined with class numbers in the form 483 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 484 [RFC2205], nodes not supporting this extension will ignore the object 485 but forward it, unexamined and unmodified, in all messages resulting 486 from this message. Especially, this object received in PathTear, or 487 PathErr messages should be forwarded immediately in the same message, 488 but should be saved with the corresponding state and forwarded in any 489 refresh message resulting from that state when received in Path 490 message. 492 5. IANA Considerations 494 IANA is requested to administer assignment of new values for 495 namespace defined in this document and summarized in this section. 497 5.1. Association Type 499 Within the current document, two new Association Types are defined in 500 the Extended ASSOCIATION object. 502 Value Type 503 ----- ----- 504 4 (TBD) Double Sided Associated Bidirectional LSPs (D) 505 5 (TBD) Single Sided Associated Bidirectional LSPs (A) 507 5.2. REVERSE_LSP Object 509 A new class named REVERSE_LSP has been created in the 11bbbbbb range 510 (TBD) with the following definition: 512 Class Types or C-types (1, TBD): 514 There are no other IANA considerations introduced by this document. 516 6. Security Considerations 518 This document introduces two new Association Types, and except this, 519 there are no security issues about the Extended ASSOCIATION object 520 are introduced here. 522 The procedures defined in this document result in an increase in the 523 amount of topology information carried in signaling messages since 524 the presence of the REVERSE_LSP object necessarily means that there 525 is more information about associated bidirectional LSPs. Thus, in 526 the event of the interception of a signaling message, slightly more 527 could be deduced about the state of the network than was previously 528 the case, but this is judged to be a very minor security risk as this 529 information is already available via routing. 531 Otherwise, this document introduces no additional security 532 considerations. For a general discussion on MPLS and GMPLS related 533 security issues, see the MPLS/GMPLS security framework [RFC5920]. 535 7. Acknowledgement 537 The authors would like to thank Lou Berger for his great guidance in 538 this work, George Swallow and Jie Dong for the discussion of 539 recovery, Lamberto Sterling for his valuable comments on the section 540 of asymmetric bandwidths, Daniel King for the review of the document, 541 Attila Takacs for the discussion of the provisioning model. At the 542 same time, the authors would also like to acknowledge the 543 contributions of Bo Wu, Xihua Fu, Lizhong Jin for the initial 544 discussions, and Wenjuan He for the prototype implementation. The 545 authors would also like to thank Siva Sivabalan, Eric Osborne and 546 Robert Sawaya for the discussion on the association object. 548 8. References 550 8.1. Normative references 552 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 553 Association Object Extensions", RFC 6780, October 2012. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 559 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 560 Functional Specification", RFC 2205, September 1997. 562 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 563 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 564 Tunnels", RFC 3209, December 2001. 566 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 567 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 568 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 570 [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions 571 to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 573 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 574 Extensions in Support of End-to-End Generalized Multi- 575 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 576 2007. 578 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 579 "GMPLS Segment Recovery", RFC 4873, May 2007. 581 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., 582 Psenak, P., Mabbey, P., "Routing Extensions for Discovery 583 of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 584 Engineering (TE) Mesh Membership", RFC 4972, July 2007. 586 8.2. Informative References 588 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 589 Element (PCE)-Based Architecture", RFC 4655, August 2006. 591 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 592 and S. Ueno, "Requirements of an MPLS Transport Profile", 593 RFC 5654, September 2009. 595 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 596 Networks", RFC 5920, July 2010. 598 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 599 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 601 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 602 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 603 Framework", RFC 6373, September 2011. 605 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 606 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 607 Switched Paths (LSPs)", RFC 6387, September 2011. 609 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 610 6689, July 2012. 612 Authors' Addresses 614 Fei Zhang (editor) 615 ZTE 617 Email: zhang.fei3@zte.com.cn 619 Ruiquan Jing 620 China Telecom 622 Email: jingrq@ctbri.com.cn 624 Fan Yang 625 ZTE 627 Email: yang.fan5@zte.com.cn 629 Weilian Jiang 630 ZTE 632 Email: jiang.weilian@zte.com.cn 634 Rakesh Gandhi 635 Cisco Systems 637 Email: rgandhi@cisco.com