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