idnits 2.17.1 draft-leedhody-pce-vn-association-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 -- The document date (June 19, 2019) is 1773 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 PCE Working Group Y. Lee 3 Internet-Draft Futurewei 4 Intended Status: Standards track X. Zhang 5 Expires: December 21, 2019 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 9 June 19, 2019 11 Path Computation Element communication Protocol (PCEP) extensions 12 for Establishing Relationships between sets of LSPs and Virtual 13 Networks 14 draft-leedhody-pce-vn-association-08 16 Abstract 18 This document describes how to extend Path Computation Element (PCE) 19 Communication Protocol (PCEP) association mechanism introduced by the 20 PCEP Association Group specification, to further associate sets of 21 LSPs with a higher-level structure such as a virtual network (VN) 22 requested by clients or applications. This extended association 23 mechanism can be used to facilitate virtual network control using PCE 24 architecture. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 https://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 https://www.ietf.org/shadow.html 46 This Internet-Draft will expire on December 21, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Applicability to H-PCE architecture . . . . . . . . . . . . . . 8 71 6. Implementation Status . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Association Object Type Indicator . . . . . . . . . . . . . 10 76 8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . . 10 77 8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. Manageability Considerations . . . . . . . . . . . . . . . . . 11 79 9.1. Control of Function and Policy . . . . . . . . . . . . . . 11 80 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 81 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 82 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 83 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 84 9.6. Impact On Network Operations . . . . . . . . . . . . . . . 12 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 The Path Computation Element communication Protocol (PCEP) provides 92 mechanisms for Path Computation Elements (PCEs) to perform path 93 computations in response to Path Computation Clients' (PCCs) 94 requests. 96 [RFC8051] describes general considerations for a stateful PCE 97 deployment and examines its applicability and benefits, as well as 98 its challenges and limitations through a number of use cases. 99 [RFC8231] describes a set of extensions to PCEP to provide stateful 100 control. A stateful PCE has access to not only the information 101 carried by the network's Interior Gateway Protocol (IGP), but also 102 the set of active paths and their reserved resources for its 103 computations. The additional state allows the PCE to compute 104 constrained paths while considering individual LSPs and their 105 interactions. 107 [RFC8281] describes the setup, maintenance and teardown of PCE- 108 initiated LSPs under the stateful PCE model. 110 [I-D.ietf-pce-association-group] introduces a generic mechanism to 111 create a grouping of LSPs. This grouping can then be used to define 112 association between sets of LSPs or between a set of LSPs and a set 113 of attributes. 115 [RFC8453] describes various Virtual Network (VN) operations initiated 116 by a customer/application. In this context, there is a need for 117 associating a set of LSPs with a VN "construct" to facilitate VN 118 operations in PCE architecture. This association allows the PCEs to 119 identify which LSPs belong to a certain VN. The PCE could then use 120 this association to optimize all LSPs belonging to the VN together. 121 The PCE could further take VN specific actions on the LSPs such as 122 relaxation of constraints, policy actions, setting default behavior 123 etc. 125 [I-D.ietf-pce-applicability-actn] examines the PCE and ACTN 126 architecture and describes how the PCE architecture is applicable to 127 ACTN. [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a 128 hierarchy of stateful PCEs with Parent PCE coordinating multi-domain 129 path computation function between Child PCE(s) and thus making it the 130 base for PCE applicability for ACTN. In this text child PCE would be 131 same as Provisioning Network Controller (PNC), and the parent PCE as 132 Multi-domain Service Coordinator (MDSC) [RFC8453]. 134 This document specifies a PCEP extension to associate a set of LSPs 135 based on Virtual Network (VN) (or customer). A Virtual Network (VN) 136 is a customer view of the TE network. Depending on the agreement 137 between client and provider various VN operations and VN views are 138 possible as described in [RFC8453]. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2. Terminology 150 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] 151 and [RFC8453]. 153 3. Operation Overview 155 As per [I-D.ietf-pce-association-group], LSPs are associated with 156 other LSPs with which they interact by adding them to a common 157 association group. 159 An association group based on VN is useful for various optimizations 160 that should be applied by considering all the LSPs in the 161 association. This includes, but not limited to - 163 o Path Computation: When computing path for a LSP, the impact of 164 this LSP, on the other LSPs belonging to the same VN is useful to 165 analyze. The aim would be optimize overall VN and all LSPs, rather 166 than a single LSP. Also, the optimization criteria such as 167 minimize the load of the most loaded link (MLL) [RFC5541] and 168 other could be applied for all the LSP belonging to the same VN, 169 identified by the VN association. 171 o Path Re-Optimization: The child PCE or the parent PCE would like 172 to use advanced path computation algorithm and optimization 173 technique that consider all the LSPs belonging to a VN/customer 174 and optimize them all together during the re-optimization. 176 This association is useful in PCEP session between parent PCE 177 (MDSC) and child PCE (PNC). The figure describes a typical VN 178 operations using PCEP for illustration purpose. 180 ****** 181 ..........*MDSC*.............................. 182 . ****** .. MPI . 183 . . . PCEP . 184 . . . PCInitiate LSPx . 185 . . . with VNAG = 10 . 186 . . . . 187 . . . . 188 . . . . 189 v v v . 190 ****** ****** ****** . 191 *PNC1* *PNC2* *PNC4* . 192 ****** ****** ****** . 193 +---------------+ +---------------+ +---------------+ . 194 |A |----| |----| C| . 195 | | | | | | . 196 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 197 +------------B13+ +---------------+ +B43------------+ . 198 / . 199 ****** / . 200 *PNC3*<............/..................... 201 ****** / 202 +---------------+/ 203 B31 B34 204 | | 205 |DOMAIN 3 B| 206 +---------------+ 208 MDSC -> Parent PCE 209 PNC -> Child PCE 210 MPI -> PCEP 212 In this draft, this grouping is used to define associations between a 213 set of LSPs and a virtual network, a new association group is defined 214 below - 216 o VN Association Group (VNAG) 218 One new Association type is defined as described in the Association 219 object - 221 o Association type = TBD1 ("VN Association") for VNAG 223 The scope and handling of VNAG identifier is similar to the generic 224 association identifier defined in [I-D.ietf-pce-association-group]. 226 In this document VNAG object refers to an Association Object with the 227 Association type set to "VNAG". 229 Local polices on the PCE MAY define the computational and 230 optimization behavior for the LSPs in the VN. An LSP MUST NOT belong 231 to more than one VNAG. If an implementation encounters more than one 232 VNAG, it MUST consider the first occurrence and ignore the others. 234 [I-D.ietf-pce-association-group] specify the mechanism for the 235 capability advertisement of the association types supported by a PCEP 236 speaker by defining a ASSOC-Type-List TLV to be carried within an 237 OPEN object. This capability exchange for the association type 238 described in this document (i.e. VN Association Type) MUST be done 239 before using the policy association. Thus the PCEP speaker MUST 240 include the VN Association Type (TBD1) in the ASSOC-Type-List TLV 241 before using the VNAG in the PCEP messages. 243 This Association-Type is dynamic in nature and created by the Parent 244 PCE (MDSC) for the LSPs belonging to the same VN or customer. These 245 associations are conveyed via PCEP messages to the PCEP peer. 246 Operator-configured Association Range MUST NOT be set for this 247 association-type and MUST be ignored. 249 4. Extensions to PCEP 251 The format of VNAG is as per the ASSOCIATION object [I-D.ietf-pce- 252 association-group]. 254 This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one 255 new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, 256 VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific 257 information. 259 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 261 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 262 specific behavioral information, described in [RFC7470]. 264 The format of VIRTUAL-NETWORK-TLV is as follows. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type=TBD2 | Length (variable) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 // Virtual Network Name // 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 1: The VIRTUAL-NETWORK-TLV formats 277 Type: TBD2 (to be allocated by IANA) 279 Length: Variable Length 281 Virtual Network Name (variable): an unique symbolic name for the VN. 282 It SHOULD be a string of printable ASCII characters, without a NULL 283 terminator. The VN name is a human-readable string that identifies 284 a VN. The VN name MUST remain constant throughout an LSP's lifetime, 285 which may span across multiple consecutive PCEP sessions and/or 286 PCC restarts. The VN name MAY be specified by an operator or 287 auto-generated by the PCEP speaker. 289 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 290 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 291 MUST send a PCErr message with Error-Type=6 (mandatory object 292 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 293 the session. 295 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 297 5. Applicability to H-PCE architecture 299 The ability to compute shortest constrained TE LSPs in Multiprotocol 300 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 301 multiple domains has been identified as a key motivation for PCE 302 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 303 architecture which can be used for computing end-to-end paths for 304 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 305 Paths (LSPs). Within the hierarchical PCE architecture, the parent 306 PCE is used to compute a multi-domain path based on the domain 307 connectivity information. A child PCE may be responsible for a 308 single domain or multiple domains, it is used to compute the intra- 309 domain path based on its domain topology information. 311 [I-D.ietf-pce-stateful-hpce] introduces general considerations for 312 stateful PCE(s) in hierarchical PCE architecture. In particular, the 313 behavior changes and additions to the existing stateful PCE 314 mechanisms in the context of a H-PCE architecture. 316 In Stateful H-PCE architecture, the Parent PCE receives a virtual 317 network creation request by its client over its Northbound API. This 318 VN is uniquely identified by an Association ID in VNAG as well as the 319 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 320 network in a single domain or across multiple domains. 322 As the Parent PCE computes the optimum E2E paths for each tunnel in 323 VN, it MUST associate each LSP with the VN to which it belongs. 324 Parent PCE sends a PCInitiate Message with this association 325 information in the VNAG Object (See Section 4 for details). This in 326 effect binds an LSP that is to be instantiated at the child PCE with 327 the VN. 329 Whenever changes occur with the instantiated LSP in a domain network, 330 the domain child PCE reports the changes using a PCRpt Message in 331 which the VNAG Object indicates the relationship between the LSP and 332 the VN. 334 Whenever an update occurs with VNs in the Parent PCE (via the 335 client's request), the parent PCE sends an PCUpd Message to inform 336 each affected child PCE of this change. 338 The Child PCE could then use this association to optimize all LSPs 339 belonging to the same VN association together. The Child PCE could 340 further take VN specific actions on the LSPs such as relaxation of 341 constraints, policy actions, setting default behavior etc. The parent 342 PCE could also maintain all E2E LSP or per-domain path segments under 343 a single VN association. 345 6. Implementation Status 347 [Note to the RFC Editor - remove this section before publication, as 348 well as remove the reference to RFC 7942.] 350 This section records the status of known implementations of the 351 protocol defined by this specification at the time of posting of this 352 Internet-Draft, and is based on a proposal described in RFC 7942 353 [RFC7942]. The description of implementations in this section is 354 intended to assist the IETF in its decision processes in progressing 355 drafts to RFCs. Please note that the listing of any individual 356 implementation here does not imply endorsement by the IETF. 357 Furthermore, no effort has been spent to verify the information 358 presented here that was supplied by IETF contributors. This is not 359 intended as, and must not be construed to be, a catalog of available 360 implementations or their features. Readers are advised to note that 361 other implementations may exist. 363 According to RFC 7942, "this will allow reviewers and working groups 364 to assign due consideration to documents that have the benefit of 365 running code, which may serve as evidence of valuable experimentation 366 and feedback that have made the implemented protocols more mature. It 367 is up to the individual working groups to use this information as 368 they see fit". 370 6.1. Huawei's Proof of Concept based on ONOS 371 The PCE function was developed in the ONOS open source platform. This 372 extension was implemented on a private version as a proof of concept 373 to ACTN. 375 o Organization: Huawei 377 o Implementation: Huawei's PoC based on ONOS 379 o Description: PCEP as a southbound plugin was added to ONOS. To 380 support ACTN, this extension in PCEP is used. Refer 381 https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 383 o Maturity Level: Prototype 385 o Coverage: Full 387 o Contact: satishk@huawei.com 389 7. Security Considerations 391 This document defines one new type for association, which do not 392 add any new security concerns beyond those discussed in [RFC5440], 393 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 395 Some deployments may find the Virtual Network Name and the VN 396 associations as extra sensitive; and thus should employ suitable 397 PCEP security mechanisms like TCP-AO [RFC5925] or [RFC8253]. 399 8. IANA Considerations 401 8.1. Association Object Type Indicator 403 This document defines a new association type, originally defined 404 in [I-D.ietf-pce-association-group], for path protection. IANA is 405 requested to make the assignment of a new value for the sub- 406 registry "ASSOCIATION Type Field" (request to be created in [I- 407 D.ietf-pce-association-group]), as follows: 409 Value Name Reference 411 TBD1 VN Association Type [This I.D.] 413 8.2. PCEP TLV Type Indicator 415 This document defines a new TLV for carrying additional 416 information of LSPs within a path protection association group. 417 IANA is requested to make the assignment of a new value for the 418 existing "PCEP TLV Type Indicators" registry as follows: 420 Value Name Reference 422 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 424 8.3. PCEP Error 426 This document defines new Error-Type and Error-Value related to 427 path protection association. IANA is requested to allocate new 428 error values within the "PCEP-ERROR Object Error Types and Values" 429 sub- registry of the PCEP Numbers registry, as follows: 431 Error-Type Meaning 433 6 Mandatory Object missing 434 Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This 435 I.D.] 437 9. Manageability Considerations 439 9.1. Control of Function and Policy 441 An operator MUST BE allowed to mark LSPs that belong to the same 442 VN. This could also be done automatically based on the VN 443 configuration. 445 9.2. Information and Data Models 447 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 448 association between LSPs including VN association. 450 9.3. Liveness Detection and Monitoring 452 Mechanisms defined in this document do not imply any new liveness 453 detection and monitoring requirements in addition to those already 454 listed in [RFC5440]. 456 9.4. Verify Correct Operations 458 Mechanisms defined in this document do not imply any new operation 459 verification requirements in addition to those already listed in 460 [RFC5440]. 462 9.5. Requirements On Other Protocols 464 Mechanisms defined in this document do not imply any new 465 requirements on other protocols. 467 9.6. Impact On Network Operations 469 Mechanisms defined in this document do not have any impact on 470 network operations in addition to those already listed in 471 [RFC5440]. 473 10. References 475 10.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, DOI 479 10.17487/RFC2119, March 1997. 481 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 482 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 483 March 2009. 485 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 486 2119 Key Words", BCP 14, RFC 8174, May 2017. 488 [RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP 489 Extensions for Stateful PCE", RFC 8231, September 2017. 491 [RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP 492 Setup in a Stateful PCE Model", RFC 8281, December 2017. 494 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 495 Establishing Relationships Between Sets of LSPs", draft- 496 ietf-pce-association-group, work in progress. 498 10.2. Informative References 500 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation 501 Element (PCE)-Based Architecture", RFC 4655, August 2006. 503 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 504 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 505 June 2010, . 507 [RFC6805] A. Farrel and D. King, "The Application of the Path 508 Computation Element Architecture to the Determination of a 509 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 510 2012. 512 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 513 Code: The Implementation Status Section", BCP 205, RFC 514 7942, DOI 10.17487/RFC7942, July 2016. 516 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 517 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 518 DOI 10.17487/RFC8453, August 2018, . 521 [I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D. 522 Ceccarelli, "Applicability of Path Computation Element 523 (PCE) for Abstraction and Control of TE Networks (ACTN)", 524 draft-ietf-pce-applicability-actn, work-in-progress. 526 [I-D.ietf-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical 527 Stateful Path Computation Element (PCE)", 528 draft-ietf-pce-stateful-hpce, work in progress. 530 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 531 Objective Functions in the Path Computation Element 532 Communication Protocol (PCEP)", RFC 5541, 533 DOI 10.17487/RFC5541, June 2009, 534 . 536 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 537 Constraints in the Path Computation Element Communication 538 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 539 . 541 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 542 Stateful Path Computation Element (PCE)", RFC 8051, 543 DOI 10.17487/RFC8051, January 2017, 544 . 546 [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 547 Transport for PCEP", RFC 8253, October 2017 . 549 [I-D.ietf-pce-pcep-yang] 550 Dhody, D., Hardwick, J., Beeram, V., and j. 551 jefftant@gmail.com, "A YANG Data Model for Path 552 Computation Element Communications Protocol (PCEP)", 553 draft-ietf-pce-pcep-yang (work in progress). 555 Contributor's Addresses 557 Dhruv Dhody 558 Huawei Technologies 559 Divyashree Technopark, Whitefield 560 Bangalore, Karnataka 560066 561 India 563 Email: dhruv.ietf@gmail.com 565 Qin Wu 566 Huawei Technologies 567 China 569 Email: bill.wu@huawei.com 571 Author's Addresses 573 Young Lee 574 Futurewei 575 5340 Legacy Drive, Building 3 576 Plano, TX 75023, 577 USA 579 Email: younglee.tx@gmail.com 581 Xian Zhang 582 Huawei Technologies 583 China 585 Email: zhang.xian@huawei.com 587 Daniele Ceccarelli 588 Ericsson 589 Torshamnsgatan,48 590 Stockholm, 591 Sweden 593 Email: daniele.ceccarelli@ericsson.com