idnits 2.17.00 (12 Aug 2021) /tmp/idnits17660/draft-ietf-anima-grasp-distribution-04.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 ([RFC8990], [RFC7575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (10 January 2022) is 124 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: 'RFC5424' is mentioned on line 745, but not defined == Missing Reference: 'RFC6241' is mentioned on line 745, but not defined == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC8933' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'RFC8995' is defined on line 1023, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: draft-ietf-anima-grasp-api has been published as RFC 8991 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xiao (Ed.) 3 Internet-Draft MRC, Huawei Technologies 4 Intended status: Standards Track B. Liu 5 Expires: 14 July 2022 Huawei Technologies 6 A. Hecker 7 MRC, Huawei Technologies 8 S. Jiang 9 Huawei Technologies 10 10 January 2022 12 Information Distribution over GRASP 13 draft-ietf-anima-grasp-distribution-04 15 Abstract 17 Autonomic network infrastructure (ANI) is a generic platform for 18 tenant applications (i.e. AFs). As we will see in some examplery 19 use cases, AFs may not only require communication capability 20 supported from the infrastructure side, but also the capability the 21 infrastructure can hold and re-distribute information on-demand. 22 This document proposes a set of solutions for information 23 distribution in the ANI. Information distribution is categorized 24 into two different modes: 1) instantaneous distribution and 2) 25 publishing for retrieval. In the former case, the information is 26 sent, propagated and disposed of after reception. In the latter 27 case, information needs to be stored in the network; additionally, 28 conflict resolution is also needed when information stored in the 29 network is updated with proposals from two different AFs. 31 The capability of information distribution is a fundamental need for 32 an autonomous network ([RFC7575]). This document describes typical 33 use cases of information distribution in ANI and requirements to ANI, 34 such that abundant ways of information distribution can be natively 35 supported. This draft proposes a series of extensions to the 36 autonomic nodes and suggests an implementation based on GRASP 37 ([RFC8990]) extensions as a protocol on the wire. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 14 July 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Use Cases of Information Distribution . . . . . . . . . . . . 4 74 2.1. Vehicle-to-Everything (V2X) Communications . . . . . . . 4 75 2.2. Service-Based Architecture (SBA) in 3GPP . . . . . . . . 5 76 2.3. In-Network Computing (INC) . . . . . . . . . . . . . . . 7 77 3. General Requirements of Information Distribution in ANI . . . 7 78 4. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Instant Information Distribution (IID) Sub-module . . . . 10 80 4.1.1. Instant P2P Communication . . . . . . . . . . . . . . 10 81 4.1.2. Instant Flooding Communication . . . . . . . . . . . 11 82 4.2. Asynchronous Information Distribution (AID) Sub-module . 12 83 4.2.1. Information Storage . . . . . . . . . . . . . . . . . 12 84 4.2.2. Event Queue . . . . . . . . . . . . . . . . . . . . . 14 85 4.3. Bulk Information Transfer . . . . . . . . . . . . . . . . 16 86 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5. Extending GRASP for Information Distribution . . . . . . . . 18 88 5.1. Realizing Instant P2P Transmission . . . . . . . . . . . 18 89 5.2. Realizing Instant Selective Flooding . . . . . . . . . . 18 90 5.3. Realizing Bulk Information Transfer . . . . . . . . . . . 19 91 5.4. Realizing Subscription as An Event . . . . . . . . . . . 19 92 5.5. Un_Subscription Objective Option . . . . . . . . . . . . 19 93 5.6. Publishing Objective Option . . . . . . . . . . . . . . . 20 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 10.2. Informative References . . . . . . . . . . . . . . . . . 21 101 Appendix A. Open Issues [RFC Editor: To Be removed before becoming 102 RFC] . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 Appendix B. Closed Issues [RFC Editor: To Be removed before 104 becoming RFC] . . . . . . . . . . . . . . . . . . . . . . 23 105 Appendix C. Change log [RFC Editor: To Be removed before becoming 106 RFC] . . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 Appendix D. Information Distribution Module in ANI . . . . . . . 23 108 Appendix E. Asynchronous ID Integrated with GRASP APIs . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 111 1. Introduction 113 In an autonomic network, autonomic functions (AFs) running on 114 autonomic nodes constantly exchange information, e.g. AF control/ 115 management signaling or AF data exchange. This document discusses 116 the information distribution capability of such exchanges among AFs. 117 Many use cases can be abstracted to this model. In the following 118 sections, we will see that the information distribution capability 119 shall become a common denominator in future application scenarios. 121 In general, depending on the number of participants, the information 122 can be distributed in in the following scenarios: 124 1) Point-to-point (P2P) Communication: information is exchanged 125 between two AFs. 127 2) One-to-Many Communication: information exchanges involve one 128 source AF and multiple receiving AFs. 130 Approaches of infrmation distribution can be mainly categorized into 131 two basic modes: 133 1) An instantaneous mode (push): a source sends the actual content 134 (e.g. control/management signaling, synchronization data and so 135 on) to all interested receiver(s) immediately. Generally, some 136 preconfigurations are required, where nodes interested in this 137 information must be already known to all nodes because any source 138 AF must be able to decide, to which AFs the data is to be sent. 140 2) An asynchronous mode (delayed pull): here, a source AF publishes 141 the content in some forms in the network, which may later be 142 looked for, found and retrieved by some endpoints in the AN. 143 Here, depending on the size of the content, either the whole 144 content or only its metadata might be published into the AN. In 145 the latter case the metadata (e.g. a content descriptor, e.g. a 146 key, and a location in the ANI) may be used for the actual 147 retrieval. Importantly, the source, i.e., here as a publisher, 148 needs to be able to determine the location, where the information 149 (or its metadata) can be stored. 151 Note that in both cases, the total size of transferred information 152 can be larger than the payload size of a single message of a used 153 transport protocol (e.g., Synchronization and Flood messages in 154 GRASP). In this situation, this document also considers a case of 155 bulk data transfer. To avoid repetitive implementations by each AF 156 developer, this document opts for a common support for information 157 distribution implemented as a basic ANI capability. Therefore, it 158 will be available to all AFs. In fact, GRASP already provides part 159 of the capabilities. 161 Regardless, an AF may still define and implement its own information 162 distribution capability. Such a capability may then be advertised 163 using the common information distribution capability defined in this 164 document. Overall, ANI nodes and AFs may decide, which of the 165 information distribution mechanisms they want to use for which type 166 of information, according to their own preferences. 168 This document first analyzes requirements for information 169 distribution in autonomic networks (Section 3) and then discuss the 170 relevant node behaviors (Section 4). After that, the required GRASP 171 extensions are formally introduced (Section 5). 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 2. Use Cases of Information Distribution 179 In this section, we present some important use cases where 180 information distribution is required and ACP's support is commanly 181 needed. 183 2.1. Vehicle-to-Everything (V2X) Communications 185 The connected Autonomous Driving (AD) vehicles market is driving the 186 evolution of the Internet of Vehicles (IoV) (or Vehicular IoT) and is 187 growing at a five-year compound annual growth rate of 45%, which is 188 10 times as fast as the overall car market. V2X communication is an 189 inevitable enabling technology that connects vehicles to networks, 190 where value-added services can be provided and enhance the 191 functionalities of a vehicle. In this section, we introduce some use 192 cases that will be closely relevant to information distribution in an 193 ANI. 195 1) Real-time and High Definition Maps (HDM): In the era of 196 autonomous driving, a digital map not only means for navigation, 197 but real-time and detailed information is required when driving a 198 vehicle. Real-time situational awareness is essential for 199 autonomous vehicles especially at critical road segments in cases 200 of changing road conditions (e.g. new traffic cone detected by 201 another vehicle some time ago). In addition, the relevant high 202 definition local maps have to be available with support from 203 infrastructure side. In this regards, a digital map should not be 204 considered as static information stored on the vehicle, which is 205 spontaneously updated in a periodical manner. Instead, it shall 206 be considered as a dynamic distribution based on information 207 aggregated from the local area and such a distribution shall 208 consider latency requirement. Clearly, the infrastructure side 209 shall be able to hold the information in the network sufficiently 210 close to the relevant area. 212 2) In-car Infotaiment: This is another popular use case where in-car 213 data demands will increase significantly in the near future. 214 Today, users their mobile phone to access Internet for retrieving 215 data for work or entertainment purposes. There is already a 216 concensus among OTTs, carriers and car manufacturers that vehicle 217 will become the center of information for passengers onboard. For 218 entertainment, typical scenarios can be stereo HD video streaming 219 and online gaming; for business purposes, examples can be mobile 220 conference. This therefore requires the infrastructure side to be 221 able to schedule and deliver requested information/data to the 222 users with quality-of-service (QoS) considerations. 224 3) Software Update: Software components of connected cars will be 225 remotely maintained in future. Therefore, software update has to 226 be supported by the infrastructure side. Although this can be 227 done by centralized solution where all vehicles access to a 228 central clouds, in terms of load balancing and efficiency, 229 prepared update components can be stored in the network and 230 delivered to endpoints in a distributed manner. 232 2.2. Service-Based Architecture (SBA) in 3GPP 234 In addition to Internet, carrier networks (i.e. wireless mobile 235 networks) is another world-wide networking system. The current 236 architecture of 5G mobile networks from 3GPP has been defined to 237 follow a service-based architecture (SBA) where any network function 238 (NF) can be dynamically associated with any other NF(s) when needed 239 to compose a network service. Note that one NF can simultaneously 240 associate with multiple other NFs, instead of being physically wired 241 as in the previous generations of mobile networks. NFs communicate 242 with each other over service-based interface (SBI), which is also 243 standardized by 3GPP [3GPP.23.501]. 245 To realize an SBA network system, detailed requirements are further 246 defined to specify how NFs should interact with each other with 247 information exchange over the SBI. We now list three requirements 248 that are related to information distribution here. 250 1) NF Pub/Sub: Any NF should be able to expose its service status to 251 the network and any NF should be able to subscribe the service 252 status of an NF and get notified if the status is available. A 253 concrete example is that a session management function (SMF) can 254 subscribe to the REGISTER notification from an access management 255 function (AMF) if there is a new user equipment trying to access 256 the mobile network [3GPP.23.502]. 258 2) Network Exposure Function (NEF): A particular network function 259 that is required to manage the event exposure and distributions. 260 Specifically, SBA requires such a functionality to register 261 network events from the other NFs (e.g. AMF, SMF and so on), 262 classify the events and properly handle event distributions 263 accordingly in terms of different criteria (e.g. priorities) 264 [3GPP.23.502]. 266 3) Network Repository Function (NRF): A particular network function 267 where all service status information is stored for the whole 268 network. An SBA network system requires all NFs to be stateless 269 so as to improve the resilience as well as agility of providing 270 network services. Therefore, the information of the available NFs 271 and the service status generated by those NFs will be globally 272 stored in NRF as a repository of the system. This clearly implies 273 storage capability that keeps the information in the network and 274 provides those information when needed. A concrete example is 275 that whenever a new NF comes up, it first of all registers itself 276 at NRF with its profile. When a network service requires a 277 certain NF, it first inquires NRF to retrieve the availability 278 information and decides whether or not there is an available NF or 279 a new NF must be instantiated [3GPP.23.502]. 281 (Note: 3GPP CT adopted HTTP2.0/JSON to be the protocol communicating 282 between NFs, but autonomic networks can also load HTTP2.0 with in 283 ACP.) 285 Note that the requirements of the information distribution for ANI 286 control plane are not mentioned here, rather only AF services that 287 have to be necessarily supported by additional information 288 distribution are discussed. 290 2.3. In-Network Computing (INC) 292 In-network computing recently gets a lot of attentions. INC improves 293 the utilization of the computing resources in the network; INC also 294 brings the processed results closer to the users, which may 295 potentially improves the QoS of network services. 297 Unlike existing network systems, INC deploys computing tasks directly 298 in the network rather than pushing the tasks to endpoints outside the 299 network. Therefore, a network device is not just a transport device, 300 but a mixture of forwarding, routing and computing. The requires an 301 INC-supported network device having storage by default. Furthermore, 302 computing agents deployed on network nodes will have to communicate 303 with each other by exchanging information. There are several typical 304 applications, where information distribution capability is required, 305 which are summarized below. 307 1) Data Backup: There can be multiple computing agents that are 308 created to serve the same purpose(s). In reality, the multiple 309 agents can run for service resilience, load balancing and so on. 310 This forms a service set. The instances in the service set can be 311 deployed at different locations in the network while they need to 312 keep synchronizing their local states for global consistency. In 313 this case, the computing agents will have to constantly send and 314 receive information across the network. 316 2) Data Aggregation: Multiple computing agents may process different 317 computing tasks but the derived results have to be aggregated or 318 combined. Then a collective result can be derived. In this case, 319 different computing agents collaborate with each other, where 320 information data are exchanged during the processing. A popular 321 example is distributed AI or federated learning applications, 322 where data are stored at different places and model training with 323 the local data is also done in a distributed way. After that, 324 trained models by distributed agents will have to be aggregated. 325 Information distribution will be utlized heavily, combining with 326 local storage. 328 Clearly, AFs running on network nodes in ANI are the abstraction of 329 the INC use case. AFs can be deployed for both scenarios above. 331 3. General Requirements of Information Distribution in ANI 333 According to the introduced use cases, the question of information 334 distribution in an autonomic network can be discussed through 335 particular use cases or more generally. Depending on the situation 336 it can be quite simple or might require more complex provisions. 338 Indeed, in the most general case, the information can be sent: 340 1) at once (in one or multiple packets, in one flow), 342 2) straightaway (send-and-forget), 344 3) to all nodes. 346 For the first scenario, presuming 1), 2) and 3) hold, information 347 distribution in smaller or scarce topologies can be implemented using 348 broadcast, i.e. unconstrained flooding. For reasons well-understood, 349 this approach has its limits in larger and denser networks. In this 350 case, a graph can be constructed such that it contains every node 351 exactly once (e.g. a spanning tree), still allowing to distribute any 352 information to all nodes straightaway. Multicast tree construction 353 protocols could be used in this case. There are reasonable use cases 354 for such scenarios, as presented in Section 2. 356 Secondly, a more complex scenario arises, if only 1) and 2) hold, but 357 the information only concerns a subset of nodes. Then, some kinds of 358 selection become required, to which nodes the given information 359 should be distributed. Here, a further distinction is necessary; 360 notably, if the selection of the target nodes is with respect to the 361 nature or position of the node, or whether it is with respect to the 362 information content. If the first, some knowledge about the node 363 types, its topological position, etc (e.g. the routing information 364 within ANI) can be used to distinguish nodes accordingly. For 365 instance, edge nodes and forwarding nodes can be distinguished in 366 this way. If the distribution scope is primarily to be defined by 367 the information elements, then a registration / join / subscription 368 or label distribution mechanism is unavoidable. This would be the 369 case, for instance, if the AFs can be dynamically deployed on nodes, 370 and the information is majorily destined to the AFs. Then, depending 371 on the current AF deployment, the distribution scope must be adjusted 372 as well. 374 Thirdly, if only 1) holds, but the information content might be 375 required again and again, or might not yet be fully available, then 376 more complex mechanisms might be required to store the information 377 within the network for later, for further redistribution, and for 378 notification of interested nodes. Examples for this include 379 distribution of reconfiguration information for different AF 380 instances, which might not require an immediate action, but only an 381 eventual update of the parameters. Also, in some situations, there 382 could be a significant delay between the occurrence of a new event 383 and the full content availability (e.g. if the processing requires a 384 lot of time). 386 Finally, none of the three might hold. Then, along with the 387 subscription and notification, the actual content might be different 388 from its metadata, i.e. some descriptions of the content and, 389 possibly, its location. The fetching can then be implemented in 390 different, appropriate ways, if necessary as a complex transport 391 session. 393 In essence, as flooding is usually not an option, and the interest of 394 nodes for particular information elements can change over time, ANI 395 should support autonomics also for the information distribution. 397 This calls for autonomic mechanisms in the ANI, allowing 398 participating nodes to 1) advertise/publish, 2) look for/subscribe to 399 3) store, 4) fetch/retrieve and 5) instantaneously push data 400 information. 402 In the following cases, situations depicting complicated ways of 403 information distribution are discussed. 405 1) Long Communication Intervals. The actual sending of the 406 information is not necessarily instantaneous with some events. 407 Sophisticated AFs may involve into longer jobs/tasks (e.g. 408 database lookup, validations, etc.) when processing requests, and 409 might not be able to reply immediately. Instead of actively 410 waiting for the reply, a better way for an interested AF might be 411 to get notified, when the reply is finally available. 413 2) Common Interest Distribution. AFs may share information that is 414 a common interest. For example, the network intent will be 415 distributed to network nodes enrolled, which is usually one-to- 416 many scenario. Intent distribution can also be performed by an 417 instant flooding (e.g. via GRASP) to every network node. However, 418 because of network changes, not every node can be just ready at 419 the moment when the network intent is broadcast. Also, a flooding 420 often does not cover all network nodes as there is usually a 421 limitation on the hop number. In fact, nodes may join in the 422 network sequentially. In this situation, an asynchronous 423 communication model could be a better choice where every (newly 424 joining) node can subscribe the intent information and will get 425 notified if it is ready (or updated). 427 3) Distributed Coordination. With computing and storage resources 428 on autonomic nodes, alive AFs not only consume but also generate 429 data information. An example is AFs coordinating with each other 430 as distributed schedulers, responding to service requests and 431 distributing tasks. It is critical for those AFs to make correct 432 decisions based on local information, which might be asymmetric as 433 well. AFs may also need synthetic/aggregated data information 434 (e.g. statistic info, like average values of several AFs, etc.) 435 to make decisions. In these situations, AFs will need an 436 efficient way to form a global view of the network (e.g. about 437 resource consumption, bandwidth and statistics). Obviously, 438 purely relying on instant communication model is inefficient, 439 while a scalable, common, yet distributed data layer, on which AFs 440 can store and share information in an asynchronous way, should be 441 a better choice. 443 4) Collision Update. Information data not only can be propagated 444 and stored on network nodes in the network, they have to be 445 conflict-free when information is updated especially when there is 446 no central authority available. For example, when two AFs try to 447 propose different updates for the same piece of information that 448 already exist in the network, a decision has to be made for how 449 the existing information shall be updated. Obviously, if this 450 duty has to be handled by individual AFs, the implematation of an 451 AF is too complicated. Therefore, information distribution should 452 consider conflict resultion and provides a set of general 453 solutions for AFs in order to keep information conflict free. 455 Therefore, for ANI, in order to support various communication 456 scenarios, an information distribution module is required, and both 457 instantaneous and asynchronous communication models should be 458 supported. Some real-world use cases are introduced in Section 2. 460 4. Node Behaviors 462 In this section, how a node should behave in order to support the two 463 identified modes of information distribution is discussed. An ANI is 464 a distributed system, so the information distribution module must be 465 implemented in a distributed way as well. 467 4.1. Instant Information Distribution (IID) Sub-module 469 In this case, an information sender directly specifies the 470 information receiver(s). The instant information distribution sub- 471 module will be the main element. 473 4.1.1. Instant P2P Communication 475 IID sub-module performs instant information transmission for ASAs 476 running in an ANI. In specific, IID sub-module will have to retrieve 477 the address of the information receiver specified by an ASA, then 478 deliver the information to the receiver. Such a delivery can be done 479 either in a connectionless or a connection-oriented way. 481 Current GRASP provides the capability to support instant P2P 482 synchronization for ASAs. A P2P synchronization is a use case of P2P 483 information transmission. However, as mentioned in Section 3, there 484 are some scenarios where one node needs to transmit some information 485 to another node(s). This is different to synchronization because 486 after transmitting the information, the local status of the 487 information does not have to be the same as the information sent to 488 the receiver. This is not directly support by existing GRASP. 490 4.1.2. Instant Flooding Communication 492 IID sub-module finishes instant flooding for ASAs in an ANI. Instant 493 flooding is for all ASAs in an ANI. An information sender has to 494 specify a special destination address of the information and 495 broadcast to all interfaces to its neighbors. When another IID sub- 496 module receives such a broadcast, after checking its TTL, it further 497 broadcast the message to the neighbors. In order to avoid flooding 498 storms in an ANI, usually a TTL number is specified, so that after a 499 pre-defined limit, the flooding message will not be further broadcast 500 again. 502 In order to avoid unnecessary flooding, a selective flooding can be 503 done where an information sender wants to send information to 504 multiple receivers at once. When doing this, sending information 505 needs to contain criteria to judge on which interfaces the 506 distributed information should and should not be sent. Specifically, 507 the criteria contain: 509 * Matching Condition: a set of matching rules such as addresses of 510 recipients, node features and so on. 512 * Action: what the node needs to do when the Matching Condition is 513 fulfilled. For example, the action could be forwarding or 514 discarding the distributed message. 516 Sent information must be included in the message distributed from the 517 sender. The receiving node reacts by first checking the carried 518 Matching Condition in the message to decide who should consume the 519 message, which could be either the node itself, some neighbors or 520 both. If the node itself is a recipient, Action field is followed; 521 if a neighbor is a recipient, the message is sent accordingly. 523 An exemplary extension to support selective flooding on GRASP is 524 described in Section 5. 526 4.2. Asynchronous Information Distribution (AID) Sub-module 528 In asynchronous information distribution, sender(s) and receiver(s) 529 are not immediately specified while they may appear in an 530 asynchronous way. Firstly, AID sub-module enables that the 531 information can be stored in the network; secondly, AID sub-module 532 provides an information publication and subscription (Pub/Sub) 533 mechanism for ASAs. 535 As sketched in the previous section, in general each node requires 536 two modules: 1) Information Storage (IS) module and 2) Event Queue 537 (EQ) module in the information distribution module. Details of the 538 two modules are described in the following sections. 540 4.2.1. Information Storage 542 IS module handles how to save and retrieve information for ASAs 543 across the network. The IS module uses a syntax to index 544 information, generating the hash index value (e.g. a hash value) of 545 the information and mapping the hash index to a certain node in ANI. 546 Note that, this mechanism can use existing solutions. Specifically, 547 storing information in an ANIMA network will be realized in the 548 following steps. 550 1) ASA-to-IS Negotiation. An ASA calls the API provided by 551 information distribution module (directly supported by IS sub- 552 module) to request to store the information somewhere in the 553 network. The IS module performs various checks of the request 554 (e.g. permitted information size). 556 2) Storing Peer Mapping. The information block will be handled by 557 the IS module in order to calculate/map to a peer node in the 558 network. Since ANIMA network is a peer-to-peer network, a typical 559 way is to use distributed hash table (DHT) to map information to a 560 unique index identifier. For example, if the size of the 561 information is reasonable, the information block itself can be 562 hashed, otherwise, some meta-data of the information block can be 563 used to generate the mapping. 565 3) Storing Peer Negotiation Request. Negotiation request of storing 566 the information will be sent from the IS module to the IS module 567 on the destination node. The negotiation request contains 568 parameters about the information block from the source IS module. 569 According to the parameters as well as the local available 570 resource, the requested storing peer will send feedback the source 571 IS module. 573 4) Storing Peer Negotiation Response. Negotiation response from the 574 storing peer is sent back to the source IS module. If the source 575 IS module gets confirmation that the information can be stored, 576 source IS module will prepare to transfer the information block; 577 otherwise, a new storing peer must be discovered (i.e. going to 578 step 7). 580 5) Information Block Transfer. Before sending the information block 581 to the storing peer that already accepts the request, the IS 582 module of the source node will check if the information block can 583 be afforded by one GRASP message. If so, the information block 584 will be directly sent by calling a GRASP API 585 ([I-D.ietf-anima-grasp-api]). Otherwise, a bulk data transmission 586 is needed. For that, there are multiple ways to do it. The first 587 option is to utilize one of existing protocols that is independent 588 of the GRASP stack. For example, a session connectivity can be 589 established to the storing peer, and over the connection the bulky 590 data can be transmitted part by part. In this case, the IS module 591 should support basic TCP-based session protocols such as HTTP(s) 592 or native TCP. The second option is to directly use GRASP itself 593 for bulky data transferring [I-D.carpenter-anima-grasp-bulk]. 595 6) Information Writing. Once the information block (or a smaller 596 block) is received, the IS module of the storing peer will store 597 the data block in the local storage is accessible. 599 7) (Optional) New Storing Peer Discovery. If the previously 600 selected storing peer is not available to store the information 601 block, the source IS module will have to identify a new 602 destination node to start a new negotiation. In this case, the 603 discovery can be done by using discovery GRASP API to identify a 604 new candidate, or more complex mechanisms can be introduced. 606 Similarly, Getting information from an ANI will be realized in the 607 following steps. 609 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 610 exposed by the information distribution module. The key/index of 611 the interested information will be sent to the IS module. An 612 assumption here is that the key/index should be known to an ASA 613 before an ASA can ask for the information. This relates to the 614 publishing/subscribing of the information, which are handled by 615 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 617 2) Storing Peer Mapping. IS module maps the key/index of the 618 requested information to a peer that stores the information, and 619 prepares the information request. The mapping here follows the 620 same mechanism when the information is stored. 622 3) Retrieval Negotiation Request. The source IS module sends a 623 request to the storing peer and asks if such an information object 624 is available. 626 4) Retrieval Negotiation Response. The storing peer checks the key/ 627 index of the information in the request, and replies to the source 628 IS module. If the information is found and the information block 629 can be afforded within one GRASP message, the information will be 630 sent together with the response to the source IS module. 632 5) (Optional) New Destination Request. If the information is not 633 found after the source IS module gets the response from the 634 originally identified storing peer, the source IS module will have 635 to discover the location of the requested information. 637 IS module can reuse distributed databases and key value stores like 638 NoSQL, Cassandra, DHT technologies. storage and retrieval of 639 information are all event-driven responsible by the EQ module. 641 4.2.2. Event Queue 643 The Event Queue (EQ) module is to help ASAs to publish information to 644 the network and subscribe to interested information in asynchronous 645 scenarios. In an ANI, information generated on network nodes is an 646 event labeled with an event ID, which is semantically related to the 647 topic of the information. Key features of EQ module are summarized 648 as follows. 650 1) Event Group: An EQ module provides isolated queues for different 651 event groups. If two groups of AFs could have completely 652 different purposes, the EQ module allows to create multiple queues 653 where only AFs interested in the same topic will be aware of the 654 corresponding event queue. 656 2) Event Prioritization: Events can have different priorities in 657 ANI. This corresponds to how much important or urgent the event 658 implies. Some of them are more urgent than regular ones. 659 Prioritization allows AFs to differentiate events (i.e. 660 information) they publish or subscribe to. 662 3) Event Matching: an information consumer has to be identified from 663 the queue in order to deliver the information from the provider. 664 Event matching keeps looking for the subscriptions in the queue to 665 see if there is an exact published event there. Whenever a match 666 is found, it will notify the upper layer to inform the 667 corresponding ASAs who are the information provider and 668 subscriber(s) respectively. 670 The EQ module on every network node operates as follows. 672 1) Event ID Generation: If information of an ASA is ready, an event 673 ID is generated according to the content of the information. This 674 is also related to how the information is stored/saved by the IS 675 module introduced before. Meanwhile, the type of the event is 676 also specified where it can be of control purpose or user plane 677 data. 679 2) Priority Specification: According to the type of the event, the 680 ASA may specify its priority to say how this event is to be 681 processed. By considering both aspects, the priority of the event 682 will be determined. 684 3) Event Enqueue: Given the event ID, event group and its priority, 685 a queue is identified locally if all criteria can be satisfied. 686 If there is such a queue, the event will be simply added into the 687 queue, otherwise a new queue will be created to accommodate such 688 an event. 690 4) Event Propagation: The published event will be propagated to the 691 other network nodes in the ANIMA domain. A propagation algorithm 692 can be employed to optimize the propagation efficiency of the 693 updated event queue states. 695 5) Event Match and Notification: While propagating updated event 696 states, EQ module in parallel keeps matching published events and 697 its interested consumers. Once a match is found, the provider and 698 subscriber(s) will be notified for final information retrieval. 700 The category of event priority is defined as the following. In 701 general, there are two event types: 703 1) Network Control Event: This type of events are defined by the ANI 704 for operational purposes on network control. A pre-defined 705 priority levels for required system messages is suggested. For 706 highest level to lowest level, the priority value ranges from 707 NC_PRIOR_HIGH to NC_PRIOR_LOW as integer values. The NC_PRIOR_* 708 values will be defined later according to the total number system 709 events required by the ANI. 711 2) Custom ASA Event: This type of events are defined by the ASAs of 712 users. This specifies the priority of the message within a group 713 of ASAs, therefore it is only effective among ASAs that join the 714 same message group. Within the message group, a group header/ 715 leader has to define a list of priority levels ranging from 716 CUST_PRIOR_HIGH to CUST_PRIOR_LOW. Such a definition completely 717 depends on the individual purposes of the message group. When a 718 system message is delivered, its event type and event priority 719 value have to be both specified. 721 Event contains the address where the information is stored, after a 722 subscriber is notified, it directly retrieves the information from 723 the given location. 725 4.3. Bulk Information Transfer 727 In both cases discussed previously, they are limited to distributing 728 GRASP Objective Options contained in messages that cannot exceed the 729 GRASP maximum message size of 2048 bytes. This places a limit on the 730 size of data that can be transferred directly in a GRASP message such 731 as a Synchronization or Flood operation for instantaneous information 732 distribution. 734 There are scenarios in autonomic networks where this restriction is a 735 problem. One example is the distribution of network policy in 736 lengthy formats such as YANG or JSON. Another case might be an 737 Autonomic Service Agent (ASA) uploading a log file to the Network 738 Operations Center (NOC). A third case might be a supervisory system 739 downloading a software upgrade to an autonomic node. A related case 740 might be installing the code of a new or updated ASA to a target 741 node. 743 Naturally, an existing solution such as a secure file transfer 744 protocol or secure HTTP might be used for this. Other management 745 protocols such as syslog [RFC5424] or NETCONF [RFC6241] might also be 746 used for related purposes, or might be mapped directly over GRASP. 747 The present document, however, applies to any scenario where it is 748 preferable to re-use the autonomic networking infrastructure itself 749 to transfer a significant amount of data, rather than install and 750 configure an additional mechanism. 752 The node behavior is to use the GRASP Negotiation process to transfer 753 and acknowledge multiple blocks of data in successive negotiation 754 steps, thereby overcoming the GRASP message size limitation. The 755 emphasis is placed on simplicity rather than efficiency, high 756 throughput, or advanced functionality. For example, if a transfer 757 gets out of step or data packets are lost, the strategy is to abort 758 the transfer and try again. In an enterprise network with low bit 759 error rates, and with GRASP running over TCP, this is not considered 760 a serious issue. Clearly, a more sophisticated approach could be 761 designed but if the application requires that, existing protocols 762 could be used, as indicated in the preceding paragraph. 764 As for any GRASP operation, the two participants are considered to be 765 Autonomic Service Agents (ASAs) and they communicate using a specific 766 GRASP Objective Option, containing its own name, some flag bits, a 767 loop count, and a value. In bulk transfer, we can model the ASA 768 acting as the source of the transfer as a download server, and the 769 destination as a download client. No changes or extensions are 770 required to GRASP itself, but compared to a normal GRASP negotiation, 771 the communication pattern is slightly asymmetric: 773 1) The client first discovers the server by the GRASP discovery 774 mechanism (M_DISCOVERY and M_RESPONSE messages). 776 2) The client then sends a GRASP negotiation request (M_REQ_NEG 777 message). The value of the objective expresses the requested item 778 (e.g., a file name - see the next section for a detailed example). 780 3) The server replies with a negotiation step (M_NEGOTIATE message). 781 The value of the objective is the first section of the requested 782 item (e.g., the first block of the requested file as a raw byte 783 string). 785 4) The client replies with a negotiation step (M_NEGOTIATE message). 786 The value of the objective is a simple acknowledgement (e.g., the 787 text string 'ACK'). 789 The last two steps repeat until the transfer is complete. The server 790 signals the end by transferring an empty byte string as the final 791 value. In this case the client responds with a normal end to the 792 negotiation (M_END message with an O_ACCEPT option). 794 Errors of any kind are handled with the normal GRASP mechanisms, in 795 particular by an M_END message with an O_DECLINE option in either 796 direction. In this case the GRASP session terminates. It is then 797 the client's choice whether to retry the operation from the start, as 798 a new GRASP session, or to abandon the transfer. The block size must 799 be chosen such that each step does not exceed the GRASP message size 800 limit of 2048 bits. 802 4.4. Summary 804 In summary, the general requirements for the information distribution 805 module on each autonomic node are realized by two sub-modules 806 handling instant communications and asynchronous communications, 807 respectively. For instantaneous mode, node requirements are simple, 808 calling for support for additional signaling. With minimum efforts, 809 reusing the existing GRASP is possible. 811 For asynchronous mode, information distribution module uses new 812 primitives on the wire, and implements an event queue and an 813 information storage mechanism. An architectural consideration on ANI 814 with the information distribution module is briefly discussed in 815 Appendix D. 817 In both cases, a scenario of bulk information transfer is considered 818 where the retrieved information cannot be fitted in one GRASP 819 message. Based on GRASP Negotiation operation, multiple 820 transmissions can be repeatedly done in order to transfer bulk 821 informtion piece by piece. 823 5. Extending GRASP for Information Distribution 825 5.1. Realizing Instant P2P Transmission 827 This could be a new message in GRASP. In fragmentary CDDL, an Un- 828 solicited Synchronization message follows the pattern: 830 unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, 831 objective] 833 A node MAY actively send a unicast Un-solicited Synchronization 834 message with the Synchronization data, to another node. This MAY be 835 sent to port GRASP_LISTEN_PORT at the destination address, which 836 might be obtained by GRASP Discovery or other possible ways. The 837 synchronization data are in the form of GRASP Option(s) for specific 838 synchronization objective(s). 840 5.2. Realizing Instant Selective Flooding 842 Since normal flooding is already supported by GRASP, this section 843 only defines the selective flooding extension. 845 In fragmentary CDDL, the selective flooding follows the pattern: 847 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 848 match-object, action] 849 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 850 Obj1 = text 852 match-rule = GREATER / LESS / WITHIN / CONTAIN 854 Obj2 = text 856 match-object = NEIGHBOR / SELF 858 action = FORWARD / DROP 860 The option field encapsulates a match-condition option which 861 represents the conditions regarding to continue or discontinue flood 862 the current message. For the match-condition option, the Obj1 and 863 Obj2 are to objects that need to be compared. For example, the Obj1 864 could be the role of the device and Obj2 could be "RSG". The match 865 rules between the two objects could be greater, less than, within, or 866 contain. The match-object represents of which Obj1 belongs to, it 867 could be the device itself or the neighbor(s) intended to be flooded. 868 The action means, when the match rule applies, the current device 869 just continues flood or discontinues. 871 5.3. Realizing Bulk Information Transfer 873 5.4. Realizing Subscription as An Event 875 In fragmentary CDDL, a Subscription Objective Option follows the 876 pattern: 878 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 879 objective-name = SUBSCRIPTION 881 objective-flags = 2 883 loop-count = 2 885 subobj = text 887 This option MAY be included in GRASP M_Synchronization, when 888 included, it means this message is for a subscription to a specific 889 object. 891 5.5. Un_Subscription Objective Option 893 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 894 pattern: 896 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 897 objective-name = SUBSCRIPTION 899 objective-flags = 2 901 loop-count = 2 903 unsubobj = text 905 This option MAY be included in GRASP M_Synchronization, when 906 included, it means this message is for a un-subscription to a 907 specific object. 909 5.6. Publishing Objective Option 911 In fragmentary CDDL, a Publish Objective Option follows the pattern: 913 publish-objection-option = [PUBLISH, 2, 2, pubobj] 915 objective-name = PUBLISH 917 objective-flags = 2 919 loop-count = 2 921 pubobj = text 923 This option MAY be included in GRASP M_Synchronization, when 924 included, it means this message is for a publish of a specific object 925 data. 927 6. Security Considerations 929 The distribution source authentication could be done at multiple 930 layers: 932 * Outer layer authentication: the GRASP communication is within ACP 933 ([RFC8994]). This is the default GRASP behavior. 935 * Inner layer authentication: the GRASP communication might not be 936 within a protected channel, then there should be embedded 937 protection in distribution information itself. Public key 938 infrastructure might be involved in this case. 940 7. IANA Considerations 942 TBD. 944 8. Acknowledgements 946 Valuable comments were received from Zoran Despotovic, Brian 947 Carpenter, Michael Richardson, Roland Bless, Mohamed Boucadair, Diego 948 Lopez, Toerless Eckert and other participants in the ANIMA working 949 group. 951 This document was produced using the xml2rfc tool [RFC2629]. 953 9. Contributors 955 Brian Carpenter 956 School of Computer Science 957 University of Auckland 958 PB 92019 959 Auckland 1142 960 New Zealand 962 Email: brian.e.carpenter@gmail.com 964 10. References 966 10.1. Normative References 968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 969 Requirement Levels", BCP 14, RFC 2119, 970 DOI 10.17487/RFC2119, March 1997, 971 . 973 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 974 DOI 10.17487/RFC2629, June 1999, 975 . 977 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 978 Autonomic Signaling Protocol (GRASP)", RFC 8990, 979 DOI 10.17487/RFC8990, May 2021, 980 . 982 10.2. Informative References 984 [I-D.carpenter-anima-grasp-bulk] 985 Carpenter, B., Jiang, S., and B. Liu, "Transferring Bulk 986 Data over the GeneRic Autonomic Signaling Protocol 987 (GRASP)", Work in Progress, Internet-Draft, draft- 988 carpenter-anima-grasp-bulk-05, 9 January 2020, 989 . 992 [I-D.du-anima-an-intent] 993 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 994 Behringer, "ANIMA Intent Policy and Format", Work in 995 Progress, Internet-Draft, draft-du-anima-an-intent-05, 14 996 February 2017, . 999 [I-D.ietf-anima-grasp-api] 1000 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1001 Autonomic Signaling Protocol Application Program Interface 1002 (GRASP API)", Work in Progress, Internet-Draft, draft- 1003 ietf-anima-grasp-api-08, 14 November 2020, 1004 . 1007 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1008 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1009 Networking: Definitions and Design Goals", RFC 7575, 1010 DOI 10.17487/RFC7575, June 2015, 1011 . 1013 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 1014 (CMS) for Algorithm Identifier Protection", RFC 8933, 1015 DOI 10.17487/RFC8933, October 2020, 1016 . 1018 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 1019 Autonomic Control Plane (ACP)", RFC 8994, 1020 DOI 10.17487/RFC8994, May 2021, 1021 . 1023 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1024 and K. Watsen, "Bootstrapping Remote Secure Key 1025 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 1026 May 2021, . 1028 Appendix A. Open Issues [RFC Editor: To Be removed before becoming RFC] 1030 1. More reference to the use cases in the introduction. 1032 2. Better explanation of the required context of the Connected-Car 1033 case: Not applicable unless the ACP will be extended to the car, 1034 which may not be desirable with the current ACP design, but maybe 1035 refocussing on an "autonomous fleet" use-case (e.g.: all cars 1036 operated by some taxi like service). 1038 3. Consider use-case/example of firmware update. By abstracting the 1039 location of the firmware from the name of the firmware, while 1040 providing a way to notify about it, this significantly supports 1041 distribution of firmware updates. References to SUIT would 1042 appropriate. 1044 4. Issues discussed in https://mailarchive.ietf.org/arch/msg/ 1045 anima/_0fYQPBcLPt8xzQee7P4dILsn3A 1047 5. Rethink/refine terminology, e.g.: "module" seems to be too 1048 prescriptive. Refine proposed extensions. 1050 6. Provide more protocol behavior description instead of only 1051 implementation / software module architecture description. 1052 Reduce the latter or provide better justification for their 1053 presence due to explained interoperability requirements. 1055 7. Better motivation in sections 1..4 of the proposed extensions 1057 8. Consider moving examples from appendices into core-text . Ideally 1058 craft a single use-case showing/applying all extensions (most 1059 simple use case that uses them all). 1061 9. Refine terminology to better match/reuse-the established 1062 terminology from the pre-existing ANIMA documents. 1064 Appendix B. Closed Issues [RFC Editor: To Be removed before becoming 1065 RFC] 1067 Appendix C. Change log [RFC Editor: To Be removed before becoming RFC] 1069 draft-ietf-anima-grasp-distribution-00, 2020-02-25: File name changed 1070 following WG adoption. __Added appendix A&B for open/closed issues. 1071 The open issues were comments received during the adoption call. 1073 Appendix D. Information Distribution Module in ANI 1075 This appendix describes how the information distribution module fits 1076 into the ANI and what extensions of GRASP are required. 1078 (preamble) 1079 +-------------------+ 1080 | ASAs | 1081 +-------------------+ 1082 ^ 1083 | 1084 v 1085 +-------------Info-Dist. APIs--------------+ 1086 | +---------------+ +--------------------+ | 1087 | | Instant Dist. | | Asynchronous Dist. | | 1088 | +---------------+ +--------------------+ | 1089 +------------------------------------------+ 1090 ^ 1091 | 1092 v 1093 +---GRASP APIs----+ 1094 | ACP | 1095 +-----------------+ 1097 As the Fig 1 shows, the information distribution module two sub- 1098 modules for instant and asynchronous information distributions, 1099 respectively, and provides APIs to ASAs. Specific Behaviors of 1100 modules are described in Section 5. 1102 Figure E.1 Information Distribution Module and GRASP Extension. 1104 Appendix E. Asynchronous ID Integrated with GRASP APIs 1106 Actions triggered to the information distribution module will 1107 eventually invoke underlying GRASP APIs. Moreover, EQ and IS modules 1108 are usually correlated. When an AF(ASA) publishes information, not 1109 only such an event is translated and sent to EQ module, but also the 1110 information is indexed and stored simultaneously. Similarly, when an 1111 AF(ASA) subscribes information, not only subscribing event is 1112 triggered and sent to EQ module, but also the information will be 1113 retrieved by IS module at the same time. 1115 * Storing and publishing information: This action involves both IS 1116 and EQ modules where a node that can store the information will be 1117 discovered first and related event will e published to the 1118 network. For this, GRASP APIs discover(), synchronize() and 1119 flood() are combined to compose such a procedure. In specific, 1120 discover() call will specific its objective being to "store_data" 1121 and the return parameters could be either an ASA_locator who will 1122 accept to store the data, or an error code indicating that no one 1123 could afford such data; after that, synchronize() call will send 1124 the data to the specified ASA_locator and the data will be stored 1125 at that node, with return of processing results like 1126 store_data_ack; meanwhile, such a successful event (i.e. data is 1127 stored successfully) will be flooded via a flood() call to 1128 interesting parties (such a multicast group existed). 1130 * Subscribing and getting information: This action involves both IS 1131 and EQ modules as well where a node that is interested in a topic 1132 will subscribe the topic by triggering EQ module and if the topic 1133 is ready IS module will retrieve the content of the topic (i.e. 1134 the data). GRASP APIs such as register_objective(), flood(), 1135 synchronize() are combined to compose the procedure. In specific, 1136 any subscription action received by EQ module will be translated 1137 to register_objective() call where the interested topic will be 1138 the parameter inside of the call; the registration will be 1139 (selectively) flooded to the network by an API call of flood() 1140 with the option we extended in this draft; once a matched topic is 1141 found (because of the previous procedure), the node finding such a 1142 match will call API synchronize() to send the stored data to the 1143 subscriber. 1145 Authors' Addresses 1147 Xun Xiao 1148 MRC, Huawei Technologies 1149 Munich Research Center 1150 Huawei Technologies 1151 Riesstr. 25 1152 80992 Muenchen 1153 Germany 1155 Email: xun.xiao@huawei.com 1157 Bing Liu 1158 Huawei Technologies 1159 Q5, Huawei Campus 1160 No.156 Beiqing Road 1161 Hai-Dian District, Beijing 1162 100095 1163 P.R. China 1165 Email: leo.liubing@huawei.com 1167 Artur Hecker 1168 MRC, Huawei Technologies 1169 Munich Research Center 1170 Huawei Technologies 1171 Riesstr. 25 1172 80992 Muenchen 1173 Germany 1175 Email: artur.hecker@huawei.com 1177 Sheng Jiang 1178 Huawei Technologies 1179 Q27, Huawei Campus 1180 No.156 Beiqing Road 1181 Hai-Dian District, Beijing 1182 100095 1183 P.R. China 1185 Email: jiangsheng@huawei.com