idnits 2.17.1 draft-zhang-pce-resource-sharing-08.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 == Line 26 has weird spacing: '... months and ...' == Line 27 has weird spacing: '... at any time...' == Line 28 has weird spacing: '...ference mate...' == Line 477 has weird spacing: '...nd such reque...' -- The document date (November 19, 2018) is 1957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3209' is mentioned on line 142, but not defined == Missing Reference: 'TBD2' is mentioned on line 378, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet Draft Haomian Zheng 3 Category: Standards track Huawei Technologies 4 Oscar Gonzales de Dios 5 Victor Lopez 6 Telefonica I+D 8 Expires: May 19, 2019 November 19, 2018 10 Extensions to Path Computation Element Protocol (PCEP) to Support 11 Resource Sharing-based Path Computation 13 draft-zhang-pce-resource-sharing-08 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 19, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Abstract 62 Resource sharing in a network means two or more Label Switched Paths 63 (LSPs) use common piece(s) of resource along their paths. This can 64 help save network resource and is useful in scenarios such as LSP 65 recovery or when two LSPs do not need to be active at the same time. 66 A Path Computation Element (PCE) is responsible for path computation 67 with such requirement. The resource-sharing-based path computation 68 with better efficiency can be achieved together with the association 69 object in PCEP. 71 This document extends the Path Computation Element Protocol (PCEP) 72 in order to support resource sharing-based path computation, which 73 is a special case in the association path computation. 75 Table of Contents 77 1. Introduction and Motivation.................................. 3 78 2. Motivation .................................................. 4 79 2.1. Single PCE Use Case..................................... 4 80 2.2. Multiple PCEs Use Case.................................. 7 81 3. Extensions to PCEP .......................................... 8 82 3.1. Association group and type.............................. 9 83 3.2. Resource Sharing TLV ................................... 9 84 3.3. Processing Rules ...................................... 10 85 4. Security Considerations .................................... 11 86 5. IANA Considerations ........................................ 12 87 5.1. Association Object Type Indicators .................... 12 88 6. References ................................................. 12 89 6.1. Normative References .................................. 12 90 6.2. Informative References ................................ 13 91 7. Authors' Addresses ......................................... 13 93 1. Introduction and Motivation 95 A Path Computation Element (PCE) provides an alternative way for 96 providing path computation function, and it is especially useful in 97 the scenarios where complex constraints and/or a demanding amount of 98 computation resource are required [RFC4655]. The development of PCE 99 standardization has evolved from stateless to stateful. A stateful 100 PCE has access to the LSP database information of the network(s) it 101 serves as a computation engine [RFC8231]. Unless specified, this 102 document assumes a PCE mentioned is a stateful PCE (either passive 103 or active). 105 Resource sharing denotes that two or more Label Switched Paths 106 (LSPs) share common piece(s) of resource, (such as a common time 107 slot of a link in an Optical Transport Network (OTN)). This is 108 usually useful in the scenario where only one LSP is active and the 109 benefit herein is to save network resources. A simple example of 110 this is dynamically calculating a LSP for an existing LSP undergoing 111 a link failure. Note that the resource sharing can be worked out 112 using a stateless PCE, but the mechanism may be complex and is out 113 the scope of this draft. 115 This document considers the following requirement: new LSP may 116 request for resource sharing with one or multiple existing LSPs. 117 Furthermore, if there is resource sharing between new LSP and 118 existing LSP, the two LSPs cannot exist simultaneously, the new LSP 119 will replace the existing LSP(s). 121 In a single domain, this is a common requirement in the recovery 122 cases especially in order to increase traffic resilience against 123 failure while reducing the amount of network resource used for 124 recovery purpose [RFC4428]. 126 The current protocol supporting the communication between a PCE and 127 a Path Computation Client (PCC), i.e. PCE Protocol (PCEP), allows 128 for re-optimization of an existing LSP [RFC5440]. This is achieved 129 by setting R bit in the Request Parameter (RP) object, together with 130 some additional information if applicable, in the Path Computation 131 Request (PCReq) message sent from a PCC to the PCE. To support this 132 type of resource sharing, a PCC needs to ask a PCE to compute a new 133 path with the constraints of sharing resource with one or multiple 134 existing LSPs. It is worth noting the "resource sharing" in this 135 draft not only means one LSP re-using the same link(s) of another 136 LSP, but also the same slice of bandwidth in TDM networks. This may 137 occur when an LSP is required for re-routing, or online re- 138 optimization. Current PCEP specifications do not provide such 139 function. More specifically, this draft describes the resource 140 sharing issue during the procedure when a new LSP is required to 141 replace an existing LSP, which can be used together with Make- 142 before-break (MBB) described in [RFC3209]. 144 There are a few objects which indicate the resource sharing/disjoint 145 relationships, such as SRLG and ASSOCIATE. However, these objects 146 are used to describe the relationship with two simultaneous LSPs, 147 instead of a new one and an old one, which is different with the 148 object proposed in this draft. 150 As mentioned in [RFC8231], the PLSP-ID is unique during a PCEP 151 session between PCC and PCE. Such identification is helpful in 152 supporting the above resource sharing requirement for 153 standardization of stateful PCEs. With a unique identifier, the 154 configuration of PCCs is greatly simplified. Instead of determining 155 all the resources to be shared, the PCC could request resource 156 sharing directly from PCE. 158 The resource sharing can also be required in an inter-layer PCEP 159 session. This is similar to the previous requirement. However, it is 160 more complex and therefore deserves a more detailed explanation 161 here. 163 In a multi-layer network, Label Switched Paths (LSPs) in a lower 164 layer are used to carry higher-layer LSPs across the lower-layer 165 network [RFC5623]. Therefore, the resource sharing constraints in 166 the higher layer might actually relate to the resource sharing in 167 the lower layer. Thus, it is useful to consider how this can be 168 achieved and whether additional extensions are needed using the 169 models defined in [RFC5623]. 171 In the next sections, use cases are provided to show what 172 information needs to be exchanged to fulfill these requirements. 173 This memo then provides extensions to PCEP to enable this function. 175 2. Motivation 177 2.1. Single PCE Use Case 179 Figure 1 shows a single domain network with a stateful PCE. Assume a 180 working LSP (N1-N2-N3) exists in the network, when there is failure 181 on the link N2-N3, it is desired to set up a restoration path for 182 this working LSP. Suppose N1 serves as the PCC and sends a request 183 to the stateful PCE for such an LSP. Before sending the request, N1 184 may need to check what policy should be applied for the path re- 185 computation. For example, it might value resource sharing and prefer 186 to share as much resource with the working LSP as possible and 187 specify this policy in the PCReq message. If resources are shared 188 between the old and new LSPs, there will be some 'interruption' when 189 the traffic is switched from the old LSP to the new LSP. Here the 190 resources to be shared mean the LSP information, which includes the 191 node, link and corresponding SRLG information, etc. 193 On the other hand, in some scenarios there are different policies, 194 for example the LSP should be restored without any interruption with 195 best effort. An example can be found in Fig. 1 without failure on 196 N2-N3 link, instead, an online re-optimization is needed for the 197 working LSP (N1-N2-N3) from the stateful PCE. In such cases, the 198 best choice is to set up a backup LSP for the working LSP with 199 totally separate routing (for example N1-N5-N4-N3), and move the 200 traffic to that backup LSP. After that the working LSP can be torn 201 down, which will not result in any interruption during the 202 optimization procedure. This can actually be implemented with 203 existing PCEP mechanism. However, if there is no such separate path, 204 existing PCEP will reply error. A secondary option for this case is 205 to set up an LSP and complete such re-optimization with resource 206 sharing, even if some interruption introduced. Given the resource 207 from the LSP to be interrupted, there may be some solutions instead 208 of Path Compute error due to the lack of resource. 210 A simple illustration is provided below: 212 +--------------+ 213 | | 214 | Stateful PCE | 215 | | 216 +--------------+ 218 +------+ +------+ +------+ 219 | N1 +----------+ N2 +-----X---+ N3 | 220 +--+---+ +---+--+ +---+--+ 221 | | | 222 | +---------+ | 223 | | | 224 | +------+ +------+ | 225 +-----+ N5 +----------+ N4 +-----+ 226 +------+ +------+ 228 Figure 1: A Single Domain Example 230 Available recovery paths computed by the stateful PCE: 232 LSP1: N1-N2-N4-N3 233 LSP2: N1-N5-N4-N3 235 If resource sharing is preferred, the stateful PCE will reply with 236 LSP1 information. Instead, if PCC prefer to have less interruption, 237 PCE will reply with LSP2 information. 239 Another piece of information that needs to be conveyed to the PCE is 240 the information about the working path LSP. Note this simple use 241 case assumes end-to-end recovery. But in order to be applicable to 242 use cases such as shared mesh protection purpose, where the head-end 243 or tail-end nodes may be different, this information is necessary in 244 the message exchange between PCCs and PCEs, so that the stateful PCE 245 knows which LSP the path computation request wants to share the 246 resource. 248 Besides, parameter changes during the resource sharing computation 249 also need to be considered. For example, the bandwidth of the 250 request LSP may be different with the existing LSP, while resource 251 sharing is still preferred by the PCC. PCE should consider the 252 sharing request together with the policy and available resource(s) 253 in the network. Details can be found in Section 3.3. 255 2.2. Multiple PCEs Use Case 257 Figure 2 shows a two-layer network example, with each layer managed 258 by a PCE. As Discussed in Section 3 of [RFC5623], there are three 259 models for inter-layer path computation. They are single PCE 260 computation, multiple PCE with inter-PCE communication and multiple 261 PCE without inter-PCE communication, respectively. For the single 262 PCE computation, the process would be similar to that of the use 263 case in Section 2.1. Thus, this model is not discussed further. 265 ----- 266 .................................| LSR | 267 .: | H5 | 268 .: /----- 269 .: / | 270 ----- -----.: ----- -----/ | 271 | LSR |--| LSR |.......................| LSR |--| LSR | / 272 | H1 | | H2 | | H3 | | H4 | / 273 ----- -----\ /----- ----- / 274 \ / / 275 \ / / 276 \ / / 277 \ / / 278 \----- -----/ / 279 | LSR |-| LSR | / 280 | L1 | | L2 | / 281 ----- -----\ / 282 | \ / 283 | \ / 284 | \ / 285 ----- \-----/ 286 | LSR |-----------| LSR | 287 | L3 | | L4 | 288 ----- ----- 289 Figure 2: A Two-layer Network Example 291 An inter-layer path computation example is shown in Fig. 2, assume a 292 LSP (LSP1: H2-H3) has been established already, visible as H2-H3 293 from view of higher-layer PCE and H2-L1-L2-H3 from the global view 294 (or from the view of lower-layer PCE). A new request comes at H2 to 295 establish a new LSP (LSP2: from H2 to H5), given the constraint it 296 can share resource with LSP1. This requirement is possible if only 297 one of the LSPs needs to be active and resource sharing is the 298 target. 300 If multiple PCE with inter-PCE communication model is employed, the 301 path computation request sent by H2 to higher-layer PCE will be 302 forwarded to lower-layer PCE since there is no resource readily 303 available in the higher layer. So it leaves the lower-layer PCE to 304 compute a path in the lower layer in order to support the higher 305 layer request. In this case, lower-layer PCE is required to compute 306 a path between H2 and H5 under the constraint that it can share the 307 resource with that of the LSP1. At this moment the lower-layer PCE 308 has the knowledge on the explicit routing that LSP1 go through (H2- 309 L1-L2-H3), and therefore can map the lower layer LSP with the 310 higher-layer one. So when lower-layer PCE computes the path for 311 LSP2, it can consider the resource used by LSP1 as available with 312 higher priority. For example, lower-layer PCE may choose H2-L1-L2- 313 L4-H5 as the computation result. On the other hand, if the path 314 computation policy is to have a separate path with LSP1, the lower- 315 layer PCE may choose H2-L1-L3-L4-H5. 317 During this procedure higher-layer PCE can only use LSP1 information 318 (such as its five-tuple LSP information) as the information, an 319 issue to solve is how lower-layer PCE can resolve this information 320 to the actual resource usage in its own layer, i.e. lower layer. 321 This could be solved by edge LSR L1 reporting this higher-lower 322 layer LSP correlation to the lower-layer PCE as part of the LSP 323 information during the LSP state synchronization process. If needed, 324 it can be later updated when there is a change in this information. 325 Alternatively, the lower-layer PCE can get this information from 326 other sources, such as network management system, where this 327 information should be stored. 329 If multiple PCE without inter-PCE communication model is employed, 330 the path computation request in the lower layer will be initiated 331 the border LSR node, i.e., L1. The process would be similar to that 332 of the previous scenario. A point worth noting is that the border 333 LSR node may be able to resolve the higher layer LSP information 334 itself, such as mapping it to the corresponding LSP in the lower 335 layer, in this way lower-layer PCE does not need to perform this 336 function. Otherwise, the mapping method mentioned above can still be 337 used. 339 3. Extensions to PCEP 341 This section provides PCEP extensions. Currently the text focuses 342 only on passive stateful PCE and corresponding PCReq. But if active 343 stateful PCE delegation is used, we would like to convey the same 344 information in PCRpt. In the passive stateful PCE architecture, a 345 PCC is allowed to specify resource sharing when sending a PCReq 346 message. It also details the processing rule and error codes needed. 348 3.1. Association group and type 350 According to the definition in [ietf-pce-association-group], the 351 association group is used to associate multiple LSPs into one group 352 for further path computation considerations, such as disjointness 353 and resource sharing. An association ID will be used to identify the 354 resource sharing group. An association type that described 355 disjointness has been defined in [ietf-pce-association-diversity]. 356 In this draft, a new association type is defined as: 358 Association type = TBD1 ("Sharing Association Type"). 360 A sharing group should have multiple LSPs. The number of LSPs and 361 the criteria for how LSPs share among each other are implementation 362 dependent. Local path computation policies apply to different PCE 363 and PCC, some examples can be found in section 2. 365 3.2. Resource Sharing TLV 367 The PCEP Resource Sharing group MUST carry the following TLV. It MAY 368 be carried within a PCReq message from the network element (or other 369 PCCs) so as to indicate the desired resource sharing requirements to 370 be applied by the stateful PCE during path computation. 372 0 1 2 3 374 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type = [TBD2] | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Flags |S|N|L| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Optional TLVs | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Currently the following flags have been defined: 392 * L (Link share) bit: when set, this flag indicates that the PCE 393 should prioritize the links that shared by existing LSPs within the 394 sharing group for path computation. 396 * N (Node share) bit: when set, this flag indicates that the PCE 397 should prioritize the nodes that shared by existing LSPs within the 398 sharing group for path computation. 400 * S (SRLG share) bit: bit: when set, this flag indicates that the 401 PCE should set the SRLG (Shared Risk Link Group) of the computed LSP 402 to the same as existing LSPs within the sharing group for path 403 computation. 405 Optional TLVs may be needed to indicate the LSP(s) with which the 406 resource is shared. If multiple LSPs are required, the PCE may need 407 to consider different sharing policies, which is implementation 408 dependent and may result in a different computing result. The 409 selection policy among multiple computation result is out of the 410 scope of this draft. 412 3.3. Processing Rules 414 To request a path allowing sharing resource with one or multiple 415 existing LSPs, a PCC includes a Resource Sharing TLV in the 416 association group object in the PCReq message. 418 On receipt of a PCReq message with a Resource Sharing TLV, a 419 stateful PCE MUST proceed as follows: 421 - If the Resource Sharing TLV is unknown/unsupported, the PCE will 422 follow procedures defined in [RFC5440]. That is, the PCE sends a 423 PCErr message with error type 3 or 4 (Unknown / Not supported 424 object) and error value 1 or 2 (unknown / unsupported object class 425 / object type), and the related path computation request is 426 discarded. 428 - If Resource Sharing TLV are unknown/unsupported and the P bit is 429 set, the PCE MUST send a PCErr message with error type 3 or 4 430 (Unknown / Not supported object) and error value 4 431 (Unrecognized/Unsupported parameter), and the related path 432 computation request MUST be discarded as defined in [RFC5440]. 434 - If the resource sharing TLV is extracted correctly, the PCE MUST 435 apply the requested resource sharing requirement. 437 The procedure of setting flags follows the rules defined in Section 438 3.1. The RSO flags may be locally configured on the requesting nodes 439 via external entities, such as a network management system or the 440 entity that impose the resource sharing requirement. 442 It is worth noting that the Resource Sharing TLV can be used 443 together with other path indication objects like IRO/XRO, with 444 difference objectives. The first difference is, the use of Resource 445 Sharing TLV is to setup an alternative path, instead a new path. It 446 is also dependent on the knowledge of PCC, e.g., if the PCC have a 447 full knowledge of the path information and have strong preference on 448 the route, it may send the PCReq with IRO message to specify the 449 route. On the other hand, if the PCC does not know how the path 450 should go but just want to set up a new LSP to replace the old one, 451 it may use the Resource Sharing TLV instead of IRO. The second 452 difference is, resource Sharing TLV is a loose requirement. For 453 example, if the constraint specified in IRO/XRO in an A-Z path 454 computation request cannot be satisfied, the PCRep from PCE to PCC 455 would be unsuccessful. However it is still possible to have a path 456 from the A-Z. If the target node/link/SRLG is set in Resource 457 Sharing TLV rather than IRO, the PCE may feedback a path that from 458 A-Z that not sharing the target specified in Resource Sharing TLV. 460 4. Security Considerations 462 Security of PCEP is discussed in [RFC5440] and [RFC6952]. The 463 extensions in this document do not change the fundamentals of 464 security for PCEP. 466 However, the introduction of the Resource Sharing TLV in association 467 group object provides a vector that may be used to probe for 468 information from a network. For example, a PCC that wants to 469 discover the path of an LSP with which it is not involved can issue 470 a PCReq with a Resource sharing TLV and may be able to get back 471 quite a lot of information about the path of the LSP through issuing 472 multiple such requests for different endpoints and analyzing the 473 received results. To protect against this, a PCE should be 474 configured with access and authorization controls such that only 475 authorized PCCs (for example, those within the network) can make 476 computation requests, only specifically authorized PCCs can make 477 requests for resource sharing, and such requests relating to 478 specific LSPs are further limited to a select few PCCs. How such 479 access controls and authorization is managed is outside the scope of 480 this document, but it will at the least include Access Control 481 Lists. 483 Furthermore, a PCC must be aware that setting up an LSP that share 484 resources with another LSP may be a way of attacking the other LSP, 485 for example by depriving it of the resources it needs to operate 486 correctly. Thus it is important that, both in PCEP and the 487 associated signaling protocols, only authorized resource sharing is 488 allowed. 490 5. IANA Considerations 492 5.1. Association Object Type Indicators 494 This document defines a new association type, with the following 495 information: 497 Object Name Object Reference 498 Class Type 499 ------------------------------------------------------------ 501 TBA1 Sharing-group Association Type [this document] 503 5.2 PCEP TLV Definitions 505 This document defines the following TLVs to support the resource 506 sharing scenario: 508 Value Name Reference 509 ------------------------------------------------------------ 511 TBA2 Resource-sharing TLV [this document] 513 IANA is requested to allocate the following bit numbers in the flag 514 spaces of Resource-sharing TLV: 516 Bit Flag name Reference 518 0 Link Share [this document] 520 1 Node Share [this document] 522 2 SRLG Share [this document] 524 6. References 526 6.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 529 requirements levels", RFC 2119, March 1997. 531 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 532 Computation Element (PCE)-Based Architecture", RFC 4655, 533 August 2006. 535 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 536 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 537 March 2009. 539 [RFC8231] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 540 Extensions for Stateful PCE", RFC8231, June 2017. 542 [ietf-pce-association-group] Minei, I., Crabbe E., Sivabalan S., 543 Ananthakrishnan H., Dhody D., Tanaka Y., "PCEP Extensions 544 for Establishing Relationships Between Sets of LSPs", work 545 in Progress. 547 [ietf-pce-association-diversity] Litkowski, S., Sivabalan, S., 548 Barth, C., Dhody, D., "Path Computation Element 549 communication Protocol extension for signaling LSP 550 diversity constraint", Work in Progress. 552 6.2. Informative References 554 [RFC4428] Papadimitriou, D., Mannie., E., "Analysis of Generalized 555 Multi-Protocol Label Switching (GMPLS)-based Recovery 556 Mechanisms (including Protection and Restoration)", 557 RFC4428, March 2006. 559 [RFC5623] Oki., E., Takeda, T., Le Roux, JL., Farrel, A., "Framework 560 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 561 Engineering", RFC5623, September 2009. 563 [RFC6952] Jethanandani, M., Patel, K., Zheng, L., "Analysis of BGP, 564 LDP, PCEP, and MSDP Issues According to the Keying and 565 Authentication for Routing Protocols (KARP) Design Guide", 566 RFC6952, May 2013. 568 7. Authors' Addresses 570 Xian Zhang 571 Huawei Technologies 573 Email: zhang.xian@huawei.com 575 Haomian Zheng 576 Huawei Technologies 577 Email: zhenghaomian@huawei.com 579 Oscar Gonzalez de Dios 580 Telefonica I+D 581 Don Ramon de la Cruz 82-84 582 Madrid 28045 583 Spain 584 EMail: ogondio@tid.es 586 Victor Lopez 587 Telefonica I+D 588 Don Ramon de la Cruz 82-84 589 Madrid 28045 590 Spain 591 EMail: vlopez@tid.es 593 Contributor's Address : 595 Dhruv Dhody 596 Huawei Technologies 597 Email: dhruv.dhody@huawei.com 599 Igor Bryskin 600 Huawei Technologies 601 Email: Igor.Bryskin@huawei.com