idnits 2.17.1 draft-yang-alto-deliver-functions-over-networks-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 : ---------------------------------------------------------------------------- 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 (30 July 2021) is 1001 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 5693 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-09 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG S. Yang 3 Internet-Draft L. Cui 4 Intended status: Standards Track Shenzhen University 5 Expires: 31 January 2022 M. Xu 6 Tsinghua University 7 C. Feng 8 Research Institute of Tsinghua University in Shenzhen 9 X.L. Xia 10 CRresolink 11 30 July 2021 13 Delivering Functions over Networks: Traffic and Performance Optimization 14 for Edge Computing using ALTO 15 draft-yang-alto-deliver-functions-over-networks-02 17 Abstract 19 As the rapid development of internet, massive data are produced. 20 Service providers typically need to deploy services near the edge 21 networks to better satisfy user_s demand. In order to obtain better 22 quality of the networks, computing functions and user traffic need to 23 be scheduled properly. However, it is challenging to efficiently 24 schedule resources among the distributed edge servers because of the 25 lack of network information, such as network topology, traffic 26 distribution, link delay/bandwidth and utilization/capability of 27 computing servers. In this standard, we employed the ALTO protocol 28 to help deliver functions and schedule traffic at the edge computing 29 platform. This protocol supplied information of multiple resources 30 for the distributed edge computing platform, thus enhancing the 31 efficiency of function delivery in edge computing platform. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 31 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 68 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Edge computing . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Features of ALTO protocol . . . . . . . . . . . . . . . . 5 71 3.3. Resources and services/functions . . . . . . . . . . . . 5 72 4. Scenario of delivering function . . . . . . . . . . . . . . . 6 73 5. Delivering functions by ALTO over edge computing . . . . . . 7 74 6. Implementation and Deployment . . . . . . . . . . . . . . . . 9 75 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 9 76 6.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.3. ALTO Integration . . . . . . . . . . . . . . . . . . . . 9 78 7. Management of Functions . . . . . . . . . . . . . . . . . . . 10 79 8. Multi-domain System . . . . . . . . . . . . . . . . . . . . . 11 80 9. Scheduling Framework . . . . . . . . . . . . . . . . . . . . 11 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 12.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 For recent years internet has been developing rapidly since it is 91 promising to be applied in industrial upgrading. In many scenarios 92 of industrial internet, massive data are produced and require to be 93 processed with high efficiency in real time. Typically, various 94 functions or services are delivered in these scenarios according to 95 the users_ demand. These functions or services could be (1) 96 surveillance videos that need analysis by AI, (2) Hi-Definition 97 videos that require to be encoded/decoded and (3) contents stored in 98 the edge network. It is noted that functions and services are 99 deployed widely in industrial internet. For instance, Function as a 100 service (FaaS) is applied and delivered more and more frequently in 101 the cloud computation service for industrial internet. 103 Many functions and services demand high quality of the supporting 104 networks. For instance, the delay and jitter are expected to be as 105 tiny as possible in order to obtain good user_s experience. 106 Different from Kubernets and Mesos that are able to efficiently 107 schedule computing resources in a single computing cluster, 108 deployment of functions in wide area networks usually encounters much 109 more complexity. 111 Many resources, including network traffic, bandwidth, topology, link 112 delay and the computing capacity/utilization of each computing 113 cluster, should be taken in to considerations when functions being 114 deployed over distributed networks. This network status or 115 information requires to be collected with unified interfaces and 116 protocols because the resources typically need to be scheduled 117 crossing different domains for satisfying user_s demands. In 118 addition, resources scheduling algorithms SHOULD and network 119 performances, such as load balancing, also needs to be optimized to 120 improve user_s experience. In this standard, we propose an efficient 121 method to utilize the computing and network resources by delivering 122 functions over the edge computing networks. 124 We use the ALTO (Application-Layer Traffic Optimization) [RFC7285] to 125 optimize network traffic and performance by delivering functions over 126 the edge computing network. ALTO can provide global network 127 information for the distributed applications, while the information 128 can not be retrieved or computed by the applications themselves 129 [RFC5693]. Specifically, the information of network for the 130 distributed edge cluster, such as network traffic, link delay and 131 other cost metrics, is collected and computed by ALTO. Subsequently, 132 by using the pre-defined scheduling algorithms, functions will be 133 delivered by system to the most suitable edge clusters based on the 134 information offered by ALTO. 136 For brevity, in this document, we will use the terminologies 137 introduced in [RFC7285] and [I-D.ietf-alto-unified-props-new]. 139 2. Conventions and Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Background 147 3.1. Edge computing 149 There are many applications and scenario of network that are very 150 sensitive to the quality of network. For instance, remote 151 controlling for machine tool typically needs enhanced broadband and 152 low-latency communication in real time. However, the scale of the 153 data generated by the equipment or sensors are usually very large (up 154 to be hundreds of GB per day). In addition, the data produced from 155 various equipment will require support of heterogeneous computing. 156 In this case, uploading these data to the centralized cloud 157 computation platform is difficult, expensive but not so useful. 158 Similarly, delivering functions or services from the cloud 159 computation platform to the local equipment is also hard and the 160 real-time performance will not be guaranteed. Alternatively, new 161 framework of computation and network SHOULD be adopted to address 162 these problems that hinder the edge computation to acquire broader 163 promotion. 165 Edge computing was designed to enhance the quality of network, 166 including the packet loss, security, bandwidth and latency. In order 167 to decrease the distance between the servers and users, people 168 typically will deploy servers at the edge nearing the users in the 169 edge computing infrastructure. In this framework, User_s tasks can 170 be submitted to the edge servers that will handle with the tasks 171 close to the user and return the computation output back to the user 172 promptly. As a consequence, the latency, bandwidth and network 173 traffic performance of edge computing will be better than that of the 174 centralized cloud computing. With these advantages, edge computing 175 has been applied in various applications in network, such as AI 176 supporting HD videos and VR/AR. 178 In this standard, functions and services will be delivered over the 179 edge computing so that we can schedule the computing functions 180 dynamically in a distributed edge computing network to enhance the 181 performance of network. Nevertheless, it should be noted that during 182 the deployment of the functions to edge servers, there are multiple 183 resources, such as bandwidth, computing and link resources, that 184 SHOULD be allocated to satisfy the requirements in terms of latency 185 and throughput. 187 3.2. Features of ALTO protocol 189 Application-Layer Traffic Optimization (ALTO) [RFC7285] is designed 190 to provide network information for distributed applications. 191 Specifically, the resource scheduling process for distributed 192 applications will be guided by the network states and information 193 that is provided by the ALTO server. Otherwise, the information will 194 fail to be retrieved by the applications. In this case, much 195 essential network information in the resource selection process, such 196 as network traffic, cost map, and cost metrics, will be offered by 197 the ALTO protocol. As a consequence, network traffic can be managed 198 by the distributed applications. In addition, they could make better 199 choice in selecting the path that contains lower delay to access the 200 network and handle with the computation tasks. 202 Because of being distributed over different areas of network, the 203 edge computing clusters would comprise various network states, such 204 as topology, network traffic, link delay and the computing capacity/ 205 utilization. Generally, in order to obtain better performance, the 206 scheduling decisions require to be adaptive to the network states 207 during the delivering of functions. Thus, the network information 208 and traffic can be managed by ALTO according to its mentioned 209 advantage. As a consequence, functions and services will be 210 delivered to a proper edge computing cluster. 212 3.3. Resources and services/functions 214 Generally, we have both limited resources and massive network 215 services/functions on the network. Some common limited resources are 216 as below. 218 * Computing resource: it usually represents the computing powers of 219 CPU or GPU. CPUs have different architectures, including ARM and 220 x86. The power of a CPU is affected by the working status, such 221 as current load, total space and available space. 223 * Link/Path: They are a physical or logical communication channel 224 between network devices, such as routers, servers and clients. 225 Properties of a link or path include hop count, bandwidth and 226 communication latency. 228 * Storage: that refers to space to store the data. The property of 229 storage includes the amount of space to save the data. 231 * Radio resource: It means the radio information in wireless 232 communication systems, such as cellular networks and wireless 233 local area networks. In 5G network, radio resources can be 234 combined with slicing technology to provide customized network 235 property for user_s differentiated network demand. 237 Except the limited resources above, as the network technology rapidly 238 develops, there are many network services and functions that could 239 supply abundant computation service to users. 241 * Software as a service: It supplies software services as a 242 platform. Software services, such as wechat and Alipay, are 243 deployed on the SaaS vendors_ servers, for users to access to and 244 use. 246 * AI as a service: it supplies artificial intelligence services as a 247 platform. Various artificial intelligence-based services, such as 248 face recognition, speech recognition and big data analysis, are 249 provided by vendors. 251 * Encoding/Decoding as a service: it supplies encoding and decoding 252 services for high-definition videos and VR/AR videos. It has been 253 widely applied in areas of smart city and online entertainment. 255 * Function as a service: it supplies function services as a 256 platform. Functions can be encapsulated docker images or pieces 257 of code. Usually, in order to let user access to FaaS easily and 258 conveniently, the vendor will expose the function APIs. One of 259 the main features of FaaS is allowing network resources to be 260 dynamically allocated to computing clusters. Therefore, users do 261 not need to handle with the complicated environment configuration 262 and resource management process, as they can utilize the function- 263 based computation services, such as face recognition, speech 264 recognition and big data analysis. 266 * Content: it supplies storage services as a platform. Utilizing 267 the content service, users can store their data such that users 268 could spare their limited local storage. Meanwhile, users can 269 retrieve the data from different terminals. 271 4. Scenario of delivering function 273 Suppose a scenario in IoT, in which unmanned aerial vehicle (UAV) are 274 connected via the network to apply for the face recognition computing 275 services. When a UAV submits a task, the face recognition function 276 will be delivered to an edge server to process the task. Then the 277 recognition results will be returned to the UAV. During this 278 process, network information, such as link delay and other cost 279 metrics, would be requested and retrieved by the ALTO protocols from 280 ALTO servers and clients in the network system. According to the 281 information supplied by ALTO, the function and task will be delivered 282 to the most suitable edge server that would provide best performance 283 to the UAVs. The schematic diagram of this framework is shown in 284 Figure 1 below. 286 +---------------+ +-------------------+ 287 | | | | 288 | | | | 289 | ALTO Server |<---------------->| ALTO Client | 290 | | | | 291 | | | | 292 +---------------+ +------^-----+------+ 293 | | 294 | | 295 | | 296 +--+-----v--+ 297 | Cluster | 298 +-------+ Client +------+ 299 | +-----------+ | 300 | | 301 | | 302 | | 303 +------v-------+ +-------v------+ 304 |Edge Computing| |Edge Computing| 305 | | ...... | | 306 | Cluster 1 | | Cluster N | 307 +--------------+ +--------------+ 309 Figure 1. Scenario of delivering function over edge network in IoT 311 5. Delivering functions by ALTO over edge computing 313 Since lots of edge clusters and servers are distributing in the 314 network, the system MUST handle the huge amount of edge devices and 315 their corresponding network traffic. A cluster client is employed to 316 manage the connectivity and traffic information of the distributed 317 edge clusters. The ALTO client will communicate with the cluster 318 client and provide the necessary network information. The usage of 319 ALTO is to optimize the network traffic and guide the function 320 delivering process in edge computing. It will provide the overall 321 network states with information for the distributed edge clusters, 322 and decide the appropriate edge cluster to deploy the functions. 324 More specifically, the ALTO server will collect and compute the 325 network cost metrics; including the link delay, availability, network 326 traffic, bandwidth, and etc. The information will then be sent to 327 the ALTO client. The ALTO client will select the target appropriate 328 edge clusters to deploy the target function. Finally, the system 329 will connect and deploy the function to the target servers, so that 330 users can submit their computation task to the selected edge 331 clusters. 333 +---------------+ +-------------------+ 334 | | (1) Network | | 335 | | Information | | 336 | ALTO Server |<---------------->| ALTO Client | 337 | | | | 338 | | | | 339 +---------------+ +------^-----+------+ 340 | | 341 (2)Get clusters | | (3)Select Cluster List 342 | | 343 +--+-----v--+ 344 | Cluster | 345 +-------+ Client +------+ 346 | +-----------+ | 347 | | 348 | (4) Connect to Cluster | 349 | and deliver function | 350 +------v-------+ +-------v------+ 351 |Edge Computing| |Edge Computing| 352 | | ...... | | 353 | Cluster 1 | | Cluster N | 354 +--------------+ +--------------+ 356 Figure 2. Delivering process in edge computing platform with ALTO 358 Figure 2 illustrates the infrastructure and function delivering 359 process of the edge computing platform. 361 1. The ALTO client requests the information, such as network map 362 and cost map of distributed edge clusters from the ALTO server, by 363 using ALTO protocol. 365 2. The Cluster Client requests an edge cluster list of the 366 network. 368 3. The ALTO Client returns the edge cluster list and 369 corresponding resource information about the clusters computed by 370 ALTO servers according to the network state. 372 4. The Cluster Client connects and delivers function to the 373 corresponding edge computing cluster according to the information, 374 and the cluster will process and return the computation results to 375 users. 377 Note that the data transfer process is using the ALTO protocol 378 described in [RFC7285] to guarantee the efficiency and security of 379 the delivering process. In this case, the edge computing clusters 380 are allowed to retrieve the network information, so that the function 381 can be delivered to the proper ones to achieve a better performance 382 in terms of latency, throughput, etc. 384 6. Implementation and Deployment 386 6.1. Implementation 388 We are inspired by the concept of Serverless Computing, which is a 389 new computing paradigm providing function-based computing services, 390 utilizing containerization technology to run functions. The 391 container, including the running code, library, and data 392 dependencies, will be deployed and orchestrated to target edge 393 servers and clusters by container orchestrator Kubernetes (or K8S). 394 The container orchestration scheme will be computed according to the 395 network information provided by ALTO. 397 IBM OpenWhisk will be used as the FaaS platform in edge clusters, in 398 which the resources are managed by K8S. With this containerization 399 technology, people can deliver functions and services flexibly to the 400 target edge server. Using this standard, users_ request for 401 function-based edge computing services can be efficiently redirected 402 to the target edge server for better performance. 404 6.2. Deployment 406 We have implemented a prototype and have been deploying it in real 407 network at a construction site and at a beer plant in Shenzhen, 408 China. The preliminary results of our deployment show that 1) the 409 performance of edge computing will be greatly improved by using the 410 supplied network information and 2) collection and scheduling 411 policies of this information need to be standardized to obtain 412 coordination among different domains. 414 6.3. ALTO Integration 416 T.B.D. 418 7. Management of Functions 420 As function standardization in our system could be useful in managing 421 functions efficiently, We will introduce this technique as below. 422 Our system can standardize the functions and expose standard APIs for 423 users to easily access to and apply for function-based computation 424 services. Above the function-based computation services, certain 425 function codes and docker images can be updated and replaced based on 426 the user_s demand or standard upgrade. This would be useful to the 427 function management of the platform. Specifically, function 428 standardization is composed of several steps below. 430 Specifically, function standardization consists of: 432 * Function repository: Generate the repository that stores all the 433 functions for users to apply for. 435 * Function registry/discovery: A service MUST be registered before 436 being applied for. After the registry, the information of service 437 will be broadcast to a registry server. In this circumstance, 438 when delivering the functions, the system will recognize which 439 node is registered with the function information by accessing to 440 the registry server. As a consequence, appropriate node can be 441 determined by our system in order to deliver functions with high 442 efficiency. 444 * Function status update: When there are updates, functions in all 445 the network nodes MUST be updated accordingly. 447 As function standardization is powerful in delivering function, users 448 can conveniently process their tasks by sending requests to the 449 interfaces of the system in which the standard APIs are exposed by 450 the process of function standardization. As described above, this 451 mechanism could help users to bypass the complexity of resource 452 deployment and configuration. In addition, the function 453 standardization is also useful in managing the system, because system 454 operators can update or replace the target functions more 455 efficiently. When users applying for functions, they can easily 456 locate the target edge servers since each function on the platform is 457 saved and registered in certain c edge servers before. 459 8. Multi-domain System 461 A function delivery platform can be a multi-domain system. For 462 example, there may be multiple service providers offering the 463 function-based computation service. In this case, we should consider 464 how to collect and manage the network information from different 465 domains, in order to achieve better function delivery performance in 466 networks. Consequently, we SHOULD develop additional designs for our 467 platform. 469 On the one hand, we introduce the layered design for function 470 delivery. More specifically, we deploy multiple distributed registry 471 servers in the lower layer, each of which processes the function 472 registry in its domain. Then we deploy a centralized registry server 473 in the upper layer to collect and manage the distributed registry 474 servers in the lower layer. A server in the lower layer will report 475 and send network information of its domain to the centralized server 476 in the upper layer periodically. And the centralized server will 477 coordinate the domains by sending instructions to the distributed 478 servers in the lower layer, which will make adjustment according to 479 the instructions of the centralized registry server. In this case, 480 the centralized registry server is able to manage the distributed 481 function and network information easily and efficiently, which is 482 beneficial to multi-domain system management. 484 On the other hand, we introduce the policy management for multiple 485 domains. Note that different domains MAY have various delivery 486 policies, thus we need to provide a policy management tool for 487 multiple domains. When delivering functions in a multi-domain 488 system, the tool will provide the overall management policy to 489 synchronize and coordinate the distributed local policies in each 490 individual domain. In this case, the distributed multiple domains in 491 different policies are able to communicate and coordinate with each 492 other, with the help of the policy management tool. Therefore, by 493 utilizing the policy management tool, we can manage the multiple 494 domains for efficient function delivery. 496 9. Scheduling Framework 498 Recently, with the development of high-capacity computing devices, 499 the computing power of networks has improved much. However, due to 500 the lack of efficient scheduling strategies, the current computing 501 platforms cannot achieve better computing throughput, i.e., the 502 ability to schedule the distributed computing power over a long 503 period. To improve the scheduling efficiency of the computing power, 504 researchers proposed some high-throughput computing scheduling 505 frameworks, for example, HTCondor, PBS, CPUsage, etc., which are able 506 to schedule the limited distributed computing power to achieve better 507 throughput of the network in a long period. Inspired by the high- 508 throughput computing scheduling frameworks, we develop the scheduling 509 framework for function delivery, in order to achieve better 510 performance of networks. 512 The objective of our scheduling framework for function delivery is to 513 minimize the computational latency. The basic idea is, our platform 514 will compute the function scheduling schemes, according to the 515 information collected by the ALTO server, including the network 516 congestion, resource utilization, etc. The users will access the 517 most appropriate edge server, which will provide the function-based 518 computation service and return the results to the users. 520 More specifically, when a user applies for the function delivery 521 service, it will send requests to the interface provided by the ALTO 522 server, along with its location and task information. The ALTO 523 server will also collect the resource utilization and network 524 information of the decentralized edge servers. Then, according to 525 the collected information, the ALTO server will compute the function 526 scheduling scheme, to determine the function delivery destination of 527 a specific edge server. The platform will select the edge server 528 with lowest computation latency for user. However, if the selected 529 edge server is overloaded, the platform will proceed to search other 530 edge server that satisfies the load balance demand, along with 531 achieving considerable latency performance. Finally, the user will 532 establish the communication channel with the target edge server, 533 which will provide the function-based service and return the results 534 to the users. 536 By developing the scheduling framework and strategy for function 537 delivery, our platform can maintain the stable network condition and 538 guarantee the load balance over a long period, which is beneficial to 539 the reliability of system. And users can enjoy a low-latency and 540 high-throughput function delivery service at the same time. 542 10. Security Considerations 544 T.B.D. 546 11. IANA Considerations 548 This document includes no requests to IANA. 550 12. References 552 12.1. Normative References 554 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 555 Optimization (ALTO) Problem Statement", RFC 5693, 556 DOI 10.17487/RFC5693, October 2009, 557 . 559 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 560 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 561 "Application-Layer Traffic Optimization (ALTO) Protocol", 562 RFC 7285, DOI 10.17487/RFC7285, September 2014, 563 . 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", March 1997. 568 12.2. Informative References 570 [I-D.ietf-alto-unified-props-new] 571 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 572 Gao, "Unified Properties for the ALTO Protocol", Work in 573 Progress, Internet-Draft, draft-ietf-alto-unified-props- 574 new-09, 4 September 2019, . 577 Authors' Addresses 579 Shu Yang 580 Shenzhen University 581 South Campus, Shenzhen University 582 Shenzhen 583 518060 584 P.R. China 586 Phone: +86-755-2653-4078 587 Email: yang.shu@szu.edu.cn 589 Laizhong Cui 590 Shenzhen University 591 South Campus, Shenzhen University 592 Shenzhen 593 518060 594 P.R. China 596 Phone: +86-755-8695-6280 597 Email: cuilz@szu.edu.cn 598 Mingwei Xu 599 Tsinghua University 600 Department of Computer Science, Tsinghua University 601 Beijing 602 100084 603 P.R. China 605 Phone: +86-10-6278-5822 606 Email: xumw@tsinghua.edu.cn 608 C.Q. Feng 609 Research Institute of Tsinghua University in Shenzhen 610 Nanshan Hi-new Technology and Industry Park 611 Shenzhen 612 518060 613 P.R. China 615 Email: 236086832@qq.com 617 Xiuli Xia 618 China Resources Resolink 619 Shenzhen New Generation Industrial Park,No.136 Zhongkang Road 620 Shenzhen 621 518049 622 P.R. China 624 Email: xiaxiuli@foxmail.com