idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02.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 13, 2015) is 3360 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 17, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 February 13, 2015 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 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 . . . . . . . . . . . . . . . . . . . . . 15 89 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 90 6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 15 91 6.3. Reverse LSP Failure PathErr Sub-code . . . . . . . . . . . 16 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 94 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 10.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 104 specifies that MPLS-TP MUST support associated bidirectional point- 105 to-point Label Switched Paths (LSPs). These requirements are given 106 in Section 2.1 (General Requirements), and are repeated below: 108 7. MPLS-TP MUST support associated bidirectional point-to-point 109 LSPs. 111 11. The end points of an associated bidirectional LSP MUST be aware 112 of the pairing relationship of the forward and reverse LSPs used to 113 support the bidirectional service. 115 12. Nodes on the LSP of an associated bidirectional LSP where both 116 the forward and backward directions transit the same node in the same 117 (sub)layer as the LSP SHOULD be aware of the pairing relationship of 118 the forward and the backward directions of the LSP. 120 50. The MPLS-TP control plane MUST support establishing associated 121 bidirectional P2P LSP including configuration of protection functions 122 and any associated maintenance functions. 124 The above requirements are also repeated in [RFC6373]. 126 Furthermore, an associated bidirectional LSP is also useful for 127 protection switching for Operations, Administrations and Maintenance 128 (OAM) messages that require a return path. 130 A variety of applications, such as Internet services and the return 131 paths of OAM messages, exist and which may have different upstream 132 and downstream bandwidth requirements. [RFC5654] specifies an 133 asymmetric bandwidth requirement in Section 2.1 (General 134 Requirements), and is repeated below: 136 14. MPLS-TP MUST support bidirectional LSPs with asymmetric 137 bandwidth requirements, i.e., the amount of reserved bandwidth 138 differs between the forward and backward directions. 140 The approach for supporting asymmetric bandwidth co-routed 141 bidirectional LSPs is defined in [RFC6387]. 143 The method of association and the corresponding Resource reSerVation 144 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 at node A is either triggered by 268 LSP2 or the reverse LSP1 existed. In all three scenarios, the two 269 unidirectional LSPs are bound together to form an associated 270 bidirectional LSP based on identical (Extended) ASSOCIATION Objects 271 in the two LSPs' Path messages. 273 3.2.2. Double Sided Provisioning 275 For the double sided provisioning model, both LSP1 and LSP2 are 276 signaled independently with (Extended) ASSOCIATION Object inserted in 277 the Path message, in which the Association Type indicating double 278 sided provisioning is included. In this case, the two unidirectional 279 LSPs are bound together to form an associated bidirectional LSP based 280 on identical (Extended) ASSOCIATION Objects in the two LSPs' Path 281 messages. The LSPs to be selected for the association are 282 provisioned by the management action applied at both endpoints in all 283 three scenarios described above. 285 3.3. Asymmetric Bandwidth Signaling Overview 287 This section provides an overview of the methods for signaling 288 asymmetric upstream and downstream bandwidths for the associated 289 bidirectional LSPs. 291 3.3.1. Single Sided Provisioning 293 A new REVERSE_LSP Object for use in the single sided provisioning 294 model is defined in this document, in Section 4.4. When the single 295 sided provisioning model is used, a SENDER_TSPEC object can be added 296 in the REVERSE_LSP Object as a subobject in the initiating LSP's Path 297 message to specify a different bandwidth for the reverse LSP. As 298 described in Section 4.4, addition of the REVERSE_LSP Object also 299 allows the initiating node to control other aspects of the reverse 300 LSP (such as its path) by including other existing objects in a 301 REVERSE_LSP Object. 303 Consider again the topology described in Figure 1, where the creation 304 of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the 305 (Extended) ASSOCIATION Object with Association Type indicating single 306 sided provisioning and inserts a SENDER_TSPEC subobject for use by 307 LSP2 in the REVERSE_LSP Object in the Path message. Node B then 308 establishes the LSP2 in the reverse direction using the asymmetric 309 bandwidth thus specified by LSP1 and allows node A to control the 310 reverse LSP2. 312 3.3.2. Double Sided Provisioning 314 When the double sided provisioning model is used, the two 315 unidirectional LSPs are established with separate bandwidths, which 316 may or may not be identical. However, these LSPs are associated 317 purely based on the identical contents of their (Extended) 318 ASSOCIATION Objects. 320 3.4. Recovery LSP Overview 322 Recovery of each unidirectional LSP forming the bidirectional LSP is 323 independent [RFC5654] and is based on the parameters signaled in 324 their respective RSVP Path messages. 326 Recovery LSP association is based on the identical content of the 327 (Extended) ASSOCIATION Objects signaled in their Path messages during 328 the initial LSP setup for both single sided and double sided 329 provisioning. As defined, see [RFC6780], multiple ASSOCIATION 330 objects may be present in the signaling of a single LSP. 332 4. Message and Object Definitions 334 4.1. RSVP Message Formats 336 This section presents the RSVP message-related formats as modified by 337 this document. Unmodified RSVP message formats are not listed. 339 The format of a Path message is as follows: 341 ::= [ ] 342 [ [ | ] ... ] 343 [ ] 344 345 346 [ ] 347 348 [ ] 349 [ ... ] 350 [ ] 351 [ ... ] 352 [ ] 353 [ ... ] 354 [ ... ] 355 [ ... ] 356 358 The format of the is not modified by this 359 document. 361 4.2. ASSOCIATION Object 363 The ASSOCIATION Object is populated using the rules defined below for 364 associating two reverse unidirectional LSPs to form an associated 365 bidirectional LSP. 367 Association Types: 369 In order to bind two reverse unidirectional LSPs to be an 370 associated bidirectional LSP, the Association Type MUST be set to 371 indicate either single sided or double sided LSPs. 373 The new Association Types are defined as follows: 375 Value Type 377 ----- ----- 378 3 Double Sided Associated Bidirectional LSP (D) 379 4 Single Sided Associated Bidirectional LSP (A) 381 Association ID: 383 For both single sided and double sided provisioning, Association 384 ID MUST be set to a value assigned by the node that originates the 385 association for the bidirectional LSP. 387 Association Source: 389 Association Source MUST be set to an address selected by the node 390 that originates the association for the bidirectional LSP. For 391 example, this may be a management entity, or in the case of single 392 sided provisioning, an address assigned to the node that 393 originates the LSP. 395 4.3. Extended ASSOCIATION Object 397 The Extended ASSOCIATION Object is populated using the rules defined 398 below for associating two reverse unidirectional LSPs to form a 399 bidirectional LSP. 401 The Association Type, Association ID and Association Source MUST be 402 set as defined for the ASSOCIATION Object in Section 4.1. 404 Global Association Source: 406 For both single sided and double sided provisioning, Global 407 Association Source, when used, MUST be set to the Global_ID 408 [RFC6370] of the node that originates the association for the 409 bidirectional LSP. 411 Extended Association ID: 413 For both single sided and double sided provisioning, Extended 414 Association ID, when used, MUST be set to a value selected by the 415 node that originates the association for the bidirectional LSP. 417 4.4. REVERSE_LSP Object Definition 419 4.4.1. REVERSE_LSP Object Format 421 The information of the reverse LSP is specified via the REVERSE_LSP 422 Object. This is an optional object carried in a Path message with 423 Class Number in the form 11bbbbbb and has the following format: 425 Class_Num = 203, C_Type = 1. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 // (Subobjects) // 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 4.4.2. REVERSE_LSP Subobjects 437 The contents of a REVERSE_LSP Object is a variable length series of 438 subobjects and have the same format as RSVP Objects, see Section 439 3.1.2 of [RFC2205]. The subobjects permitted in the REVERSE_LSP 440 Object are previously defined as Path message Objects, and have the 441 same order in the REVERSE_LSP Object. 443 Examples of the Path message objects carried in the REVERSE_LSP 444 Object are (but not limited to): 446 - SENDER_TSPEC [RFC2205] 447 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 448 - SESSION_ATTRIBUTE Object [RFC3209] 449 - ADMIN_STATUS Object [RFC3473] 450 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 451 - PROTECTION Object [RFC3473] [RFC4872] 453 5. Processing Rules 455 In general, the processing rules for the ASSOCIATION Object are as 456 specified in [RFC4872] and Extended ASSOCIATION Object are specified 457 in [RFC6780]. Following sections describe the rules for processing 458 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 459 bidirectional LSPs. 461 5.1. Rules For ASSOCIATION Object 463 This section defines the processing for the association of two 464 unidirectional LSPs to form an associated bidirectional LSP. Such 465 association is based on the use of an (Extended) ASSOCIATION Object. 467 The procedures related to the actual identification of associations 468 between LSPs based on (Extended) ASSOCIATION Objects are defined in 469 [RFC6780]. [RFC6780] specifies that in the absence of Association 470 Type-specific rule for identifying association, the included 471 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 472 for an association to exist. This document adds no specific rules 473 for the new Association Types defined, and the identification of LSP 474 association therefore proceeds as specified in [RFC6780]. 476 As described in [RFC6780], association of LSPs can be upstream or 477 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 478 in Path or Resv Messages. The association of bidirectional LSPs is 479 always upstream initialized, therefore the Association Types defined 480 in this document are only to be interpreted in Path Messages. These 481 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 482 messages and SHOULD be ignored if present. 484 To indicate an associated bidirectional LSP, an ingress node MUST 485 insert an (Extended) ASSOCIATION Object into the Path message of the 486 unidirectional LSP that is part of the associated bidirectional LSP 487 it initiates. If either Global Association Source or Extended 488 Association Address is required, then an Extended ASSOCIATION Object 489 [RFC6780] MUST be inserted in the Path message. Otherwise, an 490 ASSOCIATION Object MAY be used. Only one (Extended) ASSOCIATION 491 Object with the Association Types defined in this document SHOULD be 492 included by an ingress node in an outgoing Path message. (Extended) 493 ASSOCIATION Objects with both single sided and double sided 494 Association Types MUST NOT be added in the same Path message. 496 The ingress node MUST set the Association Type field in the 497 (Extended) ASSOCIATION Object to "Single Sided Associated 498 Bidirectional LSP" when single sided provisioning is used, and to 499 "Double Sided Associated Bidirectional LSP" when double sided 500 provisioning is used. 502 A transit node MAY identify the unidirectional LSPs of an associated 503 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 504 Association Type values defined in this document, carried in Path 505 messages. Clearly, such associations are only possible when the LSPs 506 transit the node. As mentioned above, such associations are made per 507 the rules defined in [RFC6780]. 509 Egress nodes which support the Association Types defined in this 510 document identify the unidirectional LSPs of an associated 511 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 512 Path messages. Note that an ingress node will normally be the 513 ingress for one of the unidirectional LSPs that make up an associated 514 bidirectional LSP. When an egress node receives a Path message 515 containing an (Extended) ASSOCIATION Object with one of the 516 Association Types defined in this document, it MUST attempt to 517 identify other LSPs (including ones for which it is an ingress node) 518 with which the LSP being processed is associated. As defined above, 519 such associations are made per the rules defined in [RFC6780]. If 520 the egress node does not support the Association Types defined in 521 this document, it MUST return a PathErr with Error Code "Admission 522 Control Failure (01) [RFC2205]" and Sub-code "Bad Association Type 523 (5) [RFC4872]". An LSP not being associated at the time of signaling 524 (for example, during rerouting or re-optimization) on an egress node 525 is not necessarily considered an error condition. 527 Associated bidirectional LSP teardown follows the standard procedures 528 defined in [RFC3209] and [RFC3473] either without or with the 529 administrative status. Generally, the teardown procedures of the 530 unidirectional LSPs forming an associated bidirectional LSP are 531 independent of each other, so it is possible that while one LSP 532 follows graceful teardown with administrative status, the reverse LSP 533 is torn down without administrative status (using 534 PathTear/ResvTear/PathErr with state removal). See Section 5.3 below 535 for additional rules related to LSPs established using single sided 536 provisioning. 538 When an LSP signaled with a Path message containing an (Extended) 539 ASSOCIATION Object with an Association Type defined in this document 540 is torn down, the processing node SHALL remove the binding of the LSP 541 to any previously identified associated bidirectional LSP. 543 No additional processing is needed for Path messages with an 544 (Extended) ASSOCIATION Object containing an Association Type field of 545 Double Sided Associated Bidirectional LSP. 547 5.1.1. Compatibility For ASSOCIATION Object 549 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 550 ASSOCIATION Object has been defined in [RFC6780], both with class 551 numbers in the form 11bbbbbb, which ensures compatibility with 552 non-supporting nodes. Per [RFC2205], such nodes will ignore the 553 object but forward it without modification. 555 Operators wishing to use a function supported by a particular 556 association type SHOULD ensure that the type is supported on any node 557 that is expected to act on the association [RFC6780]. 559 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 560 this document. The recovery mechanisms defined in [RFC4872] and 561 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 562 use a different value for Association Type; multiple ASSOCIATION 563 Objects can be present in the LSP Path message and can coexist with 564 the procedures defined in this document. 566 5.2. Rules For REVERSE_LSP Object 568 A node initiating a Path message containing an ASSOCIATION or 569 Extended ASSOCIATION Object with the Association Type set to "Single 570 Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object 571 in the Path message of the LSP when it wishes to control the reverse 572 LSP originating on the other endpoint node. 574 The REVERSE_LSP subobject MAY contain any of the specified objects 575 which the initiating node desires to have included in the Path 576 message for the associated reverse LSP. A REVERSE_LSP Object MUST 577 contain at least one subobject. If there is no subobject to be added 578 in the REVERSE_LSP Object, then the REVERSE_LSP Object MUST NOT be 579 added in the Path message. The REVERSE_LSP Object MUST NOT be 580 included in a REVERSE_LSP Object. 582 A node receiving a valid Path message containing a REVERSE_LSP Object 583 that is not the egress node for the LSP being signaled MUST forward 584 the REVERSE_LSP Object unchanged in the outgoing Path message. 586 An egress node, upon receiving a Path message containing an 587 REVERSE_LSP Object MUST verify that the Path message contains an 588 ASSOCIATION or Extended ASSOCIATION object with the Association Type 589 set to "Single Sided Associated Bidirectional LSP". If it does not, 590 the Path message MUST NOT trigger a reverse LSP. This verification 591 failure SHOULD NOT trigger any RSVP message but can be logged 592 locally, and perhaps reported through network management mechanisms. 594 Once validated, the egress node MUST use the subobjects contained in 595 any present REVERSE_LSP Objects in the management of the reverse LSP 596 described in the previous section. Note that the contents of a 597 REVERSE_LSP Object may change over the life of an LSP and such 598 changes MUST result in corresponding changes in the reverse LSP. An 599 addition or removal of the REVERSE_LSP Object in the received Path 600 message may cause an egress node to teardown and reestablish a new 601 reverse LSP, or trigger re-optimization or in-place modification of 602 the LSP (which may depend on the local policy). 604 5.2.1. Compatibility For REVERSE_LSP Object 606 The REVERSE_LSP Object is defined with class numbers in the form 607 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 608 [RFC2205], such nodes will ignore the object but forward it without 609 modification. 611 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown 613 An egress node, upon receiving a Path message containing an 614 ASSOCIATION or Extended ASSOCIATION Object with Association Type set 615 to "Single Sided Associated Bidirectional LSP" MUST create an LSP in 616 the reverse direction or reject the Path message. If the creation of 617 a reverse LSP fails, the egress node MUST return a PathErr with Error 618 code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse 619 LSP Failure" defined in this document. Note that normal Resv 620 processing SHOULD NOT be impacted by the presence of an ASSOCIATION 621 Object with an Association Type set to "Single Sided Associated 622 Bidirectional LSP". 624 When the REVERSE_LSP Object is not present, the egress node SHOULD 625 initiate a reverse LSP based on the information contained in the 626 received Path message of the forward LSP. The egress node SHOULD 627 copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE, 628 LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS and PROTECTION Objects to 629 form the Path message of the reverse LSP. The IP address in the 630 reverse LSP's SESSION Object SHOULD be set to the IP address carried 631 in the received SENDER_TEMPLATE Object, and conversely the IP address 632 in the SENDER_TEMPLATE object SHOULD be set to the IP address carried 633 in the received SESSION Object. There are no additional requirements 634 related to the IDs carried in the SESSION and SENDER_TEMPLATE 635 Objects. When the forward LSP Path contains a RECORD_ROUTE Object, 636 the egress node SHOULD include the received RECORD_ROUTE Object in 637 the reverse LSP Path message. Local node information SHOULD also be 638 recorded per Standard Path message processing. There are no specific 639 requirements related to other objects. The resulting Path message is 640 used to create the reverse LSP. From this point on, Standard Path 641 message processing is used in processing the resulting Path message. 642 In this case, changes to the received Path messages can result in 643 changes to the reverse LSP. In particular, any object that was 644 copied as part of initial Path message creation MUST be copied when 645 modified. 647 When REVERSE_LSP Object is present in the received Path message of 648 the LSP, the egress node follows the procedure defined in Section 5.2 649 to setup the reverse LSP. 651 In both cases, when the egress node receives a PathTear message the 652 node MUST remove the associated reverse LSP using Standard PathTear 653 message processing. Tear down of the reverse LSP for other reasons 654 SHOULD NOT trigger removal of the initiating LSP, but SHOULD result 655 in the egress node sending a PathErr with Error code "Admission 656 Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP Failure" 657 defined in this document. 659 6. IANA Considerations 661 IANA is requested to administer assignment of new values for 662 namespace defined in this document and summarized in this section. 664 6.1. Association Types 666 IANA maintains the "Generalized Multi-Protocol Label Switching 667 (GMPLS) Signaling Parameters" registry (see 668 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 669 Type" subregistry is included in this registry. 671 This registry will be updated by new Association Types for 672 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 673 as follows: 675 Value Name Reference 676 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 677 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 679 Specified Association Type values are temporary early allocations as 680 per RFC7120. 682 6.2. REVERSE_LSP Object 684 IANA maintains the "RSVP Parameters" registry (see 685 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 686 Class Names, Class Numbers, and Class Types subregistry is included 687 in this registry. 689 This registry will be extended for new Class Number (Class-Num) and 690 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 691 11bbbbbb range defined in this document as follows: 693 Class Number Class Name Reference 694 203 REVERSE_LSP Section 4.4 696 o REVERSE_LSP : Class Type or C-type = 1 698 Specified REVERSE_LSP Class Number and Class Type values are 699 temporary early allocations as per RFC7120. 701 6.3. Reverse LSP Failure PathErr Sub-code 703 IANA maintains the "RSVP Parameters" registry (see 704 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 705 Error Codes and Globally-Defined Error Value Sub-Codes subregistry is 706 included in this registry. 708 This registry will be extended for the new PathErr Sub-code defined 709 in this document as follows: 711 Error Code = 01: "Admission Control Failure" (see [RFC2205]) 713 o "Admission Control Failure/Reverse LSP Failure" (TBA) 715 There are no other IANA considerations introduced by this document. 717 7. Security Considerations 719 This document introduces two new Association Types, however, no new 720 security issues relating to the (Extended) ASSOCIATION Object are 721 introduced. 723 The procedures defined in this document result in an increased state 724 information carried in signaling messages. The presence of the 725 REVERSE_LSP Object necessarily provides more information about the 726 LSPs. Thus, in the event of the interception of a signaling message, 727 slightly more information about the state of the network could be 728 deduced than was previously the case. This is judged to be a very 729 minor security risk as this information is already available via 730 routing. 732 Otherwise, this document introduces no additional security 733 considerations. For a general discussion on MPLS and GMPLS related 734 security issues, see the MPLS/GMPLS security framework [RFC5920]. 736 8. Acknowledgement 738 The authors would like to thank Lou Berger and George Swallow for 739 their great guidance in this work, Jie Dong for the discussion of 740 recovery, Lamberto Sterling for his valuable comments on the section 741 of asymmetric bandwidths, Attila Takacs for the discussion of the 742 provisioning model and Lou Berger, Daniel King and Deborah Brungard 743 for the review of the document. At the same time, the authors would 744 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 745 Lizhong Jin for the initial discussions, and Wenjuan He for the 746 prototype implementation. The authors would also like to thank Siva 747 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 748 ASSOCIATION Object. The authors would like to thank Matt Hartley for 749 providing useful suggestions on the document and Lou Berger for 750 careful editorial reviews. 752 9. Contributing Authors 754 Fan Yang 755 ZTE 757 Email: yang.fan240347@gmail.com 759 Weilian Jiang 760 ZTE 762 Email: jiang.weilian@gmail.com 764 10. References 766 10.1. Normative References 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 772 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 773 Functional Specification", RFC 2205, September 1997. 775 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 776 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 777 Tunnels", RFC 3209, December 2001. 779 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 780 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 781 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 783 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 784 Extensions in Support of End-to-End Generalized Multi- 785 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 786 2007. 788 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 789 "GMPLS Segment Recovery", RFC 4873, May 2007. 791 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 792 Association Object Extensions", RFC 6780, October 2012. 794 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax 795 Used to Form Encoding Rules in Various Routing Protocol 796 Specifications", RFC 5511, April 2009. 798 10.2. Informative References 800 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 801 Element (PCE)-Based Architecture", RFC 4655, August 2006. 803 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 804 Ayyangarps, "Encoding of Attributes for MPLS LSP 805 Establishment Using Resource Reservation Protocol Traffic 806 Engineering (RSVP-TE)", RFC 5420, February 2009. 808 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 809 and S. Ueno, "Requirements of an MPLS Transport Profile", 810 RFC 5654, September 2009. 812 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 813 Networks", RFC 5920, July 2010. 815 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 816 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 818 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 819 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 820 Framework", RFC 6373, September 2011. 822 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 823 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 824 Switched Paths (LSPs)", RFC 6387, September 2011. 826 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 827 6689, July 2012. 829 Authors' Addresses 831 Fei Zhang (editor) 832 Huawei 834 Email: zhangfei7@huawei.com 836 Ruiquan Jing 837 China Telecom 839 Email: jingrq@ctbri.com.cn 841 Rakesh Gandhi (editor) 842 Cisco Systems 844 Email: rgandhi@cisco.com