idnits 2.17.1 draft-ietf-ccamp-lsp-diversity-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 4. IANA Considerations' ) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 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) -- Missing reference section? 'RFC2119' on line 1065 looks like a reference -- Missing reference section? 'RFC4208' on line 1087 looks like a reference -- Missing reference section? 'RFC4874' on line 1077 looks like a reference -- Missing reference section? 'RFC4920' on line 1093 looks like a reference -- Missing reference section? 'RFC5520' on line 1097 looks like a reference -- Missing reference section? 'RFC5553' on line 1081 looks like a reference -- Missing reference section? 'DRAFT-SRLG-RECORDING' on line 1102 looks like a reference -- Missing reference section? 'RFC5251' on line 377 looks like a reference -- Missing reference section? 'RFC3209' on line 1068 looks like a reference -- Missing reference section? 'RFC5920' on line 1121 looks like a reference -- Missing reference section? 'RFC2205' on line 1109 looks like a reference -- Missing reference section? 'RFC3473' on line 1072 looks like a reference -- Missing reference section? 'RFC4026' on line 1113 looks like a reference -- Missing reference section? 'RFC5253' on line 1117 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali, Ed. 3 Internet Draft George Swallow, Ed. 4 Intended status: Standard Track Cisco Systems 5 Expires: April 26, 2015 F. Zhang, Ed. 6 Huawei 7 D. Beller, Ed. 8 Alcatel-Lucent 9 October 27, 2014 11 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 12 Diversity using Exclude Route 14 draft-ietf-ccamp-lsp-diversity-05.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 April 26, 2015. 33 Copyright Notice 35 Copyright (c) 2014 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 Provisions 39 Relating to IETF Documents (http://trustee.ietf.org/license-info) 40 in effect on the date of publication of this document. Please 41 review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License 44 text as described in Section 4.e of the Trust Legal Provisions 45 and are provided without warranty as described in the Simplified 46 BSD License. 48 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 50 Abstract 52 RFC 4874 specifies methods by which path exclusions can be 53 communicated during RSVP-TE signaling in networks where precise 54 explicit paths are not computed by the LSP source node. This 55 document specifies procedures for additional route exclusion 56 subobject based on Paths currently existing or expected to exist 57 within the network. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction ..................................................2 68 1.1. Client-Initiated Identifier ...........................5 69 1.2. PCE-allocated Identifier ..............................6 70 1.3. Network-Assigned Identifier ...........................7 71 2. RSVP-TE signaling extensions ..................................9 72 2.1. Diversity XRO Subobject ...............................9 73 2.1.1. IPv4 Diversity XRO Subobject ....................9 74 2.1.2. IPv6 Diversity XRO Subobject ...................14 75 2.2. Processing rules for the Diversity XRO subobject .....17 76 2.3. Diversity EXRS Subobject .............................20 77 3. Security Considerations ......................................22 78 4. IANA Considerations ..........................................22 79 4.1. New XRO subobject types ..............................22 80 4.2. New EXRS subobject types .............................23 81 4.3. New RSVP error sub-codes .............................23 82 5. Acknowledgements .............................................23 83 6. References ...................................................24 84 6.1. Normative References 85 .................................24 86 6.2. Informative References ...............................24 88 1. Introduction 90 Path diversity for multiple connections is a well-known Service 91 Provider requirement. Diversity constraints ensure that Label- 92 Switched Paths (LSPs) can be established without sharing 93 resources, thus greatly reducing the probability of simultaneous 94 connection failures. 96 When a source node has full topological knowledge and is permitted 97 to signal an Explicit Route Object, diverse paths for LSPs can be 98 computed by this source node. However, there are scenarios when 100 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 102 path computations are performed by different nodes, and there is 103 therefore a need for relevant diversity constraints to be 104 communicated to those nodes. These include (but are not limited 105 to): 107 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 108 inter-domain LSPs; 110 . Generalized Multi-Protocol Label Switching (GMPLS) User- 111 Network Interface (UNI), where path computation may be 112 performed by the core node [RFC4208]. 114 [RFC4874] introduced a means of specifying nodes and resources to 115 be excluded from a route, using the eXclude Route Object (XRO) and 116 Explicit Exclusion Route Subobject (EXRS). It facilitates the 117 calculation of diverse paths for LSPs based on known properties of 118 those paths including addresses of links and nodes traversed, and 119 Shared Risk Link Groups (SRLGs) of traversed links. Employing 120 these mechanisms requires that the source node that initiates 121 signaling knows the relevant properties of the path(s) from which 122 diversity is desired. However, there are circumstances under which 123 this may not be possible or desirable, including (but not limited 124 to): 126 . Exclusion of a path which does not originate, terminate or 127 traverse the source node of the diverse LSP, in which case the 128 addresses of links and SRLGs of the path from which diversity 129 is required are unknown to the source node. 131 . Exclusion of a path which is known to the source node of the 132 diverse LSP for which the node has incomplete or no path 133 information, e.g. due to operator policy. In this case, the 134 existence of the reference path is known to the source node but 135 the information required to construct an XRO object to 136 guarantee diversity from the reference path is not fully known. 137 Inter-domain and GMPLS overlay networks can present such 138 restrictions. 140 This is exemplified in the Figure 1, where overlay reference 141 model from [RFC4208] is shown. 143 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 145 Overlay Overlay 146 Network +----------------------------------+ Network 147 +---------+ | | +---------+ 148 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 149 | | | | UNI | | | | | | | | UNI | | | | 150 | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 151 | | | | +--+--+ | | | | | | +---+-| | | 152 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 153 +---------+ | | | | | | | +---------+ 154 | | | | | | | 155 +---------+ | | +--+--+ | +--+--+ | | +---------+ 156 | +----+ | | | | | +-------+ +-----+ | +----+ | 157 | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | 158 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 159 | | | | UNI | +-----+ +-----+ | UNI | | | | 160 | +----+ | | | | +----+ | 161 +---------+ +----------------------------------+ +---------+ 162 Overlay Core Network Overlay 163 Network Network 165 Legend: EN - Edge Node 166 CN - Core Node 168 Figure 1: Overlay Reference Model [RFC4208] 170 Figure 1 depicts two types of UNI connectivity: single-homed and 171 dual-homed ENs (which also applies to higher order multi-homed 172 connectivity.). Single-homed EN devices are connected to a single 173 CN device via a single UNI link. This single UNI link may 174 constitute a single point of failure. UNI connection between EN1 175 and CN1 is an example of singled-homed UNI connectivity. 177 A single point of failure caused by a single-homed UNI can be 178 avoided when the EN device is connected to two different CN 179 devices, as depicted for EN2 in Figure 1. For the dual-homing 180 case, it is possible to establish two different UNI connections 181 from the same source EN device to the same destination EN device. 182 For example, two connections from EN2 to EN3 may use the two UNI 183 links EN2-CN1 and EN2-CN4. To avoid single points of failure 184 within the provider network, it is necessary to also ensure path 185 (LSP) diversity within the core network. 187 In a UNI network such as that shown in Figure 1, the CNs 188 typically perform path computation. Information sharing across 190 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 192 the UNI boundary is restricted based on the policy rules imposed 193 by the core network. Typically, the core network topology 194 information is not exposed to the ENs. In the network shown in 195 Figure 1, consider a use case where an LSP from EN2 to EN4 needs 196 to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 197 may not know SRLG attributes of the EN1- EN3 LSP and hence cannot 198 construct an XRO to exclude these SRLGs. In this example EN2 199 cannot use the procedures described in [RFC4874]. Similarly, an 200 LSP from EN2 to EN3 traversing CN1 needs to be diverse from an 201 LSP from EN2 to EN3 going via CN4. Again in this case, exclusions 202 based on [RFC4874] cannot be used. 204 This document addresses these diversity requirements by 205 introducing the notion of excluding the path taken by particular 206 LSP(s). The reference LSP(s) or route(s) from which diversity is 207 required is/are identified by an "identifier". The type of 208 identifier to use is highly dependent on the networking 209 deployment scenario; it could be client-initiated, allocated by 210 the (core) network or managed by a PCE. This document defines 211 three different types of identifiers corresponding to these three 212 cases: a client initiated identifier, a PCE allocated Identifier 213 and CN ingress node (UNI-N) allocated Identifier. 215 1.1. Client-Initiated Identifier 217 There are scenarios in which the ENs have the following 218 requirements for the diversity identifier: 220 - The identifier is controlled by the client side and is 221 specified as part of the service request. 223 - Both client and server understand the identifier. 225 - It is necessary to be able to reference the identifier even if 226 the LSP referenced by it is not yet signaled. 228 - The identifier is to be stable for a long period of time. 230 - The identifier is to be stable even when the referenced tunnel 231 is rerouted. 233 - The identifier is to be human-readable. 235 These requirements are met by using the Resource ReserVation 236 Protocol (RSVP) tunnel/ LSP Forwarding Equivalence Class (FEC) as 237 the identifier. 239 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 241 The usage of the client-initiated identifier is illustrated by 242 using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be 243 diverse with respect to a tunnel from EN1 to EN3. The tunnel FEC 244 of the EN1-EN3 tunnel is FEC1, where FEC1 is defined by the tuple 245 (tunnel-id = T1, source address = EN1.ROUTE Identifier (RID), 246 destination address = EN3.RID, extended tunnel-id = EN1.RID). 247 Similarly, tunnel FEC of the EN2-EN3 tunnel is FEC2, where FEC2 248 is defined by the tuple (tunnel-id = T2, source address = 249 EN2.RID, destination address = EN4.RID, extended tunnel-id = 250 EN2.RID). The EN1-EN3 tunnel is signaled with an exclusion 251 requirement from FEC2, and the EN2-EN3 tunnel is signaled with an 252 exclusion requirement from FEC1. In order to maintain diversity 253 between these two connections within the core network, it is 254 assumed that the core network implements Crankback Signaling 255 [RFC4920]. Note that crankback signaling is known to lead to 256 slower setup times and sub-optimal paths under some circumstances 257 as described by [RFC4920]. 259 1.2. PCE-allocated Identifier 261 In scenarios where a PCE is deployed and used to perform path 262 computation, the core edge node (e.g., node CN1 in Figure 1) 263 could consult a PCE to allocate identifiers, which are used to 264 signal path diversity constraints. In other scenarios a PCE is 265 deployed in each border node or a PCE is part of a Network 266 Management System (NMS). In all these cases, the Path Key as 267 defined in [RFC5520] can be used in RSVP signaling as the 268 identifier to ensure diversity. 270 An example of specifying LSP diversity using a Path Key is shown 271 in Figure 2, where a simple network with two domains is shown. It 272 is desired to set up a pair of path-disjoint LSPs from the source 273 in Domain 1 to the destination in Domain 2, but the domains keep 274 strict confidentiality about all path and topology information. 276 The first LSP is signaled by the source with ERO {A, B, loose Dst} 277 and is set up with the path {Src, A, B, U, V, W, Dst}. However, 278 when sending the RRO out of Domain 2, node U would normally strip 279 the path and replace it with a loose hop to the destination. With 280 this limited information, the source is unable to include enough 281 detail in the ERO of the second LSP to avoid it taking, for 282 example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. 284 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 286 --------------------- ----------------------------- 287 | Domain 1 | | Domain 2 | 288 | | | | 289 | --- --- | | --- --- --- | 290 | | A |--| B |--+--+--| U |--| V |---| W | | 291 | / --- --- | | --- --- --- \ | 292 | ---/ | | / / \--- | 293 | |Src| | | / / |Dst| | 294 | ---\ | | / / /--- | 295 | \ --- --- | | --- / --- / --- / | 296 | | C |--| D |--+--+--| X |---| Y |--| Z | | 297 | --- --- | | --- --- --- | 298 | | | | 299 --------------------- ----------------------------- 301 Figure 1: A Simple Multi-Domain Network 303 In order to improve the situation, node U performs the PCE 304 function and replaces the path segment {U, V, W} in the RRO with 305 a Path Key Subobject. The Path Key Subobject assigns an 306 "identifier" to the key. The PCE ID in the message indicates that 307 it was node U that made the replacement. 309 With this additional information, the source is able to signal 310 the subsequent LSPs with the ERO set to {C, D, exclude Path 311 Key(EXRS), loose Dst}. When the signaling message reaches node X, 312 it can consult node U to expand the Path Key and know how to 313 avoid the path of the first LSP. Alternatively, the source could 314 use an ERO of {C, D, loose Dst} and include an XRO containing the 315 Path Key. 317 This mechanism can work with all the Path-Key resolution 318 mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co- 319 located or not, may be used to resolve the Path-Key, but the node 320 (i.e., a Label Switching Router (LSR)) can also use the Path Key 321 information to index a Path Segment previously supplied to it by 322 the entity that originated the Path-Key, for example the LSR that 323 inserted the Path-Key in the RRO or a management system. 325 1.3. Network-Assigned Identifier 327 There are scenarios in which the network provides diversity- 328 related information for a service that allows the client device 329 to include this information in the signaling message. If the 330 Shared Resource Link Group (SRLG) identifier information is both 331 available and shareable (by policy) with the ENs, the procedure 333 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 335 defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG 336 identifiers associated with an LSP (LSP1). When a second LSP 337 (LSP2) needs to be diverse with respect to LSP1, the EN 338 constructing the RSVP signaling message for setting up LSP2 can 339 insert the SRLG identifiers associated with LSP1 as diversity 340 constraints into the XRO using the procedure described in 341 [RFC4874]. However, if the core network SRLG identifiers are 342 either not available or not shareable with the ENs based on 343 policies enforced by core network, existing mechanisms cannot be 344 used. 346 In this draft, a signaling mechanism is defined where information 347 signaled to the CN via the UNI does not require shared knowledge 348 of core network SRLG information. For this purpose, the concept 349 of a Path Affinity Set (PAS) is used for abstracting SRLG 350 information. The motive behind the introduction of the PAS is to 351 minimize the exchange of diversity information between the core 352 network (CNs) and the client devices (ENs). The PAS contains an 353 abstract SRLG identifier associated with a given path rather than 354 a detailed SRLG list. The PAS is a single identifier that can be 355 used to request diversity and associate diversity. The means by 356 which the processing node determines the path corresponding to 357 the PAS is beyond the scope of this document. 359 A CN on the core network boundary interprets the specific PAS 360 identifier (e.g. "123") as meaning to exclude the core network 361 SRLG information (or equivalent) that has been allocated by LSPs 362 associated with this PAS identifier value. For example, if a Path 363 exists for the LSP with the identifier "123", the CN would use 364 local knowledge of the core network SRLGs associated with the 365 "123" LSPs and use those SRLGs as constraints for path 366 computation. If a PAS identifier is included for exclusion in the 367 connection request, the CN (UNI-N) in the core network is assumed 368 to be able to determine the existing core network SRLG 369 information and calculate a path that meets the determined 370 diversity constraints. 372 When a CN satisfies a connection setup for a (SRLG) diverse 373 signaled path, the CN may optionally record the core network SRLG 374 information for that connection in terms of CN based parameters 375 and associates that with the EN addresses in the Path message. 376 Specifically for Layer-1 Virtual Private Networks (L1VPNs), Port 377 Information Tables (PIT) [RFC5251] can be leveraged to translate 378 between client (EN) addresses and core network addresses. 380 The PAS and the associated SRLG information can be distributed 381 within the core network by an Interior Gateway Protocol (IGP) or 383 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 385 by other means such as configuration. They can then be utilized 386 by other CNs when other ENs are requesting paths to be setup that 387 would require path/connection diversity. In the VPN case, this 388 information is distributed on a VPN basis and contains a PAS 389 identifier, CN addresses and SRLG information. In this way, on a 390 VPN basis, the core network can have additional opaque records 391 for the PAS values for various Paths along with the SRLG list 392 associated with the Path. This information is internal to the 393 core network and is known only to the core network. 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 by this document as 403 follows. 405 2.1.1. IPv4 Diversity XRO Subobject 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | IPv4 Diversity Identifier source address | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Diversity Identifier Value | 415 // ... // 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 L: 420 The L-flag is used as for the XRO subobjects defined in 421 [RFC4874], i.e., 423 0 indicates that the attribute specified MUST be excluded. 425 1 indicates that the attribute specified SHOULD be avoided. 427 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 429 XRO Type 431 Type for IPv4 diversity XRO subobject (to be assigned by 432 IANA; suggested value: 37). 434 Length 436 The Length contains the total length of the subobject in 437 bytes, including the Type and Length fields. The Length is 438 variable, depending on the diversity identifier value. 440 Diversity Identifier Type (DI Type) 442 Diversity Identifier Type (DI Type) indicates the way the 443 reference LSP(s) or route(s) with which diversity is 444 required is identified. Three values are defined in this 445 document: 447 IPv4 Client Initiated Identifier 1 (to be assigned by 448 IANA) 449 IPv4 PCE Allocated Identifier 2 (to be assigned by 450 IANA) 451 IPv4 Network Assigned Identifier 3 (to be assigned by 452 IANA) 454 Attribute Flags (A-Flags): 456 The Attribute Flags (A-Flags) are used to communicate 457 desirable attributes of the LSP being signaled. The 458 following flags are defined. Each flag acts independently. 459 Any combination of flags is permitted. 461 0x01 = Destination node exception 463 Indicates that the exclusion does not apply to the 464 destination node of the LSP being signaled. 466 0x02 = Processing node exception 468 Indicates that the exclusion does not apply to the 469 border node(s) performing ERO expansion for the LSP 470 being signaled. An ingress UNI-N node is an example of 471 such a node. 473 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 475 0x04 = Penultimate node exception 477 Indicates that the penultimate node of the LSP being 478 signaled MAY be shared with the excluded path even when 479 this violates the exclusion flags. 481 0x08 = LSP ID to be ignored 483 This flag is only applicable when the diversity is 484 specified using the client-initiated identifier, the 485 flag indicates tunnel level exclusion, as detailed in 486 section 2.2. 488 Exclusion Flags (E-Flags): 490 The Exclusion-Flags are used to communicate the desired 491 type(s) of exclusion. The following flags are defined. Any 492 combination of these flags is permitted. 494 0x01 = SRLG exclusion 496 Indicates that the path of the LSP being signaled is 497 requested to be SRLG-diverse from the excluded path 498 specified by the Diversity XRO subobject. 500 0x02 = Node exclusion 502 Indicates that the path of the LSP being signaled is 503 requested to be node-diverse from the excluded path 504 specified by the Diversity XRO subobject. 506 (Note: the meaning of this flag may be modified by 507 the value of the Attribute-flags.) 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 Diversity XRO subobject. 515 Resvd 517 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 519 This field is reserved. It SHOULD be set to zero on 520 transmission, and MUST be ignored on receipt. 522 IPv4 Diversity Identifier source address: 524 This field is set to the IPv4 address of the node that 525 assigns the diversity identifier. Depending on the 526 diversity identifier type, the diversity identifier source 527 may be a client node, PCE entity or network node. 528 Specifically: 530 o When the diversity identifier type is set to "IPv4 Client 531 Initiated Identifier", the value is set to IPv4 tunnel 532 sender address of the reference LSP against which 533 diversity is desired. IPv4 tunnel sender address is as 534 defined in [RFC3209]. 536 o When the diversity identifier type is set to "IPv4 PCE 537 Allocated Identifier", the value indicates the IPv4 538 address of the node that assigned the Path Key identifier 539 and that can return an expansion of the Path Key or use 540 the Path Key as exclusion in a path computation. The Path 541 Key is defined in [RFC5553]. 543 o When the diversity identifier type is set to "IPv4 544 Network Assigned Identifier", the value indicates the IPv4 545 address of the node publishing the Path Affinity Set 546 (PAS). 548 Diversity Identifier Value: 550 Encoding for this field depends on the diversity identifier 551 type, as defined in the following. 553 When the diversity identifier type is set to "IPv4 Client 554 Initiated Identifier", the diversity identifier value is 555 encoded as follows: 557 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | IPv4 tunnel end point address | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Must Be Zero | Tunnel ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Extended Tunnel ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Must Be Zero | LSP ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 The IPv4 tunnel end point address, Tunnel ID, Extended 572 Tunnel ID and LSP ID are as defined in [RFC3209]. 574 When the diversity identifier type is set to "IPv4 PCE 575 Allocated Identifier", the diversity identifier value is 576 encoded as follows: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Must Be Zero | Path Key | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 The Path Key is defined in [RFC5553]. 586 When the diversity identifier type is set to "IPv4 Network 587 Assigned Identifier", the diversity identifier value is 588 encoded as follows: 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Path Affinity Set (PAS) identifier | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 The Path affinity Set (PAS) identifier is a single number 597 that represents a summarized SRLG for the reference path 598 against which diversity is desired. The node identified by 599 the "IPv4 Diversity Identifier source address" field of 600 the diversity XRO subobject assigns the PAS value. 602 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 604 2.1.2. IPv6 Diversity XRO Subobject 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | IPv6 Diversity Identifier source address | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | IPv6 Diversity Identifier source address (cont.) | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | IPv6 Diversity Identifier source address (cont.) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | IPv6 Diversity Identifier source address (cont.) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Diversity Identifier Value | 620 // ... // 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 L: 625 The L-flag is used as for the XRO subobjects defined in 626 [RFC4874], i.e., 628 0 indicates that the attribute specified MUST be excluded. 630 1 indicates that the attribute specified SHOULD be avoided. 632 XRO Type 634 Type for IPv6 diversity XRO subobject (to be assigned by 635 IANA; suggested value: 38). 637 Length 639 The Length contains the total length of the subobject in 640 bytes, including the Type and Length fields. The Length is 641 variable, depending on the diversity identifier value. 643 Attribute Flags (A-Flags): 645 As defined in Section 2.1.1 for the IPv4 counterpart. 647 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 649 Exclusion Flags (E-Flags): 651 As defined in Section 2.1.1 for the IPv4 counterpart. 653 Resvd 655 This field is reserved. It SHOULD be set to zero on 656 transmission, and MUST be ignored on receipt. 658 Diversity Identifier Type (DI Type) 660 This field is defined in the same fashion as its IPv4 661 counter part described in Section 2.1.1. 662 The DI Types associated with IPv6 addresses are defined, 663 as follows: 665 IPv6 Client Initiated Identifier 4 (to be assigned by 666 IANA) 667 IPv6 PCE Allocated Identifier 5 (to be assigned by 668 IANA) 669 IPv6 Network Assigned Identifier 6 (to be assigned by 670 IANA) 672 These idenifier are assigned and used as defined in 673 Section 2.1.1. 675 IPv4 Diversity Identifier source address: 677 This field is set to IPv6 address of the node that assigns 678 the diversity identifier. How identity of node for various 679 diversity types is determined is as described in Section 680 2.1.1 for the IPv4 counterpart. 682 Diversity Identifier Value: 684 Encoding for this field depends on the diversity identifier 685 type, as defined in the following. 687 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 689 When the diversity identifier type is set to "IPv6 Client 690 Initiated Identifier", the diversity identifier value is 691 encoded as follows: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | IPv6 tunnel end point address | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | IPv6 tunnel end point address (cont.) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | IPv6 tunnel end point address (cont.) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | IPv6 tunnel end point address (cont.) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Must Be Zero | Tunnel ID | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Extended Tunnel ID | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Extended Tunnel ID (cont.) | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Extended Tunnel ID (cont.) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Extended Tunnel ID (cont.) | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Must Be Zero | LSP ID | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended 718 Tunnel ID and LSP ID are as defined in [RFC3209]. 720 When the diversity identifier type is set to "IPv6 PCE 721 Allocated Identifier", the diversity identifier value is 722 encoded as follows: 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Must Be Zero | Path Key | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 The Path Key is defined in [RFC5553]. 732 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 734 When the diversity identifier type is set to "IPv6 Network 735 Assigned Identifier", the diversity identifier value is 736 encoded as follows: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Path Affinity Set (PAS) identifier | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 The Path affinity Set (PAS) identifier is as defined in 745 Section 2.1.1. 747 2.2. Processing rules for the Diversity XRO subobject 749 The procedure defined in [RFC4874] for processing XRO and EXRS is 750 not changed by this document. If the processing node cannot 751 recognize the IPv4/ IPv6 Diversity XRO subobject, the node is 752 expected to follow the procedure defined in [RFC4874]. 754 An XRO object MAY contain multiple Diversity subobjects. E.g., In 755 order to exclude multiple Path Keys, an EN may include multiple 756 Diversity XRO subobjects each with a different Path Key. 757 Similarly, in order to exclude multiple PAS identifiers, an EN 758 may include multiple Diversity XRO subobjects each with a 759 different PAS identifier. However, all Diversity subobjects in an 760 XRO SHOULD contain the same Diversity Identifier Type. If a Path 761 message contains an XRO with Diversity subobjects with multiple 762 Diversity Identifier Types, the processing node SHOULD return a 763 PathErr with the error code "Routing Problem" (24) and error sub- 764 code "XRO Too Complex" (68). 766 The attribute-flags affect the processing of the Diversity XRO 767 subobject as follows: 769 o When the "destination node exception" flag is set, the 770 exclusion SHOULD be ignored for the destination node. 772 o When the "processing node exception" flag is set, the 773 exclusion SHOULD be ignored for the processing node. The 774 processing node is the node performing path calculation. 776 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 778 o When the "penultimate node exception" flag is set, the 779 exclusion SHOULD be ignored for the penultimate node on 780 the path of the LSP being established. 782 o The "LSP ID to be ignored" flag is only defined for the 783 "IPv4/ IPv6 Client Initiated Identifier" diversity types. 784 When the Diversity Identifier Type is set to any other 785 value, this flag SHOULD NOT be set on transmission and 786 MUST be ignored in processing. When this flag is not set, 787 the lsp-id is not ignored and the exclusion applies only 788 to the specified LSP (i.e., LSP level exclusion). 790 If the L-flag of the diversity XRO subobject is not set, the 791 processing node proceeds as follows. 793 - "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the 794 processing node MUST ensure that any path calculated for the 795 signaled LSP is diverse from the RSVP TE FEC identified by the 796 client in the XRO subobject. 798 - "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the 799 processing node MUST ensure that any path calculated for the 800 signaled LSP is diverse from the route identified by the Path- 801 Key. The processing node MAY use the PCE identified by the IPv4 802 Diversity Identifier source address in the subobject for route 803 computation. The processing node MAY use the Path-Key 804 resolution mechanisms described in [RFC5553]. 806 - "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the 807 processing node MUST ensure that the path calculated for the 808 signaled LSP respects the requested PAS exclusion. . 810 - Regardless of whether the path computation is performed 811 locally or at a remote node (e.g., PCE), the processing node 812 MUST ensure that any path calculated for the signaled LSP 813 respects the requested exclusion flags with respect to the 814 excluded path referenced by the subobject, including local 815 resources. 817 - If the excluded path referenced in the XRO subobject is 818 unknown to the processing node, the processing node SHOULD 819 ignore the diversity XRO subobject and SHOULD proceed with the 820 signaling request. After sending the Resv for the signaled LSP, 821 the processing node SHOULD return a PathErr with the error code 822 "Notify Error" (25) and error sub-code "Route reference in 823 diversity XRO identifier unknown" (value to be assigned by 824 IANA, suggested value: 13) for the signaled LSP. 826 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 828 - If the processing node fails to find a path that meets the 829 requested constraint, the processing node MUST return a PathErr 830 with the error code "Routing Problem" (24) and error sub-code 831 "Route blocked by Exclude Route" (67). 833 If the L-flag of the diversity XRO subobject is set, the 834 processing node proceeds as follows: 836 - "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the 837 processing node SHOULD ensure that the path calculated for the 838 signaled LSP is diverse from the RSVP TE FEC identified by the 839 client in the XRO subobject. 841 - "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the 842 processing node SHOULD ensure that the path calculated for the 843 signaled LSP is diverse from the route identified by the Path- 844 Key. 846 "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the 847 processing node SHOULD ensure that the path calculated for the 848 signaled LSP respects the requested PAS exclusion. The means by 849 which the processing node determines the path corresponding to 850 the PAS is beyond the scope of this document. 852 - The processing node SHOULD respect the requested exclusion 853 flags with respect to the excluded path to the extent possible. 855 - If the processing node fails to find a path that meets the 856 requested constraint, it SHOULD proceed with signaling using a 857 suitable path that meets the constraint as far as possible. 858 After sending the Resv for the signaled LSP, it SHOULD return a 859 PathErr message with error code "Notify Error" (25) and error 860 sub-code "Failed to respect Exclude Route" (value: to be 861 assigned by IANA, suggest value: 14) to the source node. 863 If, subsequent to the initial signaling of a diverse LSP: 865 - An excluded path referenced in the XRO subobject becomes 866 known to the processing node, or a change in the excluded path 867 becomes known to the processing node, the processing node 868 SHOULD re-evaluate the exclusion and diversity constraints 869 requested by the diverse LSP to determine whether they are 870 still satisfied. 872 - If the requested exclusion constraints for the diverse LSP are 873 no longer satisfied and an alternative path for the diverse LSP 874 that can satisfy those constraints exists, then: 876 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 878 o If the L-flag was not set in the original exclusion, the 879 processing node MUST send a PathErr message for the 880 diverse LSP with the error code "Routing Problem" (24) and 881 error sub-code "Route blocked by Exclude Route" (67). The 882 PSR flag SHOULD NOT be set. A source node receiving a 883 PathErr message with this error code and sub-code 884 combination SHOULD take appropriate actions to migrate the 885 compliant path. 887 o If the L-flag was set in the original exclusion, the 888 processing node SHOULD send a PathErr message for the 889 diverse LSP with the error code "Notify Error" (25) and a 890 new error sub-code "compliant path exists" (value: to be 891 assigned by IANA, suggest value: 15). The PSR flag SHOULD 892 NOT be set. A source node receiving a PathErr message with 893 this error code and sub-code combination MAY signal a new 894 LSP to migrate the compliant path. 896 - If the requested exclusion constraints for the diverse LSP are 897 no longer satisfied and no alternative path for the diverse LSP 898 that can satisfy those constraints exists, then: 900 o If the L-flag was not set in the original exclusion, the 901 processing node MUST send a PathErr message for the 902 diverse LSP with the error code "Routing Problem" (24) and 903 error sub-code "Route blocked by Exclude Route" (67). The 904 PSR flag SHOULD be set. 906 o If the L-flag was set in the original exclusion, the 907 processing node SHOULD send a PathErr message for the 908 diverse LSP with the error code error code "Notify Error" 909 (25) and error sub-code "Failed to respect Exclude Route" 910 (value: to be assigned by IANA, suggest value: 14). The 911 PSR flag SHOULD NOT be set. 913 The following rules apply whether or not the L-flag is set: 915 - A source node receiving a PathErr message with the error code 916 "Notify Error" (25) and error sub-codes "Route of XRO tunnel 917 identifier unknown" or "Failed to respect Exclude Route" MAY 918 take no action. 920 2.3. Diversity EXRS Subobject 922 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 923 identify abstract nodes or resources that must not or should not 924 be used on the path between two inclusive abstract nodes or 926 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 928 resources in the explicit route. An EXRS contains one or more 929 subobjects of its own, called EXRS subobjects [RFC4874]. 931 An EXRS MAY include Diversity subobject as specified in this 932 document. In this case, the IPv4 EXRS format is as follows: 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 |L| Type | Length | Reserved | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | IPv4 Diversity Identifier source address | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Diversity Identifier Value | 944 // ... // 945 | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Similarly, the IPv6 EXRS format is as follows: 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |L| Type | Length | Reserved | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | IPv6 Diversity Identifier source address | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | IPv6 Diversity Identifier source address (cont.) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | IPv6 Diversity Identifier source address (cont.) | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | IPv6 Diversity Identifier source address (cont.) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Diversity Identifier Value | 966 // ... // 967 | | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 972 The meanings of respective fields in EXRS header are as defined 973 in [RFC4874]. The meanings of respective fields in the Diversity 974 subobject are as defined earlier in this document for the XRO 975 subobject. 977 The processing rules for the EXRS object are unchanged from 978 [RFC4874]. When the EXRS contains one or more Diversity 979 subobject(s), the processing rules specified in Section 2.2 apply 980 to the node processing the ERO with the EXRS subobject. 982 If a loose-hop expansion results in the creation of another 983 loose-hop in the outgoing ERO, the processing node MAY include 984 the EXRS in the newly created loose hop for further processing by 985 downstream nodes. 987 The processing node exception for the EXRS subobject applies to 988 the node processing the ERO. 990 The destination node exception for the EXRS subobject applies to 991 the explicit node identified by the ERO subobject that identifies 992 the next abstract node. This flag is only processed if the L bit 993 is set in the ERO subobject that identifies the next abstract 994 node. 996 The penultimate node exception for the EXRS subobject applies to 997 the node before the explicit node identified by the ERO subobject 998 that identifies the next abstract node. This flag is only 999 processed if the L bit is set in the ERO subobject that 1000 identifies the next abstract node. 1002 3. Security Considerations 1004 This document does not introduce any additional security issues 1005 above those identified in [RFC5920], [RFC2205], [RFC3209], 1006 [RFC3473] and [RFC4874]. 1008 4. IANA Considerations 1010 4.1. New XRO subobject types 1012 IANA registry: RSVP PARAMETERS 1013 Subsection: Class Names, Class Numbers, and Class Types 1015 This document introduces two new subobjects for the EXCLUDE_ROUTE 1016 object [RFC4874], C-Type 1. 1018 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 1020 Subobject Description Subobject Type 1021 -------------- 1022 --------------------- 1023 IPv4 Diversity subobject To be assigned by IANA 1024 (suggested value: 37) 1025 IPv6 Diversity subobject To be assigned by IANA 1026 (suggested value: 38) 1028 4.2. New EXRS subobject types 1030 The diversity XRO subobjects are also defined as new EXRS 1031 subobjects. 1033 4.3. New RSVP error sub-codes 1035 IANA registry: RSVP PARAMETERS 1036 Subsection: Error Codes and Globally Defined Error Value Sub- 1037 Codes 1039 For Error Code "Notify Error" (25) (see [RFC3209]) the following 1040 sub-codes are defined. 1042 Sub-code Value 1043 -------- ----- 1045 Route of XRO To be assigned by IANA. 1046 tunnel identifier unknown Suggested Value: 13. 1048 Failed to respect Exclude Route To be assigned by IANA. 1049 Suggested Value: 14. 1051 Compliant path exists To be assigned by IANA. 1052 Suggested Value: 15. 1054 5. Acknowledgements 1056 The authors would like to thank Luyuan Fang and Walid Wakim for 1057 their review comments. 1059 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 1061 6. References 1063 6.1. Normative References 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, March 1997. 1068 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 1069 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 1070 LSP Tunnels", RFC 3209, December 2001. 1072 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1073 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1074 Engineering (RSVP-TE) Extensions", RFC 3473, January 1075 2003. 1077 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 1078 Routes - Extension to Resource ReserVation Protocol- 1079 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 1081 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, 1082 "Resource Reservation Protocol (RSVP) Extensions for Path Key 1083 Support", RFC 5553, May 2009. 1085 6.2. Informative References 1087 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1088 "Generalized Multiprotocol Label Switching (GMPLS) 1089 User-Network Interface (UNI): Resource ReserVation 1090 Protocol-Traffic Engineering (RSVP-TE) Support for the 1091 Overlay Model", RFC 4208, October 2005. 1093 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, 1094 N., and G. Ash, "Crankback Signaling Extensions for 1095 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 1097 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1098 "Preserving Topology Confidentiality in Inter-Domain 1099 Path Computation Using a Path-Key-Based Mechanism", RFC 1100 5520, April 2009. 1102 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 1103 Margaria, "RSVP-TE Extensions for Collecting SRLG 1104 Information", draft-ietf-ccamp-rsvp-te-srlg-collect.txt, 1105 work in progress. 1107 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 1109 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 1110 S. Jamin, "Resource ReserVation Protocol -- Version 1 1111 Functional Specification", RFC 2205, September 1997. 1113 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned 1114 Virtual Private Network (VPN) Terminology", RFC 4026, 1115 March 2005. 1117 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 1118 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 1119 July 2008. 1121 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1122 Networks", RFC 5920, July 2010. 1124 Contributors' Addresses 1126 Igor Bryskin 1127 ADVA Optical Networking 1128 Email: ibryskin@advaoptical.com 1130 Daniele Ceccarelli 1131 Ericsson 1132 Email: Daniele.Ceccarelli@ericsson.com 1134 Dhruv Dhody 1135 Huawei Technologies 1136 EMail: dhruv.ietf@gmail.com 1138 Oscar Gonzalez de Dios 1139 Telefonica I+D 1140 Email: ogondio@tid.es 1142 Don Fedyk 1143 Hewlett-Packard 1144 Email: don.fedyk@hp.com 1146 Clarence Filsfils 1147 Cisco Systems, Inc. 1148 Email: cfilsfil@cisco.com 1150 Xihua Fu 1151 ZTE 1153 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 1155 Email: fu.xihua@zte.com.cn 1157 Gabriele Maria Galimberti 1158 Cisco Systems 1159 Email: ggalimbe@cisco.com 1161 Ori Gerstel 1162 SDN Solutions Ltd. 1163 Email: origerstel@gmail.com 1165 Matt Hartley 1166 Cisco Systems 1167 Email: mhartley@cisco.com 1169 Kenji Kumaki 1170 KDDI Corporation 1171 Email: ke-kumaki@kddi.com 1173 Rudiger Kunze 1174 Deutsche Telekom AG 1175 Email: Ruediger.Kunze@telekom.de 1177 Lieven Levrau 1178 Alcatel-Lucent 1179 Email: Lieven.Levrau@alcatel-lucent.com 1181 Cyril Margaria 1182 cyril.margaria@gmail.com 1184 Julien Meuric 1185 France Telecom Orange 1186 Email: julien.meuric@orange.com 1188 Yuji Tochio 1189 Fujitsu 1190 Email: tochio@jp.fujitsu.com 1192 Xian Zhang 1193 Huawei Technologies 1194 Email: zhang.xian@huawei.com 1196 Authors' Addresses 1197 Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt 1199 Zafar Ali 1200 Cisco Systems. 1201 Email: zali@cisco.com 1203 Dieter Beller 1204 Alcatel-Lucent 1205 Email: Dieter.Beller@alcatel-lucent.com 1207 George Swallow 1208 Cisco Systems 1209 Email: swallow@cisco.com 1211 Fatai Zhang 1212 Huawei Technologies 1213 Email: zhangfatai@huawei.com