idnits 2.17.1 draft-liu-anima-grasp-distribution-12.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 : ---------------------------------------------------------------------------- ** There are 8 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 150 has weird spacing: '...ced AFs may r...' -- The document date (November 4, 2019) is 1636 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 140, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity-10' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp-api' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'I-D.carpenter-anima-grasp-bulk-02' is defined on line 695, 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-02 Summary: 2 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: May 7, 2020 MRC, Huawei Technologies 6 S. Jiang 7 Huawei Technologies 8 A. Hecker 9 Z. Despotovic 10 MRC, Huawei Technologies 11 November 4, 2019 13 Information Distribution in Autonomic Networking 14 draft-liu-anima-grasp-distribution-12 16 Abstract 18 This document discusses the requirement to autonomic nodes supporting 19 information distribution based over GRASP in autonomic networks. In 20 general, information distribution can be categorized into two 21 different modes: 1) one autonomic node instantly sends information to 22 other nodes in the domain; 2) one autonomic node publishes some 23 information and asynchronously some other interested nodes request 24 the published information. In the former case, information data will 25 be generated and consumed instantly. In the latter case, information 26 data live longer in the network. 28 These capabilities are basic and fundamental to an autonomous network 29 system (i.e. ANI [I-D.ietf-anima-reference-model]). This document 30 clarifies possible use cases of information distribution in ANI and 31 requirements to ANI so that rich information distribution can be 32 natively supported. Extensions to autonomic nodes are proposed and 33 detailed embodiments based on GRASP are discussed. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as 43 Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Copyright and License Notice 58 Copyright (c) 2019 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 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Requirements of Advanced Information Distribution . . . . . . . 4 76 4. Information Distribution Module in ANI . . . . . . . . . . . . 5 77 5. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 5 78 5.1 Instant Information Distribution . . . . . . . . . . . . . . 6 79 5.2 Asynchronous Information Distribution . . . . . . . . . . . 7 80 5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. Protocol Specification (GRASP extension) . . . . . . . . . . . 12 82 6.1 Un-solicited Synchronization Message (A new GRASP Message) . 12 83 6.2 Selective Flooding Option . . . . . . . . . . . . . . . . . 12 84 6.3 Subscription Objective Option . . . . . . . . . . . . . . . 13 85 6.4 Un_Subscription Objective Option . . . . . . . . . . . . . . 13 86 6.5 Publishing Objective Option . . . . . . . . . . . . . . . . 13 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 91 9.2 Informative References . . . . . . . . . . . . . . . . . . . 15 92 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1 Introduction 97 In an autonomic network, autonomic functions (AFs) running on 98 autonomic nodes would exchange information constantly, both for 99 controlling/management signaling and data exchange. This document 100 discusses the information distribution capability of such exchanges 101 between AFs. 103 According to the number of participants, information distribution can 104 happen with the following scenarios: 106 1) Point-to-point (P2P) Communication: information are exchanged 107 between two communicating parties from one node to another node. 109 2) One-to-Many Communication: information exchanges involve an 110 information source and multiple receivers. 112 The approaches of distributing information could be categorized into 113 two basic modes: 115 1) An instant communication: a sender connects and sends the 116 information data (e.g. control/management signaling, 117 synchronization data and so on) to the receiver(s) immediately. 119 2) An asynchronous communication: a sender saves the information 120 in the network, may or may not publish the information to the 121 other who is interested in the published information, to which a 122 node asks to retrieve. 124 The ANI should have provided a generic way to support these 125 information distribution scenarios among AFs, rather than AFs 126 managing to use other transport or routing protocols (HTTP, BGP/IGP 127 as bearing protocols etc.). In fact, GRASP already provides part of 128 the capabilities. 130 In this document, we first analyze requirements of information 131 distribution in autonomic networks (Section 3), and then introduce 132 its relationship to the other modules in ANI (Section 4). After that, 133 the node behaviors and extensions to the existing GRASP are 134 introduced in Section 5 and Section 6, respectively. 136 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Requirements of Advanced Information Distribution 143 If the information exchanged is just short and simple, this can be 144 done instantly. In practice, however, this is not always the case. In 145 the following cases, a mixture of instant and asynchronous 146 communication models is more appropriate. 148 1) Long Communication Intervals. The time interval of the 149 communication is not necessarily always short and instant. 150 Advanced AFs may rather involve heavy jobs/tasks (e.g. database 151 lookup, authentication etc.) when gearing the network, so the 152 instant mode may introduce unnecessary pending time and become 153 less efficient. If simply using an instant mode, the AF has to 154 wait until the tasks finish and return. A better way is that an AF 155 instantly sends the request but switches to an synchronous mode, 156 once the jobs are finished, AFs will get notified. 158 2) Common Interest Distribution. As mentioned, some information 159 are common interests among AFs. For example, the network intent is 160 distributed to network nodes enrolled, which is a typical one-to- 161 many scenario. We can also finish the intent distribution by an 162 instant flooding (e.g. via GRASP) to every network nodes across 163 the network domain. Because of network dynamic, however, not every 164 node can be just ready at the moment when the network intent is 165 flooded. Actually, nodes may join in the network sequentially. In 166 this situation, an asynchronous communication model could be a 167 better choice where every (newly joining) node can subscribe the 168 intent information and will get notified if it is ready (or 169 updated). 171 3) Distributed Coordination. With computing and storage resources 172 on autonomic nodes, alive AFs not only consumes but also generates 173 data information. For example, AFs coordinating with each other as 174 distributed schedulers, responding to service requests and 175 distributing tasks. It is critical for those AFs to make correct 176 decisions based on local information, which might be asymmetric as 177 well. AFs may also need synthetic/aggregated data information 178 (e.g. statistic info, like average values of several AFs, etc.) to 179 make decisions. In these situations, AFs will need an efficient 180 way to form a global view of the network (e.g. about resource 181 consumption, bandwidth and statistics). Obviously, purely relying 182 on instant communication model is inefficient, while a scalable, 183 common, yet distributed data layer, on which AFs can store and 184 share information in an asynchronous way, should be a better 185 choice. 187 For ANI, in order to support various communication scenarios, an 188 information distribution module is required, and both instant and 189 asynchronous communication models should be supported. 191 4. Information Distribution Module in ANI 193 This section describes how the information distribution module fits 194 into the ANI including what extensions of GRASP are required [I- 195 D.ietf-anima-grasp]. 197 +-------------------+ 198 | ASAs | 199 +-------------------+ 200 ^ 201 | 202 v 203 +------------------------Info-Dist. APIs-----------------------+ 204 | +--------------------+ +-------------+ +---------------+ | 205 | | Selective Flooding |-|-| Event Queue |-|-| Info. Storage | | 206 | +--------------------+ +-------------+ +---------------+ | 207 +--------------------------------------------------------------+ 208 ^ 209 | 210 v 211 +-------------GRASP APIs----------------+ 212 | +---------------+ +---------------+ | 213 | | GRASP Base |-|-| Extension | | | 214 | +---------------+ +---------------+ | 215 +---------------------------------------+ 217 Figure 1. Information Distribution Module and GRASP Extension. 219 As the Fig 1 shows, the information distribution module includes 220 three sub-modules, all of which provides APIs for ASAs. Specific 221 behaviors of these modules is described in Section 5. In order to 222 support the modules, the GRASP is also extended, which is described 223 in Section 6. 225 5. Node Behaviors 227 In this section, we discuss how each autonomic node should behave in 228 order to support the two modes of information distribution introduced 229 before. ANI is a distributed system, so the information distribution 230 module must be implemented in a distributed way as well, where every 231 node participates to contribute. 233 5.1 Instant Information Distribution 235 In this case, sender(s) and receiver(s) are specified. Information 236 will be directly sent from the sender(s) to the receiver(s). This 237 requires that every node is equipped by some signaling/transport 238 protocols so that they can coordinate with each other and correctly 239 deliver the information. 241 5.1.1 Instant P2P and Flooding Communications 243 Current GRASP provides the capability to support instant P2P and 244 flooding. It is natural to use the GRASP Synchronization message 245 directly for P2P distribution. Furthermore, it is also natural to use 246 the GRASP Flood Synchronization message for broadcast. 248 However, as mentioned in Section 3, in some scenarios one node needs 249 to communicate some information to another, rather than 250 synchronization. As a result, an un-solicited synchronization 251 mechanism is needed in GRASP. An extension of GRASP message (i.e. 252 M_UNSOLIDSYN) is defined in Section 6.1. 254 5.1.2 Instant Selective Flooding Communication 256 When doing selective flooding, the distributed information needs to 257 contain criteria for nodes to judge which interfaces should be sent 258 the distributed information and which are not. Specifically, the 259 criteria contain: 261 o Matching Condition: a set of matching rules. 263 o Matching Object: the object that the match condition would be 264 applied to. For example, the matching object could be node itself 265 or its neighbors. 267 o Action: what behavior the node needs to do when the matching 268 object matches or failed the matching condition. For example, the 269 action could be forwarding or discarding the distributed message. 271 The criteria information must be included in the message distributed 272 from the sender. The receiving node decides its reaction according to 273 the criteria carried in the message. Given the criteria appended with 274 the message, the node behaviors can be: 276 o When the Matching Object is "Neighbors", then the node matches 277 the relevant information of its neighbors to the Matching 278 Condition. If the node finds one neighbor matches the Matching 279 Condition, then it forwards the message to the neighbor. If not, 280 the node discards the message. 282 o When the Matching Object is the node itself, then the node 283 matches against to the Matching Condition. If the node finds 284 itself matches the Matching Condition, then it forwards the 285 distributed message to its neighbors; if not, the node discards 286 the message. 288 GRASP is extended with a new option field (i.e. selective-flood- 289 option) to support selective flooding, shown in Section 6.2. This 290 option will be included in the original flooding message of GRASP. An 291 example of selective flooding is briefly described in the Appendix A. 293 5.2 Asynchronous Information Distribution 295 Asynchronous information distribution happens in a different way 296 where sender(s) and receiver(s) are not immediately specified while 297 they may appear in an asynchronous way. First of all, this requires 298 that the information can be stored in the network; secondly, it 299 requires an information publication and subscription (Pub/Sub) 300 mechanism (corresponding protocol specification of Pub/Sub is defined 301 in Section 6). 303 As we sketched in the previous section that in general each node 304 requires two modules: 1) Information Storage (IS) module and 2) Event 305 Queue (EQ) module in the information distribution module. We 306 introduce details of the two modules in the following sections. 308 5.2.1 Information Storage 310 IS module handles how to save and retrieve information for ASAs 311 across the network. The IS module uses a syntax to index information, 312 generating the hash index value (e.g. a hash value) of the 313 information and mapping the hash index to a certain node in ANI. Note 314 that, this mechanism can use existing solutions. Specifically, 315 storing information in an ANIMA network will be realized in the 316 following steps. 318 1) ASA-to-IS Negotiation. An ASA calls the API provided by 319 information distribution module (directly supported by IS sub- 320 module) to request to store the information somewhere in the 321 network. Such a request will be checked by the IS module who will 322 be responsible for the request whether such a request is feasible 323 according to criteria such as permitted information size. 325 2) Destination Node Mapping. The information block will be handled 326 by the IS module in order to calculate/map to a destination node 327 in the network. Since ANIMA network is a peer-to-peer network, a 328 typical way is to use dynamic hash table (DHT) to map information 329 to a unique index identifier. For example, if the size of the 330 information is reasonable, the information block itself can be 331 hashed, otherwise, some meta-data of the information block can be 332 used to generate the mapping. 334 3) Destination Node Negotiation Request. Negotiation request of 335 storing the information will be sent from the IS module to the IS 336 module on the destination node. The negotiation request contains 337 parameters about the information block from the source IS module. 338 According to the parameters as well as the local available 339 resource, the destination node will feedback the source IS module. 341 4) Destination Node Negotiation Response. Negotiation response 342 from the destination node is sent back to the source IS module. If 343 the source IS module gets confirmation that the information can be 344 stored, source IS module will prepare to transfer the information 345 block; otherwise, a new destination node must be discovered (i.e. 346 going to step 7). 348 5) Information Block Transfer. Before sending the information 349 block to the destination node that accepts the request, the IS 350 module of the source node will check if the information block can 351 be afforded by one GRASP message. If so, the information block 352 will be directly sent by calling a GRASP API. Otherwise, bulk data 353 transmission with GRASP will be triggered, where multi-time GRASP 354 message sending will be used so that one information block will be 355 transferred by smaller pieces [I-D.ietf-anima-reference-model]. 357 6) Information Writing. Once the information block (or a smaller 358 block) is received, the IS module of the destination node will 359 store the data block in the local storage, which is accessible. 361 7) (Optional) New Destination Node Discovery. If the previously 362 selected destination node is not available to store the 363 information block, the source IS module will have to identify a 364 new destination node to start a new negotiation. In this case, the 365 discovery can be done by using discovery GRASP API to identify a 366 new candidate, or more complex mechanisms can be introduced. 368 Similarly, Getting information from an ANIMA network will be realized 369 in the following steps. 371 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 372 exposed by the information distribution module. The key/index of 373 the interested information will be sent to the IS module. An 374 assumption here is that the key/index should be ready to an ASA 375 before an ASA can ask for the information. This relates to the 376 publishing/subscribing of the information, which are handled by 377 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 379 2) Destination Node Mapping. IS module maps the key/index of the 380 requested information to a destination node, and prepares to start 381 to request the information. The mapping here follows the same 382 mechanism when the information is stored. 384 3) Retrieval Negotiation Request. The source IS module sends a 385 request to the destination node identified in the previous step 386 and asks if such an information object is available. 388 4) Retrieval Negotiation Response. The destination node checks the 389 key/index of the requested information, and replies to the source 390 IS module. If the information is found and the information block 391 can be afforded within one GRASP message, the information will be 392 sent together with the response to the source IS module. 394 5) (Optional) New Destination Request. If the information is not 395 found after the source IS module gets the response from the 396 original destination node, the source IS module will have to 397 discover where the location storing the requested information is. 399 IS module can reuse distributed databases and key value stores like 400 NoSQL, Cassandra, DHT technologies. storage and retrieval of 401 information are all event-driven responsible by the EQ module. 403 5.2.2 Event Queue 405 The main job of Event Queue (EQ) module is to help ASAs to subscribe 406 interested information and publish information to the network in 407 asynchronous scenarios. In ANI, information generated on network 408 nodes is an event labeled with an event ID, which is semantically 409 related to the topic of the information. Key features of EQ module 410 are summarized as follows. 412 1) Event Group: An EQ module provides isolated queues for different 413 event groups. If two groups of AFs could have completely different 414 purposes, the EQ module allows to create multiple queues where only 415 AFs interested in the same topic will be aware of the corresponding 416 event queue. 418 2) Event Prioritization: Events can have different priorities in ANI. 419 This corresponds to how much important or urgent the event implies. 420 Some of them are more urgent than regular ones. Prioritization allows 421 AFs to differentiate events (i.e. information) they 422 publish/subscribe. 424 3) Event Matching: an information consumer has to be identified from 425 the queue in order to deliver the information from the provider. 426 Event matching keeps looking for the subscriptions in the queue to 427 see if there is an exact published event there. Whenever a match is 428 found, it will notify the upper layer to inform the corresponding 429 ASAs who are the information provider and subscriber(s) respectively. 431 The procedure of how EQ module on every network node works is 432 introduced as follows. 434 1) Event ID Generation: If information of an ASA is ready, an 435 event ID is generated according to the content of the information. 436 This is also related to how the information is stored/saved by the 437 IS module introduced before. Meanwhile, the type of the event is 438 also specified where it can be of control purpose or user plane 439 data. 441 2) Priority Specification: According to the type of the event, the 442 ASA may specify its priority to say how this event is wanted to be 443 processed. By considering both aspects, the priority of the event 444 will be determined and ready for enqueuing. 446 3) Event Enqueue: Given the event ID, event group and its 447 priority, a queue is identified locally if all criteria can be 448 satisfied. If there is such a queue, the event will be simply 449 added into the queue, otherwise a new queue will be created to 450 accommodate such an event. 452 4) Event Propagation: The published event will be propagated to 453 the other network nodes in the ANIMA domain. A propagation 454 algorithm can be employed to here in order to optimize the 455 propagation efficiency of the updated event queue states. 457 5) Event Match and Notification: While propagating updated event 458 states, EQ module in parallel keeps matching published events and 459 its interested consumers. Once a match is found, the provider and 460 subscriber(s) will be notified for final information retrieval. 462 Here we define the category of event priority. In general, we define 463 two event types: 465 1) Network Control Event: This type of events are defined by the 466 ANI for operational purposes on network control. We suggest a pre- 467 defined priority levels for required system messages. For highest 468 level to lowest level, the priority value ranges from 469 NC_PRIOR_HIGH to NC_PRIOR_LOW as integer values. The NC_PRIOR_* 470 values will be defined later according to the total number system 471 events required by the ANI; 473 2) Custom ASA Event: This type of events are defined by the ASAs 474 of users. This specifies the priority of the message within a 475 group of ASAs, therefore it is only effective among ASAs that join 476 in the same message group. Within the message group, a group 477 header/leader has to define a list of priority levels ranging from 478 CUST_PRIOR_HIGH to CUST_PRIOR_LOW. Such a definition completely 479 depends on the individual purposes of the message group. 481 When a system message is delivered, its event type and event 482 priority value have to be both specified; 484 Event contains the address where the information is stored, after a 485 subscriber is notified, it directly retrieves the information from 486 the given location. 488 5.2.3 Integrating with GRASP APIs 490 Actions triggered to the information distribution module will 491 eventually invoke underlying GRASP APIs. Moreover, EQ and IS modules 492 are usually correlated. When an AF(ASA) publishes information, not 493 only such an event is translated and sent to EQ module, but also the 494 information is indexed and stored simultaneously. Similarly, when an 495 AF(ASA) subscribes information, not only subscribing event is 496 triggered and sent to EQ module, but also the information will be 497 retrieved by IS module at the same time. 499 o Storing and publishing information: This action involves both IS 500 and EQ modules where a node that can store the information will be 501 discovered first and related event will e published to the network. 502 For this, GRASP APIs discover(), synchronize() and flood() are 503 combined to compose such a procedure. In specific, discover() call 504 will specific its objective being to "store_data" and the return 505 parameters could be either an ASA_locator who will accept to store 506 the data, or an error code indicating that no one could afford such 507 data; after that, synchronize() call will send the data to the 508 specified ASA_locator and the data will be stored at that node, with 509 return of processing results like store_data_ack; meanwhile, such a 510 successful event (i.e. data is stored successfully) will be flooded 511 via a flood() call to interesting parties (such a multicast group 512 existed). 514 o Subscribing and getting information: This action involves both IS 515 and EQ modules as well where a node that is interested in a topic 516 will subscribe the topic by triggering EQ module and if the topic is 517 ready IS module will retrieve the content of the topic (i.e. the 518 data). GRASP APIs such as register_objective(), flood(), 519 synchronize() are combined to compose the procedure. In specific, any 520 subscription action received by EQ module will be translated to 521 register_objective() call where the interested topic will be the 522 parameter inside of the call; the registration will be (selectively) 523 flooded to the network by an API call of flood() with the option we 524 extended in this draft; once a matched topic is found (because of the 525 previous procedure), the node finding such a match will call API 526 synchronize() to send the stored data to the subscriber. 528 5.3 Summary 530 In summary, the general requirements for the information distribution 531 module on each autonomic node are two sub-modules handling instant 532 communications and asynchronous communications, respectively. For 533 instant communications, node requirements are simple, in which 534 signaling protocols have to be supported. With minimum efforts, 535 reusing the existing GRASP is possible. For asynchronous 536 communications, information distribution module requires event queue 537 and information storage mechanism to be supported. 539 6. Protocol Specification (GRASP extension) 541 There are multiple ways to integrate the information distribution 542 module. The principle we follow is to minimize modifications made to 543 the current ANI. We consider to use GRASP as a base to build up the 544 information distribution module. The main reason is that the current 545 version of GRASP is already an information distribution module for 546 the cases of P2P and flooding. In the following discussions, we 547 introduce how to complete the missing part. 549 6.1 Un-solicited Synchronization Message (A new GRASP Message) 551 In fragmentary CDDL, a Un-solicited Synchronization message follows 552 the pattern: 554 unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, 555 objective] 557 A node MAY actively send a unicast Un-solicited Synchronization 558 message with the Synchronization data, to another node. This MAY be 559 sent to port GRASP_LISTEN_PORT at the destination address, which 560 might be obtained by GRASP Discovery or other possible ways. The 561 synchronization data are in the form of GRASP Option(s) for specific 562 synchronization objective(s). 564 6.2 Selective Flooding Option 566 In fragmentary CDDL, the selective flood follows the pattern: 568 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 569 match-object, action] 570 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 571 Obj1 = text 572 match-rule = GREATER / LESS / WITHIN / CONTAIN 573 Obj2 = text 574 match-object = NEIGHBOR / SELF 575 action = FORWARD / DROP 577 The selective flood option encapsulates a match-condition option 578 which represents the conditions regarding to continue or discontinue 579 flood the current message. For the match-condition option, the Obj1 580 and Obj2 are to objects that need to be compared. For example, the 581 Obj1 could be the role of the device and Obj2 could be "RSG". The 582 match rules between the two objects could be greater, less than, 583 within, or contain. The match-object represents of which Obj1 belongs 584 to, it could be the device itself or the neighbor(s) intended to be 585 flooded. The action means, when the match rule applies, the current 586 device just continues flood or discontinues. 588 6.3 Subscription Objective Option 590 In fragmentary CDDL, a Subscription Objective Option follows the 591 pattern: 593 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 594 objective-name = SUBSCRIPTION 595 objective-flags = 2 596 loop-count = 2 597 subobj = text 599 This option MAY be included in GRASP M_Synchronization, when 600 included, it means this message is for a subscription to a specific 601 object. 603 6.4 Un_Subscription Objective Option 605 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 606 pattern: 608 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 609 objective-name = SUBSCRIPTION 610 objective-flags = 2 611 loop-count = 2 612 unsubobj = text 614 This option MAY be included in GRASP M_Synchronization, when 615 included, it means this message is for a un-subscription to a 616 specific object. 618 6.5 Publishing Objective Option 619 In fragmentary CDDL, a Publish Objective Option follows the pattern: 621 publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name 622 = PUBLISH 623 objective-flags = 2 624 loop-count = 2 625 pubobj = text 627 This option MAY be included in GRASP M_Synchronization, when 628 included, it means this message is for a publish of a specific object 629 data. 631 Note that extended GRASP messages with new arguments inside here will 632 be triggered by interactions/actions from information distribution 633 module introduced in Section 5. 635 7. Security Considerations 637 The distribution source authentication could be done at multiple 638 layers: 640 o Outer layer authentication: the GRASP communication is within 641 ACP (Autonomic Control Plane, 642 [I-D.ietf-anima-autonomic-control-plane]). This is the default 643 GRASP behavior. 645 o Inner layer authentication: the GRASP communication might not 646 be within a protected channel, then there should be embedded 647 protection in distribution information itself. Public key 648 infrastructure might be involved in this case. 650 8. IANA Considerations 652 TBD. 654 9. References 656 9.1 Normative References 658 [I-D.ietf-anima-grasp] 659 Bormann, D., Carpenter, B., and B. Liu, "A Generic 660 Autonomic Signaling Protocol (GRASP)", draft-ietf- 661 animagrasp-15 (Standard Track), October 2017. 663 9.2 Informative References 665 [RFC7575] Behringer, M., "Autonomic Networking: Definitions and 666 Design Goals", RFC 7575, June 2015 668 [I-D.ietf-anima-autonomic-control-plane] 669 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 670 Control Plane (ACP)", draft-behringer-anima-autonomic- 671 control-plane-13, December 2017. 673 [I-D.ietf-anima-stable-connectivity-10] 674 Eckert, T., Behringer, M., "Using Autonomic Control Plane 675 for Stable Connectivity of Network OAM", draft-ietf-anima- 676 stable-connectivity-10, February 2018. 678 [I-D.ietf-anima-reference-model] 679 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 680 Pierre P., Liu, B., Nobre, J., and J. Strassner, "A 681 Reference Model for Autonomic Networking", draft-ietf- 682 anima-reference-model-05, October 2017. 684 [I-D.du-anima-an-intent] 685 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 686 Behringer, "ANIMA Intent Policy and Format", draft- 687 duanima-an-intent-05 (work in progress), February 2017. 689 [I-D.ietf-anima-grasp-api] 690 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 691 Autonomic Signaling Protocol Application Program Interface 692 (GRASP API)", draft-ietf-anima-grasp-api-00 (work in 693 progress), December 2017. 695 [I-D.carpenter-anima-grasp-bulk-02] 696 Carpenter, B., Jiang, S., Liu, B., "Transferring Bulk Data 697 over the GeneRic Autonomic Signaling Protocol (GRASP)", 698 draft-carpenter-anima-grasp-bulk-02 (work in progress), 699 June 30, 2018 701 [3GPP.29.500] 702 3GPP, "Technical Realization of Service Based 703 Architecture", 3GPP TS 29.500 15.1.0, 09 2018 705 [3GPP.23.501] 706 3GPP, "System Architecture for the 5G System", 3GPP TS 707 23.501 15.2.0, 6 2018, 708 . 710 [3GPP.23.502] 711 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 712 15.2.0, 6 2018, . 715 [5GAA.use.cases] 716 White Paper "Toward fully connected vehicles: Edge 717 computing for advanced automotive communications", 5GAA 718 721 Appendix A. 723 GRASP includes flooding criteria together with the delivered 724 information so that every node will process and act according to the 725 criteria specified in the message. An example of extending GRASP with 726 selective criteria can be: 728 o Matching condition: "Device role=IPRAN_RSG" 730 o Matching objective: "Neighbors" 732 o Action: "Forward" 734 This example means: only distributing the information to the 735 neighbors who are IPRAN_RSG. 737 Authors' Addresses 739 Bing Liu 740 Huawei Technologies 741 Q27, Huawei Campus 742 No.156 Beiqing Road 743 Hai-Dian District, Beijing 100095 744 P.R. China 745 Email: leo.liubing@huawei.com 747 Sheng Jiang 748 Huawei Technologies 749 Q27, Huawei Campus 750 No.156 Beiqing Road 751 Hai-Dian District, Beijing 100095 752 P.R. China 754 Email: jiangsheng@huawei.com 756 Xun Xiao 757 Munich Research Center 758 Huawei technologies 759 Riesstr. 25, 80992, Muenchen, Germany 761 Emails: xun.xiao@huawei.com 763 Artur Hecker 764 Munich Research Center 765 Huawei technologies 766 Riesstr. 25, 80992, Muenchen, Germany 768 Emails: artur.hecker@huawei.com 770 Zoran Despotovic 771 Munich Research Center 772 Huawei technologies 773 Riesstr. 25, 80992, Muenchen, Germany 775 Emails: zoran.despotovic@huawei.com 777 Appendix A Real-world Use Cases of Information Distribution 779 The requirement analysis in Section 3 shows that generally 780 information distribution should be better of as an infrastructure 781 layer module, which provides to upper layer utilizations. In this 782 section, we review some use cases from the real-world where an 783 information distribution module with powerful functions do plays a 784 critical role there. 786 A.1 Service-Based Architecture (SBA) in 3GPP 5G 788 In addition to Internet, the telecommunication network (i.e. carrier 789 mobile wireless networks) is another world-wide networking system. 791 The architecture of the upcoming 5G mobile networks from 3GPP has 792 already been defined to follow a service-based architecture (SBA) 793 where any network function (NF) can be dynamically associated with 794 any other NF(s) when needed to compose a network service. Note that 795 one NF can simultaneously associate with multiple other NFs, instead 796 of being physically wired as in the previous generations of mobile 797 networks. NFs communicate with each other over service-based 798 interface (SBI), which is also standardized by 3GPP [3GPP.23.501]. 800 In order to realize an SBA network system, detailed requirements are 801 further defined to specify how NFs should interact with each other 802 with information exchange over the SBI. We now list three 803 requirements that are related to information distribution here. 805 1) NF Pub/Sub: Any NF should be able to expose its service status 806 to the network and any NF should be able to subscribe the service 807 status of an NF and get notified if the status is available. An 808 concrete example is that a session management function (SMF) can 809 subscribe the REGISTER notification from an access management 810 function (AMF) if there is a new user entity trying to access the 811 mobile network [3GPP.23.502]. 813 2) Network Exposure Function (NEF): A particular network function 814 that is required to manage the event exposure and distributions. 815 In specific, SBA requires such a functionality to register network 816 events from the other NFs (e.g. AMF, SMF and so on), classify the 817 events and properly handle event distributions accordingly in 818 terms of different criteria (e.g. priorities) [3GPP.23.502]. 820 3) Network Repository Function (NRF): A particular network 821 function where all service status information is stored for the 822 whole network. An SBA network system requires all NFs to be 823 stateless so as to improve the resilience as well as agility of 824 providing network services. Therefore, the information of the 825 available NFs and the service status generated by those NFs will 826 be globally stored in NRF as a repository of the system. This 827 clearly implies storage capability that keeps the information in 828 the network and provides those information when needed. A concrete 829 example is that whenever a new NF comes up, it first of all 830 registers itself at NRF with its profile. When a network service 831 requires a certain NF, it first inquires NRF to retrieve the 832 availability information and decides whether or not there is an 833 available NF or a new NF must be instantiated [3GPP.23.502]. 835 (Note: 3GPP CT might finally adopt HTTP2.0/JSON to be the protocol 836 communicating between NFs, but autonomic networks can also load 837 HTTP2.0 with in ACP.) 838 A.2 Vehicle-to-Everything 840 Carrier networks On-boarding services of vertical industries are also 841 one of some blooming topics that are heavily discussed. Connected car 842 is clearly one of the important scenarios interested in automotive 843 manufacturers, carriers and vendors. 5G Automotive Alliance - an 844 industry collaboration organization defines many promising use cases 845 where services from car industry should be supported by the 5G mobile 846 network. Here we list two examples as follows [5GAA.use.cases]. 848 1) Software/Firmware Update: Car manufacturers expect that the 849 software/firmware of their car products can be remotely 850 updated/upgraded via 5G network in future, instead of onsite 851 visiting their 4S stores/dealers offline as nowadays. This 852 requires the network to provide a mechanism for vehicles to 853 receive the latest software updates during a certain period of 854 time. In order to run such a service for a car manufacturer, the 855 network shall not be just like a network pipe anymore. Instead, 856 information data have to be stored in the network, and delivered 857 in a publishing/subscribing fashion. For example, the latest 858 release of a software will be first distributed and stored at the 859 access edges of the mobile network, after that, the updates can be 860 pushed by the car manufacturer or pulled by the car owner as 861 needed. 863 2) Real-time HD Maps: Autonomous driving clearly requires much 864 finer details of road maps. Finer details not only include the 865 details of just static road and streets, but also real-time 866 information on the road as well as the driving area for both local 867 urgent situations and intelligent driving scheduling. This asks 868 for situational awareness at critical road segments in cases of 869 changing road conditions. Clearly, a huge amount of traffic data 870 that are real-time collected will have to be stored and shared 871 across the network. This clearly requires the storage capability, 872 data synchronization and event notifications in urgent cases from 873 the network, which are still missing at the infrastructure layer. 875 A.3 Summary 877 Through the general analysis and the concrete examples from the real- 878 world, we realize that the ways information are exchanged in the 879 coming new scenarios are not just short and instant anymore. More 880 advanced as well as diverse information distribution capabilities are 881 required and should be generically supported from the infrastructure 882 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 883 utilize such a unified mechanism for their own services.