idnits 2.17.1 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-04.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 19, 2015) is 3326 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 23, 2015 China Telecom 6 Rakesh Gandhi, Ed. 7 Cisco Systems 8 February 19, 2015 10 RSVP-TE Extensions for Associated Bidirectional LSPs 11 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-04 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 . . . . . . . . . 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 . . . . . . . . . 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. 229 In each of the situations described above, both provisioning models 230 are applicable. 232 Path Computation Element (PCE)-based approaches [RFC4655], may be 233 used for path computation of an associated bidirectional LSP. 234 However, these approaches are outside the scope of this document. 236 Consider the topology described in Figure 1 (an example of associated 237 bidirectional LSP). LSP1 from A to B, takes the path A,D,B and LSP2 238 from B to A takes the path B,D,C,A. These two LSPs, once established 239 and associated, form an associated bidirectional LSP between node A 240 and node B. 242 LSP1 --> 243 A-------D-------B 244 \ / <-- LSP2 245 \ / 246 \ / 247 C 249 Figure 1: An example of associated bidirectional LSP 251 3.2.1. Single Sided Provisioning 253 For the single sided provisioning model, creation of reverse LSP1 is 254 triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. 255 When creation of reverse LSP2 is triggered by LSP1, LSP1 is 256 provisioned first (or refreshed if LSP1 already exists) at node A. 257 LSP1 is then signaled with an (Extended) ASSOCIATION and REVERSE_LSP 258 Objects inserted in the Path message. The Association Type indicates 259 single sided provisioning. Upon receiving this Path message for 260 LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION 261 Object inserted in LSP2's Path message is the same as that received 262 in LSP1's Path message. 264 A similar procedure is used if LSP2 is provisioned first at node B 265 and the creation of reverse LSP1 at node A is either triggered by 266 LSP2 or the reverse LSP1 existed. In all three scenarios, the two 267 unidirectional LSPs are bound together to form an associated 268 bidirectional LSP based on identical (Extended) ASSOCIATION Objects 269 in the two LSPs' Path messages. 271 3.2.2. Double Sided Provisioning 273 For the double sided provisioning model, both LSP1 and LSP2 are 274 signaled independently with (Extended) ASSOCIATION Object inserted in 275 the Path message, in which the Association Type indicating double 276 sided provisioning is included. In this case, the two unidirectional 277 LSPs are bound together to form an associated bidirectional LSP based 278 on identical (Extended) ASSOCIATION Objects in the two LSPs' Path 279 messages. The LSPs to be selected for the association are 280 provisioned by the management action applied at both endpoints in all 281 three scenarios described above. 283 3.3. Asymmetric Bandwidth Signaling Overview 285 This section provides an overview of the methods for signaling 286 asymmetric upstream and downstream bandwidths for the associated 287 bidirectional LSPs. 289 3.3.1. Single Sided Provisioning 291 A new REVERSE_LSP Object for use in the single sided provisioning 292 model is defined in this document, in Section 4.4. When the single 293 sided provisioning model is used, a SENDER_TSPEC Object can be added 294 in the REVERSE_LSP Object as a subobject in the initiating LSP's Path 295 message to specify a different bandwidth for the reverse LSP. As 296 described in Section 4.4, addition of the REVERSE_LSP Object also 297 allows the initiating node to control other aspects of the reverse 298 LSP (such as its path) by including other Objects in a REVERSE_LSP 299 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 used to carry information to be used by the 420 reverse LSP. The object also indicates that the LSP is the forward 421 LSP of a single sided provisioned associated bidirectional LSP. 423 The Object 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 Subobjects are used to override the default contents of Path message 438 of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP 439 Object is zero or more variable length subobjects that have the same 440 format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object 441 that may be carried in a Path message MAY be carried in the 442 REVERSE_LSP Object. Subobject ordering MUST follow any Path message 443 Object ordering requirements. 445 Examples of the Path message objects that can be carried in the 446 REVERSE_LSP Object are (but not limited to): 448 - SENDER_TSPEC [RFC2205] 449 - EXPLICIT_ROUTE Object (ERO) [RFC3209] 450 - SESSION_ATTRIBUTE Object [RFC3209] 451 - ADMIN_STATUS Object [RFC3473] 452 - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 453 - PROTECTION Object [RFC3473] [RFC4872] 455 5. Processing Rules 457 In general, the processing rules for the ASSOCIATION Object are as 458 specified in [RFC4872] and Extended ASSOCIATION Object are specified 459 in [RFC6780]. Following sections describe the rules for processing 460 (Extended) ASSOCIATION and REVERSE_LSP objects for associated 461 bidirectional LSPs. 463 5.1. Rules For ASSOCIATION Object 465 This section defines the processing for the association of two 466 unidirectional LSPs to form an associated bidirectional LSP. Such 467 association is based on the use of an (Extended) ASSOCIATION Object. 469 The procedures related to the actual identification of associations 470 between LSPs based on (Extended) ASSOCIATION Objects are defined in 471 [RFC6780]. [RFC6780] specifies that in the absence of Association 472 Type-specific rule for identifying association, the included 473 (Extended) ASSOCIATION Objects in the LSPs MUST be identical in order 474 for an association to exist. This document adds no specific rules 475 for the new Association Types defined, and the identification of LSP 476 association therefore proceeds as specified in [RFC6780]. 478 As described in [RFC6780], association of LSPs can be upstream or 479 downstream initiated, as indicated by (Extended) ASSOCIATION Objects 480 in Path or Resv Messages. The association of bidirectional LSPs is 481 always upstream initialized, therefore the Association Types defined 482 in this document are only to be interpreted in Path Messages. These 483 types SHOULD NOT be used in ASSOCIATION Objects carried in Resv 484 messages and SHOULD be ignored if present. 486 To indicate an associated bidirectional LSP, an ingress node MUST 487 insert an (Extended) ASSOCIATION Object into the Path message of the 488 unidirectional LSP that is part of the associated bidirectional LSP 489 it initiates. If either Global Association Source or Extended 490 Association Address is required, then an Extended ASSOCIATION Object 491 [RFC6780] MUST be inserted in the Path message. Otherwise, an 492 ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with 493 both single sided and double sided Association Types MUST NOT be 494 added or sent 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]. An 520 LSP not being associated at the time of signaling (for example, 521 during rerouting or re-optimization) on an egress node is not 522 necessarily considered an error condition. 524 Associated bidirectional LSP teardown follows the standard procedures 525 defined in [RFC3209] and [RFC3473] either without or with the 526 administrative status. Generally, the teardown procedures of the 527 unidirectional LSPs forming an associated bidirectional LSP are 528 independent of each other, so it is possible that while one LSP 529 follows graceful teardown with administrative status, the reverse LSP 530 is torn down without administrative status (using 531 PathTear/ResvTear/PathErr with state removal). See Section 5.2 below 532 for additional rules related to LSPs established using single sided 533 provisioning. 535 When an LSP signaled with a Path message containing an (Extended) 536 ASSOCIATION Object with an Association Type defined in this document 537 is torn down, the processing node SHALL remove the binding of the LSP 538 to any previously identified associated bidirectional LSP. 540 No additional processing is needed for Path messages with an 541 (Extended) ASSOCIATION Object containing an Association Type field of 542 Double Sided Associated Bidirectional LSP. 544 5.1.1. Compatibility For ASSOCIATION Object 546 The ASSOCIATION Object has been defined in [RFC4872] and the Extended 547 ASSOCIATION Object has been defined in [RFC6780], both with class 548 numbers in the form 11bbbbbb, which ensures compatibility with 549 non-supporting nodes. Per [RFC2205], such nodes will ignore the 550 object but forward it without modification. 552 Operators wishing to use a function supported by a particular 553 association type SHOULD ensure that the type is supported on any node 554 that is expected to act on the association [RFC6780]. 556 An egress node that does not support the Association Types defined in 557 this document, is expected to return a PathErr with Error Code 558 "Admission Control Failure (01) [RFC2205]" and Sub-code "Bad 559 Association Type (5) [RFC4872]". 561 LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by 562 this document. The recovery mechanisms defined in [RFC4872] and 563 [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but 564 use a different value for Association Type; multiple ASSOCIATION 565 Objects can be present in the LSP Path message and can coexist with 566 the procedures defined in this document. 568 5.2. Rules For REVERSE_LSP Object 570 A node initiating a Path message containing an ASSOCIATION or 571 Extended ASSOCIATION Object with the Association Type set to "Single 572 Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object 573 in the Path message of the LSP. 575 The REVERSE_LSP subobject MAY contain any of object that the 576 initiating node desires to have included in the Path message for the 577 associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be 578 included in a REVERSE_LSP Object. 580 A transit node receiving a valid Path message containing a 581 REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in 582 the outgoing Path message. 584 An egress node, upon receiving a Path message containing an 585 REVERSE_LSP Object MUST verify that the Path message contains an 586 ASSOCIATION or Extended ASSOCIATION Object with the Association Type 587 set to "Single Sided Associated Bidirectional LSP". If it does not, 588 the Path message MUST NOT trigger a reverse LSP. This verification 589 failure SHOULD NOT trigger any RSVP message but can be logged 590 locally, and perhaps reported through network management mechanisms. 592 Once validated, the egress node MUST create an LSP in the reverse 593 direction or reject the Path message. If the creation of a reverse 594 LSP fails, the egress node MUST return a PathErr with Error code 595 "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP 596 Failure" defined in this document. Note that normal Resv processing 597 SHOULD NOT be impacted by the presence of an ASSOCIATION Object with 598 an Association Type set to "Single Sided Associated Bidirectional 599 LSP". 601 The egress node MUST use the subobjects contained in the REVERSE_LSP 602 Object for initiating the reverse LSP. When a subobject is not 603 present in the received REVERSE_LSP Object, the egress node SHOULD 604 initiate the reverse LSP based on the information contained in the 605 received Path message of the forward LSP as follows: 607 o The egress node SHOULD copy the information from the received 608 SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, 609 ADMIN_STATUS and PROTECTION Objects in the forward LSP Path message 610 to form the Path message of the reverse LSP when the object is not 611 present in the received REVERSE_LSP Object. 613 o The IP address in the reverse LSP's SESSION Object SHOULD be set 614 to the IP address carried in the received SENDER_TEMPLATE Object, and 615 conversely the IP address in the SENDER_TEMPLATE Object SHOULD be set 616 to the IP address carried in the received SESSION Object. There are 617 no additional requirements related to the IDs carried in the SESSION 618 and SENDER_TEMPLATE Objects. 620 o When the forward LSP Path message contains a RECORD_ROUTE Object, 621 the egress node SHOULD include the received RECORD_ROUTE Object in 622 the reverse LSP Path message. Local node information SHOULD also be 623 recorded per Standard Path message processing. 625 o There are no specific requirements related to other objects. 627 The resulting Path message is used to create the reverse LSP. From 628 this point on, Standard Path message processing is used in processing 629 the resulting Path message. 631 Note that the contents of a forward LSP, including a carried 632 REVERSE_LSP Object, may change over the life of an LSP and such 633 changes MUST result in corresponding changes in the reverse LSP. In 634 particular, any object or subobject that was copied during the 635 creation of the initial reverse LSP's Path message MUST be copied 636 when modified in the forward LSP, and a trigger Path message MUST be 637 processed. 639 The removal of the REVERSE_LSP Object in the received Path message 640 SHOULD cause the egress node to teardown any previously established 641 reverse LSP. 643 When the egress node receives a PathTear message for the forward LSP, 644 the node MUST remove the associated reverse LSP using Standard 645 PathTear message processing. Tear down of the reverse LSP for other 646 reasons SHOULD NOT trigger removal of the initiating LSP, but SHOULD 647 result in the egress node sending a PathErr with Error code 648 "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP 649 Failure" defined in this document. 651 5.2.1. Compatibility For REVERSE_LSP Object 653 The REVERSE_LSP Object is defined with class numbers in the form 654 11bbbbbb, which ensures compatibility with non-supporting nodes. Per 655 [RFC2205], such nodes will ignore the object but forward it without 656 modification. 658 6. IANA Considerations 660 IANA is requested to administer assignment of new values for 661 namespace defined in this document and summarized in this section. 663 6.1. Association Types 665 IANA maintains the "Generalized Multi-Protocol Label Switching 666 (GMPLS) Signaling Parameters" registry (see 667 http://www.iana.org/assignments/gmpls-sig-parameters). "Association 668 Type" subregistry is included in this registry. 670 This registry will be updated by new Association Types for 671 ASSOCIATION and Extended ASSOCIATION Objects defined in this document 672 as follows: 674 Value Name Reference 675 3 Double Sided Associated Bidirectional LSP (D) Section 4.2 676 4 Single Sided Associated Bidirectional LSP (A) Section 4.2 678 Specified Association Type values are temporary early allocations as 679 per RFC7120. 681 6.2. REVERSE_LSP Object 683 IANA maintains the "RSVP Parameters" registry (see 684 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 685 Class Names, Class Numbers, and Class Types subregistry is included 686 in this registry. 688 This registry will be extended for new Class Number (Class-Num) and 689 Class Type (C-type) for RSVP REVERSE_LSP Object requested in the 690 11bbbbbb range defined in this document as follows: 692 Class Number Class Name Reference 693 203 REVERSE_LSP Section 4.4 695 o REVERSE_LSP : Class Type or C-type = 1 697 Specified REVERSE_LSP Class Number and Class Type values are 698 temporary early allocations as per RFC7120. 700 6.3. Reverse LSP Failure PathErr Sub-code 702 IANA maintains the "RSVP Parameters" registry (see 703 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 704 Error Codes and Globally-Defined Error Value Sub-Codes subregistry is 705 included in this registry. 707 This registry will be extended for the new PathErr Sub-code defined 708 in this document as follows: 710 Error Code = 01: "Admission Control Failure" (see [RFC2205]) 712 o "Admission Control Failure/Reverse LSP Failure" (TBA) 714 There are no other IANA considerations introduced by this document. 716 7. Security Considerations 718 This document introduces two new Association Types, however, no new 719 security issues relating to the (Extended) ASSOCIATION Object are 720 introduced. 722 The procedures defined in this document result in an increased state 723 information carried in signaling messages. The presence of the 724 REVERSE_LSP Object necessarily provides more information about the 725 LSPs. Thus, in the event of the interception of a signaling message, 726 slightly more information about the state of the network could be 727 deduced than was previously the case. This is judged to be a very 728 minor security risk as this information is already available via 729 routing. 731 Otherwise, this document introduces no additional security 732 considerations. For a general discussion on MPLS and GMPLS related 733 security issues, see the MPLS/GMPLS security framework [RFC5920]. 735 8. Acknowledgement 737 The authors would like to thank Lou Berger and George Swallow for 738 their great guidance in this work, Jie Dong for the discussion of 739 recovery, Lamberto Sterling for his valuable comments on the section 740 of asymmetric bandwidths, Attila Takacs for the discussion of the 741 provisioning model and Lou Berger, Daniel King and Deborah Brungard 742 for the review of the document. At the same time, the authors would 743 also like to acknowledge the contributions of Bo Wu, Xihua Fu, 744 Lizhong Jin for the initial discussions, and Wenjuan He for the 745 prototype implementation. The authors would also like to thank Siva 746 Sivabalan, Eric Osborne and Robert Sawaya for the discussions on the 747 ASSOCIATION Object. The authors would like to thank Matt Hartley for 748 providing useful suggestions on the document and Lou Berger for 749 careful editorial reviews. 751 9. Contributing Authors 753 Fan Yang 754 ZTE 756 Email: yang.fan240347@gmail.com 758 Weilian Jiang 759 ZTE 761 Email: jiang.weilian@gmail.com 763 10. References 765 10.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 771 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 772 Functional Specification", RFC 2205, September 1997. 774 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 775 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 776 Tunnels", RFC 3209, December 2001. 778 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 779 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 780 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 782 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 783 Extensions in Support of End-to-End Generalized Multi- 784 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 785 2007. 787 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 788 "GMPLS Segment Recovery", RFC 4873, May 2007. 790 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 791 Association Object Extensions", RFC 6780, October 2012. 793 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax 794 Used to Form Encoding Rules in Various Routing Protocol 795 Specifications", RFC 5511, April 2009. 797 10.2. Informative References 799 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 800 Element (PCE)-Based Architecture", RFC 4655, August 2006. 802 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 803 Ayyangarps, "Encoding of Attributes for MPLS LSP 804 Establishment Using Resource Reservation Protocol Traffic 805 Engineering (RSVP-TE)", RFC 5420, February 2009. 807 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 808 and S. Ueno, "Requirements of an MPLS Transport Profile", 809 RFC 5654, September 2009. 811 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 812 Networks", RFC 5920, July 2010. 814 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 815 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 817 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 818 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 819 Framework", RFC 6373, September 2011. 821 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 822 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 823 Switched Paths (LSPs)", RFC 6387, September 2011. 825 [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 826 6689, July 2012. 828 Authors' Addresses 830 Fei Zhang (editor) 831 Huawei 833 Email: zhangfei7@huawei.com 835 Ruiquan Jing 836 China Telecom 838 Email: jingrq@ctbri.com.cn 840 Rakesh Gandhi (editor) 841 Cisco Systems 843 Email: rgandhi@cisco.com