idnits 2.17.1 draft-xu-l2vpn-vpls-isis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2012) is 4298 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) == Unused Reference: 'RFC5331' is defined on line 503, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-xu-mpls-in-udp-01 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 2 Internet Draft Huawei 3 Category: Standard Track H. Shah 4 Ciena Corp 5 L. Yong 6 Huawei 7 Y. Fan 8 China Telecom 10 Expires: January 2013 July 13, 2012 12 Virtual Private LAN Service (VPLS) Using IS-IS 14 draft-xu-l2vpn-vpls-isis-04 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 reference 29 material or to cite them other than as "work in 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 January 13, 2013. 39 Copyright Notice 41 Copyright (c) 2009 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. 51 Abstract 53 This document describes a light-weight Virtual Private LAN Service 54 (VPLS), referred to as IS-IS VPLS, which uses IS-IS for auto- 55 discovery and signaling. IS-IS VPLS is intended to be used as a 56 scalable cloud data center network solution. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [RFC2119]. 64 Table of Contents 66 1. Introduction ................................................ 3 67 2. Terminology ................................................. 5 68 3. Control Plane ............................................... 6 69 3.1. VPLS Info TLV .......................................... 6 70 3.2. Auto-discovery ......................................... 7 71 3.3. Signaling .............................................. 8 72 4. Data Plane .................................................. 8 73 4.1. Data Encapsulation and Forwarding ...................... 8 74 4.1.1. Unicast ........................................... 8 75 4.1.2. Multicast/Broadcast .............................. 8 76 4.2. MAC Address Learning ................................... 9 77 4.2.1. Data-plane based MAC Learning ..................... 9 78 4.2.2. Control-plane based MAC Learning ................. 10 79 5. ARP Broadcast Reduction .................................... 10 80 6. Security Considerations .................................... 10 81 7. IANA Considerations ........................................ 10 82 8. Acknowledgements ........................................... 11 83 9. References ................................................. 11 84 9.1. Normative References .................................. 11 85 9.2. Informative References ................................ 11 86 10. Authors' Addresses ........................................ 12 88 1. Introduction 90 For leveraging the economics of scale, today's cloud data centers 91 tend to contain tens to hundreds of thousands of servers. Moreover 92 distributed computing and server virtualization are increasingly 93 adopted in today's cloud data centers. These factors lead to 94 significant scaling, performance, and operational challenges for 95 cloud data center networks. Therefore, to design a scalable and 96 sustainable cloud data center network solution, the following 97 requirements must be taken into account: 99 1) LAN Extension 101 To achieve service agility and business continuance, Virtual 102 Machine (VM) migration and High-Available (HA) cluster are 103 commonly used in today's cloud data centers. These two 104 applications introduce special requirements on data center 105 networks. For instance, to allow a VM to be freely migrated from 106 one server to another within data centers while retaining its IP 107 address and MAC address, the LAN where the VM is located needs to 108 be extend across multiple racks or pods within data centers. In 109 addition, as some HA cluster applications rely on link-local 110 multicast for cluster member discovery and heartbeat, cluster 111 member servers are usually required to reside within the same 112 Layer2 domain. As a result, LAN extension becomes a fundamental 113 requirement for cloud data center networks. 115 2) VPN Instance Space Scalability 117 In modern cloud data centers, tens of thousands of tenants (e.g., 118 enterprises or governments who consume computing resources such 119 as Infrastructure-as-a-Service (IaaS) offered by cloud service 120 providers), could be hosted over a shared network infrastructure. 121 For security and performance isolation considerations, these 122 tenants SHOULD be isolated from one another. Hence, cloud data 123 center networks SHOULD provide a large enough VPN instance space 124 for tenant isolation. 126 3) Forwarding Table Scalability 128 In a highly virtualized cloud data center environment, it's not 129 uncommon that millions of VMs are contained over a common network 130 infrastructure. Therefore, the forwarding table of each network 131 device within cloud data center networks SHOULD be scalable 132 enough so as to keep up with that scale of VMs. 134 4) Bandwidth Utilization Maximization 136 In modern cloud data centers, distributed computing is driving the 137 server-to-sever traffic to become the dominating traffic compared 138 to the client-to-server traffic. To meet the growing capacity 139 demands for server-to-server connectivity, shortest path 140 forwarding and Equal Cost Multi-Path (ECMP) have already been the 141 basic capabilities of cloud data center networks. 143 5) ARP/Unknown Unicast Flood Suppression 145 It's well-known that the flooding of ARP broadcast and unknown 146 unicast traffic within large Layer2 networks will lead to 147 performance impact on both networks and hosts. As the Layer2 148 domain is extended across multiple racks or pods within data 149 centers, the above problem will become even worse. As such, how 150 to suppress the flooding of ARP broadcast and unknown unicast 151 traffic within cloud data centers becomes increasingly desirable. 153 6) Flexibility for Tradeoffs between Bandwidth and State 155 It's possible that there would be a great difference between 156 tenants within a cloud data center, in terms of VM numbers or 157 multicast/broadcast traffic volume. For example, some tenants may 158 have seldom VMs while others may have a lot of VMs, or some 159 tenants may have a high volume of multicast/broadcast traffic 160 while others may have little or even no multicast/broadcast 161 traffic. As such, there is no "one size fits all" VPN 162 multicast/broadcast delivery procedure for these tenants. Hence, 163 cloud data center networks SHOULD support both the ingress 164 replication procedure and the multicast tree procedure for 165 delivering VPN multicast/broadcast traffic, so as to allow for an 166 effective tradeoff between bandwidth usage and state maintenance 167 on a per tenant basis according to the particular conditions of 168 each tenant. 170 7) Simplified Provisioning and Operation 172 It's not surprising that a single cloud data center has thousands 173 of physical switches (e.g., ToR switches). However, a network of 174 such scale usually implies a big challenge for data center 175 operators. Therefore, how to simplify and even automate network 176 provisioning and operation becomes significantly important for 177 cloud data center networks. 179 8) Reuse Existing Operation Experiences 180 IP, as a proven routing technology, has already been used in most 181 today's data centers. Furthermore, those service providers who 182 are planning to build cloud data centers have years of experience 183 in operating MPLS-based L2VPN and/or L3VPN services which can be 184 transported over MPLS or IP-enabled Packet Switching Networks 185 (PSNs). To allow data center operators to reuse their existing 186 network operation experiences, cloud data center network 187 solutions SHOULD reuse existing technologies and protocols where 188 appropriate, rather than reinventing the wheel. That's why there 189 are increasing interests from the industrial community on how to 190 adopt or adapt the existing L2VPN and/or L3VPN technologies for 191 cloud data center networks. 193 Although the existing VPLS solutions [RFC4761, RFC4762] can meet 194 most of the above requirements, there are still spaces for 195 improvement. For instance, the existing VPLS solutions require 196 establishing full-mesh of pseudo-wires (PWs) between PE routers, 197 which implies a significant scaling challenge in the cloud data 198 center environment, especially when imagining configuring thousands 199 of ToR switches as PE routers and provisioning tens of thousands of 200 VPLS instances on them; secondly, the ingress replication procedure 201 used for delivering multicast and broadcast traffic in existing VPLS 202 solutions is not optimal from the bandwidth utilization perspective; 203 thirdly, existing VPLS solutions require running one or more 204 separate protocols besides IGP within data centers for VPLS protocol 205 (e.g., LDP and/or BGP), which results in a certain complexity in 206 network management and operation, especially when considering 207 configuring BGP and VPLS parameters on thousands of ToR switches and 208 configuring thousands of BGP peers on aggregation or core switches. 210 Hence, this document describes a light-weight VPLS solution, 211 referred to as IS-IS VPLS, which uses IS-IS [IS-IS][RFC1195] for 212 VPLS protocol. IS-IS VPLS retains almost all advantages of existing 213 VPLS solutions (e.g., split-horizon forwarding) while overcoming 214 their shortages as mentioned above. For example, there is no need 215 for full-mesh PWs between PE routers in IS-IS VPLS. Furthermore, it 216 allows data center operators to flexibly make tradeoffs between 217 bandwidth and state on a per tenant basis. Finally, an already 218 deployed IGP within cloud data centers (i.e., IS-IS), rather than a 219 dedicated protocol(s), is used for providing VPLS services. 221 2. Terminology 223 This memo makes use of the terms defined in [RFC4664], [VPLS-MCAST], 224 [RFC4761] and [RFC4762]. 226 3. Control Plane 228 There are two primary functions of the VPLS control plane: auto- 229 discovery and signaling. In IS-IS VPLS, these two functions are 230 accomplished by using a single extended IS-IS TLV, referred to as 231 VPLS Info TLV (see section 3.1). By propagating such VPLS Info TLVs 232 that contain VPLS information within data center networks, PE 233 routers automatically discover which other PE routers are part of a 234 given VPLS instance and their assigned VPLS labels for that VPLS 235 instance. Furthermore, according to the ISIS specification defined 236 in [IS-IS] and [RFC1195], IS-IS routers would ignore unknown TLVs in 237 the LSP and pass them on to other neighbors unchanged. Therefore, P 238 routers don't need processing the VPLS info TLV, but instead 239 synchronizing the Link State PDUs (LSP) containing such TLV with 240 their adjacent IS-IS neighbors as normal. In addition, to overcome 241 the 255-byte TLV limit, IS-IS allows the interpretation of multiple 242 TLVs of a given type to be considered additive rather than mutually 243 exclusive (see section 6.4 in [RFC5311] for more details), therefore 244 there is no scaling issue in using IS-IS for propagating a huge 245 amount of VPLS information. 247 3.1. VPLS Info TLV 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+ 252 |Type=VPLS Info | 253 +-+-+-+-+-+-+-+-+ 254 | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 | PE's IPv4 or IPv6 Address | 258 | (128 bits) | 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Resv (12 bits) | VPLS ID (20 bits) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Resv (12 bits) | VPLS Label (20 bits) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 : : 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Resv (12 bits) | VPLS ID (20 bits) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Resv (12 bits) | VPLS Label (20 bits) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type 274 Type code for VPLS Info TLV: TBD. 276 Length 278 Total number of bytes contained in the value field. 280 PE's IPv4 or IPv6 Address 282 This 128-bit field is filled with one of the originating PE 283 router's IPv4 or IPv6 addresses which are reachable across 284 the IP backbone. The address filled in this field SHOULD be 285 used as a tunnel destination address by remote PE routers 286 when these PE routers acting as ingress PE routers want to 287 tunnel a customer Ethernet frame to such PE router. If the 288 IP address is IPv4, the last four octets of this field are 289 filled with the IPv4 address while the remaining part is set 290 to zero. In other words, it is filled with an IPv4-mapped 291 IPv6 address. 293 VPLS ID 295 This field is filled with a 20-bit globally unique VPLS ID 296 for a particular attached VPLS instance. In case that a 297 larger VPLS ID space is required, the leftmost 12-bit 298 reserved field could be used together with the VPLS ID field 299 as an extended VPLS ID field. That is to say, the whole 32 300 bits are filled with a 32-bit long extended VPLS ID value. 302 VPLS Label 304 This field is filled with a 20-bit MPLS label corresponding 305 to the VPLS instance which is identified by the VPLS ID. 307 3.2. Auto-discovery 309 In IS-IS VPLS, each PE router could automatically discover which 310 other PE routers are part of a given VPLS instance that is 311 identified by the globally unique VPLS ID. This allows each PE 312 router to be configured with only the identities of the attached 313 VPLS instances, but not identities of all the other PE routers 314 belonging to these VPLS instances. 316 3.3. Signaling 318 In IS-IS VPLS, a PE router would assign the same VPLS label for a 319 given VPLS instance to any other PE router. As such, this VPLS label 320 is only used for identifying a particular VPLS instance, rather than 321 identifying both a particular VPLS instance and the corresponding 322 ingress PE router as a PW label does. 324 4. Data Plane 326 4.1. Data Encapsulation and Forwarding 328 Since the VPLS label in IS-IS VPLS is only used for identifying a 329 particular VPLS instance, in the data-plane based MAC learning case 330 (see section 4.2.1), IP-based tunnel (e.g., GRE (Generic Routing 331 Encapsulation)/IP [RFC4023] or UDP [MPLS-in-UDP]) is RECOMMENDED to 332 be used as the PE-to-PE tunnel technology. As such, during the MAC 333 learning process, egress PE router could easily determine the 334 ingress PE router of the received VPLS packet from the tunnel source 335 address of that packet. Note that, in the control-plane based MAC 336 learning case (see section 4.2.2), there is no special requirement 337 for PE-to-PE tunnel technology in comparison with existing VPLS 338 solutions. The following sub-sections are based on an assumption 339 that IP tunnels are used between PE routers. 341 4.1.1. Unicast 343 For known unicast, MAC-in-MPLS-in-IP encapsulation [RFC4448] is used. 344 For unknown unicast, the encapsulation and forwarding procedures are 345 the same as that for multicast/broadcast described in the following 346 section. 348 4.1.2. Multicast/Broadcast 350 There are two major modes for delivering multicast and broadcast in 351 IS-IS VPLS: ingress replication mode and P-Multicast tree mode. P- 352 Multicast tree mode further includes two sub-options: non- 353 aggregative P-Multicast tree mode where one P-Multicast distribution 354 tree in the IP backbone is exclusively used by a single VPLS 355 instance, and aggregative P-Multicast tree mode in which one P- 356 Multicast tree is shared by more than one VPLS instance. The 357 corresponding encapsulation for each mode is described in the 358 following sub-sections. 360 4.1.2.1. Ingress Replication Mode 362 In the ingress replication mode, an ingress PE router forward the 363 received customer multicast/broadcast frames towards remote PE 364 routers in separate tunnels. Hence, the encapsulation in this mode 365 has no difference from that for unicast. 367 4.1.2.2. Non-aggregative P-Multicast Tree Mode 369 In the non-aggregative P-Multicast tree mode, MAC-in-IP 370 encapsulation is used directly since the destination IP address 371 (i.e., multicast address) contained in the IP-based tunnel header is 372 enough for egress PE routers to determine which VPLS instance the 373 received VPLS packet belongs to. 375 4.1.2.3. Aggregative P-Multicast Tree Mode 377 For the aggregative P-Multicast tree mode, MAC-in-MPLS-in-IP 378 encapsulation SHOULD be used. Furthermore, the MPLS label here 379 SHOULD be treated as an upstream-assigned label. For example, assume 380 a PE router has assigned a local label L for a given VPLS instance 381 and advertised that VPLS information using the VPLS Info TLV before, 382 when this PE router wants to send a multicast VPLS packet of that 383 VPLS instance through the corresponding aggregative P-Multicast tree, 384 label L as an upstream-assigned label will be contained in that VPLS 385 packet. 387 4.2. MAC Address Learning 389 MAC addresses of local CE hosts would still be learnt by PE routers 390 as normal bridges. 392 As for learning MAC addresses of remote CE hosts, IS-IS VPLS 393 provides two options: data-plane based MAC learning and control- 394 plane based MAC learning. If unknown unicast flood suppression is 395 required even at the cost of consuming more forwarding table 396 resources, the control-plane based MAC learning option could be 397 considered. Otherwise, the data-plane based MAC learning option 398 SHOULD be preferred. 400 4.2.1. Data-plane based MAC Learning 402 Upon receiving an VPLS packet from a remote PE router, the MPLS 403 label contained in the packet (or the tunnel destination IP address 404 in the non-aggregative P-Multicast tree case) is used to determine 405 the particular VPLS instance that the packet belongs to, while the 406 tunnel source IP address is used to tell from which ingress PE 407 router the packet was sent. 409 4.2.2. Control-plane based MAC Learning 411 In IS-IS VPLS, MAC addresses of remote CE hosts can also be learnt 412 on the control plane by using the MAC-Reachability TLV defined in 413 [RFC6165]. 415 Upon learning the MAC addresses of their local CE hosts, PE routers 416 would immediately advertise these MAC addresses to other PE routers 417 of the same VPN instance by using the MAC-Reachability TLV defined 418 in [RFC6165]. One or more MAC-Reachability TLVs are carried in a LSP 419 which in turn is encapsulated with an Ethernet header. The source 420 MAC address is the originating PE router's MAC address whereas the 421 destination MAC address is a to-be-defined multicast MAC address 422 specifically identifying IS-IS VPLS PE routers. Such LSPs are 423 forwarded towards remote PE routers as customer Ethernet frames by 424 ingress PE routers. Egress PE routers receiving the above packets 425 SHOULD intercept them and accordingly process them. IP address of 426 the PE router originating these MAC routes could be derived either 427 from the "IP Interface Address" field contained in the corresponding 428 LSPs (Note that the IP address here SHOULD be identical with that 429 contained in the VPLS Info TLV) or from the tunnel source IP address 430 of the VPLS packet containing such MAC routes. 432 Since these LSPs are fully transparent to P routers, there is no 433 impact on the control plane of P routers. More details about the 434 control-plane based MAC learning procedure are for further study. 436 5. ARP Broadcast Reduction 438 To suppress ARP broadcast flood within a given VPLS instance, ARP 439 cache mechanism can be enabled on PE routers. For more details about 440 ARP cache mechanism, please refer to [ARP-Reduction] 442 6. Security Considerations 444 This document doesn't introduce additional security risk to IS-IS 445 and VPLS, nor does it provide any additional security feature for 446 IS-IS and VPLS. 448 7. IANA Considerations 450 The IS-IS TLV type code for VPLS Info TLV is required to be defined 451 by IANA. 453 8. Acknowledgements 455 Thanks to Tony Li, Peter Ashwood-Smith, Phil Bedard, Kris Price, 456 Shahram Davari, Adrian Farrel, Giles Heron and Christian Jacquenet 457 for their valuable comments on this proposal. 459 9. References 461 9.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 9.2. Informative References 468 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 469 Intra-Domain Routing Exchange Protocol for use in 470 Conjunction with the Protocol for Providing the 471 Connectionless-mode Network Service (ISO 8473)", 2005. 473 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 474 Dual Environments", RFC 1195 1990. 476 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 477 "Simplified Extension of Link State PDU (LSP) Space for 478 IS-IS", RFC 5311, 2009. 480 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 481 "Encapsulation Methods for Transport of Ethernet over MPLS 482 Networks", RFC 4448, April 2006. 484 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 485 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 486 4023, March 2005. 488 [MPLS-in-UDP] X. Xu, et al., "Encapsulating MPLS in UDP", draft-xu- 489 mpls-in-udp-01.txt (work in progress), May 2012. 491 [RFC6165] A. Banerjee., D. Ward, "Extensions to IS-IS for Layer-2 492 Systems", RFC 6165, February 2011. 494 [VPLS-MCAST] R. Aggarwal., Y. Kamite., L. Fang, "Multicast in VPLS", 495 draft-ietf-l2vpn-vpls-mcast-08.txt (work in progress), 496 October 2010. 498 [ARP-Reduction] H. Shah., A. Ghanwani., and N. Bitar, "ARP Broadcast 499 Reduction for Large Data Centers", 500 draft-shah-armd-arp-reduction-02.txt (work in progress), 501 October 2011. 503 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 504 Assignment and Context-Specific Label Space", RFC 5331, 505 August 2008. 507 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 508 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. 510 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 511 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 512 4761, January 2007. 514 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 515 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 516 RFC 4762, January 2007. 518 10. Authors' Addresses 520 Xiaohu Xu 521 Huawei Technologies, 522 Beijing, China 523 Email: xuxiaohu@huawei.com 525 Himanshu Shah 526 Ciena Corp 527 Email: hshah@ciena.com 529 Lucy Yong 530 Huawei USA 531 1700 Alma Dr. Suite 500 532 Plano, TX 75075, US 533 Email: lucyyong@huawei.com 535 Yongbing Fan 536 China Telecom 537 Guangzhou, China. 538 Phone: +86 20 38639121 539 Email: fanyb@gsta.com