idnits 2.17.1 draft-ietf-teas-lsp-diversity-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2951 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) == Outdated reference: A later version (-08) exists of draft-ietf-teas-rsvp-te-srlg-collect-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Expires: September 22, 2016 F. Zhang, Ed. 6 Huawei 7 D. Beller, Ed. 8 Nokia 9 March 21, 2016 11 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 12 Diversity using Exclude Route 14 draft-ietf-teas-lsp-diversity-04.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 22, 2016. 33 Copyright Notice 35 Copyright (c) 2016 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 RFC 4874 specifies methods by which path exclusions can be 51 communicated during RSVP-TE signaling in networks where precise 52 explicit paths are not computed by the LSP source node. This 53 document specifies procedures for additional route exclusion 54 subobject based on Paths currently existing or expected to exist 55 within the network. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction..................................................2 66 1.1. Client-Initiated Identifier...........................5 67 1.2. PCE-allocated Identifier..............................6 68 1.3. Network-Assigned Identifier...........................7 69 2. RSVP-TE signaling extensions..................................9 70 2.1. Diversity XRO Subobject...............................9 71 2.2. Diversity EXRS Subobject.............................15 72 2.3. Processing rules for the Diversity XRO and EXRS 73 subobjects...........................................16 74 3. Security Considerations......................................20 75 4. IANA Considerations..........................................21 76 4.1. New XRO subobject types..............................21 77 4.2. New EXRS subobject types.............................21 78 4.3. New RSVP error sub-codes.............................21 79 5. Acknowledgements.............................................22 80 6. References...................................................22 81 6.1. Normative References.................................22 82 6.2. Informative References...............................23 84 1. Introduction 86 Path diversity for multiple connections is a well-known Service 87 Provider requirement. Diversity constraints ensure that Label- 88 Switched Paths (LSPs) can be established without sharing network 89 resources, thus greatly reducing the probability of simultaneous 90 connection failures. 92 The source node can compute diverse paths for LSPs when it has 93 full knowledge of the network topology and is permitted to signal 94 an Explicit Route Object. However, there are scenarios where 95 different nodes perform path computations, and therefore there is 96 a need for relevant diversity constraints to be signaled to those 97 nodes. These include (but are not limited to): 99 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 100 inter-domain LSPs. 102 . Generalized Multi-Protocol Label Switching (GMPLS) User- 103 Network Interface (UNI), where the core node may perform path 104 computation [RFC4208]. 106 [RFC4874] introduced a means of specifying nodes and resources to 107 be excluded from a route, using the eXclude Route Object (XRO) and 108 Explicit Exclusion Route Subobject (EXRS). It facilitates the 109 calculation of diverse paths for LSPs based on known properties of 110 those paths including addresses of links and nodes traversed, and 111 Shared Risk Link Groups (SRLGs) of traversed links. Employing 112 these mechanisms requires that the source node that initiates 113 signaling knows the relevant properties of the path(s) from which 114 diversity is desired. However, there are circumstances under which 115 this may not be possible or desirable, including (but not limited 116 to): 118 . Exclusion of a path which does not originate, terminate or 119 traverse the source node of the diverse LSP, in which case the 120 addresses of links and SRLGs of the path from which diversity 121 is required are unknown to the source node. 123 . Exclusion of a path which is known to the source node of the 124 diverse LSP for which the node has incomplete or no path 125 information, e.g. due to operator policy. In this case, the 126 source node is aware of the existence of the reference path but 127 the information required to construct an XRO object to 128 guarantee diversity from the reference path is not fully known. 129 Inter-domain and GMPLS overlay networks can impose such 130 restrictions. 132 This is exemplified in the Figure 1, where the overlay reference 133 model from [RFC4208] is shown. 135 Overlay Overlay 136 Network +----------------------------------+ Network 137 +---------+ | | +---------+ 138 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 139 | | | | UNI | | | | | | | | UNI | | | | 140 | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 141 | | | | +--+--+ | | | | | | +---+-| | | 142 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 143 +---------+ | | | | | | | +---------+ 144 | | | | | | | 145 +---------+ | | +--+--+ | +--+--+ | | +---------+ 146 | +----+ | | | | | +-------+ +-----+ | +----+ | 147 | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | 148 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 149 | | | | UNI | +-----+ +-----+ | UNI | | | | 150 | +----+ | | | | +----+ | 151 +---------+ +----------------------------------+ +---------+ 152 Overlay Core Network Overlay 153 Network Network 155 Legend: EN - Edge Node 156 CN - Core Node 158 Figure 1: Overlay Reference Model [RFC4208] 160 Figure 1 depicts two types of UNI connectivity: single-homed and 161 dual-homed ENs (which also applies to higher order multi-homed 162 connectivity.). Single-homed EN devices are connected to a single 163 CN device via a single UNI link. This single UNI link may 164 constitute a single point of failure. UNI connection between EN1 165 and CN1 is an example of singled-homed UNI connectivity. 167 A single point of failure caused by a single-homed UNI can be 168 avoided when the EN device is connected to two different CN 169 devices, as depicted for EN2 in Figure 1. For the dual-homing 170 case, it is possible to establish two different UNI connections 171 from the same source EN device to the same destination EN device. 172 For example, two connections from EN2 to EN3 may use the two UNI 173 links EN2-CN1 and EN2-CN4. To avoid single points of failure 174 within the provider network, it is necessary to also ensure path 175 (LSP) diversity within the core network. 177 In a UNI network such as that shown in Figure 1, the CNs 178 typically perform path computation. Information sharing across 179 the UNI boundary is restricted based on the policy rules imposed 180 by the core network. Typically, the core network topology 181 information is not exposed to the ENs. In the network shown in 182 Figure 1, consider a use case where an LSP from EN2 to EN4 needs 183 to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 184 may not know SRLG attributes of the EN1- EN3 LSP and hence cannot 185 construct an XRO to exclude these SRLGs. In this example EN2 186 cannot use the procedures described in [RFC4874]. Similarly, an 187 LSP from EN2 to EN3 traversing CN1 needs to be diverse from an 188 LSP from EN2 to EN3 going via CN4. Again in this case, exclusions 189 based on [RFC4874] cannot be used. 191 This document addresses these diversity requirements by 192 introducing the notion of excluding the path taken by particular 193 LSP(s). The reference LSP(s) or route(s) from which diversity is 194 required is/are identified by an "identifier". The type of 195 identifier to use is highly dependent on the networking 196 deployment scenario; it could be client-initiated, allocated by 197 the (core) network or managed by a PCE. This document defines 198 three different types of identifiers corresponding to these three 199 cases: a client initiated identifier, a PCE allocated Identifier 200 and CN ingress node (UNI-N) allocated Identifier. 202 1.1. Client-Initiated Identifier 204 There are scenarios in which the ENs have the following 205 requirements for the diversity identifier: 207 - The identifier is controlled by the client side and is 208 specified as part of the service request. 210 - Both client and server understand the identifier. 212 - It is necessary to be able to reference the identifier even if 213 the LSP referenced by it is not yet signaled. 215 - The identifier is to be stable for a long period of time. 217 - The identifier is to be stable even when the referenced LSP is 218 rerouted. 220 - The identifier is to be human-readable. 222 These requirements are met by using the LSP identifier. The LSP 223 identifier uniquely identifies an LSP in the network and 224 comprises of the following fields: IPv4/IPv6 tunnel sender 225 address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID, 226 and Extended Tunnel ID. These fields are defined in [RFC3209], 227 sections 4.6.1.1 and 4.6.2.1. 229 The usage of the client-initiated identifier is illustrated by 230 Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with 231 respect to a LSP from EN1 to EN3. The LSP identifier of the EN1- 232 EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by 233 the tuple (tunnel-id = T1, LSP ID = L1, source address = 234 EN1.ROUTE Identifier (RID), destination address = EN3.RID, 235 extended tunnel-id = EN1.RID). Similarly, LSP identifier of the 236 EN2-EN3 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER12 is defined 237 by the tuple (tunnel-id = T2, LSP IS = L1, source address = 238 EN2.RID, destination address = EN4.RID, extended tunnel-id = 239 EN2.RID). The EN1-EN3 LSP is signaled with an exclusion 240 requirement from LSP-IDENTIFIER2, and the EN2-EN3 LSP is signaled 241 with an exclusion requirement from LSP-IDENTIFIER1. In order to 242 maintain diversity between these two connections within the core 243 network, it is assumed that the core network implements Crankback 244 Signaling [RFC4920]. Note that crankback signaling is known to 245 lead to slower setup times and sub-optimal paths under some 246 circumstances as described by [RFC4920]. 248 1.2. PCE-allocated Identifier 250 In scenarios where a PCE is deployed and used to perform path 251 computation, the core edge node (e.g., node CN1 in Figure 1) 252 could consult a PCE to allocate identifiers, which are used to 253 signal path diversity constraints. In other scenarios a PCE is 254 deployed at network node(s) or a PCE is part of a Network 255 Management System (NMS). In all these cases, the Path Key as 256 defined in [RFC5520] can be used in RSVP signaling as the 257 identifier to ensure diversity. 259 An example of specifying LSP diversity using a Path Key is shown 260 in Figure 2, where a simple network with two domains is shown. It 261 is desired to set up a pair of path-disjoint LSPs from the source 262 in Domain 1 to the destination in Domain 2, but the domains keep 263 strict confidentiality about all path and topology information. 265 The first LSP is signaled by the source with ERO {A, B, loose Dst} 266 and is set up with the path {Src, A, B, U, V, W, Dst}. However, 267 when sending the RRO out of Domain 2, node U would normally strip 268 the path and replace it with a loose hop to the destination. With 269 this limited information, the source is unable to include enough 270 detail in the ERO of the second LSP to avoid it taking, for 271 example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. 273 --------------------- ----------------------------- 274 | Domain 1 | | Domain 2 | 275 | | | | 276 | --- --- | | --- --- --- | 277 | | A |--| B |--+--+--| U |--| V |---| W | | 278 | / --- --- | | --- --- --- \ | 279 | ---/ | | / / \--- | 280 | |Src| | | / / |Dst| | 281 | ---\ | | / / /--- | 282 | \ --- --- | | --- / --- / --- / | 283 | | C |--| D |--+--+--| X |---| Y |--| Z | | 284 | --- --- | | --- --- --- | 285 | | | | 286 --------------------- ----------------------------- 288 Figure 2: A Simple Multi-Domain Network 290 In order to improve the situation, node U performs the PCE 291 function and replaces the path segment {U, V, W} in the RRO with 292 a Path Key Subobject. The Path Key Subobject assigns an 293 "identifier" to the key. The PCE ID in the message indicates that 294 it was node U that made the replacement. 296 With this additional information, the source is able to signal 297 the subsequent LSPs with the ERO set to {C, D, exclude Path 298 Key(EXRS), loose Dst}. When the signaling message reaches node X, 299 it can consult node U to expand the Path Key and know how to 300 avoid the path of the first LSP. Alternatively, the source could 301 use an ERO of {C, D, loose Dst} and include an XRO containing the 302 Path Key. 304 This mechanism can work with all the Path-Key resolution 305 mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co- 306 located or not, may be used to resolve the Path-Key, but the node 307 (i.e., a Label Switching Router (LSR)) can also use the Path Key 308 information to index a Path Segment previously supplied to it by 309 the entity that originated the Path-Key, for example the LSR that 310 inserted the Path-Key in the RRO or a management system. 312 1.3. Network-Assigned Identifier 314 There are scenarios in which the network provides diversity- 315 related information for a service that allows the client device 316 to include this information in the signaling message. If the 317 Shared Resource Link Group (SRLG) identifier information is both 318 available and shareable (by policy) with the ENs, the procedure 319 defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG 320 identifiers associated with an LSP (LSP1). When a second LSP 321 (LSP2) needs to be diverse with respect to LSP1, the EN 322 constructing the RSVP signaling message for setting up LSP2 can 323 insert the SRLG identifiers associated with LSP1 as diversity 324 constraints into the XRO using the procedure described in 325 [RFC4874]. However, if the core network SRLG identifiers are 326 either not available or not shareable with the ENs based on 327 policies enforced by core network, existing mechanisms cannot be 328 used. 330 In this draft, a signaling mechanism is defined where information 331 signaled to the CN via the UNI does not require shared knowledge 332 of core network SRLG information. For this purpose, the concept 333 of a Path Affinity Set (PAS) is used for abstracting SRLG 334 information. The motive behind the introduction of the PAS is to 335 minimize the exchange of diversity information between the core 336 network (CNs) and the client devices (ENs). The PAS contains an 337 abstract SRLG identifier associated with a given path rather than 338 a detailed SRLG list. The PAS is a single identifier that can be 339 used to request diversity and associate diversity. The means by 340 which the processing node determines the path corresponding to 341 the PAS is beyond the scope of this document. 343 A CN on the core network boundary interprets the specific PAS 344 identifier (e.g. "123") as meaning to exclude the core network 345 SRLG information (or equivalent) that has been allocated by LSPs 346 associated with this PAS identifier value. For example, if a Path 347 exists for the LSP with the identifier "123", the CN would use 348 local knowledge of the core network SRLGs associated with the 349 "123" LSPs and use those SRLGs as constraints for path 350 computation. If a PAS identifier is included for exclusion in the 351 connection request, the CN (UNI-N) in the core network is assumed 352 to be able to determine the existing core network SRLG 353 information and calculate a path that meets the determined 354 diversity constraints. 356 When a CN satisfies a connection setup for a (SRLG) diverse 357 signaled path, the CN may optionally record the core network SRLG 358 information for that connection in terms of CN based parameters 359 and associates that with the EN addresses in the Path message. 360 Specifically for Layer-1 Virtual Private Networks (L1VPNs), Port 361 Information Tables (PIT) [RFC5251] can be leveraged to translate 362 between client (EN) addresses and core network addresses. 364 The means to distribute the PAS information within the core 365 network is beyond the scope of this document. The PAS and the 366 associated SRLG information can be distributed within the core 367 network by an Interior Gateway Protocol (IGP) or by other means 368 such as configuration. Regardless of means used to distribute the 369 PAS information, the information is kept inside core network and 370 is not shared with the overlay network (see Figure 1). 372 2. RSVP-TE signaling extensions 374 This section describes the signaling extensions required to 375 address the aforementioned requirements and use cases. 377 2.1. Diversity XRO Subobject 379 New Diversity XRO subobjects are defined below for the IPv4 and 380 IPv6 address families. Most of the fields in the IPv4 and IPv6 381 Diversity XRO subobjects are common and are described following 382 the definition of the two subobjects. 384 IPv4 Diversity XRO Subobject is defined as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | IPv4 Diversity Identifier Source Address | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Diversity Identifier Value | 394 // ... // 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Similarly, the IPv6 Diversity XRO Subobject is defined as 398 follows: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | IPv6 Diversity Identifier source address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | IPv6 Diversity Identifier source address (cont.) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | IPv6 Diversity Identifier source address (cont.) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | IPv6 Diversity Identifier source address (cont.) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Diversity Identifier Value | 414 // ... // 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 L: 419 The L-flag is used as for the XRO subobjects defined in 420 [RFC4874], i.e., 422 0 indicates that the attribute specified MUST be excluded. 424 1 indicates that the attribute specified SHOULD be avoided. 426 XRO Type 428 The value is set to for IPv4 diversity XRO subobject 429 (value to be assigned by IANA). Similarly, The value is 430 set to for IPv6 diversity XRO Subobject (value to be 431 assigned by IANA). 433 Length 435 The Length contains the total length of the IPv4/ IPv6 436 subobject in bytes, including the Type and Length fields. 437 The Length is variable, depending on the diversity 438 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 in the IPv4/ IPv6 Diversity 445 subobjects. The following three DI type values are defined 446 in this document: 448 DI Type value Definition 449 ------------- -------------------------------- 450 1 Client Initiated Identifier 451 2 PCE Allocated Identifier 452 3 Network Assigned Identifier 454 Attribute Flags (A-Flags): 456 The Attribute Flags (A-Flags) are used to communicate 457 desirable attributes of the LSP being signaled in the IPv4/ 458 IPv6 Diversity subobjects. The following flags are defined. 459 Each flag acts independently. Any combination of flags is 460 permitted. 462 0x01 = Destination node exception 464 Indicates that the exclusion does not apply to the 465 destination node of the LSP being signaled. 467 0x02 = Processing node exception 469 Indicates that the exclusion does not apply to the 470 node(s) performing ERO expansion for the LSP being 471 signaled. An ingress UNI-N node is an example of such a 472 node. 474 0x04 = Penultimate node exception 476 Indicates that the penultimate node of the LSP being 477 signaled MAY be shared with the excluded path even when 478 this violates the exclusion flags. 480 0x08 = LSP ID to be ignored 482 This flag is used to indicate tunnel level exclusion. 483 Specifically, this flag is used to indicate that if 484 diversity identifier contains lsp-id field, the lsp-id 485 is to be ignored and the exclusion applies to any LSP 486 matching the rest of the diversity identifier. 488 Exclusion Flags (E-Flags): 490 The Exclusion-Flags are used to communicate the desired 491 type(s) of exclusion requested in the IPv4/ IPv6 diversity 492 subobjects. The following flags are defined. Any 493 combination of these flags is permitted. Please note that 494 the exclusion specified by these flags may be modified by 495 the value of the Attribute-flags. For example, node 496 exclusion flag is ignored for the "Penultimate node" if the 497 "Penultimate node exception" flag of the Attribute-flags is 498 set. 500 0x01 = SRLG exclusion 502 Indicates that the path of the LSP being signaled is 503 requested to be SRLG-diverse from the excluded path 504 specified by the IPv4/ IPv6 Diversity XRO subobject. 506 0x02 = Node exclusion 508 Indicates that the path of the LSP being signaled is 509 requested to be node-diverse from the excluded path 510 specified by the IPv4/ IPv6 Diversity XRO subobject. 512 0x04 = Link exclusion 514 Indicates that the path of the LSP being signaled is 515 requested to be link-diverse from the path specified 516 by the IPv4/ IPv6 Diversity XRO subobject. 518 Resvd 520 This field is reserved. It SHOULD be set to zero on 521 transmission, and MUST be ignored on receipt for both 522 IPv4/ IPv6 Diversity XRO subobjects. 524 IPv4 / IPv6 Diversity Identifier source address: 526 This field is set to the IPv4/ IPv6 address of the node 527 that assigns the diversity identifier. Depending on the 528 diversity identifier type, the diversity identifier source 529 may be a client node, PCE entity or network node. 530 Specifically: 532 o When the diversity identifier type is set to "IPv4/ IPv6 533 Client Initiated Identifier", the value is set to IPv4/ 534 IPv6 tunnel sender address of the reference LSP against 535 which diversity is desired. IPv4/ IPv6 tunnel sender 536 address is as defined in [RFC3209]. 538 o When the diversity identifier type is set to "IPv4/ IPv6 539 PCE Allocated Identifier", the value indicates the IPv4/ 540 IPv6 address of the node that assigned the Path Key 541 identifier and that can return an expansion of the Path 542 Key or use the Path Key as exclusion in a path 543 computation. The Path Key is defined in [RFC5553]. 545 o When the diversity identifier type is set to "IPv4/ IPv6 546 Network Assigned Identifier", the value indicates the 547 IPv4/ IPv6 address of the node publishing the Path 548 Affinity Set (PAS). 550 Diversity Identifier Value: 552 Encoding for this field depends on the diversity identifier 553 type, as defined in the following. 555 When the diversity identifier type is set to "Client 556 Initiated Identifier" in IPv4 Diversity XRO subobject, the 557 diversity identifier value MUST be encoded as follows: 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 "IPv6 Client 575 Initiated Identifier" in IPv6 Diversity XRO subobject, the 576 diversity identifier value MUST be 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 | IPv6 tunnel end point address | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | IPv6 tunnel end point address (cont.) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | IPv6 tunnel end point address (cont.) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | IPv6 tunnel end point address (cont.) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Must Be Zero | Tunnel ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Extended Tunnel ID | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Extended Tunnel ID (cont.) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Extended Tunnel ID (cont.) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Extended Tunnel ID (cont.) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Must Be Zero | LSP ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended 603 Tunnel ID and LSP ID are as defined in [RFC3209]. 605 When the diversity identifier type is set to "PCE Allocated 606 Identifier" in IPv4 or IPv6 Diversity XRO subobject, the 607 diversity identifier value MUST be encoded as follows: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Must Be Zero | Path Key | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 The Path Key is defined in [RFC5553]. 617 When the diversity identifier type is set to "Network 618 Assigned Identifier" in IPv4 or IPv6 Diversity XRO 619 subobject, the diversity identifier value MUST be encoded 620 as follows: 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Path Affinity Set (PAS) identifier | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 The Path affinity Set (PAS) identifier field is a 32-bit 629 value that is scoped by, i.e., is only meaningful when 630 used in combination with, the Diversity Identifier source 631 address field. There are no restrictions on how a node 632 selects a PAS identifier value. Section 1.3. defines the 633 PAS term and provides context on how values may be 634 selected. 636 2.2. Diversity EXRS Subobject 638 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 639 identify abstract nodes or resources that must not or should not 640 be used on the path between two inclusive abstract nodes or 641 resources in the explicit route. An EXRS contains one or more 642 subobjects of its own, called EXRS subobjects [RFC4874]. 644 An EXRS MAY include Diversity subobject as specified in this 645 document. In this case, the IPv4 EXRS format is as follows: 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |L| Type | Length | Reserved | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | IPv4 Diversity Identifier source address | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Diversity Identifier Value | 657 // ... // 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Similarly, the IPv6 EXRS format is as follows: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |L| Type | Length | Reserved | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | IPv6 Diversity Identifier source address | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | IPv6 Diversity Identifier source address (cont.) | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | IPv6 Diversity Identifier source address (cont.) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | IPv6 Diversity Identifier source address (cont.) | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Diversity Identifier Value | 679 // ... // 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 The meanings of respective fields in EXRS header are as defined 684 in [RFC4874]. The meanings of respective fields in the Diversity 685 subobject are as defined earlier in this document for the XRO 686 Diversity subobject. 688 2.3. Processing rules for the Diversity XRO and EXRS subobjects 690 The procedure defined in [RFC4874] for processing the XRO and 691 EXRS is not changed by this document. The processing rules for 692 the Diversity XRO and EXRS subobjects are similar unless the 693 differences are explicitly described. Similarly, IPv4 and IPv6 694 Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS 695 subobjects follow the same processing rules. 697 If the processing node cannot recognize the Diversity XRO/ EXRS 698 subobject, the node is expected to follow the procedure defined 699 in [RFC4874]. 701 An XRO/ EXRS object MAY contain multiple Diversity subobjects of 702 the same DI Type. E.g., in order to exclude multiple Path Keys, a 703 node may include multiple Diversity XRO subobjects each with a 704 different Path Key. Similarly, in order to exclude the routes 705 taken by multiple LSPs, a node may include multiple Diversity 706 XRO/ EXRS subobjects each with a different LSP identifier. 707 Likewise, to exclude multiple PAS identifiers, a node may include 708 multiple Diversity XRO/ EXRS subobjects each with a different PAS 709 identifier. However, all Diversity subobjects in an XRO/ EXRS 710 MUST contain the same Diversity Identifier Type. If a Path 711 message contains an XRO/ EXRS with multiple Diversity subobjects 712 of different DI Types, the processing node MUST return a PathErr 713 with the error code "Routing Problem" (24) and error sub-code 714 "XRO/ EXRS Too Complex" (68/ 69). 716 If the processing node recognize the Diversity XRO/ EXRS 717 subobject but does not support the DI type, it MUST return a 718 PathErr with the error code "Routing Problem" and error value of 719 "Unsupported Diversity Identifier Type". 721 The nodes in the domain that perform path computation SHOULD 722 process the diversity information signaled in the XRO/ EXRS 723 Diversity subobjects. The transit nodes in a domain and the 724 domain egress node MAY ignore it. While processing EXRS object, 725 if a loose-hop expansion results in the creation of another 726 loose-hop in the outgoing ERO, the processing node MAY include 727 the EXRS in the newly created loose hop for further processing by 728 downstream nodes. 730 The attribute-flags affect the processing of the Diversity XRO/ 731 EXRS subobject as follows: 733 o When the "processing node exception" flag is set, the 734 exclusion MUST be ignored for the node processing the XRO 735 or EXRS subobject. 737 o When the "destination node exception" flag is set, the 738 exclusion MUST be ignored for the destination node in 739 processing the XRO subobject. The destination node 740 exception for the EXRS subobject applies to the explicit 741 node identified by the ERO subobject that identifies the 742 next abstract node. This flag is only processed if the L 743 bit is set in the ERO subobject that identifies the next 744 abstract node. 746 o When the "penultimate node exception" flag is set in the 747 XRO subobject, the exclusion MUST be ignored for the 748 penultimate node on the path of the LSP being established. 749 The penultimate node exception for the EXRS subobject 750 applies to the node before the explicit node identified by 751 the ERO subobject that identifies the next abstract node. 752 This flag is only processed if the L bit is set in the ERO 753 subobject that identifies the next abstract node. 755 If the L-flag of the diversity XRO subobject or diversity EXRS 756 subobject is not set, the processing node proceeds as follows. 758 - If the Diversity Identifier Type is set to "IPv4/IPv6 Client 759 Initiated Identifiers", the processing node MUST ensure that 760 the path calculated/ expended for the signaled LSP is diverse 761 from the route taken by the LSP identified in the Diversity 762 Identifier Value field. 764 - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE 765 Allocated Identifiers", the processing node MUST ensure that 766 any path calculated for the signaled LSP is diverse from the 767 route identified by the Path-Key. The processing node MAY use 768 the PCE identified by the IPv4/IPv6 Diversity Identifier Source 769 Address in the subobject for route computation. The processing 770 node MAY use the Path-Key resolution mechanisms described in 771 [RFC5553]. 773 - If the Diversity Identifier Type is set to "IPv4/IPv6 Network 774 Assigned Identifiers", the processing node MUST ensure that the 775 path calculated for the signaled LSP is diverse with respect to 776 the values associated with the PAS identifier and Diversity 777 Identifier source address fields. 779 - Regardless of whether the path computation is performed 780 locally or at a remote node (e.g., PCE), the processing node 781 MUST ensure that any path calculated for the signaled LSP is 782 diverse from the requested Exclusion Flags. 784 - If the excluded path referenced in the XRO subobject is 785 unknown to the processing node, the processing node SHOULD 786 ignore the diversity XRO subobject and SHOULD proceed with the 787 signaling request. After sending the Resv for the signaled LSP, 788 the processing node MUST return a PathErr with the error code 789 "Notify Error" (25) and error sub-code "Route reference in 790 diversity XRO identifier unknown" (value to be assigned by 791 IANA) for the signaled LSP. 793 - If the processing node fails to find a path that meets the 794 requested constraint, the processing node MUST return a PathErr 795 with the error code "Routing Problem" (24) and error sub-code 796 "Route blocked by Exclude Route" (67). 798 If the L-flag of the XRO diversity subobject or EXRS diversity 799 subobject is set, the processing node proceeds as follows: 801 - If the Diversity Identifier Type is set to "IPv4/IPv6 Client 802 Initiated Identifiers", the processing node SHOULD ensure that 803 the path calculated/ expended for the signaled LSP is diverse 804 from the route taken by the LSP identified in the Diversity 805 Identifier Value field. 807 - If the Diversity Identifier Type is set to "IPv4/IPv6 PCE 808 Allocated Identifiers", the processing node SHOULD ensure that 809 the path calculated for the signaled LSP is diverse from the 810 route identified by the Path-Key. 812 - If the Diversity Identifier Type is set to "IPv4/IPv6 Network 813 Assigned Identifiers", the processing node SHOULD ensure that 814 the path calculated for the signaled LSP is diverse with 815 respect to the values associated with the PAS identifier and 816 Diversity Identifier source address fields. 818 - If the processing node fails to find a path that meets the 819 requested constraint, it SHOULD proceed with signaling using a 820 suitable path that meets the constraint as far as possible. 821 After sending the Resv for the signaled LSP, it MUST return a 822 PathErr message with error code "Notify Error" (25) and error 823 sub-code "Failed to satisfy Exclude Route" (value: to be 824 assigned by IANA) to the source node. 826 If, subsequent to the initial signaling of a diverse LSP, an 827 excluded path referenced in the XRO subobject becomes known to 828 the processing node, or a change in the excluded path becomes 829 known to the processing node, the processing node MUST re- 830 evaluate the exclusion and diversity constraints requested by the 831 diverse LSP to determine whether they are still satisfied. 833 If, subsequent to the initial signaling of a diverse LSP, the 834 requested exclusion constraints for the diverse LSP are no longer 835 satisfied and an alternative path for the diverse LSP that can 836 satisfy those constraints exists, then: 838 - If the L-flag was not set in the original exclusion, the 839 processing node MUST send a PathErr message for the diverse LSP 840 with the error code "Routing Problem" (24) and error sub-code 841 "Route blocked by Exclude Route" (67). The Path_State_Removed 842 flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a 843 PathErr message with this error code and sub-code combination 844 SHOULD take appropriate actions to migrate to a compliant path. 846 - If the L-flag was set in the original exclusion, the 847 processing node MUST send a PathErr message for the diverse LSP 848 with the error code "Notify Error" (25) and a new error sub- 849 code "compliant path exists" (value: to be assigned by IANA). 850 The PSR flag MUST NOT be set. A source node receiving a PathErr 851 message with this error code and sub-code combination MAY 852 signal a new LSP to migrate the compliant path. 854 If, subsequent to the initial signaling of a diverse LSP, the 855 requested exclusion constraints for the diverse LSP are no longer 856 satisfied and no alternative path for the diverse LSP that can 857 satisfy those constraints exists, then: 859 - If the L-flag was not set in the original exclusion, the 860 processing node MUST send a PathErr message for the diverse LSP 861 with the error code "Routing Problem" (24) and error sub-code 862 "Route blocked by Exclude Route" (67). The PSR flag MUST be 863 set. 865 - If the L-flag was set in the original exclusion, the 866 processing node MUST send a PathErr message for the diverse LSP 867 with the error code error code "Notify Error" (25) and error 868 sub-code "Failed to satisfy Exclude Route" (value: to be 869 assigned by IANA). The PSR flag MUST NOT be set. The source 870 node MAY take no action and keep the LSP along the non- 871 compliant path. 873 3. Security Considerations 875 This document does not introduce any additional security issues 876 above those identified in [RFC5920], [RFC2205], [RFC3209], 877 [RFC3473] and [RFC4874]. 879 4. IANA Considerations 881 IANA is requested to administer the assignment of new values 882 defined in this document and summarized in this section. 884 4.1. New XRO subobject types 886 IANA registry: RSVP PARAMETERS 887 Subsection: Class Names, Class Numbers, and Class Types 889 This document defines two new subobjects for the EXCLUDE_ROUTE 890 object [RFC4874], C-Type 1. (see: 891 http://www.iana.org/assignments/rsvp-parameters/rsvp- 892 parameters.xhtml#rsvp-parameters-94) 894 Subobject Description Subobject Type 895 ------------------------ -------------- 896 IPv4 Diversity subobject TBA1 897 IPv6 Diversity subobject TBA2 899 4.2. New EXRS subobject types 901 The diversity XRO subobjects are also defined as new EXRS 902 subobjects. (see: http://www.iana.org/assignments/rsvp- 903 parameters/rsvp-parameters.xhtml#rsvp-parameters-24) 905 4.3. New RSVP error sub-codes 907 IANA registry: RSVP PARAMETERS 908 Subsection: Error Codes and Globally Defined Error Value Sub- 909 Codes. 910 For Error Code "Routing Problem" (24) (see [RFC3209]) the 911 following sub-codes are defined. (see: 912 http://www.iana.org/assignments/rsvp-parameters/rsvp- 913 parameters.xhtml#rsvp-parameters-105) 914 +-------------+----------------------------+---------------+ 915 | Error Value | Description | Reference | 916 | Sub-codes | | | 917 +-------------+----------------------------+---------------+ 918 | TBA3 | Unsupported Diversity | This document | 919 | | Identifier Type | | 920 +-------------+----------------------------+---------------+ 922 For Error Code "Notify Error" (25) (see [RFC3209]) the following 923 sub-codes are defined. (see: 924 http://www.iana.org/assignments/rsvp-parameters/rsvp- 925 parameters.xhtml#rsvp-parameters-105) 927 +-------------+----------------------------+---------------+ 928 | Error Value | Description | Reference | 929 | Sub-codes | | | 930 +-------------+----------------------------+---------------+ 931 | TBA4 | Route of XRO LSP | This document | 932 | | identifier unknown | | 933 | TBA5 | Failed to satisfy | This document | 934 | | Exclude Route | | 935 | TBA6 | Compliant path exists | This document | 936 +-------------+----------------------------+---------------+ 938 5. Acknowledgements 940 The authors would like to thank Luyuan Fang and Walid Wakim for 941 their review comments. 943 6. References 945 6.1. Normative References 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, March 1997. 950 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 951 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 952 LSP Tunnels", RFC 3209, December 2001. 954 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 955 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 956 Engineering (RSVP-TE) Extensions", RFC 3473, January 957 2003. 959 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 960 Routes - Extension to Resource ReserVation Protocol- 961 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 963 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, 964 "Resource Reservation Protocol (RSVP) Extensions for Path Key 965 Support", RFC 5553, May 2009. 967 6.2. Informative References 969 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 970 "Generalized Multiprotocol Label Switching (GMPLS) 971 User-Network Interface (UNI): Resource ReserVation 972 Protocol-Traffic Engineering (RSVP-TE) Support for the 973 Overlay Model", RFC 4208, October 2005. 975 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, 976 N., and G. Ash, "Crankback Signaling Extensions for 977 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 979 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 980 "Preserving Topology Confidentiality in Inter-Domain 981 Path Computation Using a Path-Key-Based Mechanism", RFC 982 5520, April 2009. 984 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 985 Margaria, "RSVP-TE Extensions for Collecting SRLG 986 Information", draft-ietf-teas-rsvp-te-srlg-collect-04, 987 in expert review. 989 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 990 S. Jamin, "Resource ReserVation Protocol -- Version 1 991 Functional Specification", RFC 2205, September 1997. 993 [RFC5251] D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, 994 R. Rabbat, L. Berger, "Layer 1 VPN Basic Mode", 995 RFC 5251, July 2008. 997 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 998 Networks", RFC 5920, July 2010. 1000 Contributors' Addresses 1002 Igor Bryskin 1003 ADVA Optical Networking 1004 Email: ibryskin@advaoptical.com 1006 Daniele Ceccarelli 1007 Ericsson 1008 Email: Daniele.Ceccarelli@ericsson.com 1010 Dhruv Dhody 1011 Huawei Technologies 1012 Email: dhruv.ietf@gmail.com 1014 Oscar Gonzalez de Dios 1015 Telefonica I+D 1016 Email: ogondio@tid.es 1018 Don Fedyk 1019 Hewlett-Packard 1020 Email: don.fedyk@hp.com 1022 Clarence Filsfils 1023 Cisco Systems, Inc. 1024 Email: cfilsfil@cisco.com 1026 Xihua Fu 1027 ZTE 1028 Email: fu.xihua@zte.com.cn 1029 Gabriele Maria Galimberti 1030 Cisco Systems 1031 Email: ggalimbe@cisco.com 1033 Ori Gerstel 1034 SDN Solutions Ltd. 1035 Email: origerstel@gmail.com 1037 Matt Hartley 1038 Cisco Systems 1039 Email: mhartley@cisco.com 1041 Kenji Kumaki 1042 KDDI Corporation 1043 Email: ke-kumaki@kddi.com 1045 Ruediger Kunze 1046 Deutsche Telekom AG 1047 Email: Ruediger.Kunze@telekom.de 1049 Lieven Levrau 1050 Nokia 1051 Email: Lieven.Levrau@nokia.com 1053 Cyril Margaria 1054 cyril.margaria@gmail.com 1056 Julien Meuric 1057 France Telecom Orange 1058 Email: julien.meuric@orange.com 1060 Yuji Tochio 1061 Fujitsu 1062 Email: tochio@jp.fujitsu.com 1064 Xian Zhang 1065 Huawei Technologies 1066 Email: zhang.xian@huawei.com 1068 Authors' Addresses 1070 Zafar Ali 1071 Cisco Systems. 1072 Email: zali@cisco.com 1074 Dieter Beller 1075 Nokia 1076 Email: Dieter.Beller@nokia.com 1078 George Swallow 1079 Cisco Systems 1080 Email: swallow@cisco.com 1082 Fatai Zhang 1083 Huawei Technologies 1084 Email: zhangfatai@huawei.com