idnits 2.17.1 draft-yizhou-anima-ip-to-access-control-groups-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 (June 28, 2021) is 1030 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) ** Downref: Normative reference to an Informational RFC: RFC 7575 == Outdated reference: A later version (-11) exists of draft-ietf-anima-grasp-distribution-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-anima-grasp-distribution (ref. 'I-D.ietf-anima-grasp-distribution') == Outdated reference: A later version (-13) exists of draft-ietf-cbor-network-addresses-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Y. Li 3 Internet-Draft L. Shen 4 Intended status: Standards Track Huawei Technologies 5 Expires: December 30, 2021 June 28, 2021 7 Autonomic IP Address To Access Control Groups Mapping 8 draft-yizhou-anima-ip-to-access-control-groups-00 10 Abstract 12 This document defines the autonomic technical objectives for IP 13 address/prefix to access control groups mapping. The objectives 14 defined can be used in Generic Autonomic Signaling Protocol (GRASP) 15 to make the policy enforcement point receive IP address and its tied 16 access control groups information directly from the access 17 authentication points and then execute the group based policies. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 30, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Autonomic IP Address to Access Control Groups Mapping 57 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Behaviours of IP Address to Access Control Groups Mapping 59 Requesting Nodes . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Behaviours of IP Address to Access Control Groups Mapping 61 Providing Nodes . . . . . . . . . . . . . . . . . . . . . 7 62 5. Autonomic IP Address to Access Control Groups Objectives . . 8 63 5.1. IPAddressToAccessControlGroups Objective Option . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Objective Examples . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Ubiquitous group based policy management makes sure that the users 76 can obtain the same network access permission and QoS assurance 77 wherever they access the campus network. That is, the permission and 78 QoS assurance are tied to user role, rather than access points and/or 79 IP address assigned. 81 Group means a number of endpoints connecting to the network that 82 share common network policies. It facilitates the easy design and 83 provision of policy. A user's role is usually a group indicated by a 84 group ID. Group based policy management has been replacing the 85 traditional IP address and/or port number based policy widely. 87 The policy enforcement point (PEP) requires the IP address/prefix and 88 access control group mapping information of user in order to execute 89 the group based policy. This mapping information is usually first 90 available at the access authentication point (AAP) during the 91 procedures of user access and authentication/authorization. However 92 PEP may not be the access authentication point. Therefore IP and 93 group mappings has to be passed to PEP. 95 This document defines the autonomic technical objectives for IP 96 address/prefix and access control group mapping. In this document, 97 group is also used for short to refer to the access control group. 98 The Generic Autonomic Signaling Protocol (GRASP) [RFC8990] can make 99 use of these technical objectives as the basic building blocks of a 100 ubiquitous group based policy management solution, especially for a 101 campus network. 103 Autonomic Networking Infrastructure (ANI) is designed to provide the 104 elementary functions and services to be further integrated and used 105 by Autonomic Service Agents (ASA) on nodes. The campus policy 106 management ASA can integrate the function introduced in this document 107 when necessary. 109 2. Terminologies 111 This document uses terminology defined in [RFC7575]. 113 PEP: Policy Enforcement Point. A logical entity that enforces 114 policy decisions [RFC3198]. The policy decisions are group based 115 policies in this document. 117 AAP: Access Authentication Point. A logical entity that obtains the 118 information of the attaching clients' assigned IP address/prefix 119 and their access control groups. AAP may get the information from 120 one or different resources, for example, DHCP [RFC2131] [RFC8415] 121 server and/or RADIUS [RFC3198] server. 123 3. Problems 125 The traditional policy in a campus network is normally presented as 126 IP prefix/address based, for example, "Deny the traffic from IP 127 prefix X to IP prefix Y". Each of the access port of the switches is 128 assigned a subnet prefix and each subnet implies a group. It works 129 well when the end hosts are static. With the increasing deployment 130 of wireless accessed users and more complicated and dynamic 131 requirements of campus network policy, such an assumption no longer 132 hold. For instance, a user from the engineering department may bring 133 the laptop to access the campus network via a WiFi access point. 134 Then it will be assigned an IP address from a different subnet prefix 135 from the other fixed end hosts in the same engineering department. 136 It is hard and tedious to provision the consistent policy with the 137 other hosts in the same group for this specific IP address. Another 138 example is a user can belong to more than one group, say group of 139 department A and also VIP group. Group assignment is much more 140 flexible than subnet defined IP address assignment. 142 Therefore group based policy is used in such cases. No matter what 143 IP address is assigned to the user, its belonging access control 144 groups have no change and the group based policies has no change too. 145 For example, the policy can be "Allow the traffic from group 146 engineering to group testing, and assign the traffic destined to VIP 147 group the highest priority". In order to make group based policy 148 work, the IP address and its group mapping information has to be 149 stored on PEP so that IP addresses carried in data packet can be 150 mapped to the group ID first and then the policy can be enforced. 152 IP and group mapping information is usually first available at the 153 access authentication point (AAP). Figure 1 show a typical campus 154 network. The policy enforcement point (PEP) can be core switches, 155 while the access authentication point (AAP) is the access switch in 156 the figure. AAP serves as the DHCP relay which remembers the IP 157 address assigned to the client and/or at the same time it talks to 158 AAA server to get the client's group information based on client's 159 identity. 161 +-------+ +-------+ 162 | core1 | --- | core2 | core switches (PEP) 163 +-------+ /+-------+ 164 | \ / | \ 165 | \ / | \ 166 | \ / | \ 167 | \ / | \ 168 | \ | \ 169 +-------+ / \ +-------+ +-------+ 170 | acc1 |/ \| acc2 | | acc3 | access switches 171 +-------+ +-------+ +-------+ (AAP) 172 | 173 | 174 | 175 | 176 +-------+ 177 | WiFi | 178 | AP1 | wifi access point 179 +-------+ 181 Figure 1: Hierarchical Campus Network 183 A more complex campus network is shown in Figure 2. There are 4 PEPs 184 are deployed at the key positions for different types of traffic. 185 The AAPs obtaining a user's IP and group ID mapping information are 186 access switches (not fully shown in the figure) which are the access 187 nodes for the attaching clients. 189 The problem to be solved by Autonomic Networking here is how to make 190 IP address/prefix and access control group mapping information 191 available at PEP from AAP. 193 via SSL VPN tunnel ----- 194 +--------+ / \ 195 | user2 |-----------+Internet | 196 |(group1)| | | 197 +--------+ \-------/ 198 | 199 | 200 | 201 +---------------------|--------+ 202 ----- | | | 203 / \ | +--------+ +--------+ | 204 | WAN | --------------| WAN | |SSL VPN | | 205 | | | | border | |Internet| | 206 \-------/ | |firewall| |gateway | | 207 | | +--------+ +--------+ | 208 | | |PEP3 | PEP2 | 209 | | | +----+ | 210 +------|---------+ | | | | 211 | | | | +--------+ | +--------+ | 212 | +--------+ | | | core |---+ | | | 213 | | core | | | | switch |-----|firewall| | 214 | | switch | | | +--------+ +--------+ | 215 | +--------+ | | | PEP1 | 216 | |PEP4 | | | | 217 | | | | | | 218 | | | | +--------+ +--------+ | 219 | +--------+ | | | switch | --- | switch | | 220 | | switch | | | +--------+ +--------+ | 221 | +--------+ | | | | | 222 | | | | | | | 223 | | | | +--------+ +--------+ | 224 | +--------+ | | | user1 | | user3 | | 225 | | user4 | | | |(group1)| |(group2)| | 226 | |(group2)| | | +--------+ +--------+ | 227 | +--------+ | | | 228 | | | | 229 | | | | 230 |Branch | | Headquarter | 231 +----------------+ +------------------------------+ 233 Figure 2: Campus Networks with remote access 235 Some deployment uses a centralized controller to solve this problem. 236 Every single AAP reports its IP and group ID mapping information to 237 the controller. When a PEP receives a data packet, it queries the 238 controller for the group IDs of the source and/or destination IP 239 addresses and then enforce the group based policy. This approach 240 requires an explicit controller able to talk to each and every AAP 241 and PEP. In the deployment where the headquarter and branch campus 242 networks are far apart, it will require controllers for each site to 243 exchange information or have another super-controller to help 244 exchange the information among sites. It introduces the complexity 245 and interoperability issues. 247 Autonomic Networking (AN) puts the intelligence at the node level, to 248 minimize dependency on human administrators and central management 249 such as a controller. The Autonomic Networking approach discussed in 250 this document is based on the assumption that there is a generic 251 discovery and negotiation protocol that enables direct negotiation 252 between the routers or switches. GRASP [RFC8990] is intended to be 253 such a protocol which can make use of the technical objectives 254 defined in the following sections as the basic building blocks of a 255 ubiquitous group based policy management solution, especially for a 256 campus network. The ultimate goal is self-management of campus 257 networks which can expand over multiple sites and share the same set 258 of policies, including self-configuration, self-optimization, self- 259 healing and self-protection (sometimes collectively called self-X). 261 4. Autonomic IP Address to Access Control Groups Mapping Procedures 263 An Autonomic Service Agent (ASA) participates in IP address/prefix to 264 access control groups mapping is called 265 IPAddressToAccessControlGroups ASA in this document. The procedures 266 carried out by IPAddressToAccessControlGroups ASA is illustrated 267 below. 269 4.1. Behaviours of IP Address to Access Control Groups Mapping 270 Requesting Nodes 272 IPAddressToAccessControlGroups requesting node is usually a PEP in a 273 domain which executes the group based policy. So it needs to map an 274 IP address/prefix to one or more group IDs first. Such mapping 275 information will be stored locally until either timeout or withdrawn. 277 The request can be triggered by a data packet. Group based policy 278 requires both the source and destination group IDs which are normally 279 mapped from source and destination IP addresses. If any of such 280 mapping is not locally available, the requesting node needs to ask 281 for it. In some implementation, data packet encapsulation includes 282 the source group ID directly such as in the reserved field in VXLAN 284 [RFC7348]. Therefore it is up to the requesting node to determine if 285 both source and destination groups or only one of them to be queried. 286 In some cases that the requesting node is a tunnel endpoint, it 287 should be noted that usually the inner rather than outer IP addresses 288 are to be used to query for the corresponding group id. 290 The request can also be sent periodically or voluntarily. It can 291 happen when a newly booted requesting node wants to get the whole 292 batch of IP address and access control group mapping information or 293 when a requesting node would like have an explicit refreshment on the 294 information. 296 The IPAddressToAccessControlGroups ASA should send out a GRASP 297 Discovery message that contains a IPAddressToAccessControlGroups 298 Objective option in order to discover peers supporting this option. 299 The requesting ASA acts as a GRASP synchronization initiator by 300 sending a GRASP Request message with a IPAddressToAccessControlGroups 301 Objective option. The ASA indicates an IP prefix or address in this 302 option. This starts a GRASP synchronization process. 304 4.2. Behaviours of IP Address to Access Control Groups Mapping 305 Providing Nodes 307 IPAddressToAccessControlGroups providing node is usually an AAP of a 308 user in a domain. It obtains the mapping of IP address and group IDs 309 of an endpoint in various ways. For instance, use RADIUS [RFC2865] 310 or CAPWAP [RFC5415] to get the user's access control group IDs during 311 authentication phase and/or use DHCP snooping to get the user's 312 assigned IP address. Sometimes such mapping information can be 313 statically provisioned based on port or VLAN. The mapping 314 information is stored locally on AAP. 316 A device that receives a Discovery message with a 317 IPAddressToAccessControlGroups Objective option should respond with a 318 GRASP Response message if it contains a 319 IPAddressToAccessControlGroups ASA. When this ASA receives a 320 subsequent Request message, it should reply with a GRASP 321 Synchronization messages. The Synchronization messages carry a 322 IPAddressToAccessControlGroups Objective option, which will indicate 323 the mappings between the IP address/prefix and group IDs. Optionally 324 the expiration time can be tied to each mapping. 326 The IP address to access control groups mapping providing node can 327 send the Flood Synchronization message if it has any update or 328 withdraw regarding its providing mapping information. 330 The providing nodes of address to access control groups mapping 331 information are usually at the edges and can be added or replaced 332 with the expansion of the network. The requesting nodes are normally 333 aggregation or core nodes with more storage and capability to enforce 334 the policy. Therefore the number of mapping information providing 335 nodes is usually more than the number of requesting nodes. The 336 providing node can be the one initiating the GRASP Discovery message 337 as well and/or send the unsolicited Synchronization message 338 [I-D.ietf-anima-grasp-distribution]. 340 5. Autonomic IP Address to Access Control Groups Objectives 342 This section defines the GRASP technical objective options that are 343 used to support autonomic IP address/prefix to access control groups 344 mapping. 346 5.1. IPAddressToAccessControlGroups Objective Option 348 The IPAddressToAccessControlGroups Objective option is a GRASP 349 objective option conforming to [RFC8990]. The name of this option is 350 "IPAddressToAccessControlGroups". It carries the IP prefix/address 351 and its mapping access control group id. The format of 352 IPAddressToAccessControlGroups Objective option in CBOR (Concise 353 Binary Object Representation [RFC8949]) is show in Concise data 354 definition language (CDDL) [RFC8610] as follows. Tags for general 355 IPv4 and IPv6 addresses and prefixes defined in 356 [I-D.ietf-cbor-network-addresses] are used. 358 objective = ["IPAddressToAccessControlGroups", 359 objective-flags, loop-count, 360 [ip-address-or-prefix, *group-id]] 362 group-id = uint 364 ; copied from draft-ietf-cbor-network-addresses, RFC YYYY TBD: 366 ip-address-or-prefix = ipv6-address-or-prefix/ipv4-address-or-prefix 368 ipv6-address-or-prefix = #6.54(ipv6-address / ipv6-prefix) 369 ipv4-address-or-prefix = #6.52(ipv4-address / ipv4-prefix) 371 ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes] 372 ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes] 374 ipv6-prefix-length = 0..128 375 ipv4-prefix-length = 0..32 377 ipv6-prefix-bytes = bytes .size (uint .le 16) 378 ipv4-prefix-bytes = bytes .size (uint .le 4) 380 ipv6-address = bytes .size 16 381 ipv4-address = bytes .size 4 383 ; copied from the GRASP specification, RFC 8990: 385 objective-flags = uint .bits objective-flag 387 objective-flag = &( 388 F_DISC: 0 ; valid for discovery 389 F_NEG: 1 ; valid for negotiation 390 F_SYNCH: 2 ; valid for synchronization 391 F_NEG_DRY: 3 ; negotiation is a dry run 392 ) 393 loop-count = 0..255 395 A common practice currently usually uses 16 bits to present a group 396 ID. But the representation does not limit that. Zero group ID would 397 be used for full retraction of a prefix or address. 399 6. Security Considerations 401 Security consideration for GRASP [RFC8990] applies in this document. 402 The preferred security model is that devices are trusted following 403 the secure bootstrap procedure [RFC8995] and that a secure Autonomic 404 Control Plane (ACP) [RFC8994] is in place. 406 7. IANA Considerations 408 This document defines a new GRASP Objective option name: 409 "IPAddressToAccessControlGroups". The IANA is requested to added it 410 to the "GRASP Objective Names" subregistry defined by [RFC8990]. 412 8. Acknowledgements 414 Thanks to Carsten Bormann, Brian Carpenter and Michael Richardson for 415 useful suggestions and revising CDDL representations. 417 9. References 419 9.1. Normative References 421 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 422 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 423 Networking: Definitions and Design Goals", RFC 7575, 424 DOI 10.17487/RFC7575, June 2015, 425 . 427 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 428 Definition Language (CDDL): A Notational Convention to 429 Express Concise Binary Object Representation (CBOR) and 430 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 431 June 2019, . 433 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 434 Autonomic Signaling Protocol (GRASP)", RFC 8990, 435 DOI 10.17487/RFC8990, May 2021, 436 . 438 [I-D.ietf-anima-grasp-distribution] 439 Liu, B., Xiao, X., Hecker, A., Jiang, S., Despotovic, Z., 440 and Brian, "Information Distribution over GRASP", draft- 441 ietf-anima-grasp-distribution-02 (work in progress), March 442 2021. 444 [I-D.ietf-cbor-network-addresses] 445 Richardson, M., "CBOR tags for IPv4 and IPv6 addresses and 446 prefixes", draft-ietf-cbor-network-addresses-04 (work in 447 progress), April 2021. 449 9.2. Informative References 451 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 452 RFC 2131, DOI 10.17487/RFC2131, March 1997, 453 . 455 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 456 "Remote Authentication Dial In User Service (RADIUS)", 457 RFC 2865, DOI 10.17487/RFC2865, June 2000, 458 . 460 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 461 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 462 J., and S. Waldbusser, "Terminology for Policy-Based 463 Management", RFC 3198, DOI 10.17487/RFC3198, November 464 2001, . 466 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 467 Ed., "Control And Provisioning of Wireless Access Points 468 (CAPWAP) Protocol Specification", RFC 5415, 469 DOI 10.17487/RFC5415, March 2009, 470 . 472 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 473 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 474 eXtensible Local Area Network (VXLAN): A Framework for 475 Overlaying Virtualized Layer 2 Networks over Layer 3 476 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 477 . 479 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 480 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 481 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 482 RFC 8415, DOI 10.17487/RFC8415, November 2018, 483 . 485 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 486 Representation (CBOR)", STD 94, RFC 8949, 487 DOI 10.17487/RFC8949, December 2020, 488 . 490 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 491 Autonomic Control Plane (ACP)", RFC 8994, 492 DOI 10.17487/RFC8994, May 2021, 493 . 495 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 496 and K. Watsen, "Bootstrapping Remote Secure Key 497 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 498 May 2021, . 500 Appendix A. Objective Examples 502 This appendix shows a number of examples of objective defined in this 503 document conforming to the CDDL syntax given in Section 5.1. 505 ["IPAddressToAccessControlGroups", 15, 101, 506 [54([4, h'A50386A78BA56FA4BBC734281C51']), 3506, 2698, 4562]] 508 ["IPAddressToAccessControlGroups", 5, 73, [52(h'9946B8A3'), 2881, 509 2265, 1720, 2450]] 511 ["IPAddressToAccessControlGroups", 15, 161, 512 [54(h'39F3045B641AD291B057CD1857A7314A')]] 514 ["IPAddressToAccessControlGroups", 15, 2, [52(h'98A1CE4F')]] 516 ["IPAddressToAccessControlGroups", 15, 66, [52(h'69A16BFE'), 2601, 517 1851, 3876, 1405]] 519 ["IPAddressToAccessControlGroups", 15, 254, 520 [54(h'38AB303B8895DC95068CE00248D2FE91'), 4019, 1166, 3113]] 522 ["IPAddressToAccessControlGroups", 15, 63, [52([4, h'0B48']), 3035, 523 1181]] 525 ["IPAddressToAccessControlGroups", 15, 44, [52(h'01F1D8FF'), 3099, 526 1577, 1138, 1670]] 528 ["IPAddressToAccessControlGroups", 15, 181, 529 [54(h'2C74719F9355BA4E3BDE5689D1FE4CB0')]] 531 ["IPAddressToAccessControlGroups", 15, 129, [52(h'A2EF97C7'), 3149, 532 2728]] 534 ["IPAddressToAccessControlGroups", 15, 18, 535 [54(h'CD3868615B00D72A61A028822FEE6407'), 1832, 4605, 360, 3030]] 537 ["IPAddressToAccessControlGroups", 15, 171, 538 [54(h'46929AE1103FDF6407A239323F71C234')]] 540 ["IPAddressToAccessControlGroups", 15, 42, [52([7, h'8E05'])]] 542 ["IPAddressToAccessControlGroups", 15, 180, 543 [54([41, h'2D85855FA9C3772AAB2F']), 672, 1205]] 545 Authors' Addresses 547 Yizhou Li 548 Huawei Technologies 550 Email: liyizhou@huawei.com 552 Li Shen 553 Huawei Technologies 555 Email: kevin.shenli@huawei.com