idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 3, 2015) is 3343 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: September 4, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 March 3, 2015 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 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 trigger creation of the reverse LSP and to specify parameters of the 24 reverse LSP in the single sided 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. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 61 2.2. Reverse Unidirectional LSPs . . . . . . . . . . . . . . . 4 62 2.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 4 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 4 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 . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7 75 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . 14 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 88 6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 15 89 6.3. Reverse LSP Failure PathErr Sub-code . . . . . . . . . . . 16 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 92 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 101 specifies that MPLS-TP MUST support associated bidirectional point- 102 to-point Label Switched Paths (LSPs). These requirements are given 103 in Section 2.1 (General Requirements), and are repeated below: 105 7. MPLS-TP MUST support associated bidirectional point-to-point 106 LSPs. 108 11. The end points of an associated bidirectional LSP MUST be aware 109 of the pairing relationship of the forward and reverse LSPs used to 110 support the bidirectional service. 112 12. Nodes on the LSP of an associated bidirectional LSP where both 113 the forward and backward directions transit the same node in the same 114 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 115 the forward and the backward directions of the LSP. 117 50. The MPLS-TP control plane MUST support establishing associated 118 bidirectional P2P LSP including configuration of protection functions 119 and any associated maintenance functions. 121 The above requirements are also repeated in [RFC6373]. 123 Furthermore, an associated bidirectional LSP is also useful for 124 protection switching for Operations, Administrations and Maintenance 125 (OAM) messages that require a return path. 127 A variety of applications, such as Internet services and the return 128 paths of OAM messages, exist and which may have different upstream 129 and downstream bandwidth requirements. [RFC5654] specifies an 130 asymmetric bandwidth requirement in Section 2.1 (General 131 Requirements), and is repeated below: 133 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 134 bandwidth requirements, i.e., the amount of reserved bandwidth 135 differs between the forward and backward directions. 137 The approach for supporting asymmetric bandwidth co-routed 138 bidirectional LSPs is defined in [RFC6387]. 140 The method of association and the corresponding Resource reSerVation 141 Protocol (RSVP) ASSOCIATION Object are defined in [RFC4872], 142 [RFC4873] and [RFC6689]. In that context, the ASSOCIATION Object is 143 used to associate a recovery LSP with the LSP it is protecting. This 144 object also has broader applicability as a mechanism to associate 145 RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that 146 can be more generally applied for this purpose. This document refers 147 to the [RFC4872] defined ASSOCIATION Objects and the [RFC6780] 148 defined the Extended ASSOCIATION Objects collectively as the 149 (Extended) ASSOCIATION Objects. 151 This document specifies mechanisms for binding two reverse 152 unidirectional LSPs into an associated bidirectional LSP. The 153 association is achieved by defining new Association Types for use in 154 (Extended) ASSOCIATION Objects. One of these types enables 155 independent provisioning of the associated bidirectional LSPs, while 156 the other enables single sided provisioning. The REVERSE_LSP Object 157 is also defined to enable a single endpoint to trigger creation of 158 the reverse LSP and to specify parameters of the reverse LSP in the 159 single sided provisioning case. For example, the REVERSE_LSP Object 160 allow asymmetric upstream and downstream bandwidths for the 161 associated bidirectional LSP. 163 2. Conventions Used in This Document 165 2.1. Key Word Definitions 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.2. Reverse Unidirectional LSPs 173 Two reverse unidirectional LSPs are setup in the opposite directions 174 between a pair of source and destination nodes to form an associated 175 bidirectional LSP. A reverse unidirectional LSP originates on the 176 same node where the forward unidirectional LSP terminates, and it 177 terminates on the same node where the forward unidirectional LSP 178 originates. 180 2.3. Message Formats 182 This document uses the Routing Backus-Naur Form (RBNF) to define 183 message formats as defined in [RFC5511]. 185 3. Overview 187 3.1. Provisioning Model Overview 189 This section provides an overview and definition of the models for 190 provisioning associated bidirectional LSPs. 192 The associated bidirectional LSP's forward and reverse unidirectional 193 LSPs are established, monitored, and protected independently as 194 specified by [RFC5654]. Configuration information regarding the LSPs 195 can be provided at one or both endpoints of the associated 196 bidirectional LSP. Depending on the method chosen, there are two 197 models of creating an associated bidirectional LSP; single sided 198 provisioning, and double sided provisioning. 200 3.1.1. Single Sided Provisioning 202 For the single sided provisioning, the Traffic Engineering (TE) 203 tunnel is configured only on one endpoint. An LSP for this tunnel is 204 initiated by the initiating endpoint with the (Extended) ASSOCIATION 205 and REVERSE_LSP Objects inserted in the Path message. The other 206 endpoint then creates the corresponding reverse TE tunnel and signals 207 the reverse LSP in response using information from the REVERSE_LSP 208 Object and other Objects present in the received Path message. 210 3.1.2. Double Sided Provisioning 212 For the double sided provisioning, two unidirectional TE tunnels are 213 configured independently, one on each endpoint. The LSPs for the 214 tunnels are signaled with (Extended) ASSOCIATION Objects inserted in 215 the Path message by both endpoints to indicate that the two LSPs are 216 to be associated to form a bidirectional LSP. 218 3.2. Association Signaling Overview 220 This section provides an overview of the association signaling 221 methods for the associated bidirectional LSPs. 223 Three scenarios exist for binding two unidirectional LSPs together to 224 form an associated bidirectional LSP. These are: 1) Neither 225 unidirectional LSP exists, and both must be established. 2) Both 226 unidirectional LSPs exist, but the association must be established. 227 3) One LSP exists, but the reverse associated LSP must be 228 established. Following sections describe the applicable provisioning 229 models for each of these scenarios. 231 Path Computation Element (PCE)-based approaches [RFC4655], may be 232 used for path computation of an associated bidirectional LSP. 233 However, these approaches are outside the scope of this document. 235 Consider the topology described in Figure 1 (an example of associated 236 bidirectional LSP). LSP1 from node A to B, takes the path A,D,B and 237 LSP2 from node B to A takes the path B,D,C,A. These two LSPs, once 238 established and associated, form an associated bidirectional LSP 239 between node A and node B. 241 LSP1 --> 242 A-------D-------B 243 \ / <-- LSP2 244 \ / 245 \ / 246 C 248 Figure 1: An example of associated bidirectional LSP 250 3.2.1. Single Sided Provisioning 252 For the single sided provisioning model, creation of reverse LSP1 253 shown in Figure 1 is triggered by LSP2 or creation of reverse LSP2 is 254 triggered by LSP1. When creation of reverse LSP2 is triggered by 255 LSP1, LSP1 is provisioned first (or refreshed if LSP1 already exists) 256 at node A. LSP1 is then signaled with an (Extended) ASSOCIATION and 257 REVERSE_LSP Objects inserted in the Path message. The Association 258 Type indicates single sided provisioning. Upon receiving this Path 259 message for LSP1, node B establishes reverse LSP2. The (Extended) 260 ASSOCIATION Object inserted in LSP2's Path message is the same as 261 that received in LSP1's Path message. 263 A similar procedure is used if LSP2 is provisioned first at node B 264 and the creation of reverse LSP1 at node A is triggered by LSP2. In 265 both scenarios, the two unidirectional LSPs are bound together to 266 form an associated bidirectional LSP based on identical (Extended) 267 ASSOCIATION Objects in the two LSPs' Path messages. 269 3.2.2. Double Sided Provisioning 271 For the double sided provisioning model, both LSP1 and LSP2 shown in 272 Figure 1 are signaled independently with (Extended) ASSOCIATION 273 Objects inserted in the Path messages, in which the Association Type 274 indicating double sided provisioning is included. In this case, the 275 two unidirectional LSPs are bound together to form an associated 276 bidirectional LSP based on identical (Extended) ASSOCIATION Objects 277 in the two LSPs' Path messages. The LSPs to be selected for the 278 association are provisioned by the management action applied at both 279 endpoints in all three scenarios described above. 281 3.3. Asymmetric Bandwidth Signaling Overview 283 This section provides an overview of the methods for signaling 284 asymmetric upstream and downstream bandwidths for the associated 285 bidirectional LSPs. 287 3.3.1. Single Sided Provisioning 289 A new REVERSE_LSP Object for use in the single sided provisioning 290 model is defined in this document, in Section 4.4. The REVERSE_LSP 291 Object allows the initiating node of the single sided provisioned LSP 292 to trigger creation of the reverse LSP on the remote node. When the 293 single sided provisioning model is used, a SENDER_TSPEC Object can be 294 added in the REVERSE_LSP Object as a subobject in the initiating 295 LSP's Path message to specify a different bandwidth for the reverse 296 LSP. As described in Section 4.4, addition of the REVERSE_LSP Object 297 also allows the initiating node to control other aspects of the 298 reverse LSP (such as its path) by including other 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 REVERSE_LSP Object is carried in the Path message of a forward 420 LSP to provide information to be used by the reverse LSP. The object 421 also indicates that the LSP is the forward LSP of a single sided 422 provisioned associated bidirectional LSP. 424 The Object has the following format: 426 Class_Num = 203, C_Type = 1. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 // (Subobjects) // 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 4.4.2. REVERSE_LSP Subobjects 438 Subobjects are used to override the default contents of Path message 439 of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP 440 Object is zero or more variable length subobjects that have the same 441 format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object 442 that may be carried in a Path message MAY be carried in the 443 REVERSE_LSP Object. Subobject ordering MUST follow any Path message 444 Object ordering requirements. 446 Examples of the Path message Objects that can be carried in the 447 REVERSE_LSP Object are (but not limited to): 449 - SENDER_TSPEC [RFC2205] 450 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 451 - SESSION_ATTRIBUTE Object [RFC3209] 452 - ADMIN_STATUS Object [RFC3473] 453 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 454 - PROTECTION Object [RFC3473] [RFC4872] 456 5. Processing Rules 458 In general, the processing rules for the ASSOCIATION Object are as 459 specified in [RFC4872] and Extended ASSOCIATION Object are specified 460 in [RFC6780]. Following sections describe the rules for processing 461 (Extended) ASSOCIATION Object for both double sided and single sided 462 associated bidirectional LSPs and REVERSE_LSP Object for single sided 463 associated bidirectional LSPs. 465 5.1. Rules For ASSOCIATION Object 467 This section defines the processing for the association of two 468 unidirectional LSPs to form an associated bidirectional LSP. Such 469 association is based on the use of an (Extended) ASSOCIATION Object. 471 The procedures related to the actual identification of associations 472 between LSPs based on (Extended) ASSOCIATION Objects are defined in 473 [RFC6780]. [RFC6780] specifies that in the absence of Association 474 Type-specific rule for identifying association, the included 475 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 476 for an association to exist. This document adds no specific rules 477 for the new Association Types defined, and the identification of LSP 478 association therefore proceeds as specified in [RFC6780]. 480 As described in [RFC6780], association of LSPs can be upstream or 481 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 482 in Path or Resv Messages. The association of bidirectional LSPs is 483 always upstream initialized, therefore the Association Types defined 484 in this document are only to be interpreted in Path Messages. These 485 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 486 messages and SHOULD be ignored if present. 488 To indicate an associated bidirectional LSP, an ingress node MUST 489 insert an (Extended) ASSOCIATION Object into the Path message of the 490 unidirectional LSP that is part of the associated bidirectional LSP 491 it initiates. If either Global Association Source or Extended 492 Association Address is required, then an Extended ASSOCIATION Object 493 [RFC6780] MUST be inserted in the Path message. Otherwise, an 494 ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with 495 both single sided and double sided Association Types MUST NOT be 496 added or sent in the same Path message. 498 The ingress node MUST set the Association Type field in the 499 (Extended) ASSOCIATION Object to "Single Sided Associated 500 Bidirectional LSP" when single sided provisioning is used, and to 501 "Double Sided Associated Bidirectional LSP" when double sided 502 provisioning is used. 504 A transit node MAY identify the unidirectional LSPs of an associated 505 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 506 Association Type values defined in this document, carried in Path 507 messages. Clearly, such associations are only possible when the LSPs 508 transit the node. As mentioned above, such associations are made per 509 the rules defined in [RFC6780]. 511 Egress nodes which support the Association Types defined in this 512 document identify the unidirectional LSPs of an associated 513 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 514 Path messages. Note that an ingress node will normally be the 515 ingress for one of the unidirectional LSPs that make up an associated 516 bidirectional LSP. When an egress node receives a Path message 517 containing an (Extended) ASSOCIATION Object with one of the 518 Association Types defined in this document, it MUST attempt to 519 identify other LSPs (including ones for which it is an ingress node) 520 with which the LSP being processed is associated. As defined above, 521 such associations are made per the rules defined in [RFC6780]. An 522 LSP not being associated at the time of signaling (for example, 523 during rerouting or re-optimization) on an egress node is not 524 necessarily considered an error condition. 526 Associated bidirectional LSP teardown follows the standard procedures 527 defined in [RFC3209] and [RFC3473] either without or with the 528 administrative status. Generally, the teardown procedures of the 529 unidirectional LSPs forming an associated bidirectional LSP are 530 independent of each other, so it is possible that while one LSP 531 follows graceful teardown with administrative status, the reverse LSP 532 is torn down without administrative status (using 533 PathTear/ResvTear/PathErr with state removal). See Section 5.2 below 534 for additional rules related to LSPs established using single sided 535 provisioning. 537 When an LSP signaled with a Path message containing an (Extended) 538 ASSOCIATION Object with an Association Type defined in this document 539 is torn down, the processing node SHALL remove the binding of the LSP 540 to any previously identified associated bidirectional LSP. 542 No additional processing is needed for Path messages with an 543 (Extended) ASSOCIATION Object containing an Association Type field of 544 Double Sided Associated Bidirectional LSP. 546 5.1.1. Compatibility For ASSOCIATION Object 548 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 549 ASSOCIATION Object has been defined in [RFC6780], both with class 550 numbers in the form 11bbbbbb, which ensures compatibility with 551 non-supporting nodes. Per [RFC2205], such nodes will ignore the 552 object but forward it without modification. 554 Operators wishing to use a function supported by a particular 555 association type SHOULD ensure that the type is supported on any node 556 that is expected to act on the association [RFC6780]. 558 An egress node that does not support the Association Types defined in 559 this document, is expected to return a PathErr with Error Code 560 "Admission Control Failure (01) [RFC2205]" and Sub-code "Bad 561 Association Type (5) [RFC4872]". 563 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 564 this document. The recovery mechanisms defined in [RFC4872] and 565 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 566 use a different value for Association Type; multiple ASSOCIATION 567 Objects can be present in the LSP Path message and can coexist with 568 the procedures defined in this document. 570 5.2. Rules For REVERSE_LSP Object 572 When a node initiates setup of an LSP using a PATH message containing 573 an ASSOCIATION or Extended ASSOCIATION Object, and the Association 574 Type set to "Single Sided Associated Bidirectional LSP", the PATH 575 message MUST carry the REVERSE_LSP Object to trigger creation of a 576 reverse LSP on the egress node. 578 The REVERSE_LSP subobject MAY contain any of object that the 579 initiating node desires to have included in the Path message for the 580 associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be 581 included in a REVERSE_LSP Object. 583 A transit node receiving a valid Path message containing a 584 REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in 585 the outgoing Path message. 587 An egress node, upon receiving a Path message containing an 588 REVERSE_LSP Object MUST verify that the Path message contains an 589 ASSOCIATION or Extended ASSOCIATION Object with the Association Type 590 set to "Single Sided Associated Bidirectional LSP". If it does not, 591 the Path message MUST NOT trigger a reverse LSP. This verification 592 failure SHOULD NOT trigger any RSVP message but can be logged 593 locally, and perhaps reported through network management mechanisms. 595 Once validated, the egress node MUST create an LSP in the reverse 596 direction or reject the Path message. If the creation of a reverse 597 LSP fails, the egress node MUST return a PathErr with Error code 598 "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP 599 Failure" defined in this document. Note that normal Resv processing 600 SHOULD NOT be impacted by the presence of an ASSOCIATION Object with 601 an Association Type set to "Single Sided Associated Bidirectional 602 LSP". 604 The egress node MUST use the subobjects contained in the REVERSE_LSP 605 Object for initiating the reverse LSP. When a subobject is not 606 present in the received REVERSE_LSP Object, the egress node SHOULD 607 initiate the reverse LSP based on the information contained in the 608 received Path message of the forward LSP as follows: 610 o The egress node SHOULD copy the information from the received 611 SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, 612 ADMIN_STATUS and PROTECTION Objects in the forward LSP Path message 613 to form the Path message of the reverse LSP when the object is not 614 present in the received REVERSE_LSP Object. 616 o The IP address in the reverse LSP's SESSION Object SHOULD be set 617 to the IP address carried in the received SENDER_TEMPLATE Object, and 618 conversely the IP address in the SENDER_TEMPLATE Object SHOULD be set 619 to the IP address carried in the received SESSION Object. There are 620 no additional requirements related to the IDs carried in the SESSION 621 and SENDER_TEMPLATE Objects. 623 o When the forward LSP Path message contains a RECORD_ROUTE Object, 624 the egress node SHOULD include the received RECORD_ROUTE Object in 625 the reverse LSP Path message. Local node information SHOULD also be 626 recorded per Standard Path message processing. 628 o There are no specific requirements related to other objects. 630 The resulting Path message is used to create the reverse LSP. From 631 this point on, Standard Path message processing is used in processing 632 the resulting Path message. 634 Note that the contents of a forward LSP, including a carried 635 REVERSE_LSP Object, may change over the life of an LSP and such 636 changes MUST result in corresponding changes in the reverse LSP. In 637 particular, any object or subobject that was copied during the 638 creation of the initial reverse LSP's Path message MUST be copied 639 when modified in the forward LSP, and a trigger Path message MUST be 640 processed. 642 The removal of the REVERSE_LSP Object in the received Path message 643 SHOULD cause the egress node to teardown any previously established 644 reverse LSP. 646 When the egress node receives a PathTear message for the forward LSP 647 or whenever the forward LSP is torn down, the node MUST remove the 648 associated reverse LSP using Standard PathTear message processing. 649 Tear down of the reverse LSP for other reasons SHOULD NOT trigger 650 removal of the initiating LSP, but SHOULD result in the egress node 651 sending a PathErr with Error code "Admission Control Failure (01) 652 [RFC2205]" and Sub-code "Reverse LSP Failure" defined in this 653 document. 655 5.2.1. Compatibility For REVERSE_LSP Object 657 The REVERSE_LSP Object is defined with class numbers in the form 658 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 659 [RFC2205], such nodes will ignore the object but forward it without 660 modification. 662 6. IANA Considerations 664 IANA is requested to administer assignment of new values for 665 namespace defined in this document and summarized in this section. 667 6.1. Association Types 669 IANA maintains the "Generalized Multi-Protocol Label Switching 670 (GMPLS) Signaling Parameters" registry (see 671 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 672 Type" subregistry is included in this registry. 674 This registry will be updated by new Association Types for 675 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 676 as follows: 678 Value Name Reference 679 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 680 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 682 Specified Association Type values are temporary early allocations as 683 per RFC7120. 685 6.2. REVERSE_LSP Object 687 IANA maintains the "RSVP Parameters" registry (see 688 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 689 Class Names, Class Numbers, and Class Types subregistry is included 690 in this registry. 692 This registry will be extended for new Class Number (Class-Num) and 693 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 694 11bbbbbb range defined in this document as follows: 696 Class Number Class Name Reference 697 203 REVERSE_LSP Section 4.4 699 o REVERSE_LSP : Class Type or C-type = 1 701 Specified REVERSE_LSP Class Number and Class Type values are 702 temporary early allocations as per RFC7120. 704 6.3. Reverse LSP Failure PathErr Sub-code 706 IANA maintains the "RSVP Parameters" registry (see 707 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 708 Error Codes and Globally-Defined Error Value Sub-Codes subregistry is 709 included in this registry. 711 This registry will be extended for the new PathErr Sub-code defined 712 in this document as follows: 714 Error Code = 01: "Admission Control Failure" (see [RFC2205]) 716 o "Admission Control Failure/Reverse LSP Failure" (TBA) 718 There are no other IANA considerations introduced by this document. 720 7. Security Considerations 722 This document introduces two new Association Types for the (Extended) 723 ASSOCIATION Object, double sided associated bidirectional LSP and 724 single sided associated bidirectional LSP. The introduction of these 725 types, by themselves, introduce no additional information to 726 signaling. Related security considerations are already covered for 727 this in RFC6780. 729 The REVERSE_LSP Object is carried in the Path message of a forward 730 LSP of the single sided associated bidirectional LSP. It can carry 731 parameters for the reverse LSP. This does allow for additional 732 information to be conveyed, but this information is not fundamentally 733 different from the information that is already carried in a 734 bidirectional LSP message. The processing of such messages are 735 already subject to local policy, as well as security considerations 736 discussions. For a general discussion on MPLS and GMPLS related 737 security issues, see the MPLS/GMPLS security framework [RFC5920]. 739 8. Acknowledgement 741 The authors would like to thank Lou Berger and George Swallow for 742 their great guidance in this work, Jie Dong for the discussion of 743 recovery, Lamberto Sterling for his valuable comments on the section 744 of asymmetric bandwidths, Attila Takacs for the discussion of the 745 provisioning model and Lou Berger, Daniel King and Deborah Brungard 746 for the review of the document. At the same time, the authors would 747 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 748 Lizhong Jin for the initial discussions, and Wenjuan He for the 749 prototype implementation. The authors would also like to thank Siva 750 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 751 ASSOCIATION Object. The authors would like to thank Matt Hartley for 752 providing useful suggestions on the document and Lou Berger for 753 careful editorial reviews. 755 9. Contributing Authors 757 Fan Yang 758 ZTE 760 Email: yang.fan240347@gmail.com 762 Weilian Jiang 763 ZTE 765 Email: jiang.weilian@gmail.com 767 10. References 769 10.1. Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 775 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 776 Functional Specification", RFC 2205, September 1997. 778 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 779 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 780 Tunnels", RFC 3209, December 2001. 782 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 783 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 784 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 786 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 787 Extensions in Support of End-to-End Generalized Multi- 788 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 789 2007. 791 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 792 "GMPLS Segment Recovery", RFC 4873, May 2007. 794 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 795 Association Object Extensions", RFC 6780, October 2012. 797 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax 798 Used to Form Encoding Rules in Various Routing Protocol 799 Specifications", RFC 5511, April 2009. 801 10.2. Informative References 803 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 804 Element (PCE)-Based Architecture", RFC 4655, August 2006. 806 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 807 Ayyangarps, "Encoding of Attributes for MPLS LSP 808 Establishment Using Resource Reservation Protocol Traffic 809 Engineering (RSVP-TE)", RFC 5420, February 2009. 811 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 812 and S. Ueno, "Requirements of an MPLS Transport Profile", 813 RFC 5654, September 2009. 815 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 816 Networks", RFC 5920, July 2010. 818 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 819 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 821 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 822 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 823 Framework", RFC 6373, September 2011. 825 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 826 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 827 Switched Paths (LSPs)", RFC 6387, September 2011. 829 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 830 6689, July 2012. 832 Authors' Addresses 834 Fei Zhang (editor) 835 Huawei 837 Email: zhangfei7@huawei.com 839 Ruiquan Jing 840 China Telecom 842 Email: jingrq@ctbri.com.cn 844 Rakesh Gandhi (editor) 845 Cisco Systems 847 Email: rgandhi@cisco.com