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