idnits 2.17.1 draft-liu-anima-grasp-distribution-10.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 153 has weird spacing: '...ced AFs may r...' -- The document date (March 11, 2019) is 1873 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 143, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity-10' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp-api' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'I-D.carpenter-anima-grasp-bulk-02' is defined on line 649, 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 S. Jiang 4 Intended Status: Standard Track Huawei Technologies 5 Expires: September 8, 2019 X. Xiao 6 A. Hecker 7 Z. Despotovic 8 MRC, Huawei Technologies 9 March 11, 2019 11 Information Distribution in Autonomic Networking 12 draft-liu-anima-grasp-distribution-10 14 Abstract 16 This document discusses the requirement of capability of information 17 distribution among autonomic nodes in autonomic networks. In general, 18 information distribution can be categorized into two different modes: 19 1) one autonomic node instantly sends information to other nodes in 20 the domain; 2) one autonomic node publishes some information and 21 asynchronously some other interested nodes request the published 22 information. In the former case, information data will be generated 23 and consumed instantly. In the latter case, information data live 24 longer in the network. 26 These capabilities are basic and fundamental to an autonomous network 27 system (i.e. ANI [I-D.ietf-anima-reference-model]). This document 28 clarifies possible use cases of information distribution in ANI and 29 requirements to ANI so that rich information distribution can be 30 natively supported. Possible options to realize the information 31 distribution function are also briefly discussed. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Requirements of Advanced Information Distribution . . . . . . . 4 74 4. Information Distribution in ANI . . . . . . . . . . . . . . . . 5 75 5. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 5.1 Instant Information Distribution . . . . . . . . . . . . . . 6 77 5.1.1 Instant P2P and Flooding Communications . . . . . . . . 6 78 5.1.2 Instant Selective Flooding Communication . . . . . . . 6 79 5.2 Asynchronous Information Distribution . . . . . . . . . . . 7 80 5.2.1 Information Storage . . . . . . . . . . . . . . . . . . 7 81 5.2.2 Event Queue . . . . . . . . . . . . . . . . . . . . . . 9 82 5.2.3 Interface between IS and EQ Modules . . . . . . . . . 10 83 5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6. Protocol Specification (GRASP extension) . . . . . . . . . . . 11 85 6.1 Un-solicited Synchronization Message (A new GRASP Message) 11 86 6.2 Selective Flooding Option . . . . . . . . . . . . . . . . 11 87 6.3 Subscription Objective Option . . . . . . . . . . . . . . 12 88 6.4 Un_Subscription Objective Option . . . . . . . . . . . . . 12 89 6.5 Publishing Objective Option . . . . . . . . . . . . . . . 13 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 94 9.2 Informative References . . . . . . . . . . . . . . . . . . 14 95 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 98 1 Introduction 100 In an autonomic network, autonomic functions (AFs) running on 101 autonomic nodes would exchange information constantly, both for 102 controlling/management signaling and data exchange. This document 103 discusses the information distribution capability of such exchanges 104 between AFs. 106 According to the number of participants, information distribution can 107 happen with the following scenarios: 109 1) Point-to-point (P2P) Communication: information are exchanged 110 between two communicating parties from one node to another node. 112 2) One-to-Many Communication: information exchanges involve an 113 information source and multiple receivers. 115 The approaches of distributing information could be categorized into 116 two basic models: 118 1) An instant communication: a sender connects and sends the 119 information data (e.g. control/management signaling, 120 synchronization data and so on) to the receiver(s) immediately. 122 2) An asynchronous communication: a sender saves the information 123 in the network, may or may not publish the information to the 124 other who is interested in the published information, to which a 125 node asks to retrieve. 127 The ANI should have provided a generic way to support these various 128 scenarios, rather than assisted by other transport or routing 129 protocols (HTTP, BGP/IGP as bearing protocols etc.). In fact, GRASP 130 already provides part of the capabilities. 132 In this document, we first analyze requirements of information 133 distribution in autonomic networks (Section 3), and then introduce 134 its relationship to the other modules in ANI (Section 4). After that, 135 the node behaviors and extensions to the existing GRASP are 136 introduced in Section 5 and Section 6, respectively. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. Requirements of Advanced Information Distribution 146 If the information exchanged is just short and simple, this can be 147 done instantly. In practice, however, this is not always the case. In 148 the following cases, a mixture of instant and asynchronous 149 communication models is more appropriate. 151 1) Long Communication Intervals. The time interval of the 152 communication is not necessarily always short and instant. 153 Advanced AFs may rather involve heavy jobs/tasks (e.g. database 154 lookup, authentication etc.) when gearing the network, so the 155 instant mode may introduce unnecessary pending time and become 156 less efficient. If simply using an instant mode, the AF has to 157 wait until the tasks finish and return. A better way is that an AF 158 instantly sends the request but switches to an synchronous mode, 159 once the jobs are finished, AFs will get notified. 161 2) Common Interest Distribution. As mentioned, some information 162 are common interests among AFs. For example, the network intent is 163 distributed to network nodes enrolled, which is a typical one-to- 164 many scenario. We can also finish the intent distribution by an 165 instant flooding (e.g. via GRASP) to every network nodes across 166 the network domain. Because of network dynamic, however, not every 167 node can be just ready at the moment when the network intent is 168 flooded. Actually, nodes may join in the network sequentially. In 169 this situation, an asynchronous communication model could be a 170 better choice where every (newly joining) node can subscribe the 171 intent information and will get notified if it is ready (or 172 updated). 174 3) Distributed Coordination. With computing and storage resources 175 on autonomic nodes, alive AFs not only consumes but also generates 176 data information. For example, AFs coordinating with each other as 177 distributed schedulers, responding to service requests and 178 distributing tasks. It is critical for those AFs to make correct 179 decisions based on local information, which might be asymmetric as 180 well. AFs may also need synthetic/aggregated data information 181 (e.g. statistic info, like average values of several AFs, etc.) to 182 make decisions. In these situations, AFs will need an efficient 183 way to form a global view of the network (e.g. about resource 184 consumption, bandwidth and statistics). Obviously, purely relying 185 on instant communication model is inefficient, while a scalable, 186 common, yet distributed data layer, on which AFs can store and 187 share information in an asynchronous way, should be a better 188 choice. 190 For ANI, in order to support various communication scenarios, an 191 information distribution module is required, and both instant and 192 asynchronous communication models should be supported. 194 4. Information Distribution in ANI 196 This section describes how the information distribution module fits 197 into the ANI including what extensions of GRASP are required [I- 198 D.ietf-anima-grasp]. 200 +-------------------+ 201 | ASAs + 202 +-------------------+ 203 ^ 204 | 205 v 206 +-------------------------Info-Dist. APIs-----------------------+ 207 | +---------------+ +-------------------+ +---------------+ | 208 | | Event Queue |-|-| Selective Flooding|-|-| Info. Storage | | 209 | +---------------+ +-------------------+ +---------------+ | 210 +---------------------------------------------------------------+ 211 ^ 212 | 213 v 214 +-------------GRASP APIs----------------+ 215 | +---------------+ +---------------+ | 216 | | GRASP Base |-|-| Extension | | | 217 | +---------------+ +---------------+ | 218 +---------------------------------------+ 220 Figure 1. Information Distribution Module and GRASP Extension. 222 As the Fig 1 shows, the information distribution module includes 223 three sub-modules, all of which provides APIs for ASAs. Specific 224 behaviors of these modules is described in Section 5. In order to 225 support the modules, the GRASP is also extended, which is described 226 in Section 6. 228 5. Node Behaviors 230 ANI is a distributed system, so the information distribution module 231 must be implemented in a distributed way as well. This means that 232 every node participate to contribute. In this section, we discuss how 233 each autonomic node should behave in order to realize the information 234 distribution module. Node interactions and information data exchange 235 between network nodes are necessary in order to support the instant 236 and asynchronous information distribution, which will be introduced 237 in the follow sections, respectively. 239 5.1 Instant Information Distribution 241 In this case, sender(s) and receiver(s) are specified. Information 242 will be directly sent from the sender(s) to the receiver(s). This 243 requires that every node is equipped by some signaling/transport 244 protocols so that they can coordinate with each other and correctly 245 deliver the information. 247 5.1.1 Instant P2P and Flooding Communications 249 Current GRASP already provides the capability to support instant P2P 250 and flooding. It is natural to use the GRASP Synchronization message 251 directly for P2P distribution. Furthermore, it is also natural to use 252 the GRASP Flood Synchronization message for 1-to-all distribution. 254 However, as mentioned in Section 3, in some scenarios one node needs 255 to actively send some information to another. GRASP Synchronization 256 just lacks such capability. An un-solicited synchronization mechanism 257 is needed. A relevant GRASP extension is defined in Section 6. 259 5.1.2 Instant Selective Flooding Communication 261 When doing selective flooding, the distributed information needs to 262 contain the criteria for nodes to judge which interfaces should be 263 sent the distributed information and which are not. Specifically, the 264 criteria contain: 266 o Matching condition: a set of matching rules. 268 o Matching object: the object that the match condition would be 269 applied to. For example, the matching object could be node itself 270 or its neighbors. 272 o Action: what behavior the node needs to do when the matching 273 object matches or failed the matching condition. For example, the 274 action could be forwarding or discarding the distributed message. 276 The criteria information must be include in the message that carries 277 the distributed information from the sender. The receiving node 278 decides the action according to the criteria carried in the message. 279 Still considering the criteria attached with the distributed 280 information, the node behaviors can be: 282 o When the Matching Object is "Neighbors", then the node matches 283 the relevant information of its neighbors to the Matching 284 Condition. If the node finds one neighbor matches the Matching 285 Condition, then it forwards the distributed message to the 286 neighbor. If not, the node discards forwarding the message to the 287 neighbor. 289 o When the Matching Object is the node itself, then the node 290 matches the relevant information of its own to the Matching 291 Condition. If the node finds itself matches the Matching 292 Condition, then it forwards the distributed message to its 293 neighbors; if not, the node discards forwarding the message to the 294 neighbors. 296 An example of selective flooding is briefly described in the Appendix 297 A. 299 5.2 Asynchronous Information Distribution 301 Asynchronous information distribution happens in a different way 302 where sender(s) and receiver(s) are normally not immediately 303 specified. Both senders and receivers may come up in an asynchronous 304 way. First of all, this requires that the information can be stored; 305 secondly, it requires an information publication and subscription 306 (Pub/Sub) mechanism (corresponding protocol specification of Pub/Sub 307 is defined in Section 6). 309 As we sketched in the previous section, in general, each node 310 requires two modules: 1) Information Storage (IS) module and 2) Event 311 Queue (EQ) module in the information distribution module. We 312 introduce details of the two modules in the following sections. 314 5.2.1 Information Storage 316 IS module handles how to save and retrieve information for ASAs 317 across the network. The IS module uses a syntax to index information, 318 generating the hash index value (e.g. a key) of the information and 319 mapping the hash index to a certain node in ANI. Note that, this 320 mechanism can use existing solutions. Specifically, storing 321 information in an ANIMA network will be realized in the following 322 steps. 324 1) ASA-to-IS Negotiation. An ASA calls the API provided by 325 information distribution module (directly supported by IS sub- 326 module) to request to store the information somewhere in the 327 network. Such a request will be checked by the IS module who will 328 be responsible for the request whether such a request is feasible 329 according to criteria such as permitted information size. 331 2) Destination Node Mapping. The information block will be handled 332 by the IS module in order to calculate/map to a destination node 333 in the network. Since ANIMA network is a peer-to-peer network, a 334 typical way is to use dynamic hash table (DHT) to map information 335 to a unique index identifier. For example, if the size of the 336 information is reasonable, the information block itself can be 337 hashed, otherwise, some meta-data of the information block can be 338 used to generate the mapping. 340 3) Destination Node Negotiation Request. Negotiation request of 341 storing the information will be sent from the IS module to the IS 342 module on the destination node. The negotiation request contains 343 parameters about the information block from the source IS module. 344 According to the parameters as well as the local available 345 resource, the destination node will feedback the source IS module. 347 4) Destination Node Negotiation Response. Negotiation response 348 from the destination node is sent back to the source IS module. If 349 the source IS module gets confirmation that the information can be 350 stored, source IS module will prepare to transfer the information 351 block; otherwise, a new destination node must be discovered (i.e. 352 going to step 7). 354 5) Information Block Transfer. Before sending the information 355 block to the destination node that accepts the request, the IS 356 module of the source node will check if the information block can 357 be afforded by one GRASP message. If so, the information block 358 will be directly sent by calling a GRASP API. Otherwise, bulk data 359 transmission with GRASP will be triggered, where multi-time GRASP 360 message sending will be used so that one information block will be 361 transferred by smaller pieces [I-D.ietf-anima-reference-model]. 363 6) Information Writing. Once the information block (or a smaller 364 block) is received, the IS module of the destination node will 365 store the data block in the local storage, which is accessible. 367 7) (Optional) New Destination Node Discovery. If the previously 368 selected destination node is not available to store the 369 information block, the source IS module will have to identify a 370 new destination node to start a new negotiation. In this case, the 371 discovery can be done by using discovery GRASP API to identify a 372 new candidate, or more complex mechanisms can be introduced. 374 Similarly, Getting information from an ANIMA network will be realized 375 in the following steps. 377 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 378 exposed by the information distribution module. The key/index of 379 the interested information will be sent to the IS module. An 380 assumption here is that the key/index should be ready to an ASA 381 before an ASA can ask for the information. This relates to the 382 publishing/subscribing of the information, which are handled by 383 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 385 2) Destination Node Mapping. IS module maps the key/index of the 386 requested information to a destination node, and prepares to start 387 to request the information. The mapping here follows the same 388 mechanism when the information is stored. 390 3) Retrieval Negotiation Request. The source IS module sends a 391 request to the destination node identified in the previous step 392 and asks if such an information object is available. 394 4) Retrieval Negotiation Response. The destination node checks the 395 key/index of the requested information, and replies to the source 396 IS module. If the information is found and the information block 397 can be afforded within one GRASP message, the information will be 398 sent together with the response to the source IS module. 400 5) (Optional) New Destination Request. If the information is not 401 found after the source IS module gets the response from the 402 original destination node, the source IS module will have to 403 discover where the location storing the requested information is. 405 IS module can reuse distributed databases and key value stores like 406 NoSQL, Cassandra, DHT technologies. storage and retrieval of 407 information are all event-driven responsible by the EQ module. 409 5.2.2 Event Queue 411 The main job of Event Queue (EQ) module is to help ASAs to show 412 interests to particular information and notify the occurrences of 413 that in asynchronous communication scenarios. In ANI, information 414 generated on network nodes is labeled as an event identified with an 415 event ID, which is semantically related to the topic of the 416 information. Key features of EQ module are summarized as follows. 418 1) Event Group: EQ module provides isolated queues for different 419 event groups. If two groups of AFs could have completely different 420 purposes or interests, EQ module allows to create multiple queues 421 where only AFs interested in the same topic will be aware of the 422 corresponding event queue. 424 2) Event Prioritization: Events do not have to be delivered in the 425 same priority. This corresponds to how much important the event 426 implies. Some of them are more urgent than regular ones. 428 Prioritization allows AFs to differentiate events (i.e. information) 429 they publish/subscribe. 431 3) Event Matching: an information consumer has to be identified from 432 the queue in order to deliver the information from the provider. 433 Event matching keeps looking for the subscriptions in the queue to 434 see if there is an exact published event there. Whenever a match is 435 found, it will notify the upper layer to inform the corresponding 436 ASAs who are the information provider and subscriber(s) respectively. 438 The procedure of how EQ module on every network node works is 439 introduced as follows. 441 1) Event ID Generation: If information of an ASA is ready, an 442 event ID is generated according to the content of the information. 443 This is also related to how the information is stored/saved by the 444 IS module introduced before. Meanwhile, the type of the event is 445 also specified where it can be of control purpose or user plane 446 data. 448 2) Priority Specification: According to the type of the event, the 449 ASA may specify its priority to say how this event is wanted to be 450 processed. By considering both aspects, the priority of the event 451 will be determined and ready for enqueuing. 453 3) Event Enqueue: Given the event ID, event group and its 454 priority, a queue is identified locally if all criteria can be 455 satisfied. If there is such a queue, the event will be simply 456 added into the queue, otherwise a new queue will be created to 457 accommodate such an event. 459 4) Event Propagation: The published event will be propagated to 460 the other network nodes in the ANIMA domain. A propagation 461 algorithm can be employed to here in order to optimize the 462 propagation efficiency of the updated event queue states. 464 5) Event Match and Notification: While propagating updated event 465 states, EQ module in parallel keeps matching published events and 466 its interested consumers. Once a match is found, the provider and 467 subscriber(s) will be notified for final information retrieval. 469 Event contains the address where the information is stored, after a 470 subscriber is notified, it directly retrieves the information from 471 the given location. 473 5.2.3 Interface between IS and EQ Modules 474 EQ and IS modules are correlated. When an AF publishes information, 475 not only an publishing event is translated and sent to EQ module, but 476 also the information is indexed and stored simultaneously. Similarly, 477 when an AF subscribes information, not only subscribing event is 478 triggered and sent to EQ module, but also the information will be 479 retrieved by IS module at the same time. 481 5.3 Summary 483 In summary, the general requirements for the information distribution 484 module on each autonomic node are two sub-modules handling instant 485 communications and asynchronous communications, respectively. For 486 instant communications, node requirements are simple, in which 487 signaling protocols have to be supported. With minimum efforts, 488 reusing the existing GRASP is possible. For asynchronous 489 communications, information distribution module requires event queue 490 and information storage mechanism to be supported. 492 6. Protocol Specification (GRASP extension) 494 There are multiple ways to integrate the information distribution 495 module. The principle we follow is to minimize modifications made to 496 the current ANI. 498 We consider to use GRASP as an interface to access the information 499 distribution module. The main reason is that the current version of 500 GRASP is already an information distribution module for the cases of 501 P2P and flooding. In the following discussions, we introduce how to 502 complete the missing part. 504 6.1 Un-solicited Synchronization Message (A new GRASP Message) 506 In fragmentary CDDL, a Un-solicited Synchronization message follows 507 the pattern: 509 unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] 511 A node MAY actively send a unicast Un-solicited Synchronization 512 message with the Synchronization data, to another node. This MAY be 513 sent to port GRASP_LISTEN_PORT at the destination address, which 514 might be obtained by GRASP Discovery or other possible ways. The 515 synchronization data are in the form of GRASP Option(s) for specific 516 synchronization objective(s). 518 6.2 Selective Flooding Option 520 In fragmentary CDDL, the selective flood follows the pattern: 522 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 523 match-object, action] 524 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 525 Obj1 = text 526 match-rule = GREATER / LESS / WITHIN / CONTAIN 527 Obj2 = text 528 match-object = NEIGHBOR / SELF 529 action = FORWARD / DROP 531 The selective flood option encapsulates a match-condition option 532 which represents the conditions regarding to continue or discontinue 533 flood the current message. For the match-condition option, the Obj1 534 and Obj2 are to objects that need to be compared. For example, the 535 Obj1 could be the role of the device and Obj2 could be "RSG". The 536 match rules between the two objects could be greater, less than, 537 within, or contain. The match-object represents of which Obj1 belongs 538 to, it could be the device itself or the neighbor(s) intended to be 539 flooded. The action means, when the match rule applies, the current 540 device just continues flood or discontinues. 542 6.3 Subscription Objective Option 544 In fragmentary CDDL, a Subscription Objective Option follows the 545 pattern: 547 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 548 objective-name = SUBSCRIPTION 549 objective-flags = 2 550 loop-count = 2 551 subobj = text 553 This option MAY be included in GRASP M_Synchronization, when 554 included, it means this message is for a subscription to a specific 555 object. 557 6.4 Un_Subscription Objective Option 559 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 560 pattern: 562 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 563 objective-name = SUBSCRIPTION 564 objective-flags = 2 565 loop-count = 2 566 unsubobj = text 568 This option MAY be included in GRASP M_Synchronization, when 569 included, it means this message is for a un-subscription to a 570 specific object. 572 6.5 Publishing Objective Option 574 In fragmentary CDDL, a Publish Objective Option follows the pattern: 576 publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name 577 = PUBLISH 578 objective-flags = 2 579 loop-count = 2 580 pubobj = text 582 This option MAY be included in GRASP M_Synchronization, when 583 included, it means this message is for a publish of a specific object 584 data. 586 Note that extended GRASP messages with new arguments inside here will 587 trigger interactions/actions of the underlying information 588 distribution module introduced in Section 5. 590 7. Security Considerations 592 The distribution source authentication could be done at multiple 593 layers: 595 o Outer layer authentication: the GRASP communication is within 596 ACP (Autonomic Control Plane, 597 [I-D.ietf-anima-autonomic-control-plane]). This is the default 598 GRASP behavior. 600 o Inner layer authentication: the GRASP communication might not 601 be within a protected channel, then there should be embedded 602 protection in distribution information itself. Public key 603 infrastructure might be involved in this case. 605 8. IANA Considerations 606 TBD. 608 9. References 610 9.1 Normative References 612 [I-D.ietf-anima-grasp] 613 Bormann, D., Carpenter, B., and B. Liu, "A Generic 614 Autonomic Signaling Protocol (GRASP)", draft-ietf- 615 animagrasp-15 (Standard Track), October 2017. 617 9.2 Informative References 619 [RFC7575] Behringer, M., "Autonomic Networking: Definitions and 620 Design Goals", RFC 7575, June 2015 622 [I-D.ietf-anima-autonomic-control-plane] 623 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 624 Control Plane (ACP)", draft-behringer-anima-autonomic- 625 control-plane-13, December 2017. 627 [I-D.ietf-anima-stable-connectivity-10] 628 Eckert, T., Behringer, M., "Using Autonomic Control Plane 629 for Stable Connectivity of Network OAM", draft-ietf-anima- 630 stable-connectivity-10, February 2018. 632 [I-D.ietf-anima-reference-model] 633 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 634 Pierre P., Liu, B., Nobre, J., and J. Strassner, "A 635 Reference Model for Autonomic Networking", draft-ietf- 636 anima-reference-model-05, October 2017. 638 [I-D.du-anima-an-intent] 639 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 640 Behringer, "ANIMA Intent Policy and Format", draft- 641 duanima-an-intent-05 (work in progress), February 2017. 643 [I-D.ietf-anima-grasp-api] 644 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 645 Autonomic Signaling Protocol Application Program Interface 646 (GRASP API)", draft-ietf-anima-grasp-api-00 (work in 647 progress), December 2017. 649 [I-D.carpenter-anima-grasp-bulk-02] 650 Carpenter, B., Jiang, S., Liu, B., "Transferring Bulk Data 651 over the GeneRic Autonomic Signaling Protocol (GRASP)", 652 draft-carpenter-anima-grasp-bulk-02 (work in progress), 653 June 30, 2018 655 [3GPP.29.500] 656 3GPP, "Technical Realization of Service Based 657 Architecture", 3GPP TS 29.500 15.1.0, 09 2018 659 [3GPP.23.501] 660 3GPP, "System Architecture for the 5G System", 3GPP TS 661 23.501 15.2.0, 6 2018, 662 . 664 [3GPP.23.502] 665 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 666 15.2.0, 6 2018, . 669 [5GAA.use.cases] 670 White Paper "Toward fully connected vehicles: Edge 671 computing for advanced automotive communications", 5GAA 672 675 Appendix A. 677 GRASP includes flooding criteria together with the delivered 678 information so that every node will process and act according to the 679 criteria specified in the message. An example of extending GRASP with 680 selective criteria can be: 682 o Matching condition: "Device role=IPRAN_RSG" 684 o Matching objective: "Neighbors" 686 o Action: "Forward" 688 This example means: only distributing the information to the 689 neighbors who are IPRAN_RSG. 691 Authors' Addresses 693 Bing Liu 694 Huawei Technologies 695 Q27, Huawei Campus 696 No.156 Beiqing Road 697 Hai-Dian District, Beijing 100095 698 P.R. China 700 Email: leo.liubing@huawei.com 702 Sheng Jiang 703 Huawei Technologies 704 Q27, Huawei Campus 705 No.156 Beiqing Road 706 Hai-Dian District, Beijing 100095 707 P.R. China 709 Email: jiangsheng@huawei.com 711 Xun Xiao 712 Munich Research Center 713 Huawei technologies 714 Riesstr. 25, 80992, Muenchen, Germany 716 Emails: xun.xiao@huawei.com 718 Artur Hecker 719 Munich Research Center 720 Huawei technologies 721 Riesstr. 25, 80992, Muenchen, Germany 723 Emails: artur.hecker@huawei.com 725 Zoran Despotovic 726 Munich Research Center 727 Huawei technologies 728 Riesstr. 25, 80992, Muenchen, Germany 730 Emails: zoran.despotovic@huawei.com 732 Appendix A Real-world Use Cases of Information Distribution 734 The requirement analysis in Section 3 shows that generally 735 information distribution should be better of as an infrastructure 736 layer module, which provides to upper layer utilizations. In this 737 section, we review some use cases from the real-world where an 738 information distribution module with powerful functions do plays a 739 critical role there. 741 A.1 Service-Based Architecture (SBA) in 3GPP 5G 743 In addition to Internet, the telecommunication network (i.e. carrier 744 mobile wireless networks) is another world-wide networking system. 745 The architecture of the upcoming 5G mobile networks from 3GPP has 746 already been defined to follow a service-based architecture (SBA) 747 where any network function (NF) can be dynamically associated with 748 any other NF(s) when needed to compose a network service. Note that 749 one NF can simultaneously associate with multiple other NFs, instead 750 of being physically wired as in the previous generations of mobile 751 networks. NFs communicate with each other over service-based 752 interface (SBI), which is also standardized by 3GPP [3GPP.23.501]. 754 In order to realize an SBA network system, detailed requirements are 755 further defined to specify how NFs should interact with each other 756 with information exchange over the SBI. We now list three 757 requirements that are related to information distribution here. 759 1) NF Pub/Sub: Any NF should be able to expose its service status 760 to the network and any NF should be able to subscribe the service 761 status of an NF and get notified if the status is available. An 762 concrete example is that a session management function (SMF) can 763 subscribe the REGISTER notification from an access management 764 function (AMF) if there is a new user entity trying to access the 765 mobile network [3GPP.23.502]. 767 2) Network Exposure Function (NEF): A particular network function 768 that is required to manage the event exposure and distributions. 769 In specific, SBA requires such a functionality to register network 770 events from the other NFs (e.g. AMF, SMF and so on), classify the 771 events and properly handle event distributions accordingly in 772 terms of different criteria (e.g. priorities) [3GPP.23.502]. 774 3) Network Repository Function (NRF): A particular network 775 function where all service status information is stored for the 776 whole network. An SBA network system requires all NFs to be 777 stateless so as to improve the resilience as well as agility of 778 providing network services. Therefore, the information of the 779 available NFs and the service status generated by those NFs will 780 be globally stored in NRF as a repository of the system. This 781 clearly implies storage capability that keeps the information in 782 the network and provides those information when needed. A concrete 783 example is that whenever a new NF comes up, it first of all 784 registers itself at NRF with its profile. When a network service 785 requires a certain NF, it first inquires NRF to retrieve the 786 availability information and decides whether or not there is an 787 available NF or a new NF must be instantiated [3GPP.23.502]. 789 (Note: 3GPP CT might finally adopt HTTP2.0/JSON to be the protocol 790 communicating between NFs, but autonomic networks can also load 791 HTTP2.0 with in ACP.) 793 A.2 Vehicle-to-Everything 795 Carrier networks On-boarding services of vertical industries are also 796 one of some blooming topics that are heavily discussed. Connected car 797 is clearly one of the important scenarios interested in automotive 798 manufacturers, carriers and vendors. 5G Automotive Alliance - an 799 industry collaboration organization defines many promising use cases 800 where services from car industry should be supported by the 5G mobile 801 network. Here we list two examples as follows [5GAA.use.cases]. 803 1) Software/Firmware Update: Car manufacturers expect that the 804 software/firmware of their car products can be remotely 805 updated/upgraded via 5G network in future, instead of onsite 806 visiting their 4S stores/dealers offline as nowadays. This 807 requires the network to provide a mechanism for vehicles to 808 receive the latest software updates during a certain period of 809 time. In order to run such a service for a car manufacturer, the 810 network shall not be just like a network pipe anymore. Instead, 811 information data have to be stored in the network, and delivered 812 in a publishing/subscribing fashion. For example, the latest 813 release of a software will be first distributed and stored at the 814 access edges of the mobile network, after that, the updates can be 815 pushed by the car manufacturer or pulled by the car owner as 816 needed. 818 2) Real-time HD Maps: Autonomous driving clearly requires much 819 finer details of road maps. Finer details not only include the 820 details of just static road and streets, but also real-time 821 information on the road as well as the driving area for both local 822 urgent situations and intelligent driving scheduling. This asks 823 for situational awareness at critical road segments in cases of 824 changing road conditions. Clearly, a huge amount of traffic data 825 that are real-time collected will have to be stored and shared 826 across the network. This clearly requires the storage capability, 827 data synchronization and event notifications in urgent cases from 828 the network, which are still missing at the infrastructure layer. 830 A.3 Summary 832 Through the general analysis and the concrete examples from the real- 833 world, we realize that the ways information are exchanged in the 834 coming new scenarios are not just short and instant anymore. More 835 advanced as well as diverse information distribution capabilities are 836 required and should be generically supported from the infrastructure 837 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 838 utilize such a unified mechanism for their own services.