idnits 2.17.1 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-10.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 (September 13, 2014) is 3513 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 CCAMP Working Group Fei Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track Ruiquan Jing 5 Expires: March 17, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 September 13, 2014 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-10 13 Abstract 15 This document describes Resource reSerVation Protocol (RSVP) 16 extensions to bind two point-to-point unidirectional Label Switched 17 Paths (LSPs) into an associated bidirectional LSP. The association 18 is achieved by defining new Association Types for use in ASSOCIATION 19 and in Extended ASSOCIATION Objects. One of these types enables 20 independent provisioning of the associated bidirectional LSPs on both 21 sides, while the other enables single sided provisioning. The 22 REVERSE_LSP Object is also defined to enable a single endpoint to 23 specify all the parameters of an associated LSP in the single sided 24 provisioning case. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . 4 60 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.1. Reverse Unidirectional LSPs . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 4 64 3.1.1. Single Sided Provisioning . . . . . . . . . . . . . . 5 65 3.1.2. Double Sided Provisioning . . . . . . . . . . . . . . 5 66 3.2. Association Signaling Overview . . . . . . . . . . . . . . 5 67 3.2.1. Single Sided Provisioning . . . . . . . . . . . . . . 6 68 3.2.2. Double Sided Provisioning . . . . . . . . . . . . . . 6 69 3.3. Asymmetric Bandwidth Signaling Overview . . . . . . . . . 6 70 3.3.1. Single Sided Provisioning . . . . . . . . . . . . . . 6 71 3.3.2. Double Sided Provisioning . . . . . . . . . . . . . . 7 72 3.4. Recovery LSP Overview . . . . . . . . . . . . . . . . . . 7 73 4. Message and Object Definitions . . . . . . . . . . . . . . . . 7 74 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 7 75 4.2. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8 76 4.3. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 9 77 4.4. REVERSE_LSP Object Definition . . . . . . . . . . . . . . 9 78 4.4.1. REVERSE_LSP Object Format . . . . . . . . . . . . . . 9 79 4.4.2. REVERSE_LSP Subobjects . . . . . . . . . . . . . . . . 10 80 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. Rules For ASSOCIATION Object . . . . . . . . . . . . . . . 10 82 5.1.1. Compatibility For ASSOCIATION Object . . . . . . . . . 12 83 5.2. Rules For REVERSE_LSP Object . . . . . . . . . . . . . . . 12 84 5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 13 85 5.3. Single Sided Associated Bidirectional LSP Setup and 86 Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 89 6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 14 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 100 specifies that MPLS-TP MUST support associated bidirectional point- 101 to-point Label Switched Paths (LSPs). These requirements are given 102 in Section 2.1 (General Requirements), and are repeated below: 104 7. MPLS-TP MUST support associated bidirectional point-to-point 105 LSPs. 107 11. The end points of an associated bidirectional LSP MUST be aware 108 of the pairing relationship of the forward and reverse LSPs used to 109 support the bidirectional service. 111 12. Nodes on the LSP of an associated bidirectional LSP where both 112 the forward and backward directions transit the same node in the same 113 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 114 the forward and the backward directions of the LSP. 116 50. The MPLS-TP control plane MUST support establishing associated 117 bidirectional P2P LSP including configuration of protection functions 118 and any associated maintenance functions. 120 The above requirements are also repeated in [RFC6373]. 122 Furthermore, an associated bidirectional LSP is also useful for 123 protection switching for Operations, Administrations and Maintenance 124 (OAM) messages that require a return path. 126 A variety of applications, such as Internet services and the return 127 paths of OAM messages, exist and which may have different upstream 128 and downstream bandwidth requirements. [RFC5654] specifies an 129 asymmetric bandwidth requirement in Section 2.1 (General 130 Requirements), and is repeated below: 132 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 133 bandwidth requirements, i.e., the amount of reserved bandwidth 134 differs between the forward and backward directions. 136 The approach for supporting asymmetric bandwidth co-routed 137 bidirectional LSPs is defined in [RFC6387]. 139 The method of association and the corresponding Resource reSerVation 140 Protocol (RSVP) ASSOCIATION object are defined in [RFC4872], 141 [RFC4873] and [RFC6689]. In that context, the ASSOCIATION Object is 142 used to associate a recovery LSP with the LSP it is protecting. This 143 object also has broader applicability as a mechanism to associate 144 RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that 145 can be more generally applied for this purpose. This document refers 146 to the [RFC4872] defined ASSOCIATION Objects and the [RFC6780] 147 defined the Extended ASSOCIATION Objects collectively as the 148 (Extended) ASSOCIATION Objects. 150 This document specifies mechanisms for binding two reverse 151 unidirectional LSPs into an associated bidirectional LSP. The 152 association is achieved by defining new Association Types for use in 153 (Extended) ASSOCIATION Objects. One of these types enables 154 independent provisioning of the associated bidirectional LSPs, while 155 the other enables single sided provisioning. The REVERSE_LSP Object 156 is also defined to enable a single endpoint to specify all the 157 parameters of an associated LSP in the single sided provisioning 158 case. For example, the REVERSE_LSP Object allow asymmetric upstream 159 and downstream bandwidths for the associated bidirectional LSP. 161 2. Conventions Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2.1. Definitions 169 2.1.1. Reverse Unidirectional LSPs 171 Two reverse unidirectional LSPs are setup in the opposite directions 172 between a pair of source and destination nodes to form an associated 173 bidirectional LSP. A reverse unidirectional LSP originates on the 174 same node where the forward unidirectional LSP terminates, and it 175 terminates on the same node where the forward unidirectional LSP 176 originates. 178 3. Overview 180 3.1. Provisioning Model Overview 182 This section provides an overview and definition of the models for 183 provisioning bidirectional LSPs. 185 The associated bidirectional LSP's forward and reverse unidirectional 186 LSPs are established, monitored, and protected independently as 187 specified by [RFC5654]. Configuration information regarding the LSPs 188 can be provided at one or both endpoints of the associated 189 bidirectional LSP. Depending on the method chosen, there are two 190 models of creating an associated bidirectional LSP; single sided 191 provisioning, and double sided provisioning. 193 3.1.1. Single Sided Provisioning 195 For the single sided provisioning, the TE tunnel is configured only 196 on one endpoint. An LSP for this tunnel is initiated by the 197 initiating endpoint with the (Extended) ASSOCIATION Object inserted 198 in the Path message. The other endpoint then creates the 199 corresponding reverse TE tunnel and signals the reverse LSP in 200 response. 202 3.1.2. Double Sided Provisioning 204 For the double sided provisioning, two unidirectional TE tunnels are 205 configured independently on both endpoints. The LSPs for the tunnels 206 are signaled with (Extended) ASSOCIATION Objects inserted in the Path 207 message by both endpoints to indicate that the two LSPs are to be 208 associated to form a bidirectional LSP. 210 3.2. Association Signaling Overview 212 This section provides an overview of the association signaling 213 methods for the bidirectional LSPs. 215 Three scenarios exist for binding two unidirectional LSPs together to 216 form an associated bidirectional LSP. These are: 1) Neither 217 unidirectional LSP exists, and both must be established. 2) Both 218 unidirectional LSPs exist, but the association must be established. 219 3) One LSP exists, but the reverse associated LSP must be 220 established. 222 In each of the situations described above, both provisioning models 223 are applicable. 225 Path Computation Element (PCE)-based approaches [RFC4655], may be 226 used for path computation of an associated bidirectional LSP. 227 However, these approaches are outside the scope of this document. 229 Consider the topology described in Figure 1 (an example of associated 230 bidirectional LSP). LSP1 from A to B, takes the path A,D,B and LSP2 231 from B to A takes the path B,D,C,A. These two LSPs, once established 232 and associated, form an associated bidirectional LSP between node A 233 and node B. 235 LSP1 --> 236 A-------D-------B 237 \ / <-- LSP2 238 \ / 239 \ / 240 C 242 Figure 1: An example of associated bidirectional LSP 244 3.2.1. Single Sided Provisioning 246 For the single sided provisioning model, creation of reverse LSP1 is 247 triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. 248 When creation of reverse LSP2 is triggered by LSP1, LSP1 is 249 provisioned first (or refreshed if LSP1 already exists) at node A. 250 LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted 251 in the Path message, in which the Association Type indicating single 252 sided provisioning. Upon receiving this Path message for LSP1, node 253 B establishes reverse LSP2. The (Extended) ASSOCIATION Object 254 inserted in LSP2's Path message is the same as that received in 255 LSP1's Path message. 257 A similar procedure is used if LSP2 is provisioned first at node B 258 and the creation of reverse LSP1 is triggered by LSP2. In both 259 cases, the two unidirectional LSPs are bound together to form an 260 associated bidirectional LSP based on identical (Extended) 261 ASSOCIATION Objects in the two LSPs' Path messages. 263 3.2.2. Double Sided Provisioning 265 For the double sided provisioning model, both LSP1 and LSP2 are 266 signaled independently with (Extended) ASSOCIATION Object inserted in 267 the Path message, in which the Association Type indicating double 268 sided provisioning. In this case, the two unidirectional LSPs are 269 bound together to form an associated bidirectional LSP based on 270 identical (Extended) ASSOCIATION Objects in the two LSPs' Path 271 messages. 273 3.3. Asymmetric Bandwidth Signaling Overview 275 This section provides an overview of the methods for signaling 276 asymmetric upstream and downstream bandwidths for the associated 277 bidirectional LSPs. 279 3.3.1. Single Sided Provisioning 281 A new REVERSE_LSP Object for use in the single sided provisioning 282 model is defined in this document, in Section 4.4. When the single 283 sided provisioning model is used, a SENDER_TSPEC object can be added 284 in the REVERSE_LSP Object as a subobject in the initiating LSP's Path 285 message to specify a different bandwidth for the reverse LSP. As 286 described in this document, addition of the REVERSE_LSP Object also 287 allows the initiating node to control the reverse LSP by including 288 other existing objects in a REVERSE_LSP Object. 290 Consider again the topology described in Figure 1, where the creation 291 of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the 292 (Extended) ASSOCIATION Object with Association Type indicating single 293 sided provisioning and inserts a SENDER_TSPEC subobject for use by 294 LSP2 in the REVERSE_LSP Object in the Path message. Node B then 295 establishes the LSP2 in the reverse direction using the asymmetric 296 bandwidth thus specified by LSP1 and allows node A to control the 297 reverse LSP2. 299 3.3.2. Double Sided Provisioning 301 When the double sided provisioning model is used, the two 302 unidirectional LSPs are established with separate bandwidths, which 303 may or may not be identical. However, these LSPs are associated 304 purely based on the identical contents of their (Extended) 305 ASSOCIATION Objects. 307 3.4. Recovery LSP Overview 309 Recovery of each unidirectional LSP forming the bidirectional LSP is 310 independent [RFC5654] and is based on the parameters signaled in 311 their respective RSVP Path messages. 313 Recovery LSP association is based on the identical content of the 314 (Extended) ASSOCIATION Objects signaled in their Path messages during 315 the initial LSP setup for both single sided and double sided 316 provisioning. 318 4. Message and Object Definitions 320 4.1. RSVP Message Formats 322 This section presents the RSVP message-related formats as modified by 323 this document. Unmodified RSVP message formats are not listed. 325 The format of a Path message is as follows: 327 ::= [ ] 328 [ [ | ] ... ] 330 [ ] 331 332 333 [ ] 334 335 [ ] 336 [ ... ] 337 [ ] 338 [ ... ] 339 [ ] 340 [ ... ] 341 [ ... ] 342 [ ... ] 343 345 The format of the is not modified by this 346 document. 348 4.2. ASSOCIATION Object 350 The ASSOCIATION Object is populated using the rules defined below for 351 associating two reverse unidirectional LSPs to form a bidirectional 352 LSP. 354 Association Types: 356 In order to bind two reverse unidirectional LSPs to be an 357 associated bidirectional LSP, the Association Type MUST be set to 358 indicate either single sided or double sided LSPs. 360 The new Association Types are defined as follows: 362 Value Type 364 ----- ----- 365 TBD Double Sided Associated Bidirectional LSP (D) 366 TBD Single Sided Associated Bidirectional LSP (A) 368 Association ID: 370 For both single sided and double sided provisioning, Association 371 ID MUST be set to a value assigned by the node that originates the 372 association for the bidirectional LSP. 374 Association Source: 376 Association Source MUST be set to an address selected by the node 377 that originates the association for the bidirectional LSP. For 378 example, this may be a management entity, or in the case of single 379 sided provisioning, an address assigned to the node that 380 originates the LSP. 382 4.3. Extended ASSOCIATION Object 384 The Extended ASSOCIATION Object is populated using the rules defined 385 below for associating two reverse unidirectional LSPs to form a 386 bidirectional LSP. 388 The Association Type, Association ID and Association Source MUST be 389 set as defined for the ASSOCIATION Object in Section 4.1. 391 Global Association Source: 393 For both single sided and double sided provisioning, Global 394 Association Source, when used, MUST be set to the Global_ID 395 [RFC6370] of the node that originates the association for the 396 bidirectional LSP. 398 Extended Association ID: 400 For both single sided and double sided provisioning, Extended 401 Association ID, when used, MUST be set to a value selected by the 402 node that originates the association for the bidirectional LSP. 404 4.4. REVERSE_LSP Object Definition 406 4.4.1. REVERSE_LSP Object Format 408 The information of the reverse LSP is specified via the REVERSE_LSP 409 Object. This is an optional object carried in a Path message with 410 Class Number in the form 11bbbbbb and has the following format: 412 Class_Num = TBD (of the form 11bbbbbb), C_Type = 1 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 // (Subobjects) // 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 4.4.2. REVERSE_LSP Subobjects 424 The contents of a REVERSE_LSP Object is a variable length series of 425 subobjects and have the same format as RSVP Objects, see Section 426 3.1.2 of [RFC2205]. The subobjects permitted in the REVERSE_LSP 427 Object are previously defined as Path message Objects, and have the 428 same order in the REVERSE_LSP Object. 430 Examples of the Path message objects carried in the REVERSE_LSP 431 Object are (but not limited to): 433 - SENDER_TSPEC [RFC2205] 434 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 435 - SESSION_ATTRIBUTE Object [RFC3209] 436 - ADMIN_STATUS Object [RFC3473] 437 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 438 - PROTECTION Object [RFC3473] [RFC4872] 440 5. Processing Rules 442 In general, the processing rules for the ASSOCIATION Object are as 443 specified in [RFC4872] and Extended ASSOCIATION Object are specified 444 in [RFC6780]. Following sections describe the rules for processing 445 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 446 bidirectional LSPs. 448 5.1. Rules For ASSOCIATION Object 450 This section defines the processing for the association of two 451 unidirectional LSPs to form an associated bidirectional LSP. Such 452 association is based on the use of an (Extended) ASSOCIATION Object. 454 The procedures related to the actual identification of associations 455 between LSPs based on (Extended) ASSOCIATION objects are defined in 456 [RFC6780]. [RFC6780] specifies that in the absence of Association 457 Type-specific rule for identifying association, the included 458 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 459 for an association to exist. This document adds no specific rules 460 for the new Association Types defined, and the identification of LSP 461 association therefore proceeds as specified in [RFC6780]. 463 As described in [RFC6780], association of LSPs can be upstream or 464 downstream initiated, as indicated by (Extended) ASSOCIATION objects 465 in Path or Resv Messages. The association of bidirectional LSPs is 466 always upstream initialized, therefore the Association Types defined 467 in this document are only to be interpreted in Path Messages. These 468 types SHOULD NOT be used in ASSOCIATION objects carried in Resv 469 messages and SHOULD be ignored if present. 471 To indicate an associated bidirectional LSP, an ingress MUST insert 472 an (Extended) ASSOCIATION Object into the Path message of the 473 unidirectional LSP that is part of the associated bidirectional LSP 474 it initiates. If either Global Association Source or Extended 475 Association Address is required, then an Extended ASSOCIATION Object 476 [RFC6780] MUST be inserted in the Path message. Otherwise, an 477 ASSOCIATION Object MAY be used. Only one (Extended) ASSOCIATION 478 Object with the Association Types defined in this document SHOULD be 479 included by an egress in an outgoing Path message. (Extended) 480 ASSOCIATION Objects with both single sided and double sided 481 Association Types MUST NOT be added in the same Path message. 483 The ingress node MUST set the Association Type field in the 484 (Extended) ASSOCIATION Object to "Single Sided Associated 485 Bidirectional LSP" when single sided provisioning is used, and to 486 "Double Sided Associated Bidirectional LSP" when double sided 487 provisioning is used. 489 A transit node MAY identify the unidirectional LSPs of an associated 490 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 491 Association Type values defined in this document, carried in Path 492 messages. Clearly, such associations are only possible when the LSPs 493 transit the node. As mentioned above, such associations are made per 494 the rules defined in [RFC6780]. 496 Egress nodes which support the Association Types defined in this 497 document identify the unidirectional LSPs of an associated 498 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 499 Path messages. Note that an ingress node will normally be the 500 ingress for one of the unidirectional LSPs that make up an associated 501 bidirectional LSP. When an egress node receives a Path message 502 containing an (Extended) ASSOCIATION Object with one of the 503 Association Types defined in this document, it MUST attempt to 504 identify other LSPs (including ones for which it is an ingress node) 505 with which the LSP being processed is associated. As defined above, 506 such associations are made per the rules defined in [RFC6780]. 508 Associated bidirectional LSP teardown follows the standard procedures 509 defined in [RFC3209] and [RFC3473] either without or with the 510 administrative status. Generally, the teardown procedures of the 511 unidirectional LSPs forming an associated bidirectional LSP are 512 independent of each other, so it is possible that while one LSP 513 follows graceful teardown with administrative status, the reverse LSP 514 is torn down without administrative status (using 515 PathTear/ResvTear/PathErr with state removal). See Section 5.3 below 516 for additional rules related to LSPs established using single sided 517 provisioning. 519 When an LSP signaled with a Path message containing an (Extended) 520 ASSOCIATION Object with an Association Type defined in this document 521 is torn down, the processing node SHALL remove the binding of the LSP 522 to any previously identified associated bidirectional LSP. 524 No additional processing is needed for Path messages with an 525 (Extended) ASSOCIATION Object containing an Association Type field of 526 Double Sided Associated Bidirectional LSP. 528 5.1.1. Compatibility For ASSOCIATION Object 530 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 531 ASSOCIATION Object has been defined in [RFC6780], both with class 532 numbers in the form 11bbbbbb, which ensures compatibility with 533 non-supporting nodes. Per [RFC2205], such nodes will ignore the 534 object but forward it without modification. 536 Operators wishing to use a function supported by a particular 537 association type SHOULD ensure that the type is supported on any node 538 that is expected to act on the association [RFC6780]. 540 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 541 this document. The recovery mechanisms defined in [RFC4872] and 542 [RFC4873] rely on the use of the (Extended) ASSOCIATION objects, but 543 use a different value for Association Type; multiple ASSOCIATION 544 objects can be present in the LSP Path message and can coexist with 545 the procedures defined in this document. 547 5.2. Rules For REVERSE_LSP Object 549 A node initiating a Path message containing an ASSOCIATION or 550 Extended ASSOCIATION Object with the Association Type set to "Single 551 Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object 552 in the Path message of the LSP when it wishes to control the reverse 553 LSP originating on the other endpoint node. 555 The REVERSE_LSP subobject MAY contain any of the specified objects 556 which the initiating node desires to have included in the Path 557 message for the associated reverse LSP. A REVERSE_LSP Object MUST 558 contain at least one subobject. If there is no subobject to be added 559 in the REVERSE_LSP Object, then the REVERSE_LSP Object MUST NOT be 560 added in the Path message. 562 A node receiving a valid Path message containing a REVERSE_LSP Object 563 that is not the egress node for the LSP being signaled MUST forward 564 the REVERSE_LSP Object unchanged in the outgoing Path message. 566 An egress node, upon receiving a Path message containing an 567 REVERSE_LSP Object MUST verify that the Path message contains an 568 ASSOCIATION or Extended ASSOCIATION object with the Association Type 569 set to "Single Sided Associated Bidirectional LSP". If it does not, 570 the Path message MUST NOT trigger a reverse LSP. This verification 571 failure SHOULD NOT trigger any RSVP message but can be logged 572 locally, and perhaps reported through network management mechanisms. 574 Once validated, the egress MUST use the subobjects contained in any 575 present REVERSE_LSP Objects in the management of the reverse LSP 576 described in the previous section. Note that the contents of a 577 REVERSE_LSP Object may change over the life of an LSP and such 578 changes MUST result in corresponding changes in the reverse LSP. An 579 egress node MUST tear down and reestablish a new reverse LSP when 580 REVERSE_LSP Object is either added or removed in the received Path 581 message. 583 5.2.1. Compatibility For REVERSE_LSP Object 585 The REVERSE_LSP Object is defined with class numbers in the form 586 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 587 [RFC2205], such nodes will ignore the object but forward it without 588 modification. 590 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown 592 An egress node, upon receiving a Path message containing an 593 ASSOCIATION or Extended ASSOCIATION Object with Association Type set 594 to "Single Sided Associated Bidirectional LSP" MUST create an LSP in 595 the reverse direction or reject the Path message by sending a 596 PathErr. 598 If REVERSE_LSP Object is not present in the received Path message of 599 the LSP, the egress node SHOULD use the LSP properties from the 600 received LSP Path message to signal the LSP in the reverse direction 601 (which may depend on the local policy). Note that the contents of 602 the received Path message may change over the life of an LSP and such 603 changes MUST result in corresponding changes in the reverse LSP. The 604 teardown of the initiating LSP SHOULD trigger the teardown of the 605 reverse LSP, however, teardown of the reverse LSP SHOULD NOT trigger 606 the teardown of the initiating LSP (which may depend on the local 607 policy). 609 If REVERSE_LSP Object is present in the received Path message of the 610 LSP, the egress node follows the procedure defined in Section 5.2 to 611 setup the reverse LSP. If initiating node controlling the reverse 612 LSP, wishes to tear down the associated bidirectional LSP, the 613 initiating node sends a PathTear message to the egress node, the 614 egress node MUST trigger to tear down the reverse associated LSP, 615 however, teardown of the reverse LSP SHOULD NOT trigger the teardown 616 of the initiating LSP (which may depend on the local policy). 618 6. IANA Considerations 620 IANA is requested to administer assignment of new values for 621 namespace defined in this document and summarized in this section. 623 6.1. Association Types 625 IANA maintains the "Generalized Multi-Protocol Label Switching 626 (GMPLS) Signaling Parameters" registry (see 627 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 628 Type" subregistry is included in this registry. 630 This registry will be updated by new Association Types for 631 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 632 as follows: 634 Value Name Reference 635 TBD Double Sided Associated Bidirectional LSP (D) Section 4.2 636 TBD Single Sided Associated Bidirectional LSP (A) Section 4.2 638 6.2. REVERSE_LSP Object 640 IANA maintains the "RSVP Parameters" registry (see 641 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 642 Class Names, Class Numbers, and Class Types subregistry is included 643 in this registry. 645 This registry will be extended for new Class Number (Class-Num) and 646 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 647 11bbbbbb range defined in this document as follows: 649 Class Number Class Name Reference 650 TBD REVERSE_LSP Section 4.4 652 - REVERSE_LSP Object: Class Type or C-type = 1 654 There are no other IANA considerations introduced by this document. 656 7. Security Considerations 658 This document introduces two new Association Types, however, no new 659 security issues relating to the (Extended) ASSOCIATION Object are 660 introduced. 662 The procedures defined in this document result in an increased state 663 information carried in signaling messages. The presence of the 664 REVERSE_LSP Object necessarily provides more information about the 665 LSPs. Thus, in the event of the interception of a signaling message, 666 slightly more information about the state of the network could be 667 deduced than was previously the case. This is judged to be a very 668 minor security risk as this information is already available via 669 routing. 671 Otherwise, this document introduces no additional security 672 considerations. For a general discussion on MPLS and GMPLS related 673 security issues, see the MPLS/GMPLS security framework [RFC5920]. 675 8. Acknowledgement 677 The authors would like to thank Lou Berger and George Swallow for 678 their great guidance in this work, Jie Dong for the discussion of 679 recovery, Lamberto Sterling for his valuable comments on the section 680 of asymmetric bandwidths, Attila Takacs for the discussion of the 681 provisioning model and Lou Berger, Daniel King and Deborah Brungard 682 for the review of the document. At the same time, the authors would 683 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 684 Lizhong Jin for the initial discussions, and Wenjuan He for the 685 prototype implementation. The authors would also like to thank Siva 686 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 687 ASSOCIATION object. The authors would like to thank Matt Hartley for 688 providing useful suggestions on the document and Lou Berger for 689 careful editorial reviews. 691 9. References 693 9.1. Normative References 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 699 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 700 Functional Specification", RFC 2205, September 1997. 702 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 703 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 704 Tunnels", RFC 3209, December 2001. 706 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 707 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 708 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 710 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 711 Extensions in Support of End-to-End Generalized Multi- 712 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 713 2007. 715 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 716 "GMPLS Segment Recovery", RFC 4873, May 2007. 718 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 719 Association Object Extensions", RFC 6780, October 2012. 721 9.2. Informative References 723 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 724 Element (PCE)-Based Architecture", RFC 4655, August 2006. 726 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 727 Ayyangarps, "Encoding of Attributes for MPLS LSP 728 Establishment Using Resource Reservation Protocol Traffic 729 Engineering (RSVP-TE)", RFC 5420, February 2009. 731 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 732 and S. Ueno, "Requirements of an MPLS Transport Profile", 733 RFC 5654, September 2009. 735 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 736 Networks", RFC 5920, July 2010. 738 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 739 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 741 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 742 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 743 Framework", RFC 6373, September 2011. 745 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 746 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 747 Switched Paths (LSPs)", RFC 6387, September 2011. 749 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 750 6689, July 2012. 752 Authors' Addresses 754 Fei Zhang (editor) 755 Huawei 757 Email: zhangfei7@huawei.com 759 Ruiquan Jing 760 China Telecom 762 Email: jingrq@ctbri.com.cn 764 Rakesh Gandhi (editor) 765 Cisco Systems 767 Email: rgandhi@cisco.com 769 Fan Yang 770 ZTE 772 Email: yang.fan240347@gmail.com 774 Weilian Jiang 775 ZTE 777 Email: jiang.weilian@gmail.com