idnits 2.17.1 draft-ietf-teas-lsp-diversity-10.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 02, 2018) is 2245 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 03, 2018 Huawei 7 D. Beller, Ed. 8 Nokia 9 March 02, 2018 11 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 12 Diversity using Exclude Route 14 draft-ietf-teas-lsp-diversity-10.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 03, 2018. 33 Copyright Notice 35 Copyright (c) 2018 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 label switched 52 path (LSP) setup. A typical LSP diversity use case is for 53 protection, where two LSPs should follow different paths through the 54 network in order to avoid single points of failure, thus greatly 55 improving service availability. This document specifies an approach 56 which can be used for network scenarios where full knowledge of the 57 path(s) is not necessarily known by use of an abstract identifier 58 for the path. Three types of abstract identifiers are specified: 59 client-based, Path Computation Engine (PCE)-based, network-based. 60 This document specifies two new diversity subobjects for the RSVP 61 eXclude Route Object (XRO) and the Explicit Exclusion Route 62 Subobject (EXRS). 64 For the protection use case, LSPs are typically created at a slow 65 rate and exist for a long time, so that it is reasonable to assume 66 that a given (reference) path currently existing, with a well-known 67 identifier, will continue to exist and can be used as a reference 68 when creating the new diverse path. Re-routing of the existing 69 (reference)LSP, before the new path is established, is not 70 considered. 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 Table of Contents 80 Terms and Abbreviations..........................................3 81 1. Introduction..................................................3 82 1.1. Client-Initiated Identifier..............................6 83 1.2. PCE-allocated Identifier.................................7 84 1.3. Network-Assigned Identifier..............................8 85 2. RSVP-TE signaling extensions.................................10 86 2.1. Diversity XRO Subobject.................................10 87 2.2. Diversity EXRS Subobject................................17 88 2.3. Processing rules for the Diversity XRO and EXRS 89 subobjects..............................................17 90 3. Security Considerations......................................21 91 4. IANA Considerations..........................................22 92 4.1. New XRO subobject types.................................22 93 4.2. New EXRS subobject types................................22 94 4.3. New RSVP error sub-codes................................22 96 5. Acknowledgements.............................................23 97 6. References...................................................23 98 6.1. Normative References....................................23 99 6.2. Informative References..................................24 101 Terms and Abbreviations 103 Diverse LSP: a diverse Label-Switched Path (LSP) is an LSP that 104 has a path that does not have any link or SRLG in common with the 105 path of a given LSP. Diverse LSPs are meaningful in the context 106 of protection or restoration. 108 ERO: Explicit Route Object as defined in [RFC3209] 110 EXRS: Explicit eXclusion Route Subobject as defined in [RFC4874] 112 SRLG: Shared Risk Link Group as defined in [RFC4202] 114 Reference Path: the reference path is the path of an existing 115 LSP, to which the path of a diverse LSP shall be diverse. 117 XRO: eXclude Route Object as defined in [RFC4874] 119 1. Introduction 121 Path diversity for multiple connections is a well-known 122 operational requirement. Diversity constraints ensure that Label- 123 Switched Paths (LSPs) can be established without sharing network 124 resources, thus greatly reducing the probability of simultaneous 125 connection failures. 127 The source node can compute diverse paths for LSPs when it has 128 full knowledge of the network topology and is permitted to signal 129 an Explicit Route Object (ERO). However, there are scenarios where 130 different nodes perform path computations, and therefore there is 131 a need for relevant diversity constraints to be signaled to those 132 nodes. These include (but are not limited to): 134 . LSPs with loose hops in the Explicit Route Object, e.g. inter- 135 domain LSPs. 137 . Generalized Multi-Protocol Label Switching (GMPLS) User- 138 Network Interface (UNI), where the core node may perform path 139 computation [RFC4208]. 141 [RFC4874] introduced a means of specifying nodes and resources to 142 be excluded from a route, using the eXclude Route Object (XRO) and 143 Explicit Exclusion Route Subobject (EXRS). It facilitates the 144 calculation of diverse paths for LSPs based on known properties of 145 those paths including addresses of links and nodes traversed, and 146 Shared Risk Link Groups (SRLGs) of traversed links. Employing 147 these mechanisms requires that the source node that initiates 148 signaling knows the relevant properties of the path(s) from which 149 diversity is desired. However, there are circumstances under which 150 this may not be possible or desirable, including (but not limited 151 to): 153 . Exclusion of a path which does not originate, terminate or 154 traverse the source node of the diverse LSP, in which case the 155 addresses of links and SRLGs of the path from which diversity 156 is required are unknown to the source node. 158 . Exclusion of a path which is known to the source node of the 159 diverse LSP for which the node has incomplete or no path 160 information, e.g. due to operator policy. In this case, the 161 source node is aware of the existence of the reference path but 162 the information required to construct an XRO object to 163 guarantee diversity from the reference path is not fully known. 164 Inter-domain and GMPLS overlay networks can impose such 165 restrictions. 167 This is illustrated in the Figure 1, where the overlay reference 168 model from [RFC4208] is shown. 170 Overlay Overlay 171 Network +----------------------------------+ Network 172 +---------+ | | +---------+ 173 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 174 | | | | UNI | | | | | | | | UNI | | | | 175 | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 176 | | | | +--+--+ | | | | | | +---+-| | | 177 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 178 +---------+ | | | | | | | +---------+ 179 | | | | | | | 180 +---------+ | | +--+--+ | +--+--+ | | +---------+ 181 | +----+ | | | | | +-------+ +-----+ | +----+ | 182 | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | 183 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 184 | | | | UNI | +-----+ +-----+ | UNI | | | | 185 | +----+ | | | | +----+ | 186 +---------+ +----------------------------------+ +---------+ 187 Overlay Core Network Overlay 188 Network Network 190 Legend: EN - Edge Node 191 CN - Core Node 193 Figure 1: Overlay Reference Model [RFC4208] 195 Figure 1 depicts two types of UNI connectivity: single-homed and 196 dual-homed ENs (which also applies to higher order multi-homed 197 connectivity). Single-homed EN devices are connected to a single 198 CN device via a single UNI link. This single UNI link may 199 constitute a single point of failure. UNI connection between EN1 200 and CN1 is an example of singled-homed UNI connectivity. 202 Such a single point of failure can be avoided when the EN device 203 is connected to two different CN devices, as depicted for EN2 in 204 Figure 1. For the dual-homing case, it is possible to establish 205 two different UNI connections from the same source EN device to 206 the same destination EN device. For example, two connections from 207 EN2 to EN3 may use the two UNI links EN2-CN1 and EN2-CN4. To 208 avoid single points of failure within the provider network, it is 209 necessary to also ensure path (LSP) diversity within the core 210 network. 212 In a network providing a set of UNI interfaces between ENs and 213 CNs such as that shown in Figure 1, the CNs typically perform 214 path computation. Information sharing across the UNI boundary is 215 restricted based on the policy rules imposed by the core network. 216 Typically, the core network topology information as well as LSP 217 path information is not exposed to the ENs. In the network shown 218 in Figure 1, consider a use case where an LSP from EN2 to EN4 219 needs to be SRLG diverse from an LSP from EN1 to EN3. In this 220 case, EN2 may not know SRLG attributes of the EN1- EN3 LSP and 221 hence cannot construct an XRO to exclude these SRLGs. In this 222 example EN2 cannot use the procedures described in [RFC4874]. 223 Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be 224 diverse from an LSP from EN2 to EN3 going via CN4. Again, in this 225 case, exclusions based on [RFC4874] cannot be used. 227 This document addresses these diversity requirements by 228 introducing an approach of excluding the path taken by these 229 particular LSP(s). The reference LSP(s) or route(s) from which 230 diversity is required is/are identified by an abstract 231 "identifier". The type of identifier to use is highly dependent 232 on the core network operator's networking deployment scenario; it 233 could be client-initiated (provided by the EN), provided by a PCE 234 or allocated by the (core) network. This document defines three 235 different types of identifiers corresponding to these three 236 cases: a client-initiated identifier, a PCE allocated identifier 237 and CN ingress node (UNI-N) allocated identifier (= network- 238 assigned identifier). 240 1.1. Client-Initiated Identifier 242 The following fields MUST be used to represent the client- 243 initiated identifier: IPv4/IPv6 tunnel sender address, 244 IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended 245 Tunnel ID. Based on local policy, the client MAY also include 246 the LSP ID to identify a specific LSP within the tunnel. These 247 fields are defined in [RFC3209], sections 4.6.1.1 and 4.6.2.1. 249 The usage of the client-initiated identifier is illustrated by 250 Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with 251 respect to a LSP from EN1 to EN3. The LSP identifier of the EN1- 252 EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by 253 the tuple (tunnel-id = T1, LSP ID = L1, source address = EN1.RID 254 (ROUTE Identifier), destination address = EN3.RID, extended 255 tunnel-id = EN1.RID). Similarly, LSP identifier of the EN2-EN4 256 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER2 is defined by the 257 tuple (tunnel-id = T2, LSP ID = L2, source address = EN2.RID, 258 destination address = EN4.RID, extended tunnel-id = EN2.RID). The 259 EN1-EN3 LSP is signaled with an exclusion requirement from LSP- 260 IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion 261 requirement from LSP-IDENTIFIER1. In order to maintain diversity 262 between these two connections within the core network, the core 263 network SHOULD implement Crankback Signaling Extensions as 264 defined in [RFC4920]. Note that crankback signaling is known to 265 lead to slower setup times and sub-optimal paths under some 266 circumstances as described by [RFC4920]. 268 1.2. PCE-allocated Identifier 270 In scenarios where a PCE is deployed and used to perform path 271 computation, the core edge node (e.g., node CN1 in Figure 1) 272 could consult a PCE to allocate identifiers, which are used to 273 signal path diversity constraints. In other deployment scenarios, 274 a PCE is deployed at a network node(s) or a PCE is part of a 275 Network Management System (NMS). In all these cases, the PCE is 276 consulted and the Path-Key as defined in [RFC5520] can be used in 277 RSVP signaling as the identifier to ensure diversity. 279 An example of specifying LSP diversity using a Path-Key is shown 280 in Figure 2, where a simple network with two domains is shown. It 281 is desired to set up a pair of path-disjoint LSPs from the source 282 in Domain 1 to the destination in Domain 2, but the domains keep 283 strict confidentiality about all path and topology information. 285 The first LSP is signaled by the source with ERO {A, B, loose Dst} 286 and is set up with the path {Src, A, B, U, V, W, Dst}. However, 287 when sending the Record Route Object (RRO) out of Domain 2, node 288 U would normally strip the path and replace it with a loose hop 289 to the destination. With this limited information, the source is 290 unable to include enough detail in the ERO of the second LSP to 291 avoid it taking, for example, the path {Src, C, D, X, V, W, Dst} 292 for path-disjointness. 294 --------------------- ----------------------------- 295 | Domain 1 | | Domain 2 | 296 | | | | 297 | --- --- | | --- --- --- | 298 | | A |--| B |--+--+--| U |--| V |---| W | | 299 | / --- --- | | --- --- --- \ | 300 | ---/ | | / / \--- | 301 | |Src| | | / / |Dst| | 302 | ---\ | | / / /--- | 303 | \ --- --- | | --- / --- / --- / | 304 | | C |--| D |--+--+--| X |---| Y |--| Z | | 305 | --- --- | | --- --- --- | 306 | | | | 307 --------------------- ----------------------------- 309 Figure 2: A Simple Multi-Domain Network 311 In order to support LSP diversity, node U consults the PCE and 312 replaces the path segment {U, V, W} in the RRO with a Path Key 313 subobject. The PCE function assigns an "identifier" and puts it 314 into the Path Key field of the Path Key subobject. The PCE ID in 315 the message indicates that this replacement operation was 316 performed by node U. 318 With this additional information, the source node is able to 319 signal the subsequent LSPs with the ERO set to {C, D, exclude 320 Path Key(EXRS), loose Dst}. When the signaling message reaches 321 node X, it can consult the PCE function associated with node U to 322 expand the Path Key in order to calculate a path that is diverse 323 with respect to the first LSP. Alternatively, the source node 324 could use an ERO of {C, D, loose Dst} and include an XRO 325 containing the Path Key. 327 This mechanism can work with all the Path Key resolution 328 mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co- 329 located or not, may be used to resolve the Path Key, but the node 330 (i.e., a Label Switching Router (LSR)) can also use the Path Key 331 information to index a Path Segment previously supplied to it by 332 the entity that originated the Path Key, for example the LSR that 333 inserted the Path Key in the RRO or a management system. 335 1.3. Network-Assigned Identifier 337 There are scenarios in which the network provides diversity- 338 related information for a service that allows the client device 339 to include this information in the signaling message. If the 340 Shared Resource Link Group (SRLG) identifier information is both 341 available and shareable (by policy) with the ENs, the procedure 342 defined in [RFC8001] can be used to collect SRLG identifiers 343 associated with an LSP (LSP1). When a second LSP (LSP2) needs to 344 be diverse with respect to LSP1, the EN constructing the RSVP 345 signaling message for setting up LSP2 can insert the SRLG 346 identifiers associated with LSP1 as diversity constraints into 347 the XRO using the procedure described in [RFC4874]. However, if 348 the core network SRLG identifiers are either not available or not 349 shareable with the ENs based on policies enforced by core 350 network, existing mechanisms cannot be used. 352 In this draft, a signaling mechanism is defined where information 353 signaled to the CN via the UNI does not require shared knowledge 354 of core network SRLG information. For this purpose, the concept 355 of a Path Affinity Set (PAS) is defined for abstracting SRLG 356 information. The motive behind the introduction of the PAS is to 357 minimize the exchange of diversity information between the core 358 network (CNs) and the client devices (ENs). The PAS contains an 359 abstract SRLG identifier associated with a given path rather than 360 a detailed SRLG list. The PAS is a single identifier that can be 361 used to request diversity and associate diversity. The means by 362 which the processing node determines the path corresponding to 363 the PAS is beyond the scope of this document. 365 A CN on the core network boundary interprets the specific PAS 366 identifier (e.g. "123") as meaning to exclude the core network 367 SRLG information (or equivalent) that has been allocated by LSPs 368 associated with this PAS identifier value. For example, if a Path 369 exists for the LSP with the PAS identifier "123", the CN would 370 use local knowledge of the core network SRLGs associated with the 371 LSPs tagged with PAS attribute "123" and use those SRLGs as 372 constraints for path computation. If a PAS identifier is used as 373 an exclusion identifier in the connection request, the CN (UNI-N) 374 in the core network is assumed to be able to determine the 375 existing core network SRLG information and calculate a path that 376 meets the determined diversity constraints. 378 When a CN satisfies a connection setup for a (SRLG) diverse 379 signaled path, the CN may optionally record the core network SRLG 380 information for that connection in terms of CN based parameters 381 and associates that with the EN addresses in the Path message. 382 Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port 383 Information Tables (PIT) [RFC5251] can be leveraged to translate 384 between client (EN) addresses and core network addresses. 386 The means to distribute the PAS information within the core 387 network is beyond the scope of this document. For example, the 388 PAS and the associated SRLG information can be distributed within 389 the core network by an Interior Gateway Protocol (IGP) or by 390 other means such as configuration. Regardless of means used to 391 distribute the PAS information, the information is kept inside 392 the core network and is not shared with the overlay network (see 393 Figure 1). 395 2. RSVP-TE signaling extensions 397 This section describes the signaling extensions required to 398 address the aforementioned requirements and use cases. 400 2.1. Diversity XRO Subobject 402 New Diversity XRO subobjects are defined below for the IPv4 and 403 IPv6 address families. Most of the fields in the IPv4 and IPv6 404 Diversity XRO subobjects are common and are described following 405 the definition of the two subobjects. 407 IPv4 Diversity XRO subobject is defined as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | IPv4 Diversity Identifier Source Address | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Diversity Identifier Value | 417 // ... // 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Similarly, the IPv6 Diversity XRO subobject is defined as 421 follows: 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | IPv6 Diversity Identifier source address | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | IPv6 Diversity Identifier source address (cont.) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | IPv6 Diversity Identifier source address (cont.) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | IPv6 Diversity Identifier source address (cont.) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Diversity Identifier Value | 437 // ... // 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 L: 442 The L-flag is used in the same way as for the XRO 443 subobjects defined in [RFC4874], i.e., 445 0 indicates that the diversity constraints MUST be 446 satisfied. 448 1 indicates that the diversity constraints SHOULD be 449 satisfied. 451 XRO Type 453 The value is set to TBA1 for the IPv4 Diversity XRO 454 subobject (value to be assigned by IANA). The value is set 455 to TBA2 for the IPv6 Diversity XRO subobject (value to be 456 assigned by IANA). 458 Length 459 Per [RFC4874], the Length contains the total length of the 460 IPv4/IPv6 subobject in bytes, including the XRO Type and 461 Length fields. The Length is variable, depending on the 462 diversity identifier value. 464 Diversity Identifier Type (DI Type) 466 Diversity Identifier Type (DI Type) indicates the way the 467 reference LSP(s) or route(s) with which diversity is 468 required is identified in the IPv4/IPv6 Diversity 469 subobjects. The following three DI type values are defined 470 in this document: 472 DI Type value Definition 473 ------------- -------------------------------- 474 1 Client Initiated Identifier 475 2 PCE Allocated Identifier 476 3 Network Assigned Identifier 478 Attribute Flags (A-Flags): 480 The Attribute Flags (A-Flags) are used to communicate 481 desirable attributes of the LSP being signaled in the IPv4/ 482 IPv6 Diversity subobjects. Each flag acts independently. 483 Any combination of flags is permitted. 485 0x01 = Destination node exception 487 Indicates that the exclusion does not apply to the 488 destination node of the LSP being signaled. 490 0x02 = Processing node exception 492 Indicates that the exclusion does not apply to the 493 node(s) performing ERO expansion for the LSP being 494 signaled. An ingress UNI-N node is an example of such a 495 node. 497 0x04 = Penultimate node exception 499 Indicates that the penultimate node of the LSP being 500 signaled MAY be shared with the excluded path even when 501 this violates the exclusion flags. This flag is useful, 502 for example, when an EN is not dual-homed (like EN4 in 503 Figure 1 where all LSPs have to go through CN5). 505 The penultimate node exception flag is typically set 506 when the destination node is single homed (e.g. EN1 or 507 EN4 in Figure 1). In such a case, LSP diversity can only 508 be accomplished inside the core network up to the egress 509 node and the penultimate hop must be the same for the 510 LSPs. 512 0x08 = LSP ID to be ignored 514 This flag is used to indicate tunnel level exclusion. 515 Specifically, this flag is used to indicate that if 516 diversity identifier contains LSP ID field, the LSP ID 517 is to be ignored and the exclusion applies to any LSP 518 matching the rest of the diversity identifier. 520 Exclusion Flags (E-Flags): 522 The Exclusion Flags are used to communicate the desired 523 type(s) of exclusion requested in the IPv4/IPv6 diversity 524 subobjects. The following flags are defined. Any 525 combination of these flags is permitted. Please note that 526 the exclusion specified by these flags may be modified by 527 the value of the Attribute-flags. For example, node 528 exclusion flag is ignored for the "Penultimate node" if 529 the "Penultimate node exception" flag of the Attribute- 530 flags is set. 532 0x01 = SRLG exclusion 534 Indicates that the path of the LSP being signaled is 535 requested to be SRLG disjoint with respect to the 536 excluded path specified by the IPv4/IPv6 Diversity 537 XRO subobject. 539 0x02 = Node exclusion 541 Indicates that the path of the LSP being signaled is 542 requested to be node-diverse from the excluded path 543 specified by the IPv4/IPv6 Diversity XRO subobject. 545 0x04 = Link exclusion 546 Indicates that the path of the LSP being signaled is 547 requested to be link-diverse from the path specified 548 by the IPv4/IPv6 Diversity XRO subobject. 550 0x08 = reserved 552 This flag is reserved. It MUST be set to zero on 553 transmission, and MUST be ignored on receipt for both 554 IPv4/IPv6 Diversity XRO subobjects. 556 Resvd 558 This field is reserved. It MUST be set to zero on 559 transmission, and MUST be ignored on receipt for both 560 IPv4/IPv6 Diversity XRO subobjects. 562 IPv4 / IPv6 Diversity Identifier source address: 564 This field MUST be set to the IPv4/IPv6 address of the node 565 that assigns the diversity identifier. Depending on the 566 diversity identifier type, the diversity identifier source 567 may be a client node, PCE entity or network node. 568 Specifically: 570 o When the diversity identifier type is set to "IPv4/IPv6 571 Client Initiated Identifier", the value MUST be set to 572 IPv4/IPv6 tunnel sender address of the reference LSP 573 against which diversity is desired. IPv4/IPv6 tunnel 574 sender address is as defined in [RFC3209]. 576 o When the diversity identifier type is set to "IPv4/IPv6 577 PCE Allocated Identifier", the value MUST be set to the 578 IPv4/IPv6 address of the node that assigned the Path Key 579 identifier and that can return an expansion of the Path 580 Key or use the Path Key as exclusion in a path 581 computation. The Path Key is defined in [RFC5553]. The 582 PCE-ID is carried in the Diversity Identifier Source 583 Address field of the subobject. 585 o When the diversity identifier type is set to "IPv4/IPv6 586 Network Assigned Identifier", the value MUST be set to the 587 IPv4/IPv6 address of the node allocating the Path Affinity 588 Set (PAS). 590 Diversity Identifier Value: 592 Encoding for this field depends on the diversity identifier 593 type, as defined in the following. 595 When the diversity identifier type is set to "Client 596 Initiated Identifier" in the IPv4 Diversity XRO subobject, 597 the diversity identifier value MUST be encoded as follows: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | IPv4 tunnel end point address | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Must Be Zero | Tunnel ID | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Extended Tunnel ID | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Must Be Zero | LSP ID | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 The IPv4 tunnel end point address, Tunnel ID, Extended 612 Tunnel ID and LSP ID are as defined in [RFC3209]. 614 When the diversity identifier type is set to "Client 615 Initiated Identifier" in the IPv6 Diversity XRO subobject, 616 the diversity identifier value MUST be encoded as follows: 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | IPv6 tunnel end point address | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | IPv6 tunnel end point address (cont.) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | IPv6 tunnel end point address (cont.) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | IPv6 tunnel end point address (cont.) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Must Be Zero | Tunnel ID | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Extended Tunnel ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Extended Tunnel ID (cont.) | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Extended Tunnel ID (cont.) | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Extended Tunnel ID (cont.) | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Must Be Zero | LSP ID | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended 643 Tunnel ID and LSP ID are as defined in [RFC3209]. 645 When the diversity identifier type is set to "PCE Allocated 646 Identifier" in IPv4 or IPv6 Diversity XRO subobject, the 647 diversity identifier value MUST be encoded as follows: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Must Be Zero | Path Key | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 The Path Key is defined in [RFC5553]. 657 When the diversity identifier type is set to "Network 658 Assigned Identifier" in IPv4 or IPv6 Diversity XRO 659 subobject, the diversity identifier value MUST be encoded 660 as follows: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Path Affinity Set (PAS) identifier | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 The Path Affinity Set (PAS) identifier field is a 32-bit 669 value that is scoped by, i.e., is only meaningful when 670 used in combination with, the Diversity Identifier source 671 address field. There are no restrictions on how a node 672 selects a PAS identifier value. Section 1.3 defines the 673 PAS term and provides context on how values may be 674 selected. 676 2.2. Diversity EXRS Subobject 678 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 679 identify abstract nodes or resources that must not or should not 680 be used on the path between two inclusive abstract nodes or 681 resources in the explicit route. An EXRS contains one or more 682 subobjects of its own, called EXRS subobjects [RFC4874]. 684 An EXRS MAY include a Diversity subobject as specified in this 685 document. The same type values TBA1 and TBA2 MUST be used. 687 2.3. Processing rules for the Diversity XRO and EXRS subobjects 689 The procedure defined in [RFC4874] for processing the XRO and 690 EXRS is not changed by this document. The processing rules for 691 the Diversity XRO and EXRS subobjects are similar unless the 692 differences are explicitly described. Similarly, IPv4 and IPv6 693 Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS 694 subobjects follow the same processing rules. 696 If the processing node cannot recognize the Diversity XRO/EXRS 697 subobject, the node is expected to follow the procedure defined 698 in [RFC4874]. 700 An XRO/EXRS object MAY contain multiple Diversity subobjects of 701 the same DI Type. E.g., in order to exclude multiple Path Keys, a 702 node MAY include multiple Diversity XRO subobjects each with a 703 different Path Key. Similarly, in order to exclude the routes 704 taken by multiple LSPs, a node MAY include multiple Diversity 705 XRO/EXRS subobjects each with a different LSP identifier. 706 Likewise, to exclude multiple PAS identifiers, a node MAY include 707 multiple Diversity XRO/EXRS subobjects each with a different PAS 708 identifier. However, all Diversity subobjects in an XRO/EXRS MUST 709 contain the same Diversity Identifier Type. If a Path message 710 contains an XRO/EXRS with multiple Diversity subobjects of 711 different DI Types, the processing node MUST return a PathErr 712 with the error code "Routing Problem" (24) and error sub-code 713 "XRO/EXRS Too Complex" (68/69). 715 If the processing node recognizes the Diversity XRO/EXRS 716 subobject but does not support the DI type, it MUST return a 717 PathErr with the error code "Routing Problem" (24) and error sub- 718 code "Unsupported Diversity Identifier Type" (TBA3). 720 In case of DI type "Client Initiated Identifier", all nodes along 721 the path SHOULD process the diversity information signaled in the 722 XRO/EXRS Diversity subobjects to verify that the signaled 723 diversity constraint is satisfied. If a diversity violation is 724 detected, crankback signaling MAY be initiated. 726 In case of DI type "PCE Allocated Identifier" and "Network 727 Assigned Identifier", the nodes in the domain that perform path 728 computation SHOULD process the diversity information signaled in 729 the XRO/EXRS Diversity subobjects as follows. In the PCE case, 730 the ingress node of a domain sends a path computation request for 731 a path from ingress node to egress node including diversity 732 constraints to a PCE. Or,in the PAS case, the ingress node is 733 capable to calculate the path for the new LSP from ingress node 734 to the egress node taking the diversity constraints into account. 735 The calculated path is then carried in the explicit route object 736 (ERO). Hence, the transit nodes in a domain and the domain egress 737 node SHOULD NOT process the signaled diversity information unless 738 path computation is performed. 740 While processing EXRS object, if a loose hop expansion results in 741 the creation of another loose hop in the outgoing ERO, the 742 processing node MAY include the EXRS in the newly created loose 743 hop for further processing by downstream nodes. 745 The Attribute-flags affect the processing of the Diversity 746 XRO/EXRS subobject as follows: 748 o When the "Processing node exception" flag is set, the 749 exclusion MUST be ignored for the node processing the XRO 750 or EXRS subobject. 752 o When the "Destination node exception" flag is set, the 753 exclusion MUST be ignored for the destination node in 754 processing the XRO subobject. The destination node 755 exception for the EXRS subobject applies to the explicit 756 node identified by the ERO subobject that identifies the 757 next abstract node. When the "destination node exception" 758 flag is set in the EXRS subobject, exclusion MUST be 759 ignored for the said node (i.e., the next abstract node). 761 o When the "Penultimate node exception" flag is set in the 762 XRO subobject, the exclusion MUST be ignored for the 763 penultimate node on the path of the LSP being established. 765 The penultimate node exception for the EXRS subobject 766 applies to the node before the explicit node identified by 767 the ERO subobject that identifies the next abstract node. 768 When the "penultimate node exception" flag is set in the 769 EXRS subobject, the exclusion MUST be ignored for the said 770 node (i.e., the node before the next abstract node). 772 If the L-flag of the Diversity XRO subobject or Diversity EXRS 773 subobject is not set, the processing node proceeds as follows. 775 - If the Diversity Identifier Type is set to "Client Initiated 776 Identifier", the processing node MUST ensure that the path 777 calculated/expanded for the signaled LSP is diverse from the 778 route taken by the LSP identified in the Diversity Identifier 779 Value field. 781 - If the Diversity Identifier Type is set to "PCE Allocated 782 Identifier", the processing node MUST ensure that any path 783 calculated for the signaled LSP is diverse from the route 784 identified by the Path Key. The processing node MAY use the PCE 785 identified by the Diversity Identifier Source Address in the 786 subobject for route computation. The processing node MAY use 787 the Path Key resolution mechanisms described in [RFC5553]. 789 - If the Diversity Identifier Type is set to "Network Assigned 790 Identifier", the processing node MUST ensure that the path 791 calculated for the signaled LSP is diverse with respect to the 792 values associated with the PAS identifier and Diversity 793 Identifier source address fields. 795 - Regardless of whether the path computation is performed 796 locally or at a remote node (e.g., PCE), the processing node 797 MUST ensure that any path calculated for the signaled LSP is 798 diverse from the requested Exclusion Flags. 800 - If the excluded path referenced in the XRO subobject is 801 unknown to the processing node, the processing node SHOULD 802 ignore the Diversity XRO subobject and SHOULD proceed with the 803 signaling request. After sending the Resv for the signaled LSP, 804 the processing node MUST return a PathErr with the error code 805 "Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP 806 identifier unknown" (value to be assigned by IANA) for the 807 signaled LSP. 809 - If the processing node fails to find a path that meets the 810 requested constraint, the processing node MUST return a PathErr 811 with the error code "Routing Problem" (24) and error sub-code 812 "Route blocked by Exclude Route" (67). 814 If the L-flag of the Diversity XRO subobject or Diversity EXRS 815 subobject is set, the processing node proceeds as follows: 817 - If the Diversity Identifier Type is set to " Client Initiated 818 Identifiers", the processing node SHOULD ensure that the path 819 calculated/ expended for the signaled LSP is diverse from the 820 route taken by the LSP identified in the Diversity Identifier 821 Value field. 823 - If the Diversity Identifier Type is set to " PCE Allocated 824 Identifiers", the processing node SHOULD ensure that the path 825 calculated for the signaled LSP is diverse from the route 826 identified by the Path Key. 828 - If the Diversity Identifier Type is set to "IPv4/IPv6 Network 829 Assigned Identifiers", the processing node SHOULD ensure that 830 the path calculated for the signaled LSP is diverse with 831 respect to the values associated with the PAS identifier and 832 Diversity Identifier source address fields. 834 - If the processing node fails to find a path that meets the 835 requested constraint, it SHOULD proceed with signaling using a 836 suitable path that meets the constraint as far as possible. 837 After sending the Resv for the signaled LSP, it MUST return a 838 PathErr message with error code "Notify Error" (25) and error 839 sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be 840 assigned by IANA) to the source node. 842 If, subsequent to the initial signaling of a diverse LSP, an 843 excluded path referenced in the XRO subobject becomes known to 844 the processing node, or a change in the excluded path becomes 845 known to the processing node, the processing node MUST re- 846 evaluate the exclusion and diversity constraints requested by the 847 diverse LSP to determine whether they are still satisfied. 849 - In case the L-flag was not set in the initial setup message, 850 the exclusion and diversity constraints were satisfied at the 851 time of the initial setup. If the processing node re-evaluating 852 the exclusion and diversity constraints for a diverse LSP 853 detects that the exclusion and diversity constraints are no 854 longer met, it MUST send a PathErr message for the diverse LSP 855 with the error code "Routing Problem" (24) and error sub-code 856 "Route blocked by Exclude Route" (67). The Path_State_Removed 857 flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a 858 PathErr message with this error code and sub-code combination 859 SHOULD take appropriate actions and move the diverse LSP to a 860 new path that meets the original constraints. 862 - In case the L-flag was set in the initial setup message, the 863 exclusion and diversity constraints may or may not be satisfied 864 at any given time. If the exclusion constraints for a diverse 865 LSP were satisfied before and if the processing node re- 866 evaluating the exclusion and diversity constraints for a 867 diverse LSP detects that exclusion and diversity constraints 868 are no longer met, it MUST send a PathErr message for the 869 diverse LSP with the error code error code "Notify Error" (25) 870 and error sub-code TBA5 "Failed to satisfy Exclude Route" 871 (value: to be assigned by IANA). The PSR flag MUST NOT be set. 872 The source node MAY take no consequent action and keep the LSP 873 along the path that does not meet the original constraints. 874 Similarly, if the exclusion constraints for a diverse LSP were 875 not satisfied before and if the processing node re-evaluating 876 the exclusion and diversity constraints for a diverse LSP 877 detects that the exclusion constraints are met, it MUST send a 878 PathErr message for the diverse LSP with the error code "Notify 879 Error" (25) and a new error sub- code TBA6 "Compliant path 880 exists" (value: to be assigned by IANA). The PSR flag MUST NOT 881 be set. A source node receiving a PathErr message with this 882 error code and sub-code combination MAY move the diverse LSP to 883 a new path that meets the original constraints. 885 3. Security Considerations 887 This document does not introduce any additional security issues 888 in addition to those identified in [RFC5920], [RFC2205], 889 [RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and 890 [RFC5553]. 892 The diversity mechanisms defined in this document, rely on the 893 new diversity subobject that is carried in the XRO or EXRS, 894 respectively. In section 7 of [RFC4874], it is noted some 895 administrative boundaries may remove the XRO due to security 896 concerns on explicit route information exchange. However, when 897 the diversity subobjects specified in this document are used, 898 removing at the administrative boundary an XRO containing these 899 diversity subobjects would result in the request for diversity 900 being dropped at the boundary, and path computation would be 901 unlikely to produce the requested diverse path. As such, 902 diversity subobjects MUST be retained in an XRO crossing an 903 administrative boundary, even if other subobjects are removed. 904 This retention would be based on operator policy. The use of 905 diversity subobjects are based on mutual agreement. This avoids 906 the need to share the identity of network resources when 907 supporting diversity. 909 4. IANA Considerations 911 IANA is requested to administer the assignment of new values 912 defined in this document and summarized in this section. 914 4.1. New XRO subobject types 916 IANA registry: RSVP PARAMETERS 917 Subsection: Class Names, Class Numbers, and Class Types 919 This document defines two new subobjects for the EXCLUDE_ROUTE 920 object [RFC4874], C-Type 1. (see: 921 http://www.iana.org/assignments/rsvp-parameters/rsvp- 922 parameters.xhtml#rsvp-parameters-94) 924 +--------------------------+----------------+ 925 | Subobject Description | Subobject Type | 926 +--------------------------+----------------+ 927 | IPv4 Diversity subobject | TBA1 | 928 | IPv6 Diversity subobject | TBA2 | 929 +--------------------------+----------------+ 931 4.2. New EXRS subobject types 933 The Diversity XRO subobjects are also defined as new EXRS 934 subobjects. (EXPLICIT_ROUTE see: 935 http://www.iana.org/assignments/rsvp-parameters/rsvp- 936 parameters.xhtml#rsvp-parameters-24). The same numeric subobject 937 type values TBA1 and TBA2 are being requested for the two new 938 EXRS subobjects. 940 4.3. New RSVP error sub-codes 942 IANA registry: RSVP PARAMETERS 943 Subsection: Error Codes and Globally Defined Error Value Sub- 944 Codes. 946 For Error Code "Routing Problem" (24) (see [RFC3209]) the 947 following sub-codes are defined. (see: 948 http://www.iana.org/assignments/rsvp-parameters/rsvp- 949 parameters.xhtml#rsvp-parameters-105) 951 +-------------+----------------------------+---------------+ 952 | Error Value | Description | Reference | 953 | Sub-codes | | | 954 +-------------+----------------------------+---------------+ 955 | TBA3 | Unsupported Diversity | This document | 956 | | Identifier Type | | 957 +-------------+----------------------------+---------------+ 959 For Error Code "Notify Error" (25) (see [RFC3209]) the following 960 sub-codes are defined. (see: 961 http://www.iana.org/assignments/rsvp-parameters/rsvp- 962 parameters.xhtml#rsvp-parameters-105) 964 +-------------+----------------------------+---------------+ 965 | Error Value | Description | Reference | 966 | Sub-codes | | | 967 +-------------+----------------------------+---------------+ 968 | TBA4 | Route of XRO LSP | This document | 969 | | identifier unknown | | 970 | TBA5 | Failed to satisfy | This document | 971 | | Exclude Route | | 972 | TBA6 | Compliant path exists | This document | 973 +-------------+----------------------------+---------------+ 975 5. Acknowledgements 977 The authors would like to thank Xihua Fu for his contributions. 978 The authors also would like to thank Luyuan Fang and Walid Wakim 979 for their review comments. 981 6. References 983 6.1. Normative References 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, March 1997. 988 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 989 S. Jamin, "Resource ReserVation Protocol -- Version 1 990 Functional Specification", RFC 2205, September 1997. 992 [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP 993 Cryptographic Authentication", RFC 2747, January 2000. 995 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 996 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 997 LSP Tunnels", RFC 3209, December 2001. 999 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1000 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1001 Engineering (RSVP-TE) Extensions", RFC 3473, January 1002 2003. 1004 [RFC4202] Kompella, Ed., K, Rekhter, Y, Ed., "Routing Extensions 1005 in Support of Generalized Multi-Protocol Label 1006 Switching (GMPLS)", RFC 4202, October 2005. 1008 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 1009 Routes - Extension to Resource ReserVation Protocol- 1010 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 1012 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, 1013 N., and G. Ash, "Crankback Signaling Extensions for 1014 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 1016 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, 1017 "Resource Reservation Protocol (RSVP) Extensions for 1018 Path Key Support", RFC 5553, May 2009. 1020 6.2. Informative References 1022 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1023 "Generalized Multiprotocol Label Switching (GMPLS) 1024 User-Network Interface (UNI): Resource ReserVation 1025 Protocol-Traffic Engineering (RSVP-TE) Support for the 1026 Overlay Model", RFC 4208, October 2005. 1028 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1029 "Preserving Topology Confidentiality in Inter-Domain 1030 Path Computation Using a Path-Key-Based Mechanism", RFC 1031 5520, April 2009. 1033 [RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria, 1034 "RSVP-TE Extensions for Collecting SRLG Information", 1035 RFC 8001, January 2017. 1037 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 1038 S. Jamin, "Resource ReserVation Protocol -- Version 1 1039 Functional Specification", RFC 2205, September 1997. 1041 [RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D., 1042 Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode", 1043 RFC 5251, July 2008. 1045 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1046 Networks", RFC 5920, July 2010. 1048 Contributors' Addresses 1050 Igor Bryskin 1051 Huawei Technologies 1052 Email: Igor.Bryskin@huawei.com 1054 Daniele Ceccarelli 1055 Ericsson 1056 Email: Daniele.Ceccarelli@ericsson.com 1058 Dhruv Dhody 1059 Huawei Technologies 1060 Email: dhruv.ietf@gmail.com 1062 Oscar Gonzalez de Dios 1063 Telefonica I+D 1064 Email: ogondio@tid.es 1066 Don Fedyk 1067 Hewlett-Packard Enterprise 1068 Email: don.fedyk@hpe.com 1070 Clarence Filsfils 1071 Cisco Systems, Inc. 1072 Email: cfilsfil@cisco.com 1073 Gabriele Maria Galimberti 1074 Cisco Systems 1075 Email: ggalimbe@cisco.com 1077 Ori Gerstel 1078 SDN Solutions Ltd. 1079 Email: origerstel@gmail.com 1081 Matt Hartley 1082 Cisco Systems 1083 Email: mhartley@cisco.com 1085 Kenji Kumaki 1086 KDDI Corporation 1087 Email: ke-kumaki@kddi.com 1089 Ruediger Kunze 1090 Deutsche Telekom AG 1091 Email: Ruediger.Kunze@telekom.de 1093 Lieven Levrau 1094 Nokia 1095 Email: Lieven.Levrau@nokia.com 1097 Cyril Margaria 1098 cyril.margaria@gmail.com 1100 Julien Meuric 1101 France Telecom Orange 1102 Email: julien.meuric@orange.com 1104 Yuji Tochio 1105 Fujitsu 1106 Email: tochio@jp.fujitsu.com 1108 Xian Zhang 1109 Huawei Technologies 1110 Email: zhang.xian@huawei.com 1112 Authors' Addresses 1114 Zafar Ali 1115 Cisco Systems. 1116 Email: zali@cisco.com 1118 Dieter Beller 1119 Nokia 1120 Email: Dieter.Beller@nokia.com 1122 George Swallow 1123 Cisco Systems 1124 Email: swallow@cisco.com 1126 Fatai Zhang 1127 Huawei Technologies 1128 Email: zhangfatai@huawei.com