idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In single VLAN case, the component type MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In single VLAN case, the component type MUST not be used. -- The document date (July 03, 2017) is 2482 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: 'EVPN' is mentioned on line 109, but not defined == Missing Reference: 'RFC 6074' is mentioned on line 111, but not defined -- Looks like a reference, but probably isn't: '4761' on line 115 -- Looks like a reference, but probably isn't: '4762' on line 115 -- Looks like a reference, but probably isn't: '6074' on line 116 == Unused Reference: 'RFC6074' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 511, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Hao 3 Internet-Draft Q. Liang 4 Intended status: Standards Track Huawei 5 Expires: January 4, 2018 J. Uttaro 6 AT&T 7 S. Litkowski 8 Orange Business Service 9 S. Zhuang 10 Huawei 11 July 03, 2017 13 Dissemination of Flow Specification Rules for L2 VPN 14 draft-ietf-idr-flowspec-l2vpn-07 16 Abstract 18 This document defines BGP flow-spec extension for Ethernet traffic 19 filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for 20 dissemination traffic filtering information in an L2VPN environment. 21 A new subset of component types and extended community also are 22 defined. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Layer 2 Flow Specification encoding in BGP . . . . . . . . . 3 66 3. Ethernet Flow Specification encoding in BGP . . . . . . . . . 4 67 3.1. Order of Traffic Filtering Rules . . . . . . . . . . . . 6 68 4. Ethernet Flow Specification Traffic Actions . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 BGP Flow-spec is an extension to BGP that allows for the 80 dissemination of traffic flow specification rules. It leverages the 81 BGP Control Plane to simplify the distribution of ACLs, new filter 82 rules can be injected to all BGP peers simultaneously without 83 changing router configuration. The typical application of BGP Flow- 84 spec is to automate the distribution of traffic filter lists to 85 routers for DDOS mitigation, access control, etc. 87 RFC5575 defines a new BGP Network Layer Reachability Information 88 (NLRI) format used to distribute traffic flow specification rules. 89 NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1, 90 SAFI=134)is for BGP/MPLS VPN filtering. The Flow specification match 91 part only includes L3/L4 information like source/destination prefix, 92 protocol, ports, and etc, so traffic flows can only be selectively 93 filtered based on L3/L4 information. 95 Layer 2 Virtual Private Networks (L2VPNs) have already been deployed 96 in an increasing number of networks today. In L2VPN network, we also 97 have requirement to deploy BGP Flow-spec to mitigate DDoS attack 98 traffic. Within L2VPN network, both IP and non-IP Ethernet traffic 99 maybe exist. For IP traffic filtering, the Flow specification rules 100 defined in [RFC5575] which include match criteria and actions can 101 still be used, flow specification rules received via new NLRI format 102 apply only to traffic that belongs to the VPN instance(s) in which it 103 is imported. For non-IP Ethernet traffic filtering, Layer 2 related 104 information like source/destination MAC and VLAN should be 105 considered. But the flow specification match criteria defined in 106 RFC5575 only include layer 3 and layer 4 IP information, layer 2 107 Ethernet information haven't been included. 109 There are different kinds of L2VPN networks like EVPN [EVPN], BGP 110 VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) 111 auto discovery [RFC 6074]. Because the flow-spec feature relies on 112 BGP protocol to distribute traffic filtering rules, so it can only be 113 incrementally deployed in those L2VPN networks where BGP has already 114 been used for auto discovery and/or signaling purposes such as BGP- 115 based VPLS [4761], EVPN and LDP-based VPLS [4762] with BGP auto- 116 discovery [6074]. 118 This draft proposes a new subset of component types and extended 119 community to support L2VPN flow-spec application. The flow-spec 120 rules can be enforced on all border routers or on some interface sets 121 of the border routers. SAFI=134 in [RFC5575] is redefined for 122 dissemination traffic filtering information in an L2VPN environment. 124 2. Layer 2 Flow Specification encoding in BGP 126 The [RFC5575] defines SAFI 133 and SAFI 134 for "dissemination of 127 IPv4 flow specification rules" and "dissemination of VPNv4 flow 128 specification rules" respectively. [draft-ietf-idr-flow-spec-v6-06] 129 redefines the [RFC5575] SAFIs in order to make them applicable to 130 both IPv4 and IPv6 applications. This document will further redefine 131 the SAFI 134 in order to make them applicable to L2VPN applications. 133 The following changes are defined: 135 "SAFI 134 for dissemination of L3VPN flow specification rules" to now 136 be defined as "SAFI 134 for dissemination of VPN flow specification 137 rules" 139 For SAFI 134 the indication to which address family it is referring 140 to will be recognized by AFI value (AFI=1 for VPNv4, AFI=2 VPNv6 and 141 AFI=25 for L2VPN). Such modification is fully backwards compatible 142 with existing implementation and production deployments. 144 3. Ethernet Flow Specification encoding in BGP 146 The NLRI format for this address family consists of a fixed-length 147 Route Distinguisher field (8 bytes) followed by a flow specification, 148 following the encoding defined in this document. The NLRI length 149 field shall include both the 8 bytes of the Route Distinguisher as 150 well as the subsequent flow specification. 152 Flow specification rules received via this NLRI apply only to traffic 153 that belongs to the VPN instance(s) in which it is imported. Flow 154 rules are accepted by default, when received from remote PE routers. 156 Besides the component types defined in [RFC5575] and [draft-ietf-idr- 157 flow-spec-v6-06], this document proposes the following additional 158 component types for L2VPN Ethernet traffic filtering: 160 Type 14 - Ethernet Type 162 Encoding: 164 Defines a list of {operation, value} pairs used to match two-octet 165 field. Values are encoded as 2-byte quantities. Ethernet II framing 166 defines the two-octet Ethernet Type field in an Ethernet frame, 167 preceded by destination and source MAC addresses, that identifies an 168 upper layer protocol encapsulating the frame data. 170 Type 15 - Source MAC 172 Encoding: 173 Defines the source MAC Address to match. 175 Type 16 - Destination MAC 177 Encoding: 178 Defines the destination MAC Address to match. 180 Type 17 - DSAP(Destination Service Access Point) in LLC 182 Encoding: 184 Defines a list of {operation, value} pairs used to match 1-octet DSAP 185 in the 802.2 LLC(Logical Link Control Header). Values are encoded as 186 1-byte quantities. The operation field is encoded as 'Numeric 187 operator' defined in [RFC5575]. 189 Type 18 - SSAP(Source Service Access Point) in LLC 191 Encoding: 192 Defines a list of {operation, value} pairs used to match 1-octet SSAP 193 in the 802.2 LLC. Values are encoded as 1-byte quantities. 195 Type 19 - Control field in LLC 197 Encoding: 199 Defines a list of {operation, value} pairs used to match 1-octet 200 control field in the 802.2 LLC. Values are encoded as 1-byte 201 quantities. 203 Type 20 - SNAP 205 Encoding: 207 Defines a list of {operation, value} pairs used to match 5-octet 208 SNAP(Sub-Network Access Protocol) field. Values are encoded as 209 5-byte quantities. 211 Type 21 - VLAN ID 213 Encoding: 215 Defines a list of {operation, value} pairs used to match VLAN ID. 216 Values are encoded as 2-byte quantities, where the four most 217 significant bits are zero and the 12 least significant bits contain 218 the VLAN value. 220 In virtual local-area network (VLAN) stacking case, the VLAN ID is 221 outer VLAN ID. 223 Type 22 - VLAN COS 225 Encoding: 227 Defines a list of {operation, value} pairs used to match 3-bit VLAN 228 COS fields [802.1p]. Values are encoded using a single byte, where 229 the five most significant bits are zero and the three least 230 significant bits contain the VLAN COS value. 232 In virtual local-area network (VLAN) stacking case, the VLAN COS is 233 outer VLAN COS. 235 Type 23 - Inner VLAN ID 237 Encoding: 238 Defines a list of {operation, value} pairs used to match inner VLAN 239 ID using for virtual local-area network (VLAN) stacking or Q in Q 240 case. Values are encoded as 2-byte quantities, where the four most 241 significant bits are zero and the 12 least significant bits contain 242 the VLAN value. 244 In single VLAN case, the component type MUST not be used. 246 Type 24 - Inner VLAN COS 248 Encoding: 250 Defines a list of {operation, value} pairs used to match 3-bit inner 251 VLAN COS fields [802.1p] using for virtual local-area network (VLAN) 252 stacking or Q in Q case. Values are encoded using a single byte, 253 where the five most significant bits are zero and the three least 254 significant bits contain the VLAN COS value. 256 In single VLAN case, the component type MUST not be used. 258 3.1. Order of Traffic Filtering Rules 260 The original definition for the order of traffic filtering rules can 261 be reused with new consideration for the MAC Address offset. As long 262 as the offsets are equal, the comparison is the same, retaining 263 longest-prefix-match semantics. If the offsets are not equal, the 264 lowest offset has precedence, as this flow matches the most 265 significant bit. 267 Pseudocode: 268 flow_rule_L2_cmp (a, b) 269 { 270 comp1 = next_component(a); 271 comp2 = next_component(b); 272 while (comp1 || comp2) { 273 // component_type returns infinity on end-of-list 274 if (component_type(comp1) < component_type(comp2)) { 275 return A_HAS_PRECEDENCE; 276 } 277 if (component_type(comp1) > component_type(comp2)) { 278 return B_HAS_PRECEDENCE; 279 } 281 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 282 common = MIN(MAC Address length (comp1), 283 MAC Address length (comp2)); 284 cmp = MAC Address compare(comp1, comp2, common); 285 // not equal, lowest value has precedence 286 // equal, longest match has precedence 287 } else { 288 common = 289 MIN(component_length(comp1), component_length(comp2)); 290 cmp = memcmp(data(comp1), data(comp2), common); 291 // not equal, lowest value has precedence 292 // equal, longest string has precedence 293 } 294 } 295 return EQUAL; 296 } 298 4. Ethernet Flow Specification Traffic Actions 300 The default action for a layer 2 traffic filtering flow specification 301 is to accept traffic that matches that particular rule. The 302 following extended community values per RFC5575 can be used to 303 specify particular actions in L2VPN network: 305 +--------+--------------------+--------------------------+ 306 | type | extended community | encoding | 307 +--------+--------------------+--------------------------+ 308 | 0x8006 | traffic-rate | 2-byte as#, 4-byte float | 309 | 0x8007 | traffic-action | bitmask | 310 | 0x8008 | redirect | 6-byte Route Target | 311 | 0x8009 | traffic-marking | DSCP value | 312 +--------+--------------------+--------------------------+ 313 Redirect: The action should be redefined to allow the traffic to be 314 redirected to a MAC or IP VRF routing instance that lists the 315 specified route-target in its import policy. 317 Besides the above extended communities, this document also proposes 318 the following BGP extended communities specifications for Ethernet 319 flow to extend [RFC5575]: 321 +--------+------------------------+--------------------------+ 322 | type | extended community | encoding | 323 +--------+------------------------+--------------------------+ 324 | TBD1 | VLAN-action | bitmask | 325 | TBD2 | TPID-action | bitmask | 326 +--------+------------------------+--------------------------+ 328 VLAN-action: The VLAN-action extended community consists of 6 bytes 329 which include the fields of action Flags, two VLAN IDs and the 330 associating COS value. The action Flags fields are further divided 331 into two parts which correspond to the first action and the second 332 action respectively, bit 0 to bit 7 belong to the first action part 333 while bit 8 to bit 15 belong to the second part. The bits of PO, PU, 334 SW, RI and RO in each part represent the action of Pop, Push, Swap, 335 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 336 method, more complicated actions also can be represented in a single 337 VLAN-action extend community, such as SwapPop, PushSwap, etc. For 338 example, SwapPop action is the concatenation of two actions, the 339 first action is Swap and the second action is Pop. 341 0 7 15 342 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 343 |PO1|PU1|SW1|RI1|RO1|...|PO2|PU2|SW2|RI2|RO2|...| 344 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 345 | VLAN ID1 |COS1 |R1| 346 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 347 | VLAN ID2 |COS2 |R2| 348 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 350 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 351 VLAN should be removed. 353 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 354 added, the associated COS is COS1. 356 SW1: Swap action. If the SW1 flag is one, it indicates the outer 357 VLAN and inner VLAN should be swapped. 359 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 360 VLAN should be removed. 362 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 363 added, the associated COS is COS2. 365 SW2: Swap action. If the SW2 flag is one, it indicates the outer 366 VLAN and inner VLAN should be swapped. 368 RI1 and RI2: Rewrite inner VLAN action. If the RI flag is one, it 369 indicates the inner VLAN should be replaced by a new VLAN, the new 370 VLAN is VLAN ID1, the associated COS is COS1. If the VLAN ID1 is 0, 371 the action is to only modify the COS value of inner VLAN. 373 RO1 and RO2: Rewrite outer VLAN action. If the RO flag is one, it 374 indicates the outer VLAN should be replaced by a new VLAN, the new 375 VLAN is VLAN ID2, the associated COS is COS2. If the VLAN ID2 is 0, 376 the action is to only modify the COS value of outer VLAN. 378 R1 and R2: Reserved for future use. 380 Giving an example, if the action of PUSH Inner VLAN 10 with COS value 381 5 and Outer VLAN 20 with COS value 6 is needed, the format of the 382 VLAN-action extended community is as follows: 384 0 7 15 385 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 386 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 388 | 10 |1 |0 |1 |0 | 389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 390 | 20 |1 |1 |0 |0 | 391 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 393 TPID-action: The TPID-action extended community consists of 6 bytes 394 which includes the fields of action Flags, TPID1 and TPID2. 396 0 15 397 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 398 |TI|TO| Resv | 399 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 400 | TP ID1 | 401 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 402 | TP ID2 | 403 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 404 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 405 the inner TP ID should be replaced by a new TP ID, the new TP ID is 406 TP ID1. 408 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 409 the outer TP ID should be replaced by a new TP ID, the new TP ID is 410 TP ID2. 412 Resv: Reserved for future use. 414 5. IANA Considerations 416 IANA is requested to rename currently defined SAFI 134 per [RFC5575] 417 to read: 419 134 VPN dissemination of flow specification rules 421 IANA is requested to create and maintain a new registry for "Flow 422 spec L2VPN Component Types". For completeness, the types defined in 423 [RFC5575] and [draft-ietf-idr-flow-spec-v6-06] also are listed here. 425 +--------+-------------------------------+--------------------------+ 426 | type | RFC or Draft | discription | 427 +--------+-------------------------------+--------------------------+ 428 | 1 |RFC5575 | Destination Prefix | 429 | 1 |draft-ietf-idr-flow-spec-v6-06 | Destination IPv6 Prefix | 430 | 2 |RFC5575 | Source Prefix | 431 | 2 |draft-ietf-idr-flow-spec-v6-06 | Source IPv6 Prefix | 432 | 3 |RFC5575 | IP Protocol | 433 | 3 |draft-ietf-idr-flow-spec-v6-06 | Next Header | 434 | 4 |RFC5575 | Port | 435 | 5 |RFC5575 | Destination port | 436 | 6 |RFC5575 | Source port | 437 | 7 |RFC5575 | ICMP type | 438 | 8 |RFC5575 | ICMP code | 439 | 9 |RFC5575 | TCP flags | 440 | 10 |RFC5575 | Packet length | 441 | 11 |RFC5575 | DSCP | 442 | 12 |RFC5575 | Fragment | 443 | 13 |draft-ietf-idr-flow-spec-v6-06 | Flow Label | 444 | 14 |This draft | Ethernet Type | 445 | 15 |This draft | Source MAC | 446 | 16 |This draft | Destination MAC | 447 | 17 |This draft | DSAP in LLC | 448 | 18 |This draft | SSAP in LLC | 449 | 19 |This draft | Control field in LLC | 450 | 20 |This draft | SNAP | 451 | 21 |This draft | VLAN ID | 452 | 22 |This draft | VLAN COS | 453 | 23 |This draft | Inner VLAN ID | 454 | 24 |This draft | Inner VLAN COS | 455 +--------+-------------------------------+--------------------------+ 457 IANA is requested to update the reference for the following 458 assignment in the "BGP Extended Communities Type - extended, 459 transitive" registry: 461 Type value Name Reference 463 ---------- ---------------------------------------- --------- 465 0x080A Flow spec VLAN action [this document] 467 0x080B Flow spec TPID action [this document] 469 6. Security Considerations 471 No new security issues are introduced to the BGP protocol by this 472 specification. 474 7. Acknowledgements 476 The authors wish to acknowledge the important contributions of Hannes 477 Gredler, Xiaohu Xu, Zhenbin Li and Lucy Yong. 479 8. References 481 8.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 489 LAN Service (VPLS) Using BGP for Auto-Discovery and 490 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 491 . 493 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 494 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 495 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 496 . 498 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 499 and D. McPherson, "Dissemination of Flow Specification 500 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 501 . 503 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 504 "Provisioning, Auto-Discovery, and Signaling in Layer 2 505 Virtual Private Networks (L2VPNs)", RFC 6074, 506 DOI 10.17487/RFC6074, January 2011, 507 . 509 8.2. Informative References 511 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 512 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 513 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 514 2015, . 516 Authors' Addresses 518 Weiguo Hao 519 Huawei 520 101 Software Avenue, 521 Nanjing 210012 522 China 524 Email: haoweiguo@huawei.com 526 Qiandeng Liang 527 Huawei 528 101 Software Avenue, 529 Nanjing 210012 530 China 532 Email: liangqiandeng@huawei.com 534 James Uttaro 535 AT&T 537 Email: uttaro@att.com 539 Stephane Litkowski 540 Orange Business Service 542 Email: stephane.litkowski@orange.com 544 Shunwan Zhuang 545 Huawei 546 Huawei Bld., No.156 Beiqing Rd. 547 Beijing 100095 548 China 550 Email: zhuangshunwan@huawei.com