idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01.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 (February 8, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Fei Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track Ruiquan Jing 5 Expires: August 12, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 February 8, 2015 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01 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) 2015 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 2.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 4 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 5 65 3.1.1. Single Sided Provisioning . . . . . . . . . . . . . . 5 66 3.1.2. Double Sided Provisioning . . . . . . . . . . . . . . 5 67 3.2. Association Signaling Overview . . . . . . . . . . . . . . 5 68 3.2.1. Single Sided Provisioning . . . . . . . . . . . . . . 6 69 3.2.2. Double Sided Provisioning . . . . . . . . . . . . . . 6 70 3.3. Asymmetric Bandwidth Signaling Overview . . . . . . . . . 7 71 3.3.1. Single Sided Provisioning . . . . . . . . . . . . . . 7 72 3.3.2. Double Sided Provisioning . . . . . . . . . . . . . . 7 73 3.4. Recovery LSP Overview . . . . . . . . . . . . . . . . . . 7 74 4. Message and Object Definitions . . . . . . . . . . . . . . . . 8 75 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 8 76 4.2. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 9 78 4.4. REVERSE_LSP Object Definition . . . . . . . . . . . . . . 9 79 4.4.1. REVERSE_LSP Object Format . . . . . . . . . . . . . . 9 80 4.4.2. REVERSE_LSP Subobjects . . . . . . . . . . . . . . . . 10 81 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1. Rules For ASSOCIATION Object . . . . . . . . . . . . . . . 10 83 5.1.1. Compatibility For ASSOCIATION Object . . . . . . . . . 12 84 5.2. Rules For REVERSE_LSP Object . . . . . . . . . . . . . . . 13 85 5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 13 86 5.3. Single Sided Associated Bidirectional LSP Setup and 87 Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 90 6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 15 91 6.3. Reverse LSP Failure PathErr Sub-code . . . . . . . . . . . 15 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 94 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 103 specifies that MPLS-TP MUST support associated bidirectional point- 104 to-point Label Switched Paths (LSPs). These requirements are given 105 in Section 2.1 (General Requirements), and are repeated below: 107 7. MPLS-TP MUST support associated bidirectional point-to-point 108 LSPs. 110 11. The end points of an associated bidirectional LSP MUST be aware 111 of the pairing relationship of the forward and reverse LSPs used to 112 support the bidirectional service. 114 12. Nodes on the LSP of an associated bidirectional LSP where both 115 the forward and backward directions transit the same node in the same 116 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 117 the forward and the backward directions of the LSP. 119 50. The MPLS-TP control plane MUST support establishing associated 120 bidirectional P2P LSP including configuration of protection functions 121 and any associated maintenance functions. 123 The above requirements are also repeated in [RFC6373]. 125 Furthermore, an associated bidirectional LSP is also useful for 126 protection switching for Operations, Administrations and Maintenance 127 (OAM) messages that require a return path. 129 A variety of applications, such as Internet services and the return 130 paths of OAM messages, exist and which may have different upstream 131 and downstream bandwidth requirements. [RFC5654] specifies an 132 asymmetric bandwidth requirement in Section 2.1 (General 133 Requirements), and is repeated below: 135 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 136 bandwidth requirements, i.e., the amount of reserved bandwidth 137 differs between the forward and backward directions. 139 The approach for supporting asymmetric bandwidth co-routed 140 bidirectional LSPs is defined in [RFC6387]. 142 The method of association and the corresponding Resource reSerVation 143 Protocol (RSVP) ASSOCIATION Object are defined in [RFC4872], 145 [RFC4873] and [RFC6689]. In that context, the ASSOCIATION Object is 146 used to associate a recovery LSP with the LSP it is protecting. This 147 object also has broader applicability as a mechanism to associate 148 RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that 149 can be more generally applied for this purpose. This document refers 150 to the [RFC4872] defined ASSOCIATION Objects and the [RFC6780] 151 defined the Extended ASSOCIATION Objects collectively as the 152 (Extended) ASSOCIATION Objects. 154 This document specifies mechanisms for binding two reverse 155 unidirectional LSPs into an associated bidirectional LSP. The 156 association is achieved by defining new Association Types for use in 157 (Extended) ASSOCIATION Objects. One of these types enables 158 independent provisioning of the associated bidirectional LSPs, while 159 the other enables single sided provisioning. The REVERSE_LSP Object 160 is also defined to enable a single endpoint to specify all the 161 parameters of an associated LSP in the single sided provisioning 162 case. For example, the REVERSE_LSP Object allow asymmetric upstream 163 and downstream bandwidths for the associated bidirectional LSP. 165 2. Conventions Used in This Document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 2.1. Definitions 173 2.1.1. Reverse Unidirectional LSPs 175 Two reverse unidirectional LSPs are setup in the opposite directions 176 between a pair of source and destination nodes to form an associated 177 bidirectional LSP. A reverse unidirectional LSP originates on the 178 same node where the forward unidirectional LSP terminates, and it 179 terminates on the same node where the forward unidirectional LSP 180 originates. 182 2.1.2. Message Formats 184 This document uses the Routing Backus-Naur Form (RBNF) to define 185 message formats as defined in [RFC5511]. 187 3. Overview 189 3.1. Provisioning Model Overview 191 This section provides an overview and definition of the models for 192 provisioning associated bidirectional LSPs. 194 The associated bidirectional LSP's forward and reverse unidirectional 195 LSPs are established, monitored, and protected independently as 196 specified by [RFC5654]. Configuration information regarding the LSPs 197 can be provided at one or both endpoints of the associated 198 bidirectional LSP. Depending on the method chosen, there are two 199 models of creating an associated bidirectional LSP; single sided 200 provisioning, and double sided provisioning. 202 3.1.1. Single Sided Provisioning 204 For the single sided provisioning, the Traffic Engineering (TE) 205 tunnel is configured only on one endpoint. An LSP for this tunnel is 206 initiated by the initiating endpoint with the (Extended) ASSOCIATION 207 Object inserted in the Path message. The other endpoint then creates 208 the corresponding reverse TE tunnel and signals the reverse LSP in 209 response using information from the REVERSE_LSP Object if present. 211 3.1.2. Double Sided Provisioning 213 For the double sided provisioning, two unidirectional TE tunnels are 214 configured independently, one on each endpoint. The LSPs for the 215 tunnels are signaled with (Extended) ASSOCIATION Objects inserted in 216 the Path message by both endpoints to indicate that the two LSPs are 217 to be associated to form a bidirectional LSP. 219 3.2. Association Signaling Overview 221 This section provides an overview of the association signaling 222 methods for the associated bidirectional LSPs. 224 Three scenarios exist for binding two unidirectional LSPs together to 225 form an associated bidirectional LSP. These are: 1) Neither 226 unidirectional LSP exists, and both must be established. 2) Both 227 unidirectional LSPs exist, but the association must be established. 228 3) One LSP exists, but the reverse associated LSP must be 229 established. 231 In each of the situations described above, both provisioning models 232 are applicable. 234 Path Computation Element (PCE)-based approaches [RFC4655], may be 235 used for path computation of an associated bidirectional LSP. 236 However, these approaches are outside the scope of this document. 238 Consider the topology described in Figure 1 (an example of associated 239 bidirectional LSP). LSP1 from A to B, takes the path A,D,B and LSP2 240 from B to A takes the path B,D,C,A. These two LSPs, once established 241 and associated, form an associated bidirectional LSP between node A 242 and node B. 244 LSP1 --> 245 A-------D-------B 246 \ / <-- LSP2 247 \ / 248 \ / 249 C 251 Figure 1: An example of associated bidirectional LSP 253 3.2.1. Single Sided Provisioning 255 For the single sided provisioning model, creation of reverse LSP1 is 256 triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. 257 When creation of reverse LSP2 is triggered by LSP1, LSP1 is 258 provisioned first (or refreshed if LSP1 already exists) at node A. 259 LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted 260 in the Path message, in which the Association Type indicating single 261 sided provisioning is included. Upon receiving this Path message for 262 LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION 263 Object inserted in LSP2's Path message is the same as that received 264 in LSP1's Path message. 266 A similar procedure is used if LSP2 is provisioned first at node B 267 and the creation of reverse LSP1 is triggered by LSP2. In both 268 cases, the two unidirectional LSPs are bound together to form an 269 associated bidirectional LSP based on identical (Extended) 270 ASSOCIATION Objects in the two LSPs' Path messages. 272 3.2.2. Double Sided Provisioning 274 For the double sided provisioning model, both LSP1 and LSP2 are 275 signaled independently with (Extended) ASSOCIATION Object inserted in 276 the Path message, in which the Association Type indicating double 277 sided provisioning is included. In this case, the two unidirectional 278 LSPs are bound together to form an associated bidirectional LSP based 279 on identical (Extended) ASSOCIATION Objects in the two LSPs' Path 280 messages. The LSPs to be selected for the association are 281 provisioned by the management action applied at both endpoints. 283 3.3. Asymmetric Bandwidth Signaling Overview 285 This section provides an overview of the methods for signaling 286 asymmetric upstream and downstream bandwidths for the associated 287 bidirectional LSPs. 289 3.3.1. Single Sided Provisioning 291 A new REVERSE_LSP Object for use in the single sided provisioning 292 model is defined in this document, in Section 4.4. When the single 293 sided provisioning model is used, a SENDER_TSPEC object can be added 294 in the REVERSE_LSP Object as a subobject in the initiating LSP's Path 295 message to specify a different bandwidth for the reverse LSP. As 296 described in Section 4.4, addition of the REVERSE_LSP Object also 297 allows the initiating node to control other aspects of the reverse 298 LSP (such as its path) by including other existing objects in a 299 REVERSE_LSP Object. 301 Consider again the topology described in Figure 1, where the creation 302 of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the 303 (Extended) ASSOCIATION Object with Association Type indicating single 304 sided provisioning and inserts a SENDER_TSPEC subobject for use by 305 LSP2 in the REVERSE_LSP Object in the Path message. Node B then 306 establishes the LSP2 in the reverse direction using the asymmetric 307 bandwidth thus specified by LSP1 and allows node A to control the 308 reverse LSP2. 310 3.3.2. Double Sided Provisioning 312 When the double sided provisioning model is used, the two 313 unidirectional LSPs are established with separate bandwidths, which 314 may or may not be identical. However, these LSPs are associated 315 purely based on the identical contents of their (Extended) 316 ASSOCIATION Objects. 318 3.4. Recovery LSP Overview 320 Recovery of each unidirectional LSP forming the bidirectional LSP is 321 independent [RFC5654] and is based on the parameters signaled in 322 their respective RSVP Path messages. 324 Recovery LSP association is based on the identical content of the 325 (Extended) ASSOCIATION Objects signaled in their Path messages during 326 the initial LSP setup for both single sided and double sided 327 provisioning. As defined, see [RFC6780], multiple ASSOCIATION 328 objects may be present in the signaling of a single LSP. 330 4. Message and Object Definitions 332 4.1. RSVP Message Formats 334 This section presents the RSVP message-related formats as modified by 335 this document. Unmodified RSVP message formats are not listed. 337 The format of a Path message is as follows: 339 ::= [ ] 340 [ [ | ] ... ] 341 [ ] 342 343 344 [ ] 345 346 [ ] 347 [ ... ] 348 [ ] 349 [ ... ] 350 [ ] 351 [ ... ] 352 [ ... ] 353 [ ... ] 354 356 The format of the is not modified by this 357 document. 359 4.2. ASSOCIATION Object 361 The ASSOCIATION Object is populated using the rules defined below for 362 associating two reverse unidirectional LSPs to form an associated 363 bidirectional LSP. 365 Association Types: 367 In order to bind two reverse unidirectional LSPs to be an 368 associated bidirectional LSP, the Association Type MUST be set to 369 indicate either single sided or double sided LSPs. 371 The new Association Types are defined as follows: 373 Value Type 375 ----- ----- 376 3 Double Sided Associated Bidirectional LSP (D) 377 4 Single Sided Associated Bidirectional LSP (A) 379 Association ID: 381 For both single sided and double sided provisioning, Association 382 ID MUST be set to a value assigned by the node that originates the 383 association for the bidirectional LSP. 385 Association Source: 387 Association Source MUST be set to an address selected by the node 388 that originates the association for the bidirectional LSP. For 389 example, this may be a management entity, or in the case of single 390 sided provisioning, an address assigned to the node that 391 originates the LSP. 393 4.3. Extended ASSOCIATION Object 395 The Extended ASSOCIATION Object is populated using the rules defined 396 below for associating two reverse unidirectional LSPs to form a 397 bidirectional LSP. 399 The Association Type, Association ID and Association Source MUST be 400 set as defined for the ASSOCIATION Object in Section 4.1. 402 Global Association Source: 404 For both single sided and double sided provisioning, Global 405 Association Source, when used, MUST be set to the Global_ID 406 [RFC6370] of the node that originates the association for the 407 bidirectional LSP. 409 Extended Association ID: 411 For both single sided and double sided provisioning, Extended 412 Association ID, when used, MUST be set to a value selected by the 413 node that originates the association for the bidirectional LSP. 415 4.4. REVERSE_LSP Object Definition 417 4.4.1. REVERSE_LSP Object Format 419 The information of the reverse LSP is specified via the REVERSE_LSP 420 Object. This is an optional object carried in a Path message with 421 Class Number in the form 11bbbbbb and has the following format: 423 Class_Num = 203, C_Type = 1. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | | 429 // (Subobjects) // 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 4.4.2. REVERSE_LSP Subobjects 435 The contents of a REVERSE_LSP Object is a variable length series of 436 subobjects and have the same format as RSVP Objects, see Section 437 3.1.2 of [RFC2205]. The subobjects permitted in the REVERSE_LSP 438 Object are previously defined as Path message Objects, and have the 439 same order in the REVERSE_LSP Object. 441 Examples of the Path message objects carried in the REVERSE_LSP 442 Object are (but not limited to): 444 - SENDER_TSPEC [RFC2205] 445 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 446 - SESSION_ATTRIBUTE Object [RFC3209] 447 - ADMIN_STATUS Object [RFC3473] 448 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 449 - PROTECTION Object [RFC3473] [RFC4872] 451 5. Processing Rules 453 In general, the processing rules for the ASSOCIATION Object are as 454 specified in [RFC4872] and Extended ASSOCIATION Object are specified 455 in [RFC6780]. Following sections describe the rules for processing 456 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 457 bidirectional LSPs. 459 5.1. Rules For ASSOCIATION Object 461 This section defines the processing for the association of two 462 unidirectional LSPs to form an associated bidirectional LSP. Such 463 association is based on the use of an (Extended) ASSOCIATION Object. 465 The procedures related to the actual identification of associations 466 between LSPs based on (Extended) ASSOCIATION Objects are defined in 467 [RFC6780]. [RFC6780] specifies that in the absence of Association 468 Type-specific rule for identifying association, the included 469 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 470 for an association to exist. This document adds no specific rules 471 for the new Association Types defined, and the identification of LSP 472 association therefore proceeds as specified in [RFC6780]. 474 As described in [RFC6780], association of LSPs can be upstream or 475 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 476 in Path or Resv Messages. The association of bidirectional LSPs is 477 always upstream initialized, therefore the Association Types defined 478 in this document are only to be interpreted in Path Messages. These 479 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 480 messages and SHOULD be ignored if present. 482 To indicate an associated bidirectional LSP, an ingress node MUST 483 insert an (Extended) ASSOCIATION Object into the Path message of the 484 unidirectional LSP that is part of the associated bidirectional LSP 485 it initiates. If either Global Association Source or Extended 486 Association Address is required, then an Extended ASSOCIATION Object 487 [RFC6780] MUST be inserted in the Path message. Otherwise, an 488 ASSOCIATION Object MAY be used. Only one (Extended) ASSOCIATION 489 Object with the Association Types defined in this document SHOULD be 490 included by an ingress node in an outgoing Path message. (Extended) 491 ASSOCIATION Objects with both single sided and double sided 492 Association Types MUST NOT be added in the same Path message. 494 The ingress node MUST set the Association Type field in the 495 (Extended) ASSOCIATION Object to "Single Sided Associated 496 Bidirectional LSP" when single sided provisioning is used, and to 497 "Double Sided Associated Bidirectional LSP" when double sided 498 provisioning is used. 500 A transit node MAY identify the unidirectional LSPs of an associated 501 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 502 Association Type values defined in this document, carried in Path 503 messages. Clearly, such associations are only possible when the LSPs 504 transit the node. As mentioned above, such associations are made per 505 the rules defined in [RFC6780]. 507 Egress nodes which support the Association Types defined in this 508 document identify the unidirectional LSPs of an associated 509 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 510 Path messages. Note that an ingress node will normally be the 511 ingress for one of the unidirectional LSPs that make up an associated 512 bidirectional LSP. When an egress node receives a Path message 513 containing an (Extended) ASSOCIATION Object with one of the 514 Association Types defined in this document, it MUST attempt to 515 identify other LSPs (including ones for which it is an ingress node) 516 with which the LSP being processed is associated. As defined above, 517 such associations are made per the rules defined in [RFC6780]. If 518 the egress node does not support the Association Types defined in 519 this document, it MUST return a PathErr with Error Code "Admission 520 Control Failure (01) [RFC2205]" and Sub-code "Bad Association Type 521 (5) [RFC4872]". An LSP not being associated at the time of signaling 522 (for example, during rerouting or re-optimization) on an egress node 523 is not necessarily considered an error condition. 525 Associated bidirectional LSP teardown follows the standard procedures 526 defined in [RFC3209] and [RFC3473] either without or with the 527 administrative status. Generally, the teardown procedures of the 528 unidirectional LSPs forming an associated bidirectional LSP are 529 independent of each other, so it is possible that while one LSP 530 follows graceful teardown with administrative status, the reverse LSP 531 is torn down without administrative status (using 532 PathTear/ResvTear/PathErr with state removal). See Section 5.3 below 533 for additional rules related to LSPs established using single sided 534 provisioning. 536 When an LSP signaled with a Path message containing an (Extended) 537 ASSOCIATION Object with an Association Type defined in this document 538 is torn down, the processing node SHALL remove the binding of the LSP 539 to any previously identified associated bidirectional LSP. 541 No additional processing is needed for Path messages with an 542 (Extended) ASSOCIATION Object containing an Association Type field of 543 Double Sided Associated Bidirectional LSP. 545 5.1.1. Compatibility For ASSOCIATION Object 547 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 548 ASSOCIATION Object has been defined in [RFC6780], both with class 549 numbers in the form 11bbbbbb, which ensures compatibility with 550 non-supporting nodes. Per [RFC2205], such nodes will ignore the 551 object but forward it without modification. 553 Operators wishing to use a function supported by a particular 554 association type SHOULD ensure that the type is supported on any node 555 that is expected to act on the association [RFC6780]. 557 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 558 this document. The recovery mechanisms defined in [RFC4872] and 559 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 560 use a different value for Association Type; multiple ASSOCIATION 561 Objects can be present in the LSP Path message and can coexist with 562 the procedures defined in this document. 564 5.2. Rules For REVERSE_LSP Object 566 A node initiating a Path message containing an ASSOCIATION or 567 Extended ASSOCIATION Object with the Association Type set to "Single 568 Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object 569 in the Path message of the LSP when it wishes to control the reverse 570 LSP originating on the other endpoint node. 572 The REVERSE_LSP subobject MAY contain any of the specified objects 573 which the initiating node desires to have included in the Path 574 message for the associated reverse LSP. A REVERSE_LSP Object MUST 575 contain at least one subobject. If there is no subobject to be added 576 in the REVERSE_LSP Object, then the REVERSE_LSP Object MUST NOT be 577 added in the Path message. The REVERSE_LSP Object MUST NOT be 578 included in a REVERSE_LSP Object. 580 A node receiving a valid Path message containing a REVERSE_LSP Object 581 that is not the egress node for the LSP being signaled MUST forward 582 the REVERSE_LSP Object unchanged in the outgoing Path message. 584 An egress node, upon receiving a Path message containing an 585 REVERSE_LSP Object MUST verify that the Path message contains an 586 ASSOCIATION or Extended ASSOCIATION object with the Association Type 587 set to "Single Sided Associated Bidirectional LSP". If it does not, 588 the Path message MUST NOT trigger a reverse LSP. This verification 589 failure SHOULD NOT trigger any RSVP message but can be logged 590 locally, and perhaps reported through network management mechanisms. 592 Once validated, the egress node MUST use the subobjects contained in 593 any present REVERSE_LSP Objects in the management of the reverse LSP 594 described in the previous section. Note that the contents of a 595 REVERSE_LSP Object may change over the life of an LSP and such 596 changes MUST result in corresponding changes in the reverse LSP. An 597 addition or removal of the REVERSE_LSP Object in the received Path 598 message may cause an egress node to teardown and reestablish a new 599 reverse LSP, or trigger re-optimization or in-place modification of 600 the LSP (which may depend on the local policy). 602 5.2.1. Compatibility For REVERSE_LSP Object 604 The REVERSE_LSP Object is defined with class numbers in the form 605 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 606 [RFC2205], such nodes will ignore the object but forward it without 607 modification. 609 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown 611 An egress node, upon receiving a Path message containing an 612 ASSOCIATION or Extended ASSOCIATION Object with Association Type set 613 to "Single Sided Associated Bidirectional LSP" MUST create an LSP in 614 the reverse direction or reject the Path message. If the creation of 615 a reverse LSP fails, the egress node MUST return a PathErr with Error 616 code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse 617 LSP Failure" defined in this document. 619 If REVERSE_LSP Object is not present in the received Path message of 620 the LSP, the egress node SHOULD use the LSP properties from the 621 received LSP Path message to signal the LSP in the reverse direction 622 (which may depend on the local policy). The teardown of the 623 initiating LSP SHOULD trigger the teardown of the reverse associated 624 LSP, however, teardown of the reverse LSP SHOULD NOT trigger the 625 teardown of the initiating LSP (which may depend on the local 626 policy). 628 If REVERSE_LSP Object is present in the received Path message of the 629 LSP, the egress node follows the procedure defined in Section 5.2 to 630 setup the reverse LSP. If initiating node controlling the reverse 631 LSP, wishes to teardown the associated bidirectional LSP, the 632 initiating node sends a PathTear message to the egress node, the 633 egress node MUST trigger to teardown the reverse associated LSP, 634 however, teardown of the reverse LSP SHOULD NOT trigger the teardown 635 of the initiating LSP (which may depend on the local policy). 637 6. IANA Considerations 639 IANA is requested to administer assignment of new values for 640 namespace defined in this document and summarized in this section. 642 6.1. Association Types 644 IANA maintains the "Generalized Multi-Protocol Label Switching 645 (GMPLS) Signaling Parameters" registry (see 646 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 647 Type" subregistry is included in this registry. 649 This registry will be updated by new Association Types for 650 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 651 as follows: 653 Value Name Reference 654 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 655 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 657 Specified Association Type values are temporary early allocations as 658 per RFC7120. 660 6.2. REVERSE_LSP Object 662 IANA maintains the "RSVP Parameters" registry (see 663 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 664 Class Names, Class Numbers, and Class Types subregistry is included 665 in this registry. 667 This registry will be extended for new Class Number (Class-Num) and 668 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 669 11bbbbbb range defined in this document as follows: 671 Class Number Class Name Reference 672 203 REVERSE_LSP Section 4.4 674 o REVERSE_LSP : Class Type or C-type = 1 676 Specified REVERSE_LSP Class Number and Class Type values are 677 temporary early allocations as per RFC7120. 679 6.3. Reverse LSP Failure PathErr Sub-code 681 IANA maintains the "RSVP Parameters" registry (see 682 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 683 Error Codes and Globally-Defined Error Value Sub-Codes subregistry is 684 included in this registry. 686 This registry will be extended for the new PathErr Sub-code defined 687 in this document as follows: 689 Error Code = 01: "Admission Control Failure" (see [RFC2205]) 691 o "Admission Control Failure/Reverse LSP Failure" (TBA) 693 There are no other IANA considerations introduced by this document. 695 7. Security Considerations 697 This document introduces two new Association Types, however, no new 698 security issues relating to the (Extended) ASSOCIATION Object are 699 introduced. 701 The procedures defined in this document result in an increased state 702 information carried in signaling messages. The presence of the 703 REVERSE_LSP Object necessarily provides more information about the 704 LSPs. Thus, in the event of the interception of a signaling message, 705 slightly more information about the state of the network could be 706 deduced than was previously the case. This is judged to be a very 707 minor security risk as this information is already available via 708 routing. 710 Otherwise, this document introduces no additional security 711 considerations. For a general discussion on MPLS and GMPLS related 712 security issues, see the MPLS/GMPLS security framework [RFC5920]. 714 8. Acknowledgement 716 The authors would like to thank Lou Berger and George Swallow for 717 their great guidance in this work, Jie Dong for the discussion of 718 recovery, Lamberto Sterling for his valuable comments on the section 719 of asymmetric bandwidths, Attila Takacs for the discussion of the 720 provisioning model and Lou Berger, Daniel King and Deborah Brungard 721 for the review of the document. At the same time, the authors would 722 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 723 Lizhong Jin for the initial discussions, and Wenjuan He for the 724 prototype implementation. The authors would also like to thank Siva 725 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 726 ASSOCIATION Object. The authors would like to thank Matt Hartley for 727 providing useful suggestions on the document and Lou Berger for 728 careful editorial reviews. 730 9. Contributing Authors 732 Fan Yang 733 ZTE 735 Email: yang.fan240347@gmail.com 737 Weilian Jiang 738 ZTE 740 Email: jiang.weilian@gmail.com 742 10. References 744 10.1. Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 750 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 751 Functional Specification", RFC 2205, September 1997. 753 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 754 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 755 Tunnels", RFC 3209, December 2001. 757 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 758 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 759 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 761 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 762 Extensions in Support of End-to-End Generalized Multi- 763 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 764 2007. 766 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 767 "GMPLS Segment Recovery", RFC 4873, May 2007. 769 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 770 Association Object Extensions", RFC 6780, October 2012. 772 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax 773 Used to Form Encoding Rules in Various Routing Protocol 774 Specifications", RFC 5511, April 2009. 776 10.2. Informative References 778 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 779 Element (PCE)-Based Architecture", RFC 4655, August 2006. 781 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 782 Ayyangarps, "Encoding of Attributes for MPLS LSP 783 Establishment Using Resource Reservation Protocol Traffic 784 Engineering (RSVP-TE)", RFC 5420, February 2009. 786 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 787 and S. Ueno, "Requirements of an MPLS Transport Profile", 788 RFC 5654, September 2009. 790 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 791 Networks", RFC 5920, July 2010. 793 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 794 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 796 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 797 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 798 Framework", RFC 6373, September 2011. 800 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 801 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 802 Switched Paths (LSPs)", RFC 6387, September 2011. 804 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 805 6689, July 2012. 807 Authors' Addresses 809 Fei Zhang (editor) 810 Huawei 812 Email: zhangfei7@huawei.com 814 Ruiquan Jing 815 China Telecom 817 Email: jingrq@ctbri.com.cn 819 Rakesh Gandhi (editor) 820 Cisco Systems 822 Email: rgandhi@cisco.com