idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-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 == Line 41 has weird spacing: '... months and ...' == Line 42 has weird spacing: '... at any time...' == Line 43 has weird spacing: '...ference mate...' == Line 294 has weird spacing: '...orm the re-...' == Line 404 has weird spacing: '... P flag and...' -- The document date (December 5, 2018) is 1967 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: 'RFC 5440' is mentioned on line 116, but not defined == Missing Reference: 'RFC7399' is mentioned on line 123, but not defined == Missing Reference: 'RFC5521' is mentioned on line 350, but not defined == Missing Reference: 'RFC8126' is mentioned on line 451, but not defined == Missing Reference: 'RFC7025' is mentioned on line 485, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 11 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 Young Lee (Editor) 3 Intended status: Standards Track Fatai Zhang 4 Huawei 5 Ramon Casellas 6 CTTC 7 Oscar Gonzalez de Dios 8 Telefonica I+D 9 Zafar Ali 10 Cisco Systems 12 Expires: June 5, 2019 December 5, 2018 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-09 19 Abstract 21 The Path Computation Element (PCE) facilitates Traffic Engineering 22 (TE) based path calculation in large, multi-domain, multi-region, or 23 multi-layer networks. The PCE communication Protocol (PCEP) has been 24 extended to support stateful PCE functions where the PCE retains 25 information about the paths already present in the network, but 26 those extensions are technology-agnostic. This memo provides 27 extensions required for PCEP so as to enable the usage of a stateful 28 PCE capability in GMPLS-controlled networks. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with 33 the provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other 42 documents at any time. It is inappropriate to use Internet-Drafts 43 as reference material or to cite them other than as "work in 44 progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on June 5, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 77 Table of Contents.................................................2 78 1. Introduction...................................................3 79 2. Context of Stateful PCE and PCEP for GMPLS.....................4 80 3. Main Requirements..............................................4 81 4. PCEP Extensions................................................5 82 4.1. LSP Update in GMPLS-controlled Networks...................5 83 4.2. LSP Synchronization in GMPLS-controlled Networks..........5 84 4.3. Modification of Existing PCEP Messages and Procedures.....7 85 4.3.1. Modification for LSP Re-optimization.................7 86 4.3.2. Modification for Route Exclusion.....................8 87 4.3.3. Modification for SRP Object to indicate Bi-directional 88 LSP.........................................................9 89 4.4. Object Encoding...........................................9 90 5. IANA Considerations...........................................10 91 5.1. New PCEP Error Codes.....................................10 92 5.2. New Subobject for the Exclude Route Object...............10 93 5.3. New "B" Flag in the SRP Object...........................10 94 6. Manageability Considerations..................................11 95 6.1. Requirements on Other Protocols and Functional Components11 96 7. Security Considerations.......................................11 97 8. Acknowledgement...............................................11 98 9. References....................................................12 99 9.1. Normative References.....................................12 100 9.2. Informative References...................................12 101 10. Contributors' Address........................................12 102 Authors' Addresses...............................................14 104 1. Introduction 106 [RFC4655] presents the architecture of a Path Computation Element 107 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 108 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 109 Paths (TE LSPs). To perform such a constrained computation, a PCE 110 stores the network topology (i.e., TE links and nodes) and resource 111 information (i.e., TE attributes) in its TE Database (TED). Such a 112 PCE is usually referred as a stateless PCE. To request path 113 computation services to a PCE, [RFC5440] defines the PCE 114 communication Protocol (PCEP) for interaction between a Path 115 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 116 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 117 extensions needed for GMPLS-controlled networks are provided in 118 [PCEP-GMPLS]. 120 Stateful PCEs are shown to be helpful in many application scenarios, 121 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 122 Further discussion of concept of a stateful PCE can be found in 123 [RFC7399]. In order for these applications to able to exploit the 124 capability of stateful PCEs, extensions to PCEP are required. 126 [RFC8051] describes how a stateful PCE can be applicable to solve 127 various problems for MPLS-TE and GMPLS networks and the benefits it 128 brings to such deployments. 130 [RFC8231] provides the fundamental extensions needed for stateful 131 PCE to support general functionality, but leaves out the 132 specification for technology-specific objects/TLVs. This document 133 focuses on the extensions that are necessary in order for the 134 deployment of stateful PCEs in GMPLS-controlled networks. 136 2. Context of Stateful PCE and PCEP for GMPLS 138 This document is built on the basis of Stateful PCE [RFC8231] and 139 PCEP for GMPLS [PCEP-GMPLS]. 141 There are two types of LSP operation for Stateful PCE. 143 For Active Stateful PCE, PCUpd message is sent from PCE to PCC to 144 update the LSP state for the LSP delegated to PCE. Any changes to 145 the delegated LSPs generate a PCRpt message by the PCC to PCE to 146 convey the changes of the LSP. Any modifications to the Objects/TLVs 147 that are identified in this document to support GMPLS technology- 148 specific attributes will be carried in the PCRpt and PCUpd messages. 150 For Passive Stateful PCE where PCReq/PCRep messages are used to 151 convey path computation instruction. As GMPLS-technology specific 152 Objects/TLVs are defined in [PCEP-GMPLS], this document just points 153 to the work in [PCEP-GMPLS] and add only the stateful PCE aspect 154 only if applicable. Passive Stateful PCE makes use of PCRpt messages 155 when reporting LSP State changes sent by PCC to PCEs. Any 156 modifications to the Objects/TLVs that are identified in this 157 document to support GMPLS technology-specific attributes will be 158 carried in the PCRpt message. 160 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 161 document makes use of these Objects/TLVs without modifications where 162 applicable. Some of these Objects/TLVs may require modifications to 163 incorporate stateful PCE element where applicable. 165 3. Main Requirements 167 This section notes the main functional requirements for PCEP 168 extensions to support stateful PCE for use in GMPLS-controlled 169 networks, based on the description in [RFC8051]. Many 170 requirements are common across a variety of network types (e.g., 171 MPLS-TE networks and GMPLS networks) and the protocol extensions to 172 meet the requirements are already described in [RFC8231]. This 173 document does not repeat the description of those protocol 174 extensions. This document presents protocol extensions for a set of 175 requirements which are specific to the use of a stateful PCE in a 176 GMPLS-controlled network. 178 The basic requirements are as follows: 180 o Advertisement of the stateful PCE capability. This generic 181 requirement is covered in Section 5.4. of [RFC8231]. This 182 document assumes that STATEFUL-PCE-CAPABILITY TLV can be used for 183 GMPLS Stateful PCE capability and therefore does not provide any 184 further extensions. 186 o LSP delegation is already covered in Section 5.7. of [RFC8231]. 187 Section 2.2. of this document does not provide any further 188 extensions. 190 o Active LSP update is covered in Section 6.2 of [RFC8231]. Section 191 4.1. of this document provides extension for its application in 192 GMPLS-controlled networks. 194 o LSP state synchronization and LSP state report. This is a generic 195 requirement already covered in Section 5.6. of [RFC8231]. However, 196 there are further extensions required specifically for GMPLS- 197 controlled networks and discussed in Section 4.2. 199 4. PCEP Extensions 201 4.1. LSP Update in GMPLS-controlled Networks 203 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 204 message to enable to update the attributes of an LSP. However, that 205 document does not define technology-specific parameters. 207 A key element of the PCUpd message is the attribute-list construct 208 defined in [RFC5440] and extended by many other PCEP specifications. 210 For GMPLS purposes we note that the BANDWIDTH object used in the 211 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 212 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 213 included to indicate technology-specific attributes. There are other 214 technology-specific attributes that need to be conveyed in the 215 of the construct in the PCUpd 216 message. Note that these path details in the PCUpd message are the 217 same as the of the PCRep message. See Section 4.2 218 for the details. 220 4.2. LSP Synchronization in GMPLS-controlled Networks 222 PCCs need to report the attributes of LSPs to the PCE to enable 223 stateful operation of a GMPLS network. This process is known as 224 LSP state synchronization. The LSP attributes include bandwidth, 225 associated route, and protection information etc., are stored by the 226 PCE in the LSP database (LSP-DB). Note that, as described in 227 [RFC8231], the LSP state synchronization covers both the bulk 228 reporting of LSPs at initialization as well the reporting of new or 229 modified LSP during normal operation. Incremental LSP-DB 230 synchronization may be desired in a GMPLS-controlled network and it 231 is specified in [RFC8232]. 233 [RFC8231] describes mechanisms for LSP synchronization using the 234 Path Computation State Report (PCRpt) message, but does not cover 235 reporting of technology-specific attributes. As stated in [RFC8231], 236 the construct is further composed of a compulsory ERO object 237 and a compulsory attribute-list and an optional RRO object. In order 238 to report LSP states in GMPLS networks, this specification allows 239 the use within a PCRpt message both of technology- and GMPLS- 240 specific attribute objects and TLVs defined in [PCEP-GMPLS] as 241 follows: 243 o IRO/XRO Extensions to support the inclusion/exclusion of labels 244 and label sub-objects for GMPLS. (See Section 2.6 and 2.7 in 245 [PCEP-GMPLS]) 247 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 248 in [PCEP-GMPLS]) 250 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 251 in [PCEP-GMPLS]) 253 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 255 The END-POINTS object SHOULD be carried within the attribute-list to 256 specify the endpoints pertaining to the reported LSP. The XRO object 257 MAY be carried to specify the network resources that the reported 258 LSP avoids and a PCE SHOULD consider avoid these network resources 259 during the process of re-optimizing after this LSP is delegated to 260 the PCE. To be more specific, the is updated as 261 follows: 263 ::= [] 264 [] 265 [] 266 [] 267 [] 268 [] 270 ::= [] 271 If the LSP being reported protects another LSP, the PROTECTION- 272 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 273 describe its attributes and restrictions. Moreover, if the status 274 of the protecting LSP changes from non-operational to operational, 275 this SHOULD to be synchronized to the stateful PCE using a PCRpt 276 message. 278 4.3. Modification of Existing PCEP Messages and Procedures 280 One of the advantages mentioned in [RFC8051] is that the stateful 281 nature of a PCE simplifies the information conveyed in PCEP messages, 282 notably between PCC and PCE, since it is possible to refer to PCE 283 managed state for active LSPs. To be more specific, with a stateful 284 PCE, it is possible to refer to an LSP with a unique identifier in 285 the scope of the PCC-PCE session and thus use such identifier to 286 refer to that LSP. Note this MAY also be applicable to packet 287 networks. 289 4.3.1. Modification for LSP Re-optimization 291 The Request Parameters (RP) object on a Path Computation Request 292 (PCReq) message carries the R bit. When set, this indicates that 293 the PCC is requesting re-optimization of an existing LSP. Upon 294 receiving such a PCReq, a stateful PCE SHOULD perform the re- 295 optimization in the following cases: 297 o The existing bandwidth and route information of the LSP to be 298 re-optimized is provided in the PCReq message using the 299 BANDWIDTH object and the ERO. 301 o The existing bandwidth and route information is not supplied 302 in the PCReq message, but can be found in the PCE's LSP-DB. 303 In this case, the LSP MUST be identified using an LSP 304 identifier carried in the PCReq message, and that fact 305 requires that the LSP identifier was previously supplied 306 either by the PCC in a PCRpt message or by the PCE in a PCRep 307 message. [RFC8231] defines how this is achieved using a 308 combination of the per-node LSP identifier (PLSP-ID) and the 309 PCC's address. 311 If no LSP state information is available to carry out re- 312 optimization, the stateful PCE should report the error "LSP state 313 information unavailable for the LSP re-optimization" (Error Type = 314 TBD1, Error value= TBD2). 316 4.3.2. Modification for Route Exclusion 318 [RFC5521] defines a mechanism for a PCC to request or demand that 319 specific nodes, links, or other network resources are excluded from 320 paths computed by a PCE. A PCC may wish to request the computation 321 of a path that avoids all link and nodes traversed by some other LSP. 323 To this end this document defines a new sub-object for use with 324 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 325 is as follows: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |X|Type (TBD3) | Length | Attributes | Flag | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 // Symbolic Path Name // 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 X bit and Attribute fields are defined in [RFC5521]. 339 X bit: indicates whether the exclusion is mandatory (X=1) and MUST 340 be accommodated, or desired (X=0) and SHOULD be accommodated. 342 Type: Subobject Type for an LSP exclusion sub-object. Value of 343 TBD3. To be assigned by IANA. 345 Length: The Length contains the total length of the subobject in 346 bytes, including the Type and Length fields. 348 Attributes: indicates how the exclusion object is to be 349 interpreted. Currently, Interface (Attributes = 0), Node 350 (Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521] 351 and this document does not define new values. 353 Flags: This field may be used to further specify the exclusion 354 constraint with regard to the LSP. Currently, no values are 355 defined. 357 Symbolic Path Name: This is the identifier given to a LSP and is 358 unique in the context of the PCC address as defined in [RFC8231]. 360 Reserved: MUST be transmitted as zero and SHOULD be ignored on 361 receipt. 363 This sub-object is OPTIONAL in the exclude route object (XRO) and 364 can be present multiple times. When a stateful PCE receives a PCReq 365 message carrying this sub-object, it SHOULD search for the 366 identified LSP in its LSP-DB and then exclude it from the new path 367 computation all resources used by the identified LSP. If the 368 stateful PCE cannot recognize one or more of the received LSP 369 identifiers, it should send an error message PCErr reporting "The 370 LSP state information for route exclusion purpose cannot be found" 371 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 372 with the unrecognized identifier information to the requesting PCC 373 using the error reporting techniques described in [RFC5440]. 375 4.3.3. Modification for SRP Object to indicate Bi-directional LSP 377 The format of the SRP object is defined in [RFC8231] and included 378 here for easy reference with the addition of the new B flag. This 379 SRP object is used in PCUpd and PCInit messages for GMPLS. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Flags |B|R| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | SRP-ID-number | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 // Optional TLVs // 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 3: The SRP Object Format 395 A new flag is defined to indicate a bidirectional co-routed LSP 396 setup operation initiated by the PCE: 398 B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 399 request to create a uni-directional LSP. If set to 1, it indicates 400 a request to create a bidirectional co-routed LSP. 402 4.4. Object Encoding 404 Note that, as is stated in Section 7 of [RFC8231], the P flag and 405 the I flag of the PCEP objects used on PCUpd and PCRpt messages 406 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 407 since these flags are exclusively related to path computation 408 requests. 410 5. IANA Considerations 412 IANA is requested to allocate new Types for the TLV/Object defined 413 in this document. 415 5.1. New PCEP Error Codes 417 IANA is requested to make the following allocation in the "PCEP- 418 ERROR Object Error Types and Values" registry. 420 Error Type Meaning Reference 422 TBD1 LSP state information missing [This.I-D] 424 Error-value TBD2: LSP state information unavailable [This.I-D] 426 for the LSP re-optimization 428 Error-value TBD4: LSP state information for route 430 exclusion purpose cannot be found [This.I-D] 432 5.2. New Subobject for the Exclude Route Object 434 IANA maintains the "PCEP Parameters" registry containing a 435 subregistry called "PCEP Objects". This registry has a subregistry 436 for the XRO (Exclude Route Object) listing the sub-objects that can 437 be carried in the XRO. IANA is requested to assign a further sub- 438 object that can be carried in the XRO as follows: 440 Value Description Reference 442 ----------+------------------------------+------------- 444 TBD3 LSP identifier sub-object [This.I-D] 446 5.3. New "B" Flag in the SRP Object 448 IANA has created a new subregistry, named "SRP Object Flag Field", 449 within the "Path Computation Element Protocol (PCEP) Numbers" 450 registry, to manage the Flag field of the SRP object. New values 451 are to be assigned by Standards Action [RFC8126]. Each bit is 452 tracked with the following qualities: bit number (counting from bit 453 0 as the most significant bit), description, and defining RFC. 455 The following values are defined in this document: 457 Bit Description Reference 458 --- ---------------------------- ---------- 460 TDB Bi-directional co-routed LSP [This.I-D] 462 6. Manageability Considerations 464 The description and functionality specifications presented related 465 to stateful PCEs should also comply with the manageability 466 specifications covered in Section 8 of [RFC4655]. Furthermore, a 467 further list of manageability issues presented in [RFC8231] should 468 also be considered. 470 Additional considerations are presented in the next sections. 472 6.1. Requirements on Other Protocols and Functional Components 474 When the detailed route information is included for LSP state 475 synchronization (either at the initial stage or during LSP state 476 report process), this requires the ingress node of an LSP carry the 477 RRO object in order to enable the collection of such information. 479 7. Security Considerations 481 This draft provides additional extensions to PCEP so as to 482 facilitate stateful PCE usage in GMPLS-controlled networks, on top 483 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 484 networks should be considered under the same security as for MPLS 485 networks, as noted in [RFC7025]. Therefore, the security 486 considerations elaborated in [RFC5440] still apply to this draft. 487 Furthermore, [RFC8231] provides a detailed analysis of the 488 additional security issues incurred due to the new extensions and 489 possible solutions needed to support for the new stateful PCE 490 capabilities and they apply to this document as well. 492 8. Acknowledgement 494 We would like to thank Adrian Farrel and Cyril Margaria for the 495 useful comments and discussions. 497 9. References 499 9.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 502 requirements levels", RFC 2119, March 1997. 504 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 505 Computation Element (PCE)-Based Architecture", RFC 4655, 506 August 2006. 508 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 509 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 510 March 2009. 512 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 513 Computation Element Communication Protocol (PCEP) 514 Extensions for Stateful PCE", RFC 8231, September 2017. 516 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 517 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 518 extensions, work in progress. 520 9.2. Informative References 522 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 523 Path Computation Element (PCE) ", RFC 8051, January 2017. 525 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 526 and D. Dhody, "Optimizations of Label Switched Path State 527 Synchronization Procedures for a Stateful PCE", RFC 8232, 528 September 2017. 530 10. Contributors' Address 532 Dhruv Dhody 533 Huawei Technology 534 India 536 EMail: dhruv.ietf@gmail.com 538 Yi Lin 539 Huawei Technologies 540 F3-5-B R&D Center, Huawei Base 541 Bantian, Longgang District 542 Shenzhen 518129 P.R.China 543 Phone: +86-755-28972914 544 Email: yi.lin@huawei.com 546 Authors' Addresses 548 Xian Zhang 549 Huawei Technologies 550 F3-5-B R&D Center, Huawei Base 551 Bantian, Longgang District 552 Shenzhen 518129 P.R.China 554 Phone: +86-755-28972645 555 Email: zhang.xian@huawei.com 557 Young Lee (Editor) 558 Huawei 559 5340 Legacy Drive, Suite 170 560 Plano, TX 75023 561 US 563 Phone: +1 469 278 5838 564 EMail: leeyoung@huawei.com 566 Fatai Zhang 567 Huawei 568 F3-5-B R&D Center, Huawei Base 569 Bantian, Longgang District 570 P.R. China 572 Phone: +86-755-28972912 573 Email: zhangfatai@huawei.com 575 Ramon Casellas 576 CTTC 577 Av. Carl Friedrich Gauss n7 578 Castelldefels, Barcelona 08860 579 Spain 581 Phone: 582 Email: ramon.casellas@cttc.es 584 Oscar Gonzalez de Dios 585 Telefonica Investigacion y Desarrollo 586 Emilio Vargas 6 587 Madrid, 28045 588 Spain 590 Phone: +34 913374013 591 Email: ogondio@tid.es 593 Zafar Ali 594 Cisco Systems 595 Email: zali@cisco.com