idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05.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 21, 2015) is 3344 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 25, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 February 21, 2015 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05 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. 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 specify any parameter 158 of an associated LSP in the single sided provisioning case. For 159 example, the REVERSE_LSP Object allow asymmetric upstream and 160 downstream bandwidths for the associated bidirectional LSP. 162 2. Conventions Used in This Document 164 2.1. Key Word Definitions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2.2. Reverse Unidirectional LSPs 172 Two reverse unidirectional LSPs are setup in the opposite directions 173 between a pair of source and destination nodes to form an associated 174 bidirectional LSP. A reverse unidirectional LSP originates on the 175 same node where the forward unidirectional LSP terminates, and it 176 terminates on the same node where the forward unidirectional LSP 177 originates. 179 2.3. Message Formats 181 This document uses the Routing Backus-Naur Form (RBNF) to define 182 message formats as defined in [RFC5511]. 184 3. Overview 186 3.1. Provisioning Model Overview 188 This section provides an overview and definition of the models for 189 provisioning associated bidirectional LSPs. 191 The associated bidirectional LSP's forward and reverse unidirectional 192 LSPs are established, monitored, and protected independently as 193 specified by [RFC5654]. Configuration information regarding the LSPs 194 can be provided at one or both endpoints of the associated 195 bidirectional LSP. Depending on the method chosen, there are two 196 models of creating an associated bidirectional LSP; single sided 197 provisioning, and double sided provisioning. 199 3.1.1. Single Sided Provisioning 201 For the single sided provisioning, the Traffic Engineering (TE) 202 tunnel is configured only on one endpoint. An LSP for this tunnel is 203 initiated by the initiating endpoint with the (Extended) ASSOCIATION 204 and REVERSE_LSP Objects inserted in the Path message. The other 205 endpoint then creates the corresponding reverse TE tunnel and signals 206 the reverse LSP in response using information from the REVERSE_LSP 207 Object and other Objects present in the received Path message. 209 3.1.2. Double Sided Provisioning 211 For the double sided provisioning, two unidirectional TE tunnels are 212 configured independently, one on each endpoint. The LSPs for the 213 tunnels are signaled with (Extended) ASSOCIATION Objects inserted in 214 the Path message by both endpoints to indicate that the two LSPs are 215 to be associated to form a bidirectional LSP. 217 3.2. Association Signaling Overview 219 This section provides an overview of the association signaling 220 methods for the associated bidirectional LSPs. 222 Three scenarios exist for binding two unidirectional LSPs together to 223 form an associated bidirectional LSP. These are: 1) Neither 224 unidirectional LSP exists, and both must be established. 2) Both 225 unidirectional LSPs exist, but the association must be established. 226 3) One LSP exists, but the reverse associated LSP must be 227 established. Following sections describe the applicable provisioning 228 models for each of these scenarios. 230 Path Computation Element (PCE)-based approaches [RFC4655], may be 231 used for path computation of an associated bidirectional LSP. 232 However, these approaches are outside the scope of this document. 234 Consider the topology described in Figure 1 (an example of associated 235 bidirectional LSP). LSP1 from A to B, takes the path A,D,B and LSP2 236 from B to A takes the path B,D,C,A. These two LSPs, once established 237 and associated, form an associated bidirectional LSP between node A 238 and node B. 240 LSP1 --> 241 A-------D-------B 242 \ / <-- LSP2 243 \ / 244 \ / 245 C 247 Figure 1: An example of associated bidirectional LSP 249 3.2.1. Single Sided Provisioning 251 For the single sided provisioning model, creation of reverse LSP1 252 shown in Figure 1 is triggered by LSP2 or creation of reverse LSP2 is 253 triggered by LSP1. When creation of reverse LSP2 is triggered by 254 LSP1, LSP1 is provisioned first (or refreshed if LSP1 already exists) 255 at node A. LSP1 is then signaled with an (Extended) ASSOCIATION and 256 REVERSE_LSP Objects inserted in the Path message. The Association 257 Type indicates single sided provisioning. Upon receiving this Path 258 message for LSP1, node B establishes reverse LSP2. The (Extended) 259 ASSOCIATION Object inserted in LSP2's Path message is the same as 260 that received in LSP1's Path message. 262 A similar procedure is used if LSP2 is provisioned first at node B 263 and the creation of reverse LSP1 at node A is triggered by LSP2. In 264 both scenarios, the two unidirectional LSPs are bound together to 265 form an associated bidirectional LSP based on identical (Extended) 266 ASSOCIATION Objects in the two LSPs' Path messages. 268 3.2.2. Double Sided Provisioning 270 For the double sided provisioning model, both LSP1 and LSP2 shown in 271 Figure 1 are signaled independently with (Extended) ASSOCIATION 272 Object inserted in the Path message, in which the Association Type 273 indicating double sided provisioning is included. In this case, the 274 two unidirectional LSPs are bound together to form an associated 275 bidirectional LSP based on identical (Extended) ASSOCIATION Objects 276 in the two LSPs' Path messages. The LSPs to be selected for the 277 association are provisioned by the management action applied at both 278 endpoints in all three scenarios described above. 280 3.3. Asymmetric Bandwidth Signaling Overview 282 This section provides an overview of the methods for signaling 283 asymmetric upstream and downstream bandwidths for the associated 284 bidirectional LSPs. 286 3.3.1. Single Sided Provisioning 288 A new REVERSE_LSP Object for use in the single sided provisioning 289 model is defined in this document, in Section 4.4. When the single 290 sided provisioning model is used, a SENDER_TSPEC Object can be added 291 in the REVERSE_LSP Object as a subobject in the initiating LSP's Path 292 message to specify a different bandwidth for the reverse LSP. As 293 described in Section 4.4, addition of the REVERSE_LSP Object also 294 allows the initiating node to control other aspects of the reverse 295 LSP (such as its path) by including other Objects in a REVERSE_LSP 296 Object. 298 Consider again the topology described in Figure 1, where the creation 299 of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the 300 (Extended) ASSOCIATION Object with Association Type indicating single 301 sided provisioning and inserts a SENDER_TSPEC subobject for use by 302 LSP2 in the REVERSE_LSP Object in the Path message. Node B then 303 establishes the LSP2 in the reverse direction using the asymmetric 304 bandwidth thus specified by LSP1 and allows node A to control the 305 reverse LSP2. 307 3.3.2. Double Sided Provisioning 309 When the double sided provisioning model is used, the two 310 unidirectional LSPs are established with separate bandwidths, which 311 may or may not be identical. However, these LSPs are associated 312 purely based on the identical contents of their (Extended) 313 ASSOCIATION Objects. 315 3.4. Recovery LSP Overview 317 Recovery of each unidirectional LSP forming the bidirectional LSP is 318 independent [RFC5654] and is based on the parameters signaled in 319 their respective RSVP Path messages. 321 Recovery LSP association is based on the identical content of the 322 (Extended) ASSOCIATION Objects signaled in their Path messages during 323 the initial LSP setup for both single sided and double sided 324 provisioning. As defined, see [RFC6780], multiple ASSOCIATION 325 objects may be present in the signaling of a single LSP. 327 4. Message and Object Definitions 329 4.1. RSVP Message Formats 331 This section presents the RSVP message-related formats as modified by 332 this document. Unmodified RSVP message formats are not listed. 334 The format of a Path message is as follows: 336 ::= [ ] 337 [ [ | ] ... ] 338 [ ] 339 340 341 [ ] 342 343 [ ] 344 [ ... ] 345 [ ] 346 [ ... ] 347 [ ] 348 [ ... ] 349 [ ... ] 350 [ ... ] 351 353 The format of the is not modified by this 354 document. 356 4.2. ASSOCIATION Object 358 The ASSOCIATION Object is populated using the rules defined below for 359 associating two reverse unidirectional LSPs to form an associated 360 bidirectional LSP. 362 Association Types: 364 In order to bind two reverse unidirectional LSPs to be an 365 associated bidirectional LSP, the Association Type MUST be set to 366 indicate either single sided or double sided LSPs. 368 The new Association Types are defined as follows: 370 Value Type 372 ----- ----- 373 3 Double Sided Associated Bidirectional LSP (D) 374 4 Single Sided Associated Bidirectional LSP (A) 376 Association ID: 378 For both single sided and double sided provisioning, Association 379 ID MUST be set to a value assigned by the node that originates the 380 association for the bidirectional LSP. 382 Association Source: 384 Association Source MUST be set to an address selected by the node 385 that originates the association for the bidirectional LSP. For 386 example, this may be a management entity, or in the case of single 387 sided provisioning, an address assigned to the node that 388 originates the LSP. 390 4.3. Extended ASSOCIATION Object 392 The Extended ASSOCIATION Object is populated using the rules defined 393 below for associating two reverse unidirectional LSPs to form a 394 bidirectional LSP. 396 The Association Type, Association ID and Association Source MUST be 397 set as defined for the ASSOCIATION Object in Section 4.1. 399 Global Association Source: 401 For both single sided and double sided provisioning, Global 402 Association Source, when used, MUST be set to the Global_ID 403 [RFC6370] of the node that originates the association for the 404 bidirectional LSP. 406 Extended Association ID: 408 For both single sided and double sided provisioning, Extended 409 Association ID, when used, MUST be set to a value selected by the 410 node that originates the association for the bidirectional LSP. 412 4.4. REVERSE_LSP Object Definition 414 4.4.1. REVERSE_LSP Object Format 416 The REVERSE_LSP Object is used to carry information to be used by the 417 reverse LSP. The object also indicates that the LSP is the forward 418 LSP of a single sided provisioned associated bidirectional LSP. 420 The Object has the following format: 422 Class_Num = 203, C_Type = 1. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 // (Subobjects) // 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 4.4.2. REVERSE_LSP Subobjects 434 Subobjects are used to override the default contents of Path message 435 of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP 436 Object is zero or more variable length subobjects that have the same 437 format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object 438 that may be carried in a Path message MAY be carried in the 439 REVERSE_LSP Object. Subobject ordering MUST follow any Path message 440 Object ordering requirements. 442 Examples of the Path message objects that can be carried in the 443 REVERSE_LSP Object are (but not limited to): 445 - SENDER_TSPEC [RFC2205] 446 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 447 - SESSION_ATTRIBUTE Object [RFC3209] 448 - ADMIN_STATUS Object [RFC3473] 449 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 450 - PROTECTION Object [RFC3473] [RFC4872] 452 5. Processing Rules 454 In general, the processing rules for the ASSOCIATION Object are as 455 specified in [RFC4872] and Extended ASSOCIATION Object are specified 456 in [RFC6780]. Following sections describe the rules for processing 457 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 458 bidirectional LSPs. 460 5.1. Rules For ASSOCIATION Object 462 This section defines the processing for the association of two 463 unidirectional LSPs to form an associated bidirectional LSP. Such 464 association is based on the use of an (Extended) ASSOCIATION Object. 466 The procedures related to the actual identification of associations 467 between LSPs based on (Extended) ASSOCIATION Objects are defined in 468 [RFC6780]. [RFC6780] specifies that in the absence of Association 469 Type-specific rule for identifying association, the included 470 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 471 for an association to exist. This document adds no specific rules 472 for the new Association Types defined, and the identification of LSP 473 association therefore proceeds as specified in [RFC6780]. 475 As described in [RFC6780], association of LSPs can be upstream or 476 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 477 in Path or Resv Messages. The association of bidirectional LSPs is 478 always upstream initialized, therefore the Association Types defined 479 in this document are only to be interpreted in Path Messages. These 480 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 481 messages and SHOULD be ignored if present. 483 To indicate an associated bidirectional LSP, an ingress node MUST 484 insert an (Extended) ASSOCIATION Object into the Path message of the 485 unidirectional LSP that is part of the associated bidirectional LSP 486 it initiates. If either Global Association Source or Extended 487 Association Address is required, then an Extended ASSOCIATION Object 488 [RFC6780] MUST be inserted in the Path message. Otherwise, an 489 ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with 490 both single sided and double sided Association Types MUST NOT be 491 added or sent in the same Path message. 493 The ingress node MUST set the Association Type field in the 494 (Extended) ASSOCIATION Object to "Single Sided Associated 495 Bidirectional LSP" when single sided provisioning is used, and to 496 "Double Sided Associated Bidirectional LSP" when double sided 497 provisioning is used. 499 A transit node MAY identify the unidirectional LSPs of an associated 500 bidirectional LSP based on (Extended) ASSOCIATION Objects, with the 501 Association Type values defined in this document, carried in Path 502 messages. Clearly, such associations are only possible when the LSPs 503 transit the node. As mentioned above, such associations are made per 504 the rules defined in [RFC6780]. 506 Egress nodes which support the Association Types defined in this 507 document identify the unidirectional LSPs of an associated 508 bidirectional LSP based on (Extended) ASSOCIATION Objects carried in 509 Path messages. Note that an ingress node will normally be the 510 ingress for one of the unidirectional LSPs that make up an associated 511 bidirectional LSP. When an egress node receives a Path message 512 containing an (Extended) ASSOCIATION Object with one of the 513 Association Types defined in this document, it MUST attempt to 514 identify other LSPs (including ones for which it is an ingress node) 515 with which the LSP being processed is associated. As defined above, 516 such associations are made per the rules defined in [RFC6780]. An 517 LSP not being associated at the time of signaling (for example, 518 during rerouting or re-optimization) on an egress node is not 519 necessarily considered an error condition. 521 Associated bidirectional LSP teardown follows the standard procedures 522 defined in [RFC3209] and [RFC3473] either without or with the 523 administrative status. Generally, the teardown procedures of the 524 unidirectional LSPs forming an associated bidirectional LSP are 525 independent of each other, so it is possible that while one LSP 526 follows graceful teardown with administrative status, the reverse LSP 527 is torn down without administrative status (using 528 PathTear/ResvTear/PathErr with state removal). See Section 5.2 below 529 for additional rules related to LSPs established using single sided 530 provisioning. 532 When an LSP signaled with a Path message containing an (Extended) 533 ASSOCIATION Object with an Association Type defined in this document 534 is torn down, the processing node SHALL remove the binding of the LSP 535 to any previously identified associated bidirectional LSP. 537 No additional processing is needed for Path messages with an 538 (Extended) ASSOCIATION Object containing an Association Type field of 539 Double Sided Associated Bidirectional LSP. 541 5.1.1. Compatibility For ASSOCIATION Object 543 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 544 ASSOCIATION Object has been defined in [RFC6780], both with class 545 numbers in the form 11bbbbbb, which ensures compatibility with 546 non-supporting nodes. Per [RFC2205], such nodes will ignore the 547 object but forward it without modification. 549 Operators wishing to use a function supported by a particular 550 association type SHOULD ensure that the type is supported on any node 551 that is expected to act on the association [RFC6780]. 553 An egress node that does not support the Association Types defined in 554 this document, is expected to return a PathErr with Error Code 555 "Admission Control Failure (01) [RFC2205]" and Sub-code "Bad 556 Association Type (5) [RFC4872]". 558 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 559 this document. The recovery mechanisms defined in [RFC4872] and 560 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 561 use a different value for Association Type; multiple ASSOCIATION 562 Objects can be present in the LSP Path message and can coexist with 563 the procedures defined in this document. 565 5.2. Rules For REVERSE_LSP Object 567 When a node initiates setup of an LSP using a PATH message containing 568 an ASSOCIATION or Extended ASSOCIATION Object, and the Association 569 Type set to "Single Sided Associated Bidirectional LSP", the PATH 570 message MUST carry the REVERSE_LSP Object to trigger creation of a 571 reverse LSP on the egress node. 573 The REVERSE_LSP subobject MAY contain any of object that the 574 initiating node desires to have included in the Path message for the 575 associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be 576 included in a REVERSE_LSP Object. 578 A transit node receiving a valid Path message containing a 579 REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in 580 the outgoing Path message. 582 An egress node, upon receiving a Path message containing an 583 REVERSE_LSP Object MUST verify that the Path message contains an 584 ASSOCIATION or Extended ASSOCIATION Object with the Association Type 585 set to "Single Sided Associated Bidirectional LSP". If it does not, 586 the Path message MUST NOT trigger a reverse LSP. This verification 587 failure SHOULD NOT trigger any RSVP message but can be logged 588 locally, and perhaps reported through network management mechanisms. 590 Once validated, the egress node MUST create an LSP in the reverse 591 direction or reject the Path message. If the creation of a reverse 592 LSP fails, the egress node MUST return a PathErr with Error code 593 "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP 594 Failure" defined in this document. Note that normal Resv processing 595 SHOULD NOT be impacted by the presence of an ASSOCIATION Object with 596 an Association Type set to "Single Sided Associated Bidirectional 597 LSP". 599 The egress node MUST use the subobjects contained in the REVERSE_LSP 600 Object for initiating the reverse LSP. When a subobject is not 601 present in the received REVERSE_LSP Object, the egress node SHOULD 602 initiate the reverse LSP based on the information contained in the 603 received Path message of the forward LSP as follows: 605 o The egress node SHOULD copy the information from the received 606 SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, 607 ADMIN_STATUS and PROTECTION Objects in the forward LSP Path message 608 to form the Path message of the reverse LSP when the object is not 609 present in the received REVERSE_LSP Object. 611 o The IP address in the reverse LSP's SESSION Object SHOULD be set 612 to the IP address carried in the received SENDER_TEMPLATE Object, and 613 conversely the IP address in the SENDER_TEMPLATE Object SHOULD be set 614 to the IP address carried in the received SESSION Object. There are 615 no additional requirements related to the IDs carried in the SESSION 616 and SENDER_TEMPLATE Objects. 618 o When the forward LSP Path message contains a RECORD_ROUTE Object, 619 the egress node SHOULD include the received RECORD_ROUTE Object in 620 the reverse LSP Path message. Local node information SHOULD also be 621 recorded per Standard Path message processing. 623 o There are no specific requirements related to other objects. 625 The resulting Path message is used to create the reverse LSP. From 626 this point on, Standard Path message processing is used in processing 627 the resulting Path message. 629 Note that the contents of a forward LSP, including a carried 630 REVERSE_LSP Object, may change over the life of an LSP and such 631 changes MUST result in corresponding changes in the reverse LSP. In 632 particular, any object or subobject that was copied during the 633 creation of the initial reverse LSP's Path message MUST be copied 634 when modified in the forward LSP, and a trigger Path message MUST be 635 processed. 637 The removal of the REVERSE_LSP Object in the received Path message 638 SHOULD cause the egress node to teardown any previously established 639 reverse LSP. 641 When the egress node receives a PathTear message for the forward LSP 642 or whenever the forward LSP is torn down, the node MUST remove the 643 associated reverse LSP using Standard PathTear message processing. 644 Tear down of the reverse LSP for other reasons SHOULD NOT trigger 645 removal of the initiating LSP, but SHOULD result in the egress node 646 sending a PathErr with Error code "Admission Control Failure (01) 647 [RFC2205]" and Sub-code "Reverse LSP Failure" defined in this 648 document. 650 5.2.1. Compatibility For REVERSE_LSP Object 652 The REVERSE_LSP Object is defined with class numbers in the form 653 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 654 [RFC2205], such nodes will ignore the object but forward it without 655 modification. 657 6. IANA Considerations 659 IANA is requested to administer assignment of new values for 660 namespace defined in this document and summarized in this section. 662 6.1. Association Types 664 IANA maintains the "Generalized Multi-Protocol Label Switching 665 (GMPLS) Signaling Parameters" registry (see 666 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 667 Type" subregistry is included in this registry. 669 This registry will be updated by new Association Types for 670 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 671 as follows: 673 Value Name Reference 674 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 675 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 677 Specified Association Type values are temporary early allocations as 678 per RFC7120. 680 6.2. REVERSE_LSP Object 682 IANA maintains the "RSVP Parameters" registry (see 683 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 684 Class Names, Class Numbers, and Class Types subregistry is included 685 in this registry. 687 This registry will be extended for new Class Number (Class-Num) and 688 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 689 11bbbbbb range defined in this document as follows: 691 Class Number Class Name Reference 692 203 REVERSE_LSP Section 4.4 694 o REVERSE_LSP : Class Type or C-type = 1 696 Specified REVERSE_LSP Class Number and Class Type values are 697 temporary early allocations as per RFC7120. 699 6.3. Reverse LSP Failure PathErr Sub-code 701 IANA maintains the "RSVP Parameters" registry (see 702 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 703 Error Codes and Globally-Defined Error Value Sub-Codes subregistry is 704 included in this registry. 706 This registry will be extended for the new PathErr Sub-code defined 707 in this document as follows: 709 Error Code = 01: "Admission Control Failure" (see [RFC2205]) 711 o "Admission Control Failure/Reverse LSP Failure" (TBA) 713 There are no other IANA considerations introduced by this document. 715 7. Security Considerations 717 This document introduces two new Association Types, double sided 718 associated bidirectional LSP and single sided associated 719 bidirectional LSP. For the double sided associated bidirectional 720 LSP, no new security issues relating to the (Extended) ASSOCIATION 721 Object are introduced. For the single sided associated bidirectional 722 LSP, the initiating node triggers an LSP creation on the remote node. 723 This introduces a security issue on the remote node. An 724 administrative policy may be provisioned on the remote node to deny 725 the triggering of an LSP by an initiating node. 727 The procedures defined in this document result in an increased state 728 information carried in signaling messages. The presence of the 729 REVERSE_LSP Object necessarily provides more information about the 730 LSPs. Thus, in the event of the interception of a signaling message, 731 slightly more information about the state of the network could be 732 deduced than was previously the case. This is judged to be a very 733 minor security risk as this information is already available via 734 routing. 736 Otherwise, this document introduces no additional security 737 considerations. For a general discussion on MPLS and GMPLS related 738 security issues, see the MPLS/GMPLS security framework [RFC5920]. 740 8. Acknowledgement 742 The authors would like to thank Lou Berger and George Swallow for 743 their great guidance in this work, Jie Dong for the discussion of 744 recovery, Lamberto Sterling for his valuable comments on the section 745 of asymmetric bandwidths, Attila Takacs for the discussion of the 746 provisioning model and Lou Berger, Daniel King and Deborah Brungard 747 for the review of the document. At the same time, the authors would 748 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 749 Lizhong Jin for the initial discussions, and Wenjuan He for the 750 prototype implementation. The authors would also like to thank Siva 751 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 752 ASSOCIATION Object. The authors would like to thank Matt Hartley for 753 providing useful suggestions on the document and Lou Berger for 754 careful editorial reviews. 756 9. Contributing Authors 758 Fan Yang 759 ZTE 761 Email: yang.fan240347@gmail.com 763 Weilian Jiang 764 ZTE 766 Email: jiang.weilian@gmail.com 768 10. References 770 10.1. Normative References 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 776 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 777 Functional Specification", RFC 2205, September 1997. 779 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 780 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 781 Tunnels", RFC 3209, December 2001. 783 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 784 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 785 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 787 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 788 Extensions in Support of End-to-End Generalized Multi- 789 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 790 2007. 792 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 793 "GMPLS Segment Recovery", RFC 4873, May 2007. 795 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 796 Association Object Extensions", RFC 6780, October 2012. 798 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax 799 Used to Form Encoding Rules in Various Routing Protocol 800 Specifications", RFC 5511, April 2009. 802 10.2. Informative References 804 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 805 Element (PCE)-Based Architecture", RFC 4655, August 2006. 807 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 808 Ayyangarps, "Encoding of Attributes for MPLS LSP 809 Establishment Using Resource Reservation Protocol Traffic 810 Engineering (RSVP-TE)", RFC 5420, February 2009. 812 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 813 and S. Ueno, "Requirements of an MPLS Transport Profile", 814 RFC 5654, September 2009. 816 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 817 Networks", RFC 5920, July 2010. 819 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 820 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 822 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 823 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 824 Framework", RFC 6373, September 2011. 826 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 827 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 828 Switched Paths (LSPs)", RFC 6387, September 2011. 830 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 831 6689, July 2012. 833 Authors' Addresses 835 Fei Zhang (editor) 836 Huawei 838 Email: zhangfei7@huawei.com 840 Ruiquan Jing 841 China Telecom 843 Email: jingrq@ctbri.com.cn 845 Rakesh Gandhi (editor) 846 Cisco Systems 848 Email: rgandhi@cisco.com