idnits 2.17.1 draft-li-idr-cc-bgp-arch-00.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 (October 20, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4271' is mentioned on line 86, but not defined == Missing Reference: 'RFC 4760' is mentioned on line 88, but not defined == Missing Reference: 'RFC 4724' is mentioned on line 287, but not defined == Unused Reference: 'RFC4271' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'I-D.chen-idr-rr-based-traffic-steering-usecase' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'I-D.li-l2vpn-segment-evpn' is defined on line 490, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-04 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-04 == Outdated reference: A later version (-01) exists of draft-li-l2vpn-segment-evpn-00 == Outdated reference: A later version (-02) exists of draft-li-mpls-global-label-framework-00 == Outdated reference: A later version (-03) exists of draft-li-mpls-global-label-usecases-00 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft M. Chen 4 Intended status: Informational S. Zhuang 5 Expires: April 23, 2014 Huawei Technologies 6 October 20, 2013 8 An Architecture of Central Controlled Border Gateway Protocol (BGP) 9 draft-li-idr-cc-bgp-arch-00 11 Abstract 13 As the Software Defined Networks (SDN) solution develops, BGP is 14 extended to support central control. This document introduces an 15 architecture of using BGP for central controlling. Some use cases 16 under this new framework are also discussed. For specific use cases, 17 making necessary extensions in BGP are required. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 23, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Deployment Mode . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Requirement of Protocol Extensions . . . . . . . . . . . 5 65 3.3.1. Building Connectivity . . . . . . . . . . . . . . . . 5 66 3.3.2. Roles Auto-Discovery . . . . . . . . . . . . . . . . 6 67 3.3.3. Establishing BGP Sessions . . . . . . . . . . . . . . 6 68 3.3.4. Capability Negotiation . . . . . . . . . . . . . . . 6 69 3.3.5. High Availability . . . . . . . . . . . . . . . . . . 6 70 3.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Network Topology Acquirement . . . . . . . . . . . . . . 7 73 4.2. Simplifying Network Operation and Maintenance . . . . . . 7 74 4.3. MPLS Global Label Allocation . . . . . . . . . . . . . . 8 75 4.4. RR-Based Traffic Steering . . . . . . . . . . . . . . . . 8 76 4.5. Inter-Controller Applications . . . . . . . . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 7.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 The Border Gateway Protocol (BGP) defined in [RFC 4271], is well- 87 known as Internet inter-domain routing protocol. Multiprotocol BGP 88 (MP-BGP) framework defined in [RFC 4760], is an extension to BGP that 89 enables BGP to carry routing information for multiple network layers 90 and address families. The current MP-BGP specification can provide a 91 rich service set within a BGP enabled network, such as L2VPN, L3VPN, 92 MVPN, EVPN,etc. 94 There have been some BGP-based central controlled applications, such 95 as BGP RR [RFC4456]. A route reflector (RR) is a network routing 96 component. The purpose of the RR is concentration in that way all 97 Client's forwarding routes are exchanged by the central RR Router. 98 It offers an alternative to the logical full-mesh requirement of 99 internal border gateway protocol (IBGP). A RR acts as a focal point 100 for IBGP sessions. Multiple IBGP routers can only peer with a 101 central point, rather than peer with every other router in a full 102 mesh manner. All the other IBGP routers become route reflector 103 clients. 105 With the emergence of Software Defined Networks (SDN), BGP plays as 106 an important part in a central controlled environment. 108 1 Building a central controlled framework for Controller and its 109 Clients, BGP can be used to communicate between Controller and its 110 Clients, Controller and other Controllers. The information carried 111 by BGP includes network and service topology, network and service 112 forwarding entries etc. 114 2 Many new applications are emerging under the centrally-controlled 115 framework, such as network virtualization, global traffic engineering 116 etc. Some new applications bring extension requirements to BGP. 118 This document defines an architecture of Central Controlled BGP and 119 then use cases under this framework are described. For some use 120 cases requirements of BGP extensions are discussed. 122 2. Terminology 124 BGP: Border Gateway Protocol 126 EVPN: Ethernet VPN 128 L2VPN: Layer 2 VPN 130 L3VPN: Layer 3 VPN 132 MVPN: Multicast VPN 134 RR: Route Reflector 136 SDN: Software-Defined Network 138 S-EVPN: Segment-based EVPN 140 3. Architecture 142 3.1. Reference Model 144 +------------------------------+ +------------------------------+ 145 | AS 1 | | AS 2 | 146 | +------------+ | | +------------+ | 147 | | BGP | | | | BGP | | 148 | | Controller |----------------------| Controller | | 149 | | (RR+) | | | | (RR+) | | 150 | | | | | | | | 151 | +------------+ | | +------------+ | 152 | / \ | | / \ | 153 | / \ | | / \ | 154 | / \ | | / \ | 155 | +--------+ +--------+ | | +--------+ +--------+ | 156 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 157 | | | ...... | | | | | | ...... | | | 158 | | BGP | | BGP | | | | BGP | | BGP | | 159 | | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | | 160 | +--------+ +--------+ | | +--------+ +--------+ | 161 | | | | 162 +------------------------------+ +------------------------------+ 164 Figure 1: An Architecture of Central Controlled BGP 166 The figure above depicts a typical architecture of central controlled 167 BGP. It consists of two essential network elements: BGP Controller 168 and BGP Client. BGP Controller controls all the BGP Clients within 169 its administrative domain by communicating with them. 171 In the above framework, BGP Controller is placed at the same position 172 of traditional Route Reflector (RR) [RFC4456]. Moreover from point 173 of view of implementation BGP Controller can be considered as 174 function-enhanced RR. So in this document, BGP Controller is named 175 RR+ as well. 177 3.2. Deployment Mode 179 BGP Controller can run on a general-purpose server or a network 180 device. If BGP Controller runs on a network device, it MUST support 181 both central-controlled functionality and forwarding functionality. 182 Same as BGP Controller, BGP Client can run on a general-purpose 183 server or a network device. It is more meaningful to decouple 184 control plane and forwarding functionality on BGP Client because this 185 manner enables network devices focusing on forwarding functionality. 186 This deployment model is shown in the following figure: 188 +------------------------------+ +------------------------------+ 189 | AS 1 | | AS 2 | 190 | +------------+ | | +------------+ | 191 | | BGP | | | | BGP | | 192 | | Controller |----------------------| Controller | | 193 | | (RR+) | | | | (RR+) | | 194 | | | | | | | | 195 | +------------+ | | +------------+ | 196 | / \ | | / \ | 197 | / \ | | / \ | 198 | / \ | | / \ | 199 | +--------+ +--------+ | | +--------+ +--------+ | 200 | | | | | | | | | | | | 201 | | | ...... | | | | | | ...... | | | 202 | | BGP | | BGP | | | | BGP | | BGP | | 203 | |CLIENT 1| |CLIENT n| | | |CLIENT 1| |CLIENT n| | 204 | +--------+ +--------+ | | +--------+ +--------+ | 205 | | | | | | | | 206 | | | | | | | | 207 | | | | | | | | 208 | +--------+ +--------+ | | +--------+ +--------+ | 209 | | | | | | | | | | | | 210 | |Forward | ...... |Forward | | | |Forward | ...... |Forward | | 211 | | | | | | | | | | | | 212 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 213 | +--------+ +--------+ | | +--------+ +--------+ | 214 +------------------------------+ +------------------------------+ 215 Figure 2: Decoupling BGP Client and Forwarding 217 In the reference model, there are multiple BGP controllers in 218 multiple ASes. In fact in one AS, there can also be multiple BGP 219 controllers to control different sets of BGP clients and IBGP peers 220 are set up between these BGP controllers. Such application scenario 221 can refer to [I-D.ietf-mpls-seamless-mpls] in which there are 222 multiple IGP areas which runs BGP in one AS. This document focuses 223 on multiple BGP controller in different ASes. The requirement and 224 use cases can also be applied to the case of multiple BGP controller 225 in one AS. 227 3.3. Requirement of Protocol Extensions 229 Building a BGP-based Central Controlled Framework needs extensions to 230 IGP, BGP and I2RS etc. 232 3.3.1. Building Connectivity 233 Connectivity between BGP Controller and BGP Clients in an AS can be 234 built by extending IGP protocol. In order to simplify network 235 operations, such connectivity SHOULD be automatically established. 237 3.3.2. Roles Auto-Discovery 239 A BGP-based Central Controlled Framework consists of two basic roles: 240 BGP Controller and BGP Client. Such roles can be auto-discovered by 241 extending IGP protocol to flooding the role information within an AS. 242 When IGP has finished the flooding process of role information, BGP 243 Controller and BGP Client can establish a BGP session on demand. 245 3.3.3. Establishing BGP Sessions 247 For the intra-AS case, when IGP has finished the flooding process of 248 role information within an AS, BGP Controller and BGP Client can 249 automatically establish a BGP session. It is not necessary to 250 establish BGP sessions amongst BGP Clients. 252 For the inter-AS case, the peer BGP controller SHOULD be specified to 253 establish BGP sessions. 255 3.3.4. Capability Negotiation 257 In order for BGP Controller and BGP Client to support BGP-based 258 Central Controlled framework in a friendly way, this document 259 suggests to defines a new BGP Central Control Capability. The 260 Central Control Capability SHOULD be defined as per [RFC5492]. By 261 advertising the BGP Central Control Capability to a peer, a BGP 262 speaker conveys information if it is able to send, receive, and 263 properly handle BGP Central Control related processes. 265 The existing BGP capabilities should be kept in the Central 266 Controlled framework and other new capabilities should be extended 267 according to new applications based on the Central Controlled 268 framework. 270 3.3.5. High Availability 272 In the BGP-based Central Controlled framework, BGP Controller plays a 273 key role. To void one-point-failure of BGP Controller, it is 274 possible to run redundant BGP Controllers for high availability. 276 With multiple BGP Controllers, it is important to synchronize route 277 processing policy configuration for all of them to perform the 278 exactly same routing decisions. When Primary BGP Controller failed, 279 the Backup BGP Controllers will take over the work of the Primary BGP 280 Controller. 282 To ensure BGP route persistence in case of occurrence of BGP 283 Controller failure, the new Primary BGP Controller SHOULD perform 284 resynchronization with BGP Clients. 286 When BGP Client loses connection with Primary BGP Controller, it 287 SHOULD following BGP Graceful Restart routine defined in [RFC 4724] 288 similar as a GR Helper. 290 3.3.6. Security 292 In BGP-based Central Controlled framework, it SHOULD be ensured that 293 communications between BGP Controllers and BGP Clients conform to 294 network security policy. The communication key used on BGP Client 295 can be configured through I2RS or other way. 297 4. Use Cases 299 In BGP-based Central Controlled framework, new use cases which are 300 difficult to be supported in traditional networks are emerging. In 301 some specific use cases, extension and enhancement of BGP protocol 302 are necessary. 304 4.1. Network Topology Acquirement 306 In BGP-based Central Controlled framework, BGP Controller can get the 307 topology of the whole network. Some applications such as ALTO can 308 get network topology information from BGP Controller. The topology 309 information of one AS can also be advertised by the controller to the 310 other BGP Controller in the other AS. BGP has been extended to 311 distribute link-state and traffic engineering information as defined 312 in [I-D.ietf-idr-ls-distribution]. 314 4.2. Simplifying Network Operation and Maintenance 316 The adoption of the new BGP-based Central Controlled Framework can 317 reduce the complexity and effort of network operation and maintenance 318 by following manners: 320 1. By using I2RS APIs, it would allow network operator to setup BGP 321 policy configuration from a single central point. This helps avoid 322 manual configuration of BGP policy on multiple BGP Clients and reduce 323 the complexity of BGP policy configuration. 325 2. For network with VPN service which includes L3VPN, L2VPN, E-VPN 326 etc, BGP Controller COULD store all the VPN user information. Use of 327 I2RS APIs to set L3VPN configuration from BGP Controller would allow 328 network operator no need to configure a VPN many times on different 329 BGP Clients. Furthermore, in the new Central Controlled framework 330 VPN parameters such as Route Distinguisher (RD), Route Targets (RT) 331 can be automatically generated and the configuration between CE and 332 PE can be generated automatically after the CE is authenticated by 333 the Central Controller. This can simply network operations and 334 maintenance greatly. 336 4.3. MPLS Global Label Allocation 338 MPLS Global Label should be allocated in a central point to guarantee 339 all distributed network nodes can understand meaning of a specific 340 global label in same. The new BGP-based Central Controlled framework 341 is particularly suitable to allocate MPLS Global Label through some 342 necessary MP-BGP extensions. 344 MPLS Global Label is defined in [I-D.li-mpls-global-label-framework] 345 and related use cases are defined in [I-D.li-mpls-global-label- 346 usecases]. 348 The extensions of BGP for MPLS global label include: 350 1. A new BGP Capability called Global Label Capability is suggested 351 to be introduced by following [RFC5492]. BGP Controller can 352 negotiate with BGP client on this new BGP capability. 354 2. BGP Controller determines the COMMON label space for all its BGP 355 Clients. 357 3. For each BGP client, BGP Controller allocates different MPLS 358 Global Labels for different services and advertises the MPLS Global 359 Labels to the BGP Client. 361 4. BGP Client receives the MPLS Global Labels, and generates 362 corresponding MPLS forwarding entries. 364 Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514], 365 E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP. So making extensions 366 to MP-BGP to allocate MPLS global label for these services is a 367 nature way from point of network solution. The use cases of MPLS 368 global label defined in [I-D.li-mpls-global-label-usecases] includes 369 S-EVPN, Split Horizon in VPLS MCAST and BGP MVPN, Egress PE 370 protection in VPN, etc. 372 4.4. RR-Based Traffic Steering 374 RR-based Traffic Steering (RRTS) defined in [I-D.chen-idr-rr-based- 375 traffic-steering-usecase], is an idea that leverages the BGP route 376 reflection mechanism to realize traffic steering in the network, 377 therefore the operators can conduct specific traffic to traverse 378 specific path, domains and/or planes as demand. The essential of 379 RRTS is that the concept of traffic engineering is introduced into 380 BGP network. With the new BGP-based Central Controlled framework 381 defined in this document, the operators can steer the network traffic 382 easily. More detailed description could be found in [I-D.chen-idr- 383 rr-based-traffic-steering-usecase]. 385 4.5. Inter-Controller Applications 387 Information is communicated between the BGP controller to fulfill the 388 inter-AS applications such as inter-AS VPN. Besides the inter-AS 389 applications, there proposes a type of new application to communicate 390 control information only between BGP Controllers to set up service 391 directly and download necessary forwarding entry to the nodes. Thus 392 the BGP sessions between the Controller and the node can be saved and 393 the control functionality on the node can be saved further. This 394 type of model is shown in the following figure. In this model, the 395 service set up between the nodes is proxied by the BGP Controllers. 397 +----------------------------------------------------------------+ 398 | AS | 399 | +------------+ +------------+ | 400 | | BGP | | BGP | | 401 | | Controller |--------------------| Controller | | 402 | | (RR+) | | (RR+) | | 403 | | | | | | 404 | +------------+ +------------+ | 405 | / \ / \ | 406 | / \ / \ | 407 | / \ / \ | 408 | +--------+ +--------+ +--------+ +--------+ | 409 | | | | | | | | | | 410 | |Forward | ...... |Forward | |Forward | ...... |Forward | | 411 | | | | | | | | | | 412 | | NODE 1 | | NODE n | | NODE 1 | | NODE n | | 413 | +--------+ +--------+ +--------+ +--------+ | 414 +----------------------------------------------------------------+ 415 Figure 3: Removing BGP Session between Controller and NODE 417 5. IANA Considerations 419 This document makes no request of IANA. 421 6. Security Considerations 423 TBD. 425 7. References 427 7.1. Normative References 429 [I-D.ietf-l2vpn-evpn] 430 Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., 431 Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", 432 draft-ietf-l2vpn-evpn-04 (work in progress), July 2013. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 438 Protocol 4 (BGP-4)", RFC 4271, January 2006. 440 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 441 Heron, "Pseudowire Setup and Maintenance Using the Label 442 Distribution Protocol (LDP)", RFC 4447, April 2006. 444 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 445 Reflection: An Alternative to Full Mesh Internal BGP 446 (IBGP)", RFC 4456, April 2006. 448 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 449 "Multiprotocol Extensions for BGP-4", RFC 4760, January 450 2007. 452 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 453 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 454 4761, January 2007. 456 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 457 with BGP-4", RFC 5492, February 2009. 459 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 460 "Provisioning, Auto-Discovery, and Signaling in Layer 2 461 Virtual Private Networks (L2VPNs)", RFC 6074, January 462 2011. 464 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 465 VPNs", RFC 6513, February 2012. 467 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 468 Encodings and Procedures for Multicast in MPLS/BGP IP 469 VPNs", RFC 6514, February 2012. 471 7.2. Informative References 473 [I-D.chen-idr-rr-based-traffic-steering-usecase] 474 Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of 475 Route Reflection based Traffic Steering", draft-chen-idr- 476 rr-based-traffic-steering-usecase-00 (work in progress), 477 July 2013. 479 [I-D.ietf-idr-ls-distribution] 480 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 481 Ray, "North-Bound Distribution of Link-State and TE 482 Information using BGP", draft-ietf-idr-ls-distribution-03 483 (work in progress), May 2013. 485 [I-D.ietf-mpls-seamless-mpls] 486 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 487 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 488 ietf-mpls-seamless-mpls-04 (work in progress), July 2013. 490 [I-D.li-l2vpn-segment-evpn] 491 Li, Z., Yong, L., and J. Zhang, "Segment-Based 492 EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-00 (work in 493 progress), July 2013. 495 [I-D.li-mpls-global-label-framework] 496 Li, Z., Zhao, Q., and T. Yang, "A Framework of MPLS Global 497 Label", draft-li-mpls-global-label-framework-00 (work in 498 progress), July 2013. 500 [I-D.li-mpls-global-label-usecases] 501 Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global 502 Label", draft-li-mpls-global-label-usecases-00 (work in 503 progress), July 2013. 505 Authors' Addresses 507 Zhenbin Li 508 Huawei Technologies 509 Huawei Bld., No.156 Beiqing Rd. 510 Beijing 100095 511 China 513 Email: lizhenbin@huawei.com 514 Mach(Guoyi) Chen 515 Huawei Technologies 516 Huawei Bld., No.156 Beiqing Rd. 517 Beijing 100095 518 China 520 Email: mach.chen@huawei.com 522 Shunwan Zhuang 523 Huawei Technologies 524 Huawei Bld., No.156 Beiqing Rd. 525 Beijing 100095 526 China 528 Email: zhuangshunwan@huawei.com