idnits 2.17.1 draft-jiang-service-oriented-ip-02.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-carpenter-limited-domains-10 == Outdated reference: A later version (-01) exists of draft-li-apn6-problem-statement-usecases-00 == Outdated reference: A later version (-06) exists of draft-troan-6man-universal-ra-option-01 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: May 1, 2020 Huawei Technologies Co., Ltd 6 G. Li 7 Huawei Technologies 8 October 29, 2019 10 Service Oriented Internet Protocol 11 draft-jiang-service-oriented-ip-02 13 Abstract 15 This document proposes a new, backwards-compatible, approach to 16 packet forwarding, where the service required rather than the IP 17 address required acts as the vector for routing packets at the edge 18 of the network. Deeper in the network, the mechanism can interface 19 to conventional and future methods of service or application aware 20 networking. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 1, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 (https://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 respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Coexistence Issues . . . . . . . . . . . . . . . . . . . . . 7 59 4. Some Usage Examples . . . . . . . . . . . . . . . . . . . . . 8 60 5. Continuity with the Existing Internet . . . . . . . . . . . . 8 61 6. Interface with Service and Application Domains . . . . . . . 9 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Possible TLV and CBOR Encodings . . . . . . . . . . 11 66 A.1. TLV Mapping . . . . . . . . . . . . . . . . . . . . . . . 11 67 A.2. CBOR Mapping . . . . . . . . . . . . . . . . . . . . . . 12 68 Appendix B. Change log [RFC Editor: Please remove] . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 An important aspect of the Internet today is that it is no longer a 74 uniform space with uniform requirements. For both technical and 75 economic reasons, we see an emerging trend of usage scenarios that 76 are confined to some form of limited domain, and which inevitably 77 lead to applications and protocols that are only suitable within a 78 given scope [I-D.carpenter-limited-domains]. In particular, various 79 techniques have emerged for packet treatments that are specific to a 80 type of application or service. This trend collides immediately with 81 two factors: the original design concept of an Internet with end to 82 end IP transparency (such that any locally defined protocol running 83 over IP is almost certain to escape the local network), and with the 84 increasing presence of middleboxes. In this emerging context, where 85 end to end IP service is no longer a safe assumption, and where there 86 is increasing demand for specific services, this document proposes a 87 new, backwards-compatible, approach to packet forwarding, where the 88 service required rather than the IP address required acts as the 89 vector for routing packets at the edge of the network, close to the 90 host requiring a particular service or application. This form of 91 service based packet forwarding is referred to as Service Oriented IP 92 (SOIP). 94 We propose an addition to the existing core function of the network, 95 which is reachability over IPv6 or IPv4. Today, IP is focussed on 96 reachability, using best effort forwarding both to find a route and 97 to automatically share transmission resources in a simple and low- 98 cost way. As a result, transport protocols such as TCP and UDP learn 99 little or nothing about the network, beyond congestion or loss 100 signals. Several ISPs may lie on the path between a user and a 101 server, but they are largely ignorant about the services a user 102 requires. Typical services could be streamed content, regular 103 content, user posting, storage access, or calculation, but this list 104 is not exclusive. 106 Both service providers and users will benefit if a packet stream can 107 be identified intrinsically as requiring a certain kind of service. 108 This is particularly applicable for edge networks, such as those 109 supported by 5G technology, where there is an emphasis on upper layer 110 service provision. Whatever the business model - for example the ISP 111 operates all types of service, or the ISP operates no user services 112 at all and has contracts with specific service providers, or the ISP 113 is agnostic about user services - SOIP will allow for optimised 114 packet delivery. The ISP will have the choice to provide some or all 115 services. The user will have the choice to use ISP services or 116 bypass them. Traffic that leaves the domain where SOIP is in use 117 will be perfectly normal IPv6 or IPv4 traffic, sent by an exit node 118 acting as a proxy (not an IP-layer translator) for the user. 119 Additionally, IPv6 and IPv4 will be modelled as services available to 120 the user, thereby giving continuity of access to everything the user 121 has today. This is a logical extension of a principle already 122 adopted to model IPv4 as a service available via IPv6 [RFC8585]. 124 As new service and application oriented features are deployed in the 125 network, SOIP will provide a seamless interface to both existing and 126 future mechanisms. Effectively it will make client hosts future- 127 proof as the network evolves. 129 2. Proposed Solution 131 NOTE: This is a preliminary draft expected to stimulate discussion, 132 so many details are not yet defined. 134 The approach is to make the service be the central component of the 135 network. Conceptually, the user's packets will be directed at a 136 service, not at an IP host. The first hop SOIP router will either 137 forward the packets to an upstream SOIP router, or immediately 138 dispatch the session to a suitable service. At least one SOIP router 139 in a domain must be capable of acting as a dispatcher. The 140 dispatched traffic may either remain in SOIP format, or be 141 transformed by a proxy mechanism into a conventional IP-based format. 142 Figure 1 gives an overview, and Section 5 and Section 6 discuss this 143 further. 145 ----------- ----------- 146 |End-user | <-----> | SOIP | 147 | Host | | router | 148 ----------- ----------- 149 ^ 150 | 151 v 152 -------------- ----------- ----------------- 153 | SOIP-based | | SOIP | | Unknown | 154 | services |---| router + |---| future | 155 | | |dispatcher| | services | 156 -------------- ------------ ----------------- 157 | | | 158 -------------- | | | ----------------- 159 |Traditional |____/ | \____|Segment Routing| 160 |IP services | | |services | 161 -------------- ------------ ----------------- 162 | SDN | 163 | services | 164 ------------ 166 Figure 1 168 The service actions that the network can provide are abstracted into 169 a number of classes called Service Action Types (SATs). While there 170 needs to be flexibility and extensibility, the number of service 171 action types will be limited. They will not be numerous like IP 172 protocol numbers or well-known TCP or UDP port numbers. Along with 173 the SAT, a source IPv6 address is used to identify the client system. 174 As will be seen below, the destination IPv6 address becomes optional. 175 A consequence is that the IP header and some aspects of the protocol 176 stack have to be redesigned. We will show below how this can be done 177 without disturbing most of the running network. Another consequence 178 is that the first step in processing a packet is to process the SAT, 179 not the destination address (if there is one). 181 Traditional reachability, when required, is provided by classical 182 IPv6, or by IPv4 as-a-service. 184 When an SOIP packet enters a router, it is classified at line speed 185 according to the SAT. Routing to upstream SOIP routers will be based 186 on the SAT, not on a destination IP address. Routing from a 187 dispatcher may be based on the SAT if the service required is based 188 on SOIP, or on a conventional IP address otherwise. A preliminary 189 list of SATs is shown in Figure 2, with brief descriptions: 191 ------------------------------------------------------------------ 192 | SATs | Direction | Description | 193 |----------------------------------------------------------------| 194 | IPv4 reachability| Request | IPv4 destination host | 195 | |___________| | 196 | | Response | IPv4 source host | 197 |----------------------------------------------------------------| 198 | IPv6 reachability| Request | IPv6 destination host | 199 | |___________| | 200 | | Response | IPv6 source host | 201 |----------------------------------------------------------------| 202 | Discovery Service| Request | Discover network services, e.g. | 203 | |___________| DNS, CDN. May map to IP Anycast | 204 | | Response | Content ID, service ID. | 205 | | | Or "service not available" error| 206 |----------------------------------------------------------------| 207 | Multicast Service| Request | Join multicast service for some | 208 | |___________| content, e.g. video stream | 209 | | Response | Multicast directory answers | 210 | | | request, provides m/c source. | 211 |----------------------------------------------------------------| 212 | Computation | Request | Submit task to network, with | 213 | Service | | computation type, task | 214 | |___________| descriptor and requester ID | 215 | | Response | Computation resource ID, or | 216 | | | direct result of task. | 217 | | | Or "service not available" error| 218 |----------------------------------------------------------------| 219 | Storage Service | Request | Submit/retrieve data to/from | 220 | | | network storage, with data | 221 | |___________| description and/or data ID | 222 | | Response | Storage locator, data ID. | 223 | | | Or "service not available" error| 224 |----------------------------------------------------------------| 225 | App Server | Request | To submit source code or deploy | 226 | Service | | package to application platform,| 227 | |___________| with necessary configurations. | 228 | | Response | Answer with service ID. | 229 | | | Or "service not available" error| 230 ------------------------------------------------------------------ 232 Figure 2 234 For each request there will be a corresponding response. The details 235 remain to be worked out - probably a generic response message 236 including the SAT. To allow multiple overlapping sessions, each 237 request/response sequence should have a unique ID, which will be used 238 by the SOIP dispatcher to match service responses to the appropriate 239 user session. 241 For IPv6-only networks, is expected that IPv4 reachability will be 242 provided by a solution such as 464XLAT. Also, no separate SAT is 243 needed for IPv6 to IPv4 translation. For example, if a host requests 244 IPv4 reachability but supplies an IPv6 address as its own locator, 245 NAT64 is implied. 247 For the moment codes for the SATs are undefined, but they are assumed 248 to be small integers. There are two possible approaches to the 249 packet format. One is to use a traditional Type-Length-Value (TLV) 250 layout. Another is to use a more flexible encoding at the lowest 251 level, taking advantage of some form of network processor in the 252 routers. An obvious choice would be Concise Binary Object 253 Representation (CBOR) [RFC7049], which combines flexibility with 254 efficiency. In either case we could require that the first four bits 255 of the wire format are a new IP version number other than 4 or 6. An 256 alternative, at least for early experimentation, is to run SOIP over 257 UDP and IPv6. 259 Examples of both encoding choices are described below. In either 260 case, the essential content of a packet header is as follows: 262 o The SAT code (small integer) 264 o Flag bits 266 o Traffic class (as for IPv6) 268 o Session Identifier (so that sessions can be tracked regardless of 269 IP address) 271 o Hop limit (small integer) 273 o User locator (IP address or identifier) 275 o Service data length (not needed in CBOR version) 277 o Service data (length depends on SAT) 279 o Payload length (not needed in CBOR version) 281 o Payload 283 Experience with IPv4 options, and IPv6 extension headers and options, 284 has shown that new ones are very hard to deploy on an operational 285 network, and that the ones defined during the initial design are not 286 always useful. Therefore we propose that all options and extensions 287 are defined as part of the service data and are not visible as part 288 of the basic packet header, giving good flexibility. 290 We propose to include the exact equivalent of the IPv6 Traffic Class, 291 which can work exactly as for IPv6 and IPv4. In contrast, one defect 292 in the IPv6 flow label is that it is different in the two directions 293 of a flow. Instead we propose a session ID that is the same in both 294 directions, which has various advantages by allowing immediate 295 session identification. 297 The flag bits provide useful indications to the routing system, if 298 set: 300 o Mobile - set if the user system is mobile 302 o Flow size (3 bits) 304 * 000 means a single packet, no flow/congestion state needed 306 * other values TBD indicate type of flow/congestion state 308 o Authenticated - set if packet authenticated (details TBD) 310 o Encrypted - set if encryption applied (details TBD) 312 Note that fragmentation is not supported. Fragmentation, and the 313 related mechanisms of MTU discovery, are a significant operational 314 problem in the current Internet [I-D.ietf-intarea-frag-fragile]. We 315 simply abolish this problem area in SOIP. It is designed for use in 316 managed networks where a single size of maximum transmission unit 317 (MTU) is available everywhere. An SOIP network will have a globally 318 defined MTU. Of course, IPv4 and IPv6 reachability services via the 319 open Internet will have to support PMTUD and fragmentation as best 320 they can, but this concerns the embedded IP packets, not the SOIP 321 packets, and will be invisible locally. 323 Appendix A outlines possible TLV and CBOR encodings of the SOIP 324 protocol. 326 3. Coexistence Issues 328 SOIP is expected to coexist with IPv6; in a sense it is a low-level 329 method of orchestrating IPv6 connections. We assume that each SOIP 330 client host has at least one IPv6 address, and that SOIP routers will 331 announce themselves using a suitable IPv6 Router Advertisement 332 extension [I-D.troan-6man-universal-ra-option]. Normally, the first- 333 hop SOIP router will be the same as the IPv6 first-hop router. 335 As a result of this, all standard management mechanisms such as 336 NETCONF may be used without further specification. Also, when a data 337 connection of any kind is established after a SOIP request/response 338 exchange, all standard transport mechanisms are available over IPv6. 339 As noted above, they are subject to the locally defined MTU as long 340 as they remain within the SOIP domain. 342 We do not define how SOIP would operate in an IPv4-only network. 344 4. Some Usage Examples 346 o Storage request (upload content): 348 * Service data identifies storage requirement (temporary/ 349 permanent, private/public, encryption, etc.) 351 * Payload identifies data (path/name.format, etc.) 353 o Storage request (download content): 355 * Service data identifies transmission requirement (streamed, 356 block, etc. and the specific transport protocol - UDP, TCP, 357 QUIC, etc. - if needed) 359 * Payload identifies data (path/name.format, etc.) 361 o Computation request 363 * Service data identifies computing requirement 365 * Payload identifies computing application 367 o Reachability request 369 * Service data gives destination IP address (or DNS name) 371 * Indication of transport protocol required (details TBD) 373 * Indication of options or extension headers required (details 374 TBD) 376 5. Continuity with the Existing Internet 378 Continuity is provided in two ways: 380 1. A user node can simply use IP completely in parallel with SOIP. 381 The network stack in the user node will simply encode the IP 382 packets as SOIP packets with the SAT for IP reachability, and a 383 SOIP dispatcher will send and receive IP packets at the SOIP 384 domain boundary. 386 2. If a service in the SOIP domain needs service from elsewhere in 387 the IP Internet to respond to a user request, it will use a 388 similar dispatcher function to do so.This could also be described 389 as a proxy mechanism. (Of course, services in interconnected 390 SOIP domains may talk to each other directly.) 392 6. Interface with Service and Application Domains 394 Various techniques are emerging for service or application specific 395 networking within operators' networks. An overview of the 396 motivations is given in [I-D.li-apn6-problem-statement-usecases], and 397 specific techniques have been defined such as Network Service Headers 398 [RFC8300] and Segment Routing [RFC8402], as well as Software-Defined 399 Networking in general [RFC7426]. A SOIP dispatcher that is aware of 400 such techniques may convert SOIP traffic into one of these 401 mechanisms, for example by encapsulation or proxying. Furthermore, 402 the model is future-proof. The dispatcher could be upgraded to 403 support unknown future service or application oriented networking 404 mechanisms, without requiring changes to SOIP clients or routers. 406 7. Security Considerations 408 It is intended that both authentication and encryption should be 409 available for all SOIP packets. However, this requires further work, 410 especially to determine whether existing mechanisms for key 411 management can be used. 413 Since clients are identified by an IPv6 address, existing layer 3 414 privacy considerations for IPv6 addresses will apply to SOIP 415 [RFC7721]. Upper layer privacy considerations will depend on the 416 service concerned. 418 8. IANA Considerations 420 This document makes no request of the IANA. 422 9. References 424 [I-D.carpenter-limited-domains] 425 Carpenter, B. and B. Liu, "Limited Domains and Internet 426 Protocols", draft-carpenter-limited-domains-10 (work in 427 progress), August 2019. 429 [I-D.ietf-intarea-frag-fragile] 430 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 431 and F. Gont, "IP Fragmentation Considered Fragile", draft- 432 ietf-intarea-frag-fragile-17 (work in progress), September 433 2019. 435 [I-D.li-apn6-problem-statement-usecases] 436 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 437 Ebisawa, K., Ueno, Y., Previdi, S., and J. Guichard, 438 "Problem statement and use cases of Application-aware IPv6 439 Networking (APN6)", draft-li-apn6-problem-statement- 440 usecases-00 (work in progress), September 2019. 442 [I-D.troan-6man-universal-ra-option] 443 Troan, O., "The Universal IPv6 Router Advertisement Option 444 (experiment)", draft-troan-6man-universal-ra-option-01 445 (work in progress), December 2018. 447 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 448 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 449 October 2013, . 451 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 452 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 453 Defined Networking (SDN): Layers and Architecture 454 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 455 2015, . 457 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 458 Considerations for IPv6 Address Generation Mechanisms", 459 RFC 7721, DOI 10.17487/RFC7721, March 2016, 460 . 462 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 463 "Network Service Header (NSH)", RFC 8300, 464 DOI 10.17487/RFC8300, January 2018, 465 . 467 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 468 Decraene, B., Litkowski, S., and R. Shakir, "Segment 469 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 470 July 2018, . 472 [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, 473 "Requirements for IPv6 Customer Edge Routers to Support 474 IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 475 2019, . 477 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 478 Definition Language (CDDL): A Notational Convention to 479 Express Concise Binary Object Representation (CBOR) and 480 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 481 June 2019, . 483 Appendix A. Possible TLV and CBOR Encodings 485 A.1. TLV Mapping 487 Figure 3 shows a possible type-length-value packet format. 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |Version|R R R R| SAT |M F F F A E R R| Traffic Class | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Session Identifier (32 bits) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Hop Limit | | 495 +-+-+-+-+-+-+-+-+ + 496 | | 497 + + 498 | Client Locator / Identifier (128 bits) | 499 + + 500 | | 501 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | SD length | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 504 | | 505 + Service Data (variable length) + 506 ... ... 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Payload Length | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + 510 | | 511 + Payload Data (variable length) + 512 ... ... 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 3 517 Version - IP version number TBD 519 R - Reserved, must be zero 521 SAT - Service Action Type code 523 M - Mobile flag 524 FFF - Flow type flags (FFF = 000 for single-packet flows; other 525 values for longer flows) 527 A - Authentication flag 529 E - Privacy (encryption) flag 531 Traffic class, exactly as for IPv6 533 Session identifier, 32-bit pseudo random number 535 Client Locator / Identifier - globally unique IPv6 address 537 A.2. CBOR Mapping 539 The packet consists of a CBOR byte string preceded by a single byte 540 (Figure 4). For example, for version 7, this byte would be 0x70. 541 This byte is not decoded as CBOR. 543 +-+-+-+-+-+-+-+-+ 544 |Version|R R R R| 545 +-+-+-+-+-+-+-+-+ 547 Figure 4 549 The CBOR bytes then obey the CDDL [RFC8610] specification in 550 Figure 5. 552 sat-packet = [sat, flags, traffic-class, session-id, hop-limit, 553 source, service-data, ?payload] 555 sat = 0..255 556 flags = bytes .size 1 557 traffic-class = 0..255 558 session-id = 0..4294967295 ;up to 32 bits 559 hop-limit = 0..255 560 client = ipv6-address 561 service-data = any 562 payload = any 564 ipv6-address = bytes .size 16 566 Figure 5 568 The syntax of the various service-data formats can be defined in 569 separate documents for each SAT value. 571 We assume that routers capable of handling a CBOR-based layer 3 572 protocol will exist, and will use some form of programmable network 573 processor rather than traditional ASIC or FPGA designs. This allows 574 great flexibility and software-friendly extensibility, especially of 575 the service data formats. Further investigation is needed whether 576 this is realistic. 578 Appendix B. Change log [RFC Editor: Please remove] 580 draft-jiang-service-oriented-ip-00, 2019-05-07: 582 Initial version 584 draft-jiang-service-oriented-ip-01, 2019-06-21: 586 Editorial corrections 588 draft-jiang-service-oriented-ip-02, 2019-10-29: 590 Added overview diagram 592 Added discussion of dispatcher function 594 Clarifications and editorial corrections 596 Authors' Addresses 598 Brian Carpenter 599 The University of Auckland 600 School of Computer Science 601 University of Auckland 602 PB 92019 603 Auckland 1142 604 New Zealand 606 Email: brian.e.carpenter@gmail.com 608 Sheng Jiang 609 Huawei Technologies Co., Ltd 610 Q14, Huawei Campus, No.156 Beiqing Road 611 Hai-Dian District, Beijing, 100095 612 P.R. China 614 Email: jiangsheng@huawei.com 615 Guangpeng Li 616 Huawei Technologies 617 Q14, Huawei Campus 618 No.156 Beiqing Road 619 Hai-Dian District, Beijing 100095 620 P.R. China 622 Email: liguangpeng@huawei.com