idnits 2.17.1 draft-liu-anima-grasp-distribution-13.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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([I-D.ietf-anima-reference-model]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 458 has weird spacing: '...network nod...' -- The document date (December 12, 2019) is 1596 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: 'RFC2119' is mentioned on line 157, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity-10' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp-api' is defined on line 701, but no explicit reference was found in the text -- No information found for draft-ietf-animagrasp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-anima-grasp' -- Unexpected draft version: The latest known version of draft-behringer-anima-autonomic-control-plane is -03, but you're referring to -13. (However, the state information for draft-ietf-animagrasp is not up-to-date. The last update was unsuccessful) == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-05 -- No information found for draft-duanima-an-intent - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-anima-grasp-api-00 == Outdated reference: A later version (-05) exists of draft-carpenter-anima-grasp-bulk-04 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG B. Liu 3 INTERNET-DRAFT Huawei Technologies 4 Intended Status: Standard Track X. Xiao 5 Expires: June 14, 2020 A. Hecker 6 MRC, Huawei Technologies 7 S. Jiang 8 Huawei Technologies 9 Z. Despotovic 10 MRC, Huawei Technologies 11 December 12, 2019 13 Information Distribution in Autonomic Networking 14 draft-liu-anima-grasp-distribution-13 16 Abstract 18 This document proposes a solution for information distribution in 19 autonomic networks. Information distribution is categorized into two 20 different modes: 1) instantaneous distribution; 2) publication for 21 retrieval. In the former case, the information is sent, propagates 22 and is disposed of after reception. In the latter case, information 23 needs to be stored in the network. 25 The capabilities to distribute information are basic and fundamental 26 needs for an autonomous network (cf. ANI [I-D.ietf-anima-reference- 27 model]). This document describes typical use cases of information 28 distribution in ANI and requirements to ANI, such that rich 29 information distribution can be natively supported. The document 30 proposes extensions to the autonomic nodes and suggests an 31 implementation based on GRASP extensions as a protocol on the wire. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Requirements of Enriched Information Distribution . . . . . . . 4 74 4. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1 Instant Information Distribution (IID) Sub-module . . . . . 5 76 4.2 Asynchronous Information Distribution (AID) Sub-module . . . 6 77 4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Extending GRASP for Information Distribution . . . . . . . . . 10 79 5.1 Realizing Instant P2P Transmission . . . . . . . . . . . . . 10 80 5.2 Realizing Instant Selective Flooding . . . . . . . . . . . . 11 81 5.3 Realizing Subscription as An Event . . . . . . . . . . . . . 11 82 5.4 Un_Subscription Objective Option . . . . . . . . . . . . . . 12 83 5.5 Publishing Objective Option . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 88 8.2 Informative References . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 Appendix A. Real-world Use Cases of Information Distribution . . . 15 91 Appendix B. Information Distribution Module in ANI . . . . . . . . 18 92 Appendix C. Asynchronous Information Distribution Integrated 93 with GRASP APIs . . . . . . . . . . . . . . . . . . . . . 18 95 1 Introduction 97 In an autonomic network, autonomic functions (AFs) running on 98 autonomic nodes constantly exchange information, e.g. AF 99 control/management signaling or AF data exchange. This document 100 discusses the information distribution capability of such exchanges 101 between AFs. 103 Depending on the number of participants, the information can be 104 distributed in in the following scenarios: 106 1) Point-to-point (P2P) Communication: information is exchanged 107 between parties, i.e. two nodes. 109 2) One-to-Many Communication: information exchanges involve an 110 information source and multiple receivers. 112 The approaches to information distribution can be chiefly categorized 113 into two basic modes: 115 1) An instantaneous mode (push): a source sends the actual content 116 (e.g. control/management signaling, synchronization data and so 117 on) to all interested receiver(s) immediately. Generally, some 118 preconfiguration is required, as nodes interested in this 119 information must be already known to all nodes in the sense that 120 any receiving node must be able to decide, to which nodes this 121 data is to be sent. 123 2) An asynchronous mode (delayed pull): here, a source publishes 124 the content in some form in the network, which may later be looked 125 for, found and retrieved by some endpoints in the AN. Here, 126 depending on the size of the content, either the whole content or 127 only its metadata might be published into the AN. In the latter 128 case the metadata (e.g. a content descriptor, e.g. a key, and a 129 location in the ANI) may be used for the actual retrieval. 130 Importantly, the source, i.e. here publisher, needs to be able to 131 determine the node, where the information (or its metadata) can be 132 stored. 134 To avoid repetitive implementations by each AF developer, this 135 document opts for a common support for information distribution 136 implemented as a basic ANI capability, therefore available to all 137 AFs. In fact, GRASP already provides part of the capabilities. 139 Regardless, an AF may still define and implement its own information 140 distribution capability. Such a capability may then be advertised 141 using the common information distribution capability defined in this 142 document. Overall, ANI nodes and AFs may decide, which of the 143 information distribution mechanisms they want to use for which type 144 of information, according to their own preferences (e.g. semantic 145 routing table, etc.) 147 This document first analyzes requirements for information 148 distribution in autonomic networks (Section 3) and then discuss the 149 relevant node behavior (Section 4). After that, the required GRASP 150 extensions are formally introduced (Section 5). 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 3. Requirements for Information Distribution in ANI 160 The question of information distribution in an autonomic network can 161 be discussed through particular use cases or more generally. 162 Depending on the situation it can be quite simple or might require 163 more complex provisions. 165 Indeed, in the simplest case, the information can be sent: 166 1) at once (in one packet, in one flow), 167 2) straightaway (send-and-forget), 168 3) to all nodes. 170 Presuming 1), 2) and 3) hold, information distribution in smaller or 171 scarce topologies can be implemented using broadcast, i.e. 172 unconstrained flooding. For reasons well-understood, this approach 173 has its limits in larger and denser networks. In this case, a graph 174 can be constructed such that it contains every node exactly once 175 (e.g. a spanning tree), still allowing to distribute any information 176 to all nodes straightaway. Multicast tree construction protocols 177 could be used in this case. There are reasonable use cases for such 178 scenarios, as presented in Appendix B. 180 A more complex scenario arises, if only 1) and 2) hold, but the 181 information only concerns a subset of nodes. Then, some kind of 182 selection becomes required, to which nodes the given information 183 should be distributed. Here, a further distinction is necessary; 184 notably, if the selection of the target nodes is with respect to the 185 nature or position of the node, or whether it is with respect to the 186 information content. If the first, some knowledge about the node 187 types, its topological position, etc (e.g. the routing information 188 within ANI) can be used to distinguish nodes accordingly. For 189 instance, edge nodes and forwarding nodes can be distinguished in 190 this way. If the distribution scope is primarily to be defined by the 191 information elements, then a registration / join / subscription or 192 label distribution mechanism is unavoidable. This would be the case, 193 for instance, if the AFs can be dynamically deployed on nodes, and 194 the information is majorily destined to the AFs. Then, depending on 195 the current AF deployment, the distribution scope must be adjusted as 196 well. 198 If only 1) holds, but the information content might be required again 199 and again, or might not yet be fully available, then more complex 200 mechanisms might be required to store the information within the 201 network for later, for further redistribution, and for notification 202 of interested nodes. Examples for this include distribution of 203 reconfiguration information for different AF instances, which might 204 not require an immediate action, but only an eventual update of the 205 parameters. Also, in some situations, there could be a significant 206 delay between the occurrence of a new event and the full content 207 availability (e.g. if the processing requires a lot of time). 209 Finally, none of the three might hold. Then, along with the 210 subscription and notification, the actual content might be different 211 from its metadata, i.e. some description of the content and, 212 possibly, its location. The fetching can then be implemented in 213 different, appropriate ways, if necessary as a complex transport 214 session. 216 In essence, as flooding is usually not an option, and the interest of 217 nodes for particular information elements can change over time, ANI 218 should support autonomics also for the information distribution. 220 This calls for autonomic mechanisms in the ANI, allowing 221 participating nodes to 1) advertise or publish 2) look for or 222 subscribe to 3) store 4) fetch/retrieve 5) instantaneously push 223 information elements. 225 In the following cases, situations depicting diverse information 226 distribution needs are discussed. 228 1) Long Communication Intervals. The actual sending of the 229 information is not necessarily instantaneous with some event. 230 Advanced AFs may involve into longer jobs/tasks (e.g. database 231 lookup, authentication etc.) when processing requests, and might 232 not be able to reply immediately. Instead of actively waiting for 233 the reply, a better way for an interested AF might be to get 234 notified, when the reply is finally available. 236 2) Common Interest Distribution. AFs may share interest in common 237 information. For example, the network intent will be distributed 238 to network nodes enrolled, which is usually one-to-many scenario. 239 Intent distribution can also be performed by an instant flooding 240 (e.g. via GRASP) to every network node. However, because of 241 network dynamics, not every node can be just ready at the moment 242 when the network intent is broadcast. Also, a flooding often does 243 not cover all network nodes as there is usually a limitation on 244 the hop number. In fact, nodes may join in the network 245 sequentially. In this situation, an asynchronous communication 246 model could be a better choice where every (newly joining) node 247 can subscribe the intent information and will get notified if it 248 is ready (or updated). 250 3) Distributed Coordination. With computing and storage resources 251 on autonomic nodes, alive AFs not only consume but also generate 252 data information. An example is AFs coordinating with each other 253 as distributed schedulers, responding to service requests and 254 distributing tasks. It is critical for those AFs to make correct 255 decisions based on local information, which might be asymmetric as 256 well. AFs may also need synthetic/aggregated data information 257 (e.g. statistic info, like average values of several AFs, etc.) to 258 make decisions. In these situations, AFs will need an efficient 259 way to form a global view of the network (e.g. about resource 260 consumption, bandwidth and statistics). Obviously, purely relying 261 on instant communication model is inefficient, while a scalable, 262 common, yet distributed data layer, on which AFs can store and 263 share information in an asynchronous way, should be a better 264 choice. 266 Therefore, for ANI, in order to support various communication 267 scenarios, an information distribution module is required, and both 268 instantaneous and asynchronous communication models should be 269 supported. Some real-world use cases are introduced in Appendix A. 271 4. Node Behaviors 273 In this section, how a node should behave in order to support the two 274 identified modes of information distribution is discussed. An ANI is 275 a distributed system, so the information distribution module must be 276 implemented in a distributed way as well. 278 4.1 Instant Information Distribution (IID) Sub-module 280 In this case, An information sender directly specifies the 281 information receiver(s). The instant information distribution sub- 282 module will be the main element. 284 4.1.1 Instant P2P Communication 286 IID sub-module performs instant information transmission for ASAs 287 running in an ANI. In specific, IID sub-module will have to retrieve 288 the address of the information receiver specified by an ASA, then 289 deliver the information to the receiver. Such a delivery can be done 290 either in a connectionless or a connection-oriented way. 292 Current GRASP provides the capability to support instant P2P 293 synchronization for ASAs. A P2P synchronization is a use case of P2P 294 information transmission. However, as mention in Section 3, there are 295 some scenarios where one node needs to transmit some information to 296 another node(s). This is different to synchronization because after 297 transmitting the information, the local status of the information 298 does not have to be the same as the information sent to the receiver. 299 This is not directly support by existing GRASP. 301 4.1.2 Instant Flooding Communication 303 IID sub-module finishes instant flooding for ASAs in an ANI. Instant 304 flooding is for all ASAs in an ANI. An information sender has to 305 specify a special destination address of the information and 306 broadcast to all interfaces to its neighbors. When another IID sub- 307 module receives such a broadcast, after checking its TTL, it further 308 broadcast the message to the neighbors. In order to avoid flooding 309 storms in an ANI, usually a TTL number is specified, so that after a 310 pre-defined limit, the flooding message will not be further broadcast 311 again. 313 In order to avoid unnecessary flooding, a selective flooding can be 314 done where an information sender wants to send information to 315 multiple receivers at once. When doing this, sending information 316 needs to contain criteria to judge on which interfaces the 317 distributed information should and should not be sent. Specifically, 318 the criteria contain: 320 o Matching Condition: a set of matching rules such as addresses 321 of recipients, node features and so on. 323 o Action: what the node needs to do when the Matching Condition 324 is fulfilled. For example, the action could be forwarding or 325 discarding the distributed message. 327 Sent information must be included in the message distributed from the 328 sender. The receiving node reacts by first checking the carried 329 Matching Condition in the message to decide who should consume the 330 message, which could be either the node itself, some neighbors or 331 both. If the node itself is a recipient, Action field is followed; if 332 a neighbor is a recipient, the message is sent accordingly. 334 An exemplary extension to support selective flooding on GRASP is 335 described in Section 5. 337 4.2 Asynchronous Information Distribution (AID) Sub-module 339 In asynchronous information distribution, sender(s) and receiver(s) 340 are not immediately specified while they may appear in an 341 asynchronous way. Firstly, AID sub-module enables that the 342 information can be stored in the network; secondly, AID sub-module 343 provides an information publication and subscription (Pub/Sub) 344 mechanism for ASAs. 346 As sketched in the previous section, in general each node requires 347 two modules: 1) Information Storage (IS) module and 2) Event Queue 348 (EQ) module in the information distribution module. Details of the 349 two modules are described in the following sections. 351 4.2.1 Information Storage 353 IS module handles how to save and retrieve information for ASAs 354 across the network. The IS module uses a syntax to index information, 355 generating the hash index value (e.g. a hash value) of the 356 information and mapping the hash index to a certain node in ANI. Note 357 that, this mechanism can use existing solutions. Specifically, 358 storing information in an ANIMA network will be realized in the 359 following steps. 361 1) ASA-to-IS Negotiation. An ASA calls the API provided by 362 information distribution module (directly supported by IS sub- 363 module) to request to store the information somewhere in the 364 network. The IS module performs various checks of the request 365 (e.g. permitted information size). 367 2) Storing Peer Mapping. The information block will be handled by 368 the IS module in order to calculate/map to a peer node in the 369 network. Since ANIMA network is a peer-to-peer network, a typical 370 way is to use distributed hash table (DHT) to map information to a 371 unique index identifier. For example, if the size of the 372 information is reasonable, the information block itself can be 373 hashed, otherwise, some meta-data of the information block can be 374 used to generate the mapping. 376 3) Storing Peer Negotiation Request. Negotiation request of 377 storing the information will be sent from the IS module to the IS 378 module on the destination node. The negotiation request contains 379 parameters about the information block from the source IS module. 380 According to the parameters as well as the local available 381 resource, the requested storing peer will send feedback the source 382 IS module. 384 4) Storing Peer Negotiation Response. Negotiation response from 385 the storing peer is sent back to the source IS module. If the 386 source IS module gets confirmation that the information can be 387 stored, source IS module will prepare to transfer the information 388 block; otherwise, a new storing peer must be discovered (i.e. 389 going to step 7). 391 5) Information Block Transfer. Before sending the information 392 block to the storing peer that already accepts the request, the IS 393 module of the source node will check if the information block can 394 be afforded by one GRASP message. If so, the information block 395 will be directly sent by calling a GRASP API. Otherwise, a bulk 396 data transmission is needed. For that, there are multiple ways to 397 do it. 399 The first option is to utilize one of existing protocols that is 400 independent of the GRASP stack. For example, a session 401 connectivity can be established to the storing peer, and over the 402 connection the bulky data can be transmitted part by part. In this 403 case, the IS module should support basic TCP-based session 404 protocols such as HTTP(s) or native TCP. 406 The second option is to directly use GRASP itself for bulky data 407 transferring. [I-D.carpenter-anima-grasp-bulk-04]. 409 6) Information Writing. Once the information block (or a smaller 410 block) is received, the IS module of the storing peer will store 411 the data block in the local storage is accessible. 413 7) (Optional) New Storing Peer Discovery. If the previously 414 selected storing peer is not available to store the information 415 block, the source IS module will have to identify a new 416 destination node to start a new negotiation. In this case, the 417 discovery can be done by using discovery GRASP API to identify a 418 new candidate, or more complex mechanisms can be introduced. 420 Similarly, Getting information from an ANI will be realized in the 421 following steps. 423 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 424 exposed by the information distribution module. The key/index of 425 the interested information will be sent to the IS module. An 426 assumption here is that the key/index should be known to an ASA 427 before an ASA can ask for the information. This relates to the 428 publishing/subscribing of the information, which are handled by 429 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 431 2) Storing Peer Mapping. IS module maps the key/index of the 432 requested information to a peer that stores the information, and 433 prepares the information request. The mapping here follows the 434 same mechanism when the information is stored. 436 3) Retrieval Negotiation Request. The source IS module sends a 437 request to the storing peer and asks if such an information object 438 is available. 440 4) Retrieval Negotiation Response. The storing peer checks the 441 key/index of the information in the request, and replies to the 442 source IS module. If the information is found and the information 443 block can be afforded within one GRASP message, the information 444 will be sent together with the response to the source IS module. 446 5) (Optional) New Destination Request. If the information is not 447 found after the source IS module gets the response from the 448 originally identified storing peer, the source IS module will have 449 to discover the location of the requested information. 451 IS module can reuse distributed databases and key value stores like 452 NoSQL, Cassandra, DHT technologies. storage and retrieval of 453 information are all event-driven responsible by the EQ module. 455 4.2.2 Event Queue The Event Queue (EQ) module is to help ASAs to 456 publish information to the network and subscribe to interested 457 information in asynchronous scenarios. In an ANI, information 458 generated on network nodes is an event labeled with an event ID, 459 which is semantically related to the topic of the information. Key 460 features of EQ module are summarized as follows. 462 1) Event Group: An EQ module provides isolated queues for different 463 event groups. If two groups of AFs could have completely different 464 purposes, the EQ module allows to create multiple queues where only 465 AFs interested in the same topic will be aware of the corresponding 466 event queue. 468 2) Event Prioritization: Events can have different priorities in ANI. 469 This corresponds to how much important or urgent the event implies. 470 Some of them are more urgent than regular ones. Prioritization allows 471 AFs to differentiate events (i.e. information) they publish or 472 subscribe to. 474 3) Event Matching: an information consumer has to be identified from 475 the queue in order to deliver the information from the provider. 476 Event matching keeps looking for the subscriptions in the queue to 477 see if there is an exact published event there. Whenever a match is 478 found, it will notify the upper layer to inform the corresponding 479 ASAs who are the information provider and subscriber(s) respectively. 481 The EQ module on every network node operates as follows. 483 1) Event ID Generation: If information of an ASA is ready, an 484 event ID is generated according to the content of the information. 485 This is also related to how the information is stored/saved by the 486 IS module introduced before. Meanwhile, the type of the event is 487 also specified where it can be of control purpose or user plane 488 data. 490 2) Priority Specification: According to the type of the event, the 491 ASA may specify its priority to say how this event is to be 492 processed. By considering both aspects, the priority of the event 493 will be determined. 495 3) Event Enqueue: Given the event ID, event group and its 496 priority, a queue is identified locally if all criteria can be 497 satisfied. If there is such a queue, the event will be simply 498 added into the queue, otherwise a new queue will be created to 499 accommodate such an event. 501 4) Event Propagation: The published event will be propagated to 502 the other network nodes in the ANIMA domain. A propagation 503 algorithm can be employed to optimize the propagation efficiency 504 of the updated event queue states. 506 5) Event Match and Notification: While propagating updated event 507 states, EQ module in parallel keeps matching published events and 508 its interested consumers. Once a match is found, the provider and 509 subscriber(s) will be notified for final information retrieval. 511 The category of event priority is defined as the following. In 512 general, there are two event types: 514 1) Network Control Event: This type of events are defined by the 515 ANI for operational purposes on network control. A pre-defined 516 priority levels for required system messages is suggested. For 517 highest level to lowest level, the priority value ranges from 518 NC_PRIOR_HIGH to NC_PRIOR_LOW as integer values. The NC_PRIOR_* 519 values will be defined later according to the total number system 520 events required by the ANI; 522 2) Custom ASA Event: This type of events are defined by the ASAs 523 of users. This specifies the priority of the message within a 524 group of ASAs, therefore it is only effective among ASAs that join 525 the same message group. Within the message group, a group 526 header/leader has to define a list of priority levels ranging from 527 CUST_PRIOR_HIGH to CUST_PRIOR_LOW. Such a definition completely 528 depends on the individual purposes of the message group. 530 When a system message is delivered, its event type and event 531 priority value have to be both specified; 533 Event contains the address where the information is stored, after a 534 subscriber is notified, it directly retrieves the information from 535 the given location. 537 4.3 Summary 539 In summary, the general requirements for the information distribution 540 module on each autonomic node are realized by two sub-modules 541 handling instant communications and asynchronous communications, 542 respectively. For instantaneous mode, node requirements are simple, 543 calling for support for additional signaling. With minimum efforts, 544 reusing the existing GRASP is possible. 546 For asynchronous mode, information distribution module uses new 547 primitives on the wire, and implements an event queue and an 548 information storage mechanism. An architectural consideration on ANI 549 with the information distribution module is briefly discussed in 550 Appendix B. 552 5. Extending GRASP for Information Distribution 554 5.1 Realizing Instant P2P Transmission 556 This could be a new message in GRASP. In fragmentary CDDL, an Un- 557 solicited Synchronization message follows the pattern: 559 unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, 560 objective] 562 A node MAY actively send a unicast Un-solicited Synchronization 563 message with the Synchronization data, to another node. This MAY be 564 sent to port GRASP_LISTEN_PORT at the destination address, which 565 might be obtained by GRASP Discovery or other possible ways. The 566 synchronization data are in the form of GRASP Option(s) for specific 567 synchronization objective(s). 569 5.2 Realizing Instant Selective Flooding 571 Since normal flooding is already supported by GRASP, this section 572 only defines the selective flooding extension. 574 In fragmentary CDDL, the selective flooding follows the pattern: 576 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 577 match-object, action] 579 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 580 Obj1 = text 582 match-rule = GREATER / LESS / WITHIN / CONTAIN 584 Obj2 = text 586 match-object = NEIGHBOR / SELF 588 action = FORWARD / DROP 590 The option field encapsulates a match-condition option which 591 represents the conditions regarding to continue or discontinue flood 592 the current message. For the match-condition option, the Obj1 and 593 Obj2 are to objects that need to be compared. For example, the Obj1 594 could be the role of the device and Obj2 could be "RSG". The match 595 rules between the two objects could be greater, less than, within, or 596 contain. The match-object represents of which Obj1 belongs to, it 597 could be the device itself or the neighbor(s) intended to be flooded. 598 The action means, when the match rule applies, the current device 599 just continues flood or discontinues. 601 5.3 Realizing Subscription as An Event 603 In fragmentary CDDL, a Subscription Objective Option follows the 604 pattern: 606 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 607 objective-name = SUBSCRIPTION 609 objective-flags = 2 611 loop-count = 2 613 subobj = text 615 This option MAY be included in GRASP M_Synchronization, when 616 included, it means this message is for a subscription to a specific 617 object. 619 5.4 Un_Subscription Objective Option 621 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 622 pattern: 624 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 625 objective-name = SUBSCRIPTION 626 objective-flags = 2 627 loop-count = 2 628 unsubobj = text 630 This option MAY be included in GRASP M_Synchronization, when 631 included, it means this message is for a un-subscription to a 632 specific object. 634 5.5 Publishing Objective Option 636 In fragmentary CDDL, a Publish Objective Option follows the pattern: 638 publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name 639 = PUBLISH 640 objective-flags = 2 641 loop-count = 2 642 pubobj = text 644 This option MAY be included in GRASP M_Synchronization, when 645 included, it means this message is for a publish of a specific object 646 data. 647 6. Security Considerations 649 The distribution source authentication could be done at multiple 650 layers: 652 o Outer layer authentication: the GRASP communication is within 653 ACP (Autonomic Control Plane, 654 [I-D.ietf-anima-autonomic-control-plane]). This is the default 655 GRASP behavior. 657 o Inner layer authentication: the GRASP communication might not 658 be within a protected channel, then there should be embedded 659 protection in distribution information itself. Public key 660 infrastructure might be involved in this case. 662 7. IANA Considerations 664 TBD. 666 8. References 668 8.1 Normative References 670 [I-D.ietf-anima-grasp] 671 Bormann, D., Carpenter, B., and B. Liu, "A Generic 672 Autonomic Signaling Protocol (GRASP)", draft-ietf- 673 animagrasp-15 (Standard Track), October 2017. 675 8.2 Informative References 677 [RFC7575] Behringer, M., "Autonomic Networking: Definitions and 678 Design Goals", RFC 7575, June 2015 680 [I-D.ietf-anima-autonomic-control-plane] 681 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 682 Control Plane (ACP)", draft-behringer-anima-autonomic- 683 control-plane-13, December 2017. 685 [I-D.ietf-anima-stable-connectivity-10] 686 Eckert, T., Behringer, M., "Using Autonomic Control Plane 687 for Stable Connectivity of Network OAM", draft-ietf-anima- 688 stable-connectivity-10, February 2018. 690 [I-D.ietf-anima-reference-model] 691 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 692 Pierre P., Liu, B., Nobre, J., and J. Strassner, "A 693 Reference Model for Autonomic Networking", draft-ietf- 694 anima-reference-model-05, October 2017. 696 [I-D.du-anima-an-intent] 697 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 698 Behringer, "ANIMA Intent Policy and Format", draft- 699 duanima-an-intent-05 (work in progress), February 2017. 701 [I-D.ietf-anima-grasp-api] 702 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 703 Autonomic Signaling Protocol Application Program Interface 704 (GRASP API)", draft-ietf-anima-grasp-api-00 (work in 705 progress), December 2017. 707 [I-D.carpenter-anima-grasp-bulk-04] 708 Carpenter, B., Jiang, S., Liu, B., "Transferring Bulk Data 709 over the GeneRic Autonomic Signaling Protocol (GRASP)", 710 draft-carpenter-anima-grasp-bulk-04 (work in progress), 711 July 3, 2019 713 [3GPP.29.500] 714 3GPP, "Technical Realization of Service Based 715 Architecture", 3GPP TS 29.500 15.1.0, 09 2018 717 [3GPP.23.501] 718 3GPP, "System Architecture for the 5G System", 3GPP TS 719 23.501 15.2.0, 6 2018, 720 . 722 [3GPP.23.502] 723 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 724 15.2.0, 6 2018, . 727 [5GAA.use.cases] 728 White Paper "Toward fully connected vehicles: Edge 729 computing for advanced automotive communications", 5GAA 730 733 Authors' Addresses 735 Bing Liu 736 Huawei Technologies 737 Q27, Huawei Campus 739 No.156 Beiqing Road 740 Hai-Dian District, Beijing 100095 741 P.R. China 743 Email: leo.liubing@huawei.com 745 Sheng Jiang 746 Huawei Technologies 747 Q27, Huawei Campus 748 No.156 Beiqing Road 749 Hai-Dian District, Beijing 100095 750 P.R. China 752 Email: jiangsheng@huawei.com 754 Xun Xiao 755 Munich Research Center 756 Huawei technologies 757 Riesstr. 25, 80992, Muenchen, Germany 759 Emails: xun.xiao@huawei.com 761 Artur Hecker 762 Munich Research Center 763 Huawei technologies 764 Riesstr. 25, 80992, Muenchen, Germany 766 Emails: artur.hecker@huawei.com 768 Zoran Despotovic 769 Munich Research Center 770 Huawei technologies 771 Riesstr. 25, 80992, Muenchen, Germany 773 Emails: zoran.despotovic@huawei.com 775 Appendix A. Real-world Use Cases of Information Distribution 776 The requirement analysis in Section 3 shows that generally 777 information distribution should be better of as an infrastructure 778 layer module, which provides to upper layer utilizations. In this 779 section, we review some use cases from the real-world where an 780 information distribution module with powerful functions do plays a 781 critical role there. 783 A.1 Service-Based Architecture (SBA) in 3GPP 5G 785 In addition to Internet, the telecommunication network (i.e. carrier 786 mobile wireless networks) is another world-wide networking system. 787 The architecture of the 5G mobile networks from 3GPP has been defined 788 to follow a service-based architecture (SBA) where any network 789 function (NF) can be dynamically associated with any other NF(s) when 790 needed to compose a network service. Note that one NF can 791 simultaneously associate with multiple other NFs, instead of being 792 physically wired as in the previous generations of mobile networks. 793 NFs communicate with each other over service-based interface (SBI), 794 which is also standardized by 3GPP [3GPP.23.501]. 796 In order to realize an SBA network system, detailed requirements are 797 further defined to specify how NFs should interact with each other 798 with information exchange over the SBI. We now list three 799 requirements that are related to information distribution here. 801 1) NF Pub/Sub: Any NF should be able to expose its service status 802 to the network and any NF should be able to subscribe the service 803 status of an NF and get notified if the status is available. A 804 concrete example is that a session management function (SMF) can 805 subscribe to the REGISTER notification from an access management 806 function (AMF) if there is a new user equipment trying to access 807 the mobile network [3GPP.23.502]. 809 2) Network Exposure Function (NEF): A particular network function 810 that is required to manage the event exposure and distributions. 811 Specifically, SBA requires such a functionality to register 812 network events from the other NFs (e.g. AMF, SMF and so on), 813 classify the events and properly handle event distributions 814 accordingly in terms of different criteria (e.g. priorities) 815 [3GPP.23.502]. 817 3) Network Repository Function (NRF): A particular network 818 function where all service status information is stored for the 819 whole network. An SBA network system requires all NFs to be 820 stateless so as to improve the resilience as well as agility of 821 providing network services. Therefore, the information of the 822 available NFs and the service status generated by those NFs will 823 be globally stored in NRF as a repository of the system. This 824 clearly implies storage capability that keeps the information in 825 the network and provides those information when needed. A concrete 826 example is that whenever a new NF comes up, it first of all 827 registers itself at NRF with its profile. When a network service 828 requires a certain NF, it first inquires NRF to retrieve the 829 availability information and decides whether or not there is an 830 available NF or a new NF must be instantiated [3GPP.23.502]. 832 (Note: 3GPP CT adopted HTTP2.0/JSON to be the protocol communicating 833 between NFs, but autonomic networks can also load HTTP2.0 with in 834 ACP.) 836 A.2 Vehicle-to-Everything 838 Connected car is one of scenarios interested in automotive 839 manufacturers, carriers and vendors. 5G Automotive Alliance - an 840 industry collaboration organization defines many promising use cases 841 where services from car industry should be supported by the 5G mobile 842 network. Here we list two examples as follows [5GAA.use.cases]. 844 1) Software/Firmware Update: Car manufacturers expect that the 845 software/firmware of their car products can be remotely 846 updated/upgraded via 5G network, instead of onsite visiting their 847 4S stores/dealers offline as nowadays. This requires the network 848 to provide a mechanism for vehicles to receive the latest software 849 updates during a certain period of time. In order to run such a 850 service for a car manufacturer, the network shall not be just like 851 a network pipe anymore. Instead, information data have to be 852 stored in the network, and delivered in a publishing/subscribing 853 fashion. For example, the latest release of a software will be 854 first distributed and stored at the access edges of the mobile 855 network, after that, the updates can be pushed by the car 856 manufacturer or pulled by the car owner as needed. 858 2) Real-time HD Maps: Autonomous driving clearly requires much 859 finer details of road maps. Finer details not only include the 860 details of just static road and streets, but also real-time 861 information on the road as well as the driving area for both local 862 urgent situations and intelligent driving scheduling. This asks 863 for situational awareness at critical road segments in cases of 864 changing road conditions. Clearly, a huge amount of traffic data 865 that are real-time collected will have to be stored and shared 866 across the network. This clearly requires the storage capability, 867 data synchronization and event notifications in urgent cases from 868 the network, which are still missing at the infrastructure layer. 870 A.3 Summary 871 Through the general analysis and the concrete examples from the real- 872 world, we realize that the ways information are exchanged in the 873 coming new scenarios are not just short and instant anymore. More 874 advanced as well as diverse information distribution capabilities are 875 required and should be generically supported from the infrastructure 876 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 877 utilize such a unified mechanism for their own services. 879 Appendix B. Information Distribution Module in ANI 881 This section describes how the information distribution module fits 882 into the ANI and what extensions of GRASP are required [I-D.ietf- 883 anima-grasp]. 885 +-------------------+ 886 | ASAs | 887 +-------------------+ 888 ^ 889 | 890 v 891 +-------------Info-Dist. APIs--------------+ 892 | +---------------+ +--------------------+ | 893 | | Instant Dist. | | Asynchronous Dist. | | 894 | +---------------+ +--------------------+ | 895 +------------------------------------------+ 896 ^ 897 | 898 v 899 +---GRASP APIs----+ 900 | ACP | 901 +-----------------+ 903 Figure 1. Information Distribution Module and GRASP Extension. 905 As the Fig 1 shows, the information distribution module two sub- 906 modules for instant and asynchronous information distributions, 907 respectively, and provides APIs to ASAs. Specific Behaviors of 908 modules are described in Section 5. 910 Appendix C. Asynchronous ID Integrated with GRASP APIs 912 Actions triggered to the information distribution module will 913 eventually invoke underlying GRASP APIs. Moreover, EQ and IS modules 914 are usually correlated. When an AF(ASA) publishes information, not 915 only such an event is translated and sent to EQ module, but also the 916 information is indexed and stored simultaneously. Similarly, when an 917 AF(ASA) subscribes information, not only subscribing event is 918 triggered and sent to EQ module, but also the information will be 919 retrieved by IS module at the same time. 921 o Storing and publishing information: This action involves both IS 922 and EQ modules where a node that can store the information will be 923 discovered first and related event will e published to the network. 924 For this, GRASP APIs discover(), synchronize() and flood() are 925 combined to compose such a procedure. In specific, discover() call 926 will specific its objective being to "store_data" and the return 927 parameters could be either an ASA_locator who will accept to store 928 the data, or an error code indicating that no one could afford such 929 data; after that, synchronize() call will send the data to the 930 specified ASA_locator and the data will be stored at that node, with 931 return of processing results like store_data_ack; meanwhile, such a 932 successful event (i.e. data is stored successfully) will be flooded 933 via a flood() call to interesting parties (such a multicast group 934 existed). 936 o Subscribing and getting information: This action involves both IS 937 and EQ modules as well where a node that is interested in a topic 938 will subscribe the topic by triggering EQ module and if the topic is 939 ready IS module will retrieve the content of the topic (i.e. the 940 data). GRASP APIs such as register_objective(), flood(), 941 synchronize() are combined to compose the procedure. In specific, any 942 subscription action received by EQ module will be translated to 943 register_objective() call where the interested topic will be the 944 parameter inside of the call; the registration will be (selectively) 945 flooded to the network by an API call of flood() with the option we 946 extended in this draft; once a matched topic is found (because of the 947 previous procedure), the node finding such a match will call API 948 synchronize() to send the stored data to the subscriber.