idnits 2.17.1 draft-ietf-teas-lsp-diversity-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2580 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 Zafar Ali, Ed. 3 Internet Draft George Swallow, Ed. 4 Intended status: Standard Track Cisco Systems 5 Updates RFC4874 F. Zhang, Ed. 6 Expires: September 28, 2017 Huawei 7 D. Beller, Ed. 8 Nokia 9 March 27, 2017 11 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 12 Diversity using Exclude Route 14 draft-ietf-teas-lsp-diversity-07.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 28, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 Resource ReserVation Protocol-Traffic Engineering provides support 51 for the communication of exclusion information during labeled switch 52 path setup. This document specifies three new route exclusion types. 53 The new types include exclusions based on LSP, PCE, and network 54 assigned identifiers. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction..................................................2 65 1.1. Client-Initiated Identifier..............................5 66 1.2. PCE-allocated Identifier.................................6 67 1.3. Network-Assigned Identifier..............................7 68 2. RSVP-TE signaling extensions..................................9 69 2.1. Diversity XRO Subobject..................................9 70 2.2. Diversity EXRS Subobject................................15 71 2.3. Processing rules for the Diversity XRO and EXRS 72 subobjects..............................................16 73 3. Security Considerations......................................20 74 4. IANA Considerations..........................................20 75 4.1. New XRO subobject types.................................20 76 4.2. New EXRS subobject types................................21 77 4.3. New RSVP error sub-codes................................21 78 5. Acknowledgements.............................................22 79 6. References...................................................22 80 6.1. Normative References....................................22 81 6.2. Informative References..................................23 83 1. Introduction 85 Path diversity for multiple connections is a well-known Service 86 Provider requirement. Diversity constraints ensure that Label- 87 Switched Paths (LSPs) can be established without sharing network 88 resources, thus greatly reducing the probability of simultaneous 89 connection failures. 91 The source node can compute diverse paths for LSPs when it has 92 full knowledge of the network topology and is permitted to signal 93 an Explicit Route Object. However, there are scenarios where 94 different nodes perform path computations, and therefore there is 95 a need for relevant diversity constraints to be signaled to those 96 nodes. These include (but are not limited to): 98 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 99 inter-domain LSPs. 101 . Generalized Multi-Protocol Label Switching (GMPLS) User- 102 Network Interface (UNI), where the core node may perform path 103 computation [RFC4208]. 105 [RFC4874] introduced a means of specifying nodes and resources to 106 be excluded from a route, using the eXclude Route Object (XRO) and 107 Explicit Exclusion Route Subobject (EXRS). It facilitates the 108 calculation of diverse paths for LSPs based on known properties of 109 those paths including addresses of links and nodes traversed, and 110 Shared Risk Link Groups (SRLGs) of traversed links. Employing 111 these mechanisms requires that the source node that initiates 112 signaling knows the relevant properties of the path(s) from which 113 diversity is desired. However, there are circumstances under which 114 this may not be possible or desirable, including (but not limited 115 to): 117 . Exclusion of a path which does not originate, terminate or 118 traverse the source node of the diverse LSP, in which case the 119 addresses of links and SRLGs of the path from which diversity 120 is required are unknown to the source node. 122 . Exclusion of a path which is known to the source node of the 123 diverse LSP for which the node has incomplete or no path 124 information, e.g. due to operator policy. In this case, the 125 source node is aware of the existence of the reference path but 126 the information required to construct an XRO object to 127 guarantee diversity from the reference path is not fully known. 128 Inter-domain and GMPLS overlay networks can impose such 129 restrictions. 131 This is exemplified in the Figure 1, where the overlay reference 132 model from [RFC4208] is shown. 134 Overlay Overlay 135 Network +----------------------------------+ Network 136 +---------+ | | +---------+ 137 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 138 | | | | UNI | | | | | | | | UNI | | | | 139 | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 140 | | | | +--+--+ | | | | | | +---+-| | | 141 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 142 +---------+ | | | | | | | +---------+ 143 | | | | | | | 144 +---------+ | | +--+--+ | +--+--+ | | +---------+ 145 | +----+ | | | | | +-------+ +-----+ | +----+ | 146 | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | 147 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 148 | | | | UNI | +-----+ +-----+ | UNI | | | | 149 | +----+ | | | | +----+ | 150 +---------+ +----------------------------------+ +---------+ 151 Overlay Core Network Overlay 152 Network Network 154 Legend: EN - Edge Node 155 CN - Core Node 157 Figure 1: Overlay Reference Model [RFC4208] 159 Figure 1 depicts two types of UNI connectivity: single-homed and 160 dual-homed ENs (which also applies to higher order multi-homed 161 connectivity.). Single-homed EN devices are connected to a single 162 CN device via a single UNI link. This single UNI link may 163 constitute a single point of failure. UNI connection between EN1 164 and CN1 is an example of singled-homed UNI connectivity. 166 A single point of failure caused by a single-homed UNI can be 167 avoided when the EN device is connected to two different CN 168 devices, as depicted for EN2 in Figure 1. For the dual-homing 169 case, it is possible to establish two different UNI connections 170 from the same source EN device to the same destination EN device. 171 For example, two connections from EN2 to EN3 may use the two UNI 172 links EN2-CN1 and EN2-CN4. To avoid single points of failure 173 within the provider network, it is necessary to also ensure path 174 (LSP) diversity within the core network. 176 In a UNI network such as that shown in Figure 1, the CNs 177 typically perform path computation. Information sharing across 178 the UNI boundary is restricted based on the policy rules imposed 179 by the core network. Typically, the core network topology 180 information is not exposed to the ENs. In the network shown in 181 Figure 1, consider a use case where an LSP from EN2 to EN4 needs 182 to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 183 may not know SRLG attributes of the EN1- EN3 LSP and hence cannot 184 construct an XRO to exclude these SRLGs. In this example EN2 185 cannot use the procedures described in [RFC4874]. Similarly, an 186 LSP from EN2 to EN3 traversing CN1 needs to be diverse from an 187 LSP from EN2 to EN3 going via CN4. Again in this case, exclusions 188 based on [RFC4874] cannot be used. 190 This document addresses these diversity requirements by 191 introducing the notion of excluding the path taken by particular 192 LSP(s). The reference LSP(s) or route(s) from which diversity is 193 required is/are identified by an "identifier". The type of 194 identifier to use is highly dependent on the networking 195 deployment scenario; it could be client-initiated, allocated by 196 the (core) network or managed by a PCE. This document defines 197 three different types of identifiers corresponding to these three 198 cases: a client initiated identifier, a PCE allocated Identifier 199 and CN ingress node (UNI-N) allocated Identifier. 201 1.1. Client-Initiated Identifier 203 There are scenarios in which the ENs have the following 204 requirements for the diversity identifier: 206 - The identifier is controlled by the client side and is 207 specified as part of the service request. 209 - Both client and server understand the identifier. 211 - It is necessary to be able to reference the identifier even if 212 the LSP referenced by it is not yet signaled. 214 - The identifier is to be stable for a long period of time. 216 - The identifier is to be stable even when the referenced LSP is 217 rerouted. 219 These requirements are met by using the LSP identifier. The LSP 220 identifier uniquely identifies an LSP in the network and 221 comprises of the following fields: IPv4/IPv6 tunnel sender 222 address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID, 223 and Extended Tunnel ID. These fields are defined in [RFC3209], 224 sections 4.6.1.1 and 4.6.2.1. 226 The usage of the client-initiated identifier is illustrated by 227 Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with 228 respect to a LSP from EN1 to EN3. The LSP identifier of the EN1- 229 EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by 230 the tuple (tunnel-id = T1, LSP ID = L1, source address = 231 EN1.ROUTE Identifier (RID), destination address = EN3.RID, 232 extended tunnel-id = EN1.RID). Similarly, LSP identifier of the 233 EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined 234 by the tuple (tunnel-id = T2, LSP IS = L1, source address = 235 EN2.RID, destination address = EN4.RID, extended tunnel-id = 236 EN2.RID). The EN1-EN3 LSP is signaled with an exclusion 237 requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled 238 with an exclusion requirement from LSP-IDENTIFIER1. In order to 239 maintain diversity between these two connections within the core 240 network, it is assumed that the core network implements Crankback 241 Signaling [RFC4920]. Note that crankback signaling is known to 242 lead to slower setup times and sub-optimal paths under some 243 circumstances as described by [RFC4920]. 245 1.2. PCE-allocated Identifier 247 In scenarios where a PCE is deployed and used to perform path 248 computation, the core edge node (e.g., node CN1 in Figure 1) 249 could consult a PCE to allocate identifiers, which are used to 250 signal path diversity constraints. In other scenarios a PCE is 251 deployed at network node(s) or a PCE is part of a Network 252 Management System (NMS). In all these cases, the Path Key as 253 defined in [RFC5520] can be used in RSVP signaling as the 254 identifier to ensure diversity. 256 An example of specifying LSP diversity using a Path Key is shown 257 in Figure 2, where a simple network with two domains is shown. It 258 is desired to set up a pair of path-disjoint LSPs from the source 259 in Domain 1 to the destination in Domain 2, but the domains keep 260 strict confidentiality about all path and topology information. 262 The first LSP is signaled by the source with ERO {A, B, loose Dst} 263 and is set up with the path {Src, A, B, U, V, W, Dst}. However, 264 when sending the RRO out of Domain 2, node U would normally strip 265 the path and replace it with a loose hop to the destination. With 266 this limited information, the source is unable to include enough 267 detail in the ERO of the second LSP to avoid it taking, for 268 example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. 270 --------------------- ----------------------------- 271 | Domain 1 | | Domain 2 | 272 | | | | 273 | --- --- | | --- --- --- | 274 | | A |--| B |--+--+--| U |--| V |---| W | | 275 | / --- --- | | --- --- --- \ | 276 | ---/ | | / / \--- | 277 | |Src| | | / / |Dst| | 278 | ---\ | | / / /--- | 279 | \ --- --- | | --- / --- / --- / | 280 | | C |--| D |--+--+--| X |---| Y |--| Z | | 281 | --- --- | | --- --- --- | 282 | | | | 283 --------------------- ----------------------------- 285 Figure 2: A Simple Multi-Domain Network 287 In order to improve the situation, node U performs the PCE 288 function and replaces the path segment {U, V, W} in the RRO with 289 a Path Key subobject. The Path Key subobject assigns an 290 "identifier" to the key. The PCE ID in the message indicates that 291 it was node U that made the replacement. 293 With this additional information, the source is able to signal 294 the subsequent LSPs with the ERO set to {C, D, exclude Path 295 Key(EXRS), loose Dst}. When the signaling message reaches node X, 296 it can consult node U to expand the Path Key and know how to 297 avoid the path of the first LSP. Alternatively, the source could 298 use an ERO of {C, D, loose Dst} and include an XRO containing the 299 Path Key. 301 This mechanism can work with all the Path-Key resolution 302 mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co- 303 located or not, may be used to resolve the Path-Key, but the node 304 (i.e., a Label Switching Router (LSR)) can also use the Path Key 305 information to index a Path Segment previously supplied to it by 306 the entity that originated the Path-Key, for example the LSR that 307 inserted the Path-Key in the RRO or a management system. 309 1.3. Network-Assigned Identifier 311 There are scenarios in which the network provides diversity- 312 related information for a service that allows the client device 313 to include this information in the signaling message. If the 314 Shared Resource Link Group (SRLG) identifier information is both 315 available and shareable (by policy) with the ENs, the procedure 316 defined in [RFC8001] can be used to collect SRLG identifiers 317 associated with an LSP (LSP1). When a second LSP (LSP2) needs to 318 be diverse with respect to LSP1, the EN constructing the RSVP 319 signaling message for setting up LSP2 can insert the SRLG 320 identifiers associated with LSP1 as diversity constraints into 321 the XRO using the procedure described in [RFC4874]. However, if 322 the core network SRLG identifiers are either not available or not 323 shareable with the ENs based on policies enforced by core 324 network, existing mechanisms cannot be used. 326 In this draft, a signaling mechanism is defined where information 327 signaled to the CN via the UNI does not require shared knowledge 328 of core network SRLG information. For this purpose, the concept 329 of a Path Affinity Set (PAS) is defined for abstracting SRLG 330 information. The motive behind the introduction of the PAS is to 331 minimize the exchange of diversity information between the core 332 network (CNs) and the client devices (ENs). The PAS contains an 333 abstract SRLG identifier associated with a given path rather than 334 a detailed SRLG list. The PAS is a single identifier that can be 335 used to request diversity and associate diversity. The means by 336 which the processing node determines the path corresponding to 337 the PAS is beyond the scope of this document. 339 A CN on the core network boundary interprets the specific PAS 340 identifier (e.g. "123") as meaning to exclude the core network 341 SRLG information (or equivalent) that has been allocated by LSPs 342 associated with this PAS identifier value. For example, if a Path 343 exists for the LSP with the identifier "123", the CN would use 344 local knowledge of the core network SRLGs associated with the 345 "123" LSPs and use those SRLGs as constraints for path 346 computation. If a PAS identifier is included for exclusion in the 347 connection request, the CN (UNI-N) in the core network is assumed 348 to be able to determine the existing core network SRLG 349 information and calculate a path that meets the determined 350 diversity constraints. 352 When a CN satisfies a connection setup for a (SRLG) diverse 353 signaled path, the CN may optionally record the core network SRLG 354 information for that connection in terms of CN based parameters 355 and associates that with the EN addresses in the Path message. 356 Specifically, for Layer-1 Virtual Private Networks (L1VPNs), Port 357 Information Tables (PIT) [RFC5251] can be leveraged to translate 358 between client (EN) addresses and core network addresses. 360 The means to distribute the PAS information within the core 361 network is beyond the scope of this document. For example, the 362 PAS and the associated SRLG information can be distributed within 363 the core network by an Interior Gateway Protocol (IGP) or by 364 other means such as configuration. Regardless of means used to 365 distribute the PAS information, the information is kept inside 366 core network and is not shared with the overlay network (see 367 Figure 1). 369 2. RSVP-TE signaling extensions 371 This section describes the signaling extensions required to 372 address the aforementioned requirements and use cases. 374 2.1. Diversity XRO Subobject 376 New Diversity XRO subobjects are defined below for the IPv4 and 377 IPv6 address families. Most of the fields in the IPv4 and IPv6 378 Diversity XRO subobjects are common and are described following 379 the definition of the two subobjects. 381 IPv4 Diversity XRO subobject is defined as follows: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | IPv4 Diversity Identifier Source Address | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Diversity Identifier Value | 391 // ... // 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Similarly, the IPv6 Diversity XRO subobject is defined as 395 follows: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | IPv6 Diversity Identifier source address | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | IPv6 Diversity Identifier source address (cont.) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | IPv6 Diversity Identifier source address (cont.) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | IPv6 Diversity Identifier source address (cont.) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Diversity Identifier Value | 411 // ... // 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 L: 416 The L-flag is used as for the XRO subobjects defined in 417 [RFC4874], i.e., 419 0 indicates that the attribute specified MUST be excluded. 421 1 indicates that the attribute specified SHOULD be avoided. 423 XRO Type 425 The value is set to TBA1 for the IPv4 diversity XRO 426 subobject (value to be assigned by IANA). Similarly, the 427 value is set to TBA2 for the IPv6 diversity XRO subobject 428 (value to be assigned by IANA). 430 Length 432 Per [RFC4874], the Length contains the total length of the 433 IPv4/ IPv6 subobject in bytes, including the Type and 434 Length fields. The Length is variable, depending on the 435 diversity identifier value. 437 Diversity Identifier Type (DI Type) 439 Diversity Identifier Type (DI Type) indicates the way the 440 reference LSP(s) or route(s) with which diversity is 441 required is identified in the IPv4/ IPv6 Diversity 442 subobjects. The following three DI type values are defined 443 in this document: 445 DI Type value Definition 446 ------------- -------------------------------- 447 1 Client Initiated Identifier 448 2 PCE Allocated Identifier 449 3 Network Assigned Identifier 451 Attribute Flags (A-Flags): 453 The Attribute Flags (A-Flags) are used to communicate 454 desirable attributes of the LSP being signaled in the IPv4/ 455 IPv6 Diversity subobjects. The following flags are defined. 456 Each flag acts independently. Any combination of flags is 457 permitted. 459 0x01 = Destination node exception 461 Indicates that the exclusion does not apply to the 462 destination node of the LSP being signaled. 464 0x02 = Processing node exception 466 Indicates that the exclusion does not apply to the 467 node(s) performing ERO expansion for the LSP being 468 signaled. An ingress UNI-N node is an example of such a 469 node. 471 0x04 = Penultimate node exception 473 Indicates that the penultimate node of the LSP being 474 signaled MAY be shared with the excluded path even when 475 this violates the exclusion flags. 477 0x08 = LSP ID to be ignored 479 This flag is used to indicate tunnel level exclusion. 480 Specifically, this flag is used to indicate that if 481 diversity identifier contains lsp-id field, the lsp-id 482 is to be ignored and the exclusion applies to any LSP 483 matching the rest of the diversity identifier. 485 Exclusion Flags (E-Flags): 487 The Exclusion-Flags are used to communicate the desired 488 type(s) of exclusion requested in the IPv4/ IPv6 diversity 489 subobjects. The following flags are defined. Any 490 combination of these flags is permitted. Please note that 491 the exclusion specified by these flags may be modified by 492 the value of the Attribute-flags. For example, node 493 exclusion flag is ignored for the "Penultimate node" if 494 the "Penultimate node exception" flag of the Attribute- 495 flags is set. 497 0x01 = SRLG exclusion 499 Indicates that the path of the LSP being signaled is 500 requested to be SRLG-diverse from the excluded path 501 specified by the IPv4/ IPv6 Diversity XRO subobject. 503 0x02 = Node exclusion 505 Indicates that the path of the LSP being signaled is 506 requested to be node-diverse from the excluded path 507 specified by the IPv4/ IPv6 Diversity XRO subobject. 509 0x04 = Link exclusion 511 Indicates that the path of the LSP being signaled is 512 requested to be link-diverse from the path specified 513 by the IPv4/ IPv6 Diversity XRO subobject. 515 Resvd 517 This field is reserved. It MUST be set to zero on 518 transmission, and MUST be ignored on receipt for both 519 IPv4/ IPv6 Diversity XRO subobjects. 521 IPv4 / IPv6 Diversity Identifier source address: 523 This field MUST be set to the IPv4/ IPv6 address of the 524 node that assigns the diversity identifier. Depending on 525 the diversity identifier type, the diversity identifier 526 source may be a client node, PCE entity or network node. 527 Specifically: 529 o When the diversity identifier type is set to "IPv4/ IPv6 530 Client Initiated Identifier", the value MUST be set to 531 IPv4/ IPv6 tunnel sender address of the reference LSP 532 against which diversity is desired. IPv4/ IPv6 tunnel 533 sender address is as defined in [RFC3209]. 535 o When the diversity identifier type is set to "IPv4/ IPv6 536 PCE Allocated Identifier", the value MUST be set to the 537 IPv4/ IPv6 address of the node that assigned the Path Key 538 identifier and that can return an expansion of the Path 539 Key or use the Path Key as exclusion in a path 540 computation. The Path Key is defined in [RFC5553]. The 541 PCE-ID is carried in the Identifier Source Address field 542 of the subobject. 544 o When the diversity identifier type is set to "IPv4/ IPv6 545 Network Assigned Identifier", the value MUST be set to the 546 IPv4/ IPv6 address of the node publishing the Path 547 Affinity Set (PAS). 549 Diversity Identifier Value: 551 Encoding for this field depends on the diversity identifier 552 type, as defined in the following. 554 When the diversity identifier type is set to "Client 555 Initiated Identifier" in IPv4 Diversity XRO subobject, the 556 diversity identifier value MUST be encoded as follows: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | IPv4 tunnel end point address | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Must Be Zero | Tunnel ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Extended Tunnel ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Must Be Zero | LSP ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 The IPv4 tunnel end point address, Tunnel ID, Extended 571 Tunnel ID and LSP ID are as defined in [RFC3209]. 573 When the diversity identifier type is set to "IPv6 Client 574 Initiated Identifier" in IPv6 Diversity XRO subobject, the 575 diversity identifier value MUST be encoded as follows: 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | IPv6 tunnel end point address | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | IPv6 tunnel end point address (cont.) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | IPv6 tunnel end point address (cont.) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | IPv6 tunnel end point address (cont.) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Must Be Zero | Tunnel ID | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Extended Tunnel ID | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Extended Tunnel ID (cont.) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Extended Tunnel ID (cont.) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Extended Tunnel ID (cont.) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Must Be Zero | LSP ID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended 601 Tunnel ID and LSP ID are as defined in [RFC3209]. 603 When the diversity identifier type is set to "PCE Allocated 604 Identifier" in IPv4 or IPv6 Diversity XRO subobject, the 605 diversity identifier value MUST be encoded as follows: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Must Be Zero | Path Key | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 The Path Key is defined in [RFC5553]. 615 When the diversity identifier type is set to "Network 616 Assigned Identifier" in IPv4 or IPv6 Diversity XRO 617 subobject, the diversity identifier value MUST be encoded 618 as follows: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Path Affinity Set (PAS) identifier | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 The Path Affinity Set (PAS) identifier field is a 32-bit 627 value that is scoped by, i.e., is only meaningful when 628 used in combination with, the Diversity Identifier source 629 address field. There are no restrictions on how a node 630 selects a PAS identifier value. Section 1.3 defines the 631 PAS term and provides context on how values may be 632 selected. 634 2.2. Diversity EXRS Subobject 636 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 637 identify abstract nodes or resources that must not or should not 638 be used on the path between two inclusive abstract nodes or 639 resources in the explicit route. An EXRS contains one or more 640 subobjects of its own, called EXRS subobjects [RFC4874]. 642 An EXRS MAY include Diversity subobject as specified in this 643 document. The same type values TBA1 and TBA2 SHALL be used. 645 2.3. Processing rules for the Diversity XRO and EXRS subobjects 647 The procedure defined in [RFC4874] for processing the XRO and 648 EXRS is not changed by this document. The processing rules for 649 the Diversity XRO and EXRS subobjects are similar unless the 650 differences are explicitly described. Similarly, IPv4 and IPv6 651 Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS 652 subobjects follow the same processing rules. 654 If the processing node cannot recognize the Diversity XRO/ EXRS 655 subobject, the node is expected to follow the procedure defined 656 in [RFC4874]. 658 An XRO/ EXRS object MAY contain multiple Diversity subobjects of 659 the same DI Type. E.g., in order to exclude multiple Path Keys, a 660 node MAY include multiple Diversity XRO subobjects each with a 661 different Path Key. Similarly, in order to exclude the routes 662 taken by multiple LSPs, a node MAY include multiple Diversity 663 XRO/ EXRS subobjects each with a different LSP identifier. 664 Likewise, to exclude multiple PAS identifiers, a node MAY include 665 multiple Diversity XRO/ EXRS subobjects each with a different PAS 666 identifier. However, all Diversity subobjects in an XRO/ EXRS 667 MUST contain the same Diversity Identifier Type. If a Path 668 message contains an XRO/ EXRS with multiple Diversity subobjects 669 of different DI Types, the processing node MUST return a PathErr 670 with the error code "Routing Problem" (24) and error sub-code 671 "XRO/ EXRS Too Complex" (68/ 69). 673 If the processing node recognize the Diversity XRO/ EXRS 674 subobject but does not support the DI type, it MUST return a 675 PathErr with the error code TBA3 "Routing Problem" and error 676 value of "Unsupported Diversity Identifier Type". 678 The nodes in the domain that perform path computation SHOULD 679 process the diversity information signaled in the XRO/ EXRS 680 Diversity subobjects. The transit nodes in a domain and the 681 domain egress node SHOULD NOT process the signaled diversity 682 information. While processing EXRS object, if a loose-hop 683 expansion results in the creation of another loose-hop in the 684 outgoing ERO, the processing node MAY include the EXRS in the 685 newly created loose hop for further processing by downstream 686 nodes. 688 The attribute-flags affect the processing of the Diversity XRO/ 689 EXRS subobject as follows: 691 o When the "processing node exception" flag is set, the 692 exclusion MUST be ignored for the node processing the XRO 693 or EXRS subobject. 695 o When the "destination node exception" flag is set, the 696 exclusion MUST be ignored for the destination node in 697 processing the XRO subobject. The destination node 698 exception for the EXRS subobject applies to the explicit 699 node identified by the ERO subobject that identifies the 700 next abstract node. When the "destination node exception" 701 flag is set in the EXRS subobject, exclusion MUST be 702 ignored for the said node (i.e., the next abstract node). 704 o When the "penultimate node exception" flag is set in the 705 XRO subobject, the exclusion MUST be ignored for the 706 penultimate node on the path of the LSP being established. 707 The penultimate node exception for the EXRS subobject 708 applies to the node before the explicit node identified by 709 the ERO subobject that identifies the next abstract node. 710 When the "penultimate node exception" flag is set in the 711 EXRS subobject, the exclusion MUST be ignored for the said 712 node (i.e., the node before the next abstract node). 714 If the L-flag of the diversity XRO subobject or diversity EXRS 715 subobject is not set, the processing node proceeds as follows. 717 - If the Diversity Identifier Type is set to "IPv4/IPv6 Client 718 Initiated Identifiers", the processing node MUST ensure that 719 the path calculated/ expended for the signaled LSP is diverse 720 from the route taken by the LSP identified in the Diversity 721 Identifier Value field. 723 - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE 724 Allocated Identifiers", the processing node MUST ensure that 725 any path calculated for the signaled LSP is diverse from the 726 route identified by the Path-Key. The processing node MAY use 727 the PCE identified by the IPv4/IPv6 Diversity Identifier Source 728 Address in the subobject for route computation. The processing 729 node MAY use the Path-Key resolution mechanisms described in 730 [RFC5553]. 732 - If the Diversity Identifier Type is set to "IPv4/IPv6 Network 733 Assigned Identifiers", the processing node MUST ensure that the 734 path calculated for the signaled LSP is diverse with respect to 735 the values associated with the PAS identifier and Diversity 736 Identifier source address fields. 738 - Regardless of whether the path computation is performed 739 locally or at a remote node (e.g., PCE), the processing node 740 MUST ensure that any path calculated for the signaled LSP is 741 diverse from the requested Exclusion Flags. 743 - If the excluded path referenced in the XRO subobject is 744 unknown to the processing node, the processing node SHOULD 745 ignore the diversity XRO subobject and SHOULD proceed with the 746 signaling request. After sending the Resv for the signaled LSP, 747 the processing node MUST return a PathErr with the error code 748 "Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP 749 identifier unknown" (value to be assigned by IANA) for the 750 signaled LSP. 752 - If the processing node fails to find a path that meets the 753 requested constraint, the processing node MUST return a PathErr 754 with the error code "Routing Problem" (24) and error sub-code 755 "Route blocked by Exclude Route" (67). 757 If the L-flag of the XRO diversity subobject or EXRS diversity 758 subobject is set, the processing node proceeds as follows: 760 - If the Diversity Identifier Type is set to "IPv4/IPv6 Client 761 Initiated Identifiers", the processing node SHOULD ensure that 762 the path calculated/ expended for the signaled LSP is diverse 763 from the route taken by the LSP identified in the Diversity 764 Identifier Value field. 766 - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE 767 Allocated Identifiers", the processing node SHOULD ensure that 768 the path calculated for the signaled LSP is diverse from the 769 route identified by the Path-Key. 771 - If the Diversity Identifier Type is set to "IPv4/IPv6 Network 772 Assigned Identifiers", the processing node SHOULD ensure that 773 the path calculated for the signaled LSP is diverse with 774 respect to the values associated with the PAS identifier and 775 Diversity Identifier source address fields. 777 - If the processing node fails to find a path that meets the 778 requested constraint, it SHOULD proceed with signaling using a 779 suitable path that meets the constraint as far as possible. 780 After sending the Resv for the signaled LSP, it MUST return a 781 PathErr message with error code "Notify Error" (25) and error 782 sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be 783 assigned by IANA) to the source node. 785 If, subsequent to the initial signaling of a diverse LSP, an 786 excluded path referenced in the XRO subobject becomes known to 787 the processing node, or a change in the excluded path becomes 788 known to the processing node, the processing node MUST re- 789 evaluate the exclusion and diversity constraints requested by the 790 diverse LSP to determine whether they are still satisfied. 792 If, subsequent to the initial signaling of a diverse LSP, the 793 requested exclusion constraints for the diverse LSP are no longer 794 satisfied and an alternative path for the diverse LSP that can 795 satisfy those constraints exists, then: 797 - If the L-flag was not set in the original exclusion, the 798 processing node MUST send a PathErr message for the diverse LSP 799 with the error code "Routing Problem" (24) and error sub-code 800 "Route blocked by Exclude Route" (67). The Path_State_Removed 801 flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a 802 PathErr message with this error code and sub-code combination 803 SHOULD take appropriate actions to migrate to a compliant path. 805 - If the L-flag was set in the original exclusion, the 806 processing node MUST send a PathErr message for the diverse LSP 807 with the error code "Notify Error" (25) and a new error sub- 808 code TBA6 "Compliant path exists" (value: to be assigned by 809 IANA). The PSR flag MUST NOT be set. A source node receiving a 810 PathErr message with this error code and sub-code combination 811 MAY signal a new LSP to migrate the compliant path. 813 If, subsequent to the initial signaling of a diverse LSP, the 814 requested exclusion constraints for the diverse LSP are no longer 815 satisfied and no alternative path for the diverse LSP that can 816 satisfy those constraints exists, then: 818 - If the L-flag was not set in the original exclusion, the 819 processing node MUST send a PathErr message for the diverse LSP 820 with the error code "Routing Problem" (24) and error sub-code 821 "Route blocked by Exclude Route" (67). The PSR flag MUST be 822 set. 824 - If the L-flag was set in the original exclusion, the 825 processing node MUST send a PathErr message for the diverse LSP 826 with the error code error code "Notify Error" (25) and error 827 sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be 828 assigned by IANA). The PSR flag MUST NOT be set. The source 829 node MAY take no action and keep the LSP along the non- 830 compliant path. 832 3. Security Considerations 834 This document does not introduce any additional security issues 835 above those identified in [RFC5920], [RFC2205], [RFC3209], 836 [RFC3473] and [RFC4874]. 838 The diversity mechanism defined in this document, relies on the 839 new diversity subobject that is carried in the XRO or EXRS, 840 respectively. In section 7 of [RFC4874], it is stated that the 841 XRO could be considered for removal from the Path message due to 842 security concerns for example at administrative boundaries. In 843 this case, the diversity subobject would also be removed. Hence, 844 the diversity subobject must be kept while other subobjects may 845 be removed. 847 4. IANA Considerations 849 IANA is requested to administer the assignment of new values 850 defined in this document and summarized in this section. 852 4.1. New XRO subobject types 854 IANA registry: RSVP PARAMETERS 855 Subsection: Class Names, Class Numbers, and Class Types 857 This document defines two new subobjects for the EXCLUDE_ROUTE 858 object [RFC4874], C-Type 1. (see: 859 http://www.iana.org/assignments/rsvp-parameters/rsvp- 860 parameters.xhtml#rsvp-parameters-94) 862 Subobject Description Subobject Type 863 ------------------------ -------------- 864 IPv4 Diversity subobject TBA1 865 IPv6 Diversity subobject TBA2 867 4.2. New EXRS subobject types 869 The diversity XRO subobjects are also defined as new EXRS 870 subobjects. (EXPLICIT_ROUTE see: 871 http://www.iana.org/assignments/rsvp-parameters/rsvp- 872 parameters.xhtml#rsvp-parameters-24). The same numeric subobject 873 type values TBA1 and TBA2 are being requested for the two new 874 EXRS subobjects. 876 4.3. New RSVP error sub-codes 878 IANA registry: RSVP PARAMETERS 879 Subsection: Error Codes and Globally Defined Error Value Sub- 880 Codes. 881 For Error Code "Routing Problem" (24) (see [RFC3209]) the 882 following sub-codes are defined. (see: 883 http://www.iana.org/assignments/rsvp-parameters/rsvp- 884 parameters.xhtml#rsvp-parameters-105) 886 +-------------+----------------------------+---------------+ 888 | Error Value | Description | Reference | 890 | Sub-codes | | | 892 +-------------+----------------------------+---------------+ 894 | TBA3 | Unsupported Diversity | This document | 896 | | Identifier Type | | 898 +-------------+----------------------------+---------------+ 900 For Error Code "Notify Error" (25) (see [RFC3209]) the following 901 sub-codes are defined. (see: 902 http://www.iana.org/assignments/rsvp-parameters/rsvp- 903 parameters.xhtml#rsvp-parameters-105) 904 +-------------+----------------------------+---------------+ 905 | Error Value | Description | Reference | 906 | Sub-codes | | | 907 +-------------+----------------------------+---------------+ 908 | TBA4 | Route of XRO LSP | This document | 909 | | identifier unknown | | 910 | TBA5 | Failed to satisfy | This document | 911 | | Exclude Route | | 912 | TBA6 | Compliant path exists | This document | 913 +-------------+----------------------------+---------------+ 915 5. Acknowledgements 917 The authors would like to thank Xihua Fu for his contributions. 918 The authors also would like to thank Luyuan Fang and Walid Wakim 919 for their review comments. 921 6. References 923 6.1. Normative References 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, March 1997. 928 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 929 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 930 LSP Tunnels", RFC 3209, December 2001. 932 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 933 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 934 Engineering (RSVP-TE) Extensions", RFC 3473, January 935 2003. 937 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 938 Routes - Extension to Resource ReserVation Protocol- 939 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 941 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, 942 "Resource Reservation Protocol (RSVP) Extensions for 943 Path Key Support", RFC 5553, May 2009. 945 6.2. Informative References 947 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 948 "Generalized Multiprotocol Label Switching (GMPLS) 949 User-Network Interface (UNI): Resource ReserVation 950 Protocol-Traffic Engineering (RSVP-TE) Support for the 951 Overlay Model", RFC 4208, October 2005. 953 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, 954 N., and G. Ash, "Crankback Signaling Extensions for 955 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 957 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 958 "Preserving Topology Confidentiality in Inter-Domain 959 Path Computation Using a Path-Key-Based Mechanism", RFC 960 5520, April 2009. 962 [RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria, 963 "RSVP-TE Extensions for Collecting SRLG Information", 964 RFC 8001, January 2017. 966 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 967 S. Jamin, "Resource ReserVation Protocol -- Version 1 968 Functional Specification", RFC 2205, September 1997. 970 [RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D., 971 Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode", 972 RFC 5251, July 2008. 974 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 975 Networks", RFC 5920, July 2010. 977 Contributors' Addresses 979 Igor Bryskin 980 Huawei Technologies 981 Email: Igor.Bryskin@huawei.com 983 Daniele Ceccarelli 984 Ericsson 985 Email: Daniele.Ceccarelli@ericsson.com 987 Dhruv Dhody 988 Huawei Technologies 989 Email: dhruv.ietf@gmail.com 990 Oscar Gonzalez de Dios 991 Telefonica I+D 992 Email: ogondio@tid.es 994 Don Fedyk 995 Hewlett-Packard 996 Email: don.fedyk@hp.com 998 Clarence Filsfils 999 Cisco Systems, Inc. 1000 Email: cfilsfil@cisco.com 1002 Gabriele Maria Galimberti 1003 Cisco Systems 1004 Email: ggalimbe@cisco.com 1006 Ori Gerstel 1007 SDN Solutions Ltd. 1008 Email: origerstel@gmail.com 1010 Matt Hartley 1011 Cisco Systems 1012 Email: mhartley@cisco.com 1014 Kenji Kumaki 1015 KDDI Corporation 1016 Email: ke-kumaki@kddi.com 1018 Ruediger Kunze 1019 Deutsche Telekom AG 1020 Email: Ruediger.Kunze@telekom.de 1022 Lieven Levrau 1023 Nokia 1024 Email: Lieven.Levrau@nokia.com 1026 Cyril Margaria 1027 cyril.margaria@gmail.com 1029 Julien Meuric 1030 France Telecom Orange 1031 Email: julien.meuric@orange.com 1032 Yuji Tochio 1033 Fujitsu 1034 Email: tochio@jp.fujitsu.com 1036 Xian Zhang 1037 Huawei Technologies 1038 Email: zhang.xian@huawei.com 1040 Authors' Addresses 1042 Zafar Ali 1043 Cisco Systems. 1044 Email: zali@cisco.com 1046 Dieter Beller 1047 Nokia 1048 Email: Dieter.Beller@nokia.com 1050 George Swallow 1051 Cisco Systems 1052 Email: swallow@cisco.com 1054 Fatai Zhang 1055 Huawei Technologies 1056 Email: zhangfatai@huawei.com