idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-00.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 (December 8, 2014) is 3420 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: June 11, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 December 8, 2014 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-00 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 Traffic Engineering (TE) 196 tunnel is configured only on one endpoint. An LSP for this tunnel is 197 initiated by the initiating endpoint with the (Extended) ASSOCIATION 198 Object inserted in the Path message. The other endpoint then creates 199 the 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 an associated 352 bidirectional 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 (values are 361 temporary early allocations as per RFC7120): 363 Value Type 365 ----- ----- 366 3 Double Sided Associated Bidirectional LSP (D) 367 4 Single Sided Associated Bidirectional LSP (A) 369 Association ID: 371 For both single sided and double sided provisioning, Association 372 ID MUST be set to a value assigned by the node that originates the 373 association for the bidirectional LSP. 375 Association Source: 377 Association Source MUST be set to an address selected by the node 378 that originates the association for the bidirectional LSP. For 379 example, this may be a management entity, or in the case of single 380 sided provisioning, an address assigned to the node that 381 originates the LSP. 383 4.3. Extended ASSOCIATION Object 385 The Extended ASSOCIATION Object is populated using the rules defined 386 below for associating two reverse unidirectional LSPs to form a 387 bidirectional LSP. 389 The Association Type, Association ID and Association Source MUST be 390 set as defined for the ASSOCIATION Object in Section 4.1. 392 Global Association Source: 394 For both single sided and double sided provisioning, Global 395 Association Source, when used, MUST be set to the Global_ID 396 [RFC6370] of the node that originates the association for the 397 bidirectional LSP. 399 Extended Association ID: 401 For both single sided and double sided provisioning, Extended 402 Association ID, when used, MUST be set to a value selected by the 403 node that originates the association for the bidirectional LSP. 405 4.4. REVERSE_LSP Object Definition 407 4.4.1. REVERSE_LSP Object Format 409 The information of the reverse LSP is specified via the REVERSE_LSP 410 Object. This is an optional object carried in a Path message with 411 Class Number in the form 11bbbbbb and has the following format: 413 Class_Num = 203 (of the form 11bbbbbb), C_Type = 1 (values are 414 temporary early allocations as per RFC7120) 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 // (Subobjects) // 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 4.4.2. REVERSE_LSP Subobjects 426 The contents of a REVERSE_LSP Object is a variable length series of 427 subobjects and have the same format as RSVP Objects, see Section 428 3.1.2 of [RFC2205]. The subobjects permitted in the REVERSE_LSP 429 Object are previously defined as Path message Objects, and have the 430 same order in the REVERSE_LSP Object. 432 Examples of the Path message objects carried in the REVERSE_LSP 433 Object are (but not limited to): 435 - SENDER_TSPEC [RFC2205] 436 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 437 - SESSION_ATTRIBUTE Object [RFC3209] 438 - ADMIN_STATUS Object [RFC3473] 439 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 440 - PROTECTION Object [RFC3473] [RFC4872] 442 5. Processing Rules 444 In general, the processing rules for the ASSOCIATION Object are as 445 specified in [RFC4872] and Extended ASSOCIATION Object are specified 446 in [RFC6780]. Following sections describe the rules for processing 447 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 448 bidirectional LSPs. 450 5.1. Rules For ASSOCIATION Object 452 This section defines the processing for the association of two 453 unidirectional LSPs to form an associated bidirectional LSP. Such 454 association is based on the use of an (Extended) ASSOCIATION Object. 456 The procedures related to the actual identification of associations 457 between LSPs based on (Extended) ASSOCIATION Objects are defined in 458 [RFC6780]. [RFC6780] specifies that in the absence of Association 459 Type-specific rule for identifying association, the included 460 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 461 for an association to exist. This document adds no specific rules 462 for the new Association Types defined, and the identification of LSP 463 association therefore proceeds as specified in [RFC6780]. 465 As described in [RFC6780], association of LSPs can be upstream or 466 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 467 in Path or Resv Messages. The association of bidirectional LSPs is 468 always upstream initialized, therefore the Association Types defined 469 in this document are only to be interpreted in Path Messages. These 470 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 471 messages and SHOULD be ignored if present. 473 To indicate an associated bidirectional LSP, an ingress node MUST 474 insert an (Extended) ASSOCIATION Object into the Path message of the 475 unidirectional LSP that is part of the associated bidirectional LSP 476 it initiates. If either Global Association Source or Extended 477 Association Address is required, then an Extended ASSOCIATION Object 478 [RFC6780] MUST be inserted in the Path message. Otherwise, an 479 ASSOCIATION Object MAY be used. Only one (Extended) ASSOCIATION 480 Object with the Association Types defined in this document SHOULD be 481 included by an ingress node in an outgoing Path message. (Extended) 482 ASSOCIATION Objects with both single sided and double sided 483 Association Types MUST NOT be added in the same Path message. 485 The ingress node MUST set the Association Type field in the 486 (Extended) ASSOCIATION Object to "Single Sided Associated 487 Bidirectional LSP" when single sided provisioning is used, and to 488 "Double Sided Associated Bidirectional LSP" when double sided 489 provisioning is used. 491 A transit node MAY identify the unidirectional LSPs of an associated 492 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 493 Association Type values defined in this document, carried in Path 494 messages. Clearly, such associations are only possible when the LSPs 495 transit the node. As mentioned above, such associations are made per 496 the rules defined in [RFC6780]. 498 Egress nodes which support the Association Types defined in this 499 document identify the unidirectional LSPs of an associated 500 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 501 Path messages. Note that an ingress node will normally be the 502 ingress for one of the unidirectional LSPs that make up an associated 503 bidirectional LSP. When an egress node receives a Path message 504 containing an (Extended) ASSOCIATION Object with one of the 505 Association Types defined in this document, it MUST attempt to 506 identify other LSPs (including ones for which it is an ingress node) 507 with which the LSP being processed is associated. As defined above, 508 such associations are made per the rules defined in [RFC6780]. 510 Associated bidirectional LSP teardown follows the standard procedures 511 defined in [RFC3209] and [RFC3473] either without or with the 512 administrative status. Generally, the teardown procedures of the 513 unidirectional LSPs forming an associated bidirectional LSP are 514 independent of each other, so it is possible that while one LSP 515 follows graceful teardown with administrative status, the reverse LSP 516 is torn down without administrative status (using 517 PathTear/ResvTear/PathErr with state removal). See Section 5.3 below 518 for additional rules related to LSPs established using single sided 519 provisioning. 521 When an LSP signaled with a Path message containing an (Extended) 522 ASSOCIATION Object with an Association Type defined in this document 523 is torn down, the processing node SHALL remove the binding of the LSP 524 to any previously identified associated bidirectional LSP. 526 No additional processing is needed for Path messages with an 527 (Extended) ASSOCIATION Object containing an Association Type field of 528 Double Sided Associated Bidirectional LSP. 530 5.1.1. Compatibility For ASSOCIATION Object 532 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 533 ASSOCIATION Object has been defined in [RFC6780], both with class 534 numbers in the form 11bbbbbb, which ensures compatibility with 535 non-supporting nodes. Per [RFC2205], such nodes will ignore the 536 object but forward it without modification. 538 Operators wishing to use a function supported by a particular 539 association type SHOULD ensure that the type is supported on any node 540 that is expected to act on the association [RFC6780]. 542 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 543 this document. The recovery mechanisms defined in [RFC4872] and 544 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 545 use a different value for Association Type; multiple ASSOCIATION 546 Objects can be present in the LSP Path message and can coexist with 547 the procedures defined in this document. 549 5.2. Rules For REVERSE_LSP Object 551 A node initiating a Path message containing an ASSOCIATION or 552 Extended ASSOCIATION Object with the Association Type set to "Single 553 Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object 554 in the Path message of the LSP when it wishes to control the reverse 555 LSP originating on the other endpoint node. 557 The REVERSE_LSP subobject MAY contain any of the specified objects 558 which the initiating node desires to have included in the Path 559 message for the associated reverse LSP. A REVERSE_LSP Object MUST 560 contain at least one subobject. If there is no subobject to be added 561 in the REVERSE_LSP Object, then the REVERSE_LSP Object MUST NOT be 562 added in the Path message. 564 A node receiving a valid Path message containing a REVERSE_LSP Object 565 that is not the egress node for the LSP being signaled MUST forward 566 the REVERSE_LSP Object unchanged in the outgoing Path message. 568 An egress node, upon receiving a Path message containing an 569 REVERSE_LSP Object MUST verify that the Path message contains an 570 ASSOCIATION or Extended ASSOCIATION object with the Association Type 571 set to "Single Sided Associated Bidirectional LSP". If it does not, 572 the Path message MUST NOT trigger a reverse LSP. This verification 573 failure SHOULD NOT trigger any RSVP message but can be logged 574 locally, and perhaps reported through network management mechanisms. 576 Once validated, the egress node MUST use the subobjects contained in 577 any present REVERSE_LSP Objects in the management of the reverse LSP 578 described in the previous section. Note that the contents of a 579 REVERSE_LSP Object may change over the life of an LSP and such 580 changes MUST result in corresponding changes in the reverse LSP. An 581 egress node MUST tear down and reestablish a new reverse LSP when 582 REVERSE_LSP Object is either added or removed in the received Path 583 message. 585 5.2.1. Compatibility For REVERSE_LSP Object 587 The REVERSE_LSP Object is defined with class numbers in the form 588 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 589 [RFC2205], such nodes will ignore the object but forward it without 590 modification. 592 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown 594 An egress node, upon receiving a Path message containing an 595 ASSOCIATION or Extended ASSOCIATION Object with Association Type set 596 to "Single Sided Associated Bidirectional LSP" MUST create an LSP in 597 the reverse direction or reject the Path message by sending a 598 PathErr. 600 If REVERSE_LSP Object is not present in the received Path message of 601 the LSP, the egress node SHOULD use the LSP properties from the 602 received LSP Path message to signal the LSP in the reverse direction 603 (which may depend on the local policy). Note that the contents of 604 the received Path message may change over the life of an LSP and such 605 changes MUST result in corresponding changes in the reverse LSP. The 606 teardown of the initiating LSP SHOULD trigger the teardown of the 607 reverse LSP, however, teardown of the reverse LSP SHOULD NOT trigger 608 the teardown of the initiating LSP (which may depend on the local 609 policy). 611 If REVERSE_LSP Object is present in the received Path message of the 612 LSP, the egress node follows the procedure defined in Section 5.2 to 613 setup the reverse LSP. If initiating node controlling the reverse 614 LSP, wishes to tear down the associated bidirectional LSP, the 615 initiating node sends a PathTear message to the egress node, the 616 egress node MUST trigger to tear down the reverse associated LSP, 617 however, teardown of the reverse LSP SHOULD NOT trigger the teardown 618 of the initiating LSP (which may depend on the local policy). 620 6. IANA Considerations 622 IANA is requested to administer assignment of new values for 623 namespace defined in this document and summarized in this section. 625 6.1. Association Types 627 IANA maintains the "Generalized Multi-Protocol Label Switching 628 (GMPLS) Signaling Parameters" registry (see 629 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 630 Type" subregistry is included in this registry. 632 This registry will be updated by new Association Types for 633 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 634 as follows: 636 Value Name Reference 637 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 638 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 640 Specified Association Type values are temporary early allocations as 641 per RFC7120. 643 6.2. REVERSE_LSP Object 645 IANA maintains the "RSVP Parameters" registry (see 646 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 647 Class Names, Class Numbers, and Class Types subregistry is included 648 in this registry. 650 This registry will be extended for new Class Number (Class-Num) and 651 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 652 11bbbbbb range defined in this document as follows: 654 Class Number Class Name Reference 655 203 REVERSE_LSP Section 4.4 657 - REVERSE_LSP : Class Type or C-type = 1 659 Specified REVERSE_LSP Class Number and Class Type values are 660 temporary early allocations as per RFC7120. 662 There are no other IANA considerations introduced by this document. 664 7. Security Considerations 666 This document introduces two new Association Types, however, no new 667 security issues relating to the (Extended) ASSOCIATION Object are 668 introduced. 670 The procedures defined in this document result in an increased state 671 information carried in signaling messages. The presence of the 672 REVERSE_LSP Object necessarily provides more information about the 673 LSPs. Thus, in the event of the interception of a signaling message, 674 slightly more information about the state of the network could be 675 deduced than was previously the case. This is judged to be a very 676 minor security risk as this information is already available via 677 routing. 679 Otherwise, this document introduces no additional security 680 considerations. For a general discussion on MPLS and GMPLS related 681 security issues, see the MPLS/GMPLS security framework [RFC5920]. 683 8. Acknowledgement 685 The authors would like to thank Lou Berger and George Swallow for 686 their great guidance in this work, Jie Dong for the discussion of 687 recovery, Lamberto Sterling for his valuable comments on the section 688 of asymmetric bandwidths, Attila Takacs for the discussion of the 689 provisioning model and Lou Berger, Daniel King and Deborah Brungard 690 for the review of the document. At the same time, the authors would 691 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 692 Lizhong Jin for the initial discussions, and Wenjuan He for the 693 prototype implementation. The authors would also like to thank Siva 694 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 695 ASSOCIATION Object. The authors would like to thank Matt Hartley for 696 providing useful suggestions on the document and Lou Berger for 697 careful editorial reviews. 699 9. References 701 9.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 707 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 708 Functional Specification", RFC 2205, September 1997. 710 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 711 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 712 Tunnels", RFC 3209, December 2001. 714 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 715 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 716 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 718 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 719 Extensions in Support of End-to-End Generalized Multi- 720 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 721 2007. 723 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 724 "GMPLS Segment Recovery", RFC 4873, May 2007. 726 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 727 Association Object Extensions", RFC 6780, October 2012. 729 9.2. Informative References 731 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 732 Element (PCE)-Based Architecture", RFC 4655, August 2006. 734 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 735 Ayyangarps, "Encoding of Attributes for MPLS LSP 736 Establishment Using Resource Reservation Protocol Traffic 737 Engineering (RSVP-TE)", RFC 5420, February 2009. 739 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 740 and S. Ueno, "Requirements of an MPLS Transport Profile", 741 RFC 5654, September 2009. 743 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 744 Networks", RFC 5920, July 2010. 746 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 747 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 749 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 750 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 751 Framework", RFC 6373, September 2011. 753 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 754 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 755 Switched Paths (LSPs)", RFC 6387, September 2011. 757 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 758 6689, July 2012. 760 Authors' Addresses 762 Fei Zhang (editor) 763 Huawei 765 Email: zhangfei7@huawei.com 767 Ruiquan Jing 768 China Telecom 770 Email: jingrq@ctbri.com.cn 772 Rakesh Gandhi (editor) 773 Cisco Systems 775 Email: rgandhi@cisco.com 777 Fan Yang 778 ZTE 780 Email: yang.fan240347@gmail.com 782 Weilian Jiang 783 ZTE 785 Email: jiang.weilian@gmail.com