idnits 2.17.1 draft-liu-anima-grasp-distribution-07.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 9 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 2014 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 582, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity-10' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp-api' is defined on line 613, 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 Summary: 1 error (**), 0 flaws (~~), 11 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-07 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 In general, each node requires two modules: 1) Event Queue (EQ) 317 module and 2) Information Storage (IS) module. 1. These two modules 318 should be integrated with the information distribution module. We 319 introduce details of the two modules in the following sections. 321 5.2.1 Information Storage 323 IS module handles how to save and retrieve information for ASAs 324 across the network. The IS module uses a syntax to index information, 325 not only generating the hash index value (e.g. a key) for the 326 information, but also mapping the hash index to a certain ANIMA node 327 in ANI. NOte that, this mechanism can use existing solutions. 328 Specifically, storing information in an ANIMA network will be 329 realized in the following steps. 331 1) ASA-to-IS Negotiation. An ASA calls the API provided by 332 information distribution module (directly supported by IS sub- 333 module) to request to store the information somewhere in the 334 network. Such a request will be checked by the IS module who will 335 response the request from the ASA whether such a request is 336 feasible according to criteria such as permitted information size. 338 2) Destination Node Mapping. The information block will be handled 339 by the IS module in order to calculate/map to a destination node 340 in the network. Since ANIMA network is a peer-to-peer network, a 341 typical way is to use dynamic hash table to map information to a 342 unique index identifier. For example, if the size of the 343 information is reasonable, the information block itself can be 344 hashed, otherwise, some meta-data of the information block can be 345 used to generate the mapping. 347 3) Destination Node Negotiation Request. Negotiation request of 348 storing the information will be sent from the IS module to the IS 349 module on the destination node. The negotiation request contains 350 parameters about the information block from the source IS module. 351 According to the parameters as well as the local available 352 resource, the destination node will feedback the source IS module. 354 4) Destination Node Negotiation Response. Negotiation response 355 from the destination node is sent back to the source IS module. If 356 the source IS module gets confirmation that the information can be 357 stored, source IS module will prepare to transfer the information 358 block; otherwise, a new destination node must be discovered (i.e. 359 going to step 7). 361 5) Information Block Transfer. Before sending the information 362 block to the destination node that accepts the request, source 363 node will check if the information block can be afforded by one 364 GRASP message. If so, the information block will be directly sent 365 by calling a GRASP API. Otherwise, bulk data transmission with 366 GRASP will be triggered, where multi-time GRASP message sending 367 will be used so that one information block will be transferred by 368 smaller pieces. 370 6) Information Writing. Once the information block (or a smaller 371 block) is received, the IS module of the destination node will 372 store the data block in the local storage, which is accessible. 374 7) (Optional) New Destination Node Discovery. If the previously 375 selected destination node is not available to store the 376 information block, the source IS module will have to identify a 377 new destination node to start a new negotiation. In this case, the 378 discovery can be done by using discovery GRASP API to identify a 379 new candidate, or more complex mechanisms can be introduced. 381 Similarly, Getting information from an ANIMA network will be realized 382 in the following steps. 384 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 385 exposed by the information distribution module. The key/index of 386 the interested information will be sent to the IS module. An 387 assumption here is that the key/index should be ready to an ASA 388 before an ASA can ask for the information. This relates to the 389 publishing/subscribing of the information, which are handled by 390 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 392 2) Destination Node Mapping. IS module maps the key/index of the 393 requested information to a destination node, and prepares to start 394 to request the information. The mapping here follows the same 395 mechanism when the information is stored. 397 3) Retrieval Negotiation Request. The source IS module sends a 398 request to the destination node identified in the previous step 399 and asks if such an information object is available. 401 4) Retrieval Negotiation Response. The destination node checks the 402 key/index of the requested information, and replies to the source 403 IS module. If the information is found and the information block 404 can be afforded within one GRASP message, the information will be 405 sent together with the response to the source IS module. 407 5) (Optional) New Destination Request. If the information is not 408 found after the source IS module gets the response from the 409 original destination node, the source IS module will have to 410 discover where the location storing the requested information is. 412 IS module can reuse distributed databases and key value stores like 413 NoSQL, Cassandra, DHT technologies. storage and retrieval of 414 information are all event-driven responsible by the EQ module. 416 5.2.2 Event Queue 418 Event Queue (EQ) module is responsible for event classification, 419 event prioritization and event matching. 421 Firstly, EQ module provides isolated event queues customized for 422 different event groups. Specifically, two groups of AFs could have 423 completely different purposes or interests, therefore EQ 424 classification allows to create multiple message queues where only 425 AFs interested in the same category of events will be aware of the 426 corresponding event queue. 428 Secondly, events generated may have to be processed with different 429 priorities. Some of them are more urgent than the normal and regular 430 ones. Also between two event queues, their priorities may be 431 different. EQ prioritization allows AFs to set different priorities 432 on the information they published. Based on the priority settings in 433 the event queue, matching and delivery of them will be adjusted. EQ 434 module can provide several pre-defined priority levels for both 435 intra-queue and inter-queue prioritizations. 437 Third, events in queues will be listened and if a publishing event is 438 found and matched by a registration event, information retrieval will 439 be triggered. 441 5.2.3 Interface between IS and EQ Modules 443 EQ and IS modules are correlated. When an AF publishes information, 444 not only an publishing event is translated and sent to EQ module, but 445 also the information is indexed and stored simultaneously. Similarly, 446 when an AF subscribes information, not only subscribing event is 447 triggered and sent to EQ module, but also the information will be 448 retrieved by IS module at the same time. 450 5.3 Summary 452 In summary, the general requirements for the information distribution 453 module on each autonomic node are two sub-modules handling instant 454 communications and asynchronous communications, respectively. For 455 instant communications, node requirements are simple, in which 456 signaling protocols have to be supported. With minimum efforts, 457 reusing the existing GRASP is possible. For asynchronous 458 communications, information distribution module requires event queue 459 and information storage mechanism to be supported. 461 6. Protocol Specification (GRASP extension) 463 There are multiple ways to integrate the information distribution 464 module. The principle we follow is to minimize modifications made to 465 the current ANI. 467 We consider to use GRASP as an interface to access the information 468 distribution module. The main reason is that the current version of 469 GRASP is already an information distribution module for the cases of 470 P2P and flooding. In the following discussions, we introduce how to 471 complete the missing part. 473 6.1 Un-solicited Synchronization Message (A new GRASP Message) 475 In fragmentary CDDL, a Un-solicited Synchronization message follows 476 the pattern: 478 unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] 480 A node MAY actively send a unicast Un-solicited Synchronization 481 message with the Synchronization data, to another node. This MAY be 482 sent to port GRASP_LISTEN_PORT at the destination address, which 483 might be obtained by GRASP Discovery or other possible ways. The 484 synchronization data are in the form of GRASP Option(s) for specific 485 synchronization objective(s). 487 6.2 Selective Flooding Option 489 In fragmentary CDDL, the selective flood follows the pattern: 491 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 492 match-object, action] 493 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 494 Obj1 = text 495 match-rule = GREATER / LESS / WITHIN / CONTAIN 496 Obj2 = text 497 match-object = NEIGHBOR / SELF 498 action = FORWARD / DROP 500 The selective flood option encapsulates a match-condition option 501 which represents the conditions regarding to continue or discontinue 502 flood the current message. For the match-condition option, the Obj1 503 and Obj2 are to objects that need to be compared. For example, the 504 Obj1 could be the role of the device and Obj2 could be "RSG". The 505 match rules between the two objects could be greater, less than, 506 within, or contain. The match-object represents of which Obj1 belongs 507 to, it could be the device itself or the neighbor(s) intended to be 508 flooded. The action means, when the match rule applies, the current 509 device just continues flood or discontinues. 511 6.3 Subscription Objective Option 513 In fragmentary CDDL, a Subscription Objective Option follows the 514 pattern: 516 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 517 objective-name = SUBSCRIPTION 518 objective-flags = 2 519 loop-count = 2 520 subobj = text 522 This option MAY be included in GRASP M_Synchronization, when 523 included, it means this message is for a subscription to a specific 524 object. 526 6.4 Un_Subscription Objective Option 528 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 529 pattern: 531 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 532 objective-name = SUBSCRIPTION 533 objective-flags = 2 534 loop-count = 2 535 unsubobj = text 537 This option MAY be included in GRASP M_Synchronization, when 538 included, it means this message is for a un-subscription to a 539 specific object. 541 6.5 Publishing Objective Option 543 In fragmentary CDDL, a Publish Objective Option follows the pattern: 545 publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name 546 = PUBLISH 547 objective-flags = 2 548 loop-count = 2 549 pubobj = text 551 This option MAY be included in GRASP M_Synchronization, when 552 included, it means this message is for a publish of a specific object 553 data. 555 Note that extended GRASP messages with new arguments inside here will 556 trigger interactions/actions of the underlying information 557 distribution module introduced in Section 5. 559 7. Security Considerations 561 The distribution source authentication could be done at multiple 562 layers: 564 o Outer layer authentication: the GRASP communication is within 565 ACP (Autonomic Control Plane, 566 [I-D.ietf-anima-autonomic-control-plane]). This is the default 567 GRASP behavior. 569 o Inner layer authentication: the GRASP communication might not 570 be within a protected channel, then there should be embedded 571 protection in distribution information itself. Public key 572 infrastructure might be involved in this case. 574 8. IANA Considerations 576 TBD. 578 9. References 580 9.1 Normative References 582 [I-D.ietf-anima-grasp] 583 Bormann, D., Carpenter, B., and B. Liu, "A Generic 584 Autonomic Signaling Protocol (GRASP)", draft-ietf- 585 animagrasp-15 (Standard Track), October 2017. 587 9.2 Informative References 589 [RFC7575] Behringer, M., "Autonomic Networking: Definitions and 590 Design Goals", RFC 7575, June 2015 592 [I-D.ietf-anima-autonomic-control-plane] 593 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 594 Control Plane (ACP)", draft-behringer-anima-autonomic- 595 control-plane-13, December 2017. 597 [I-D.ietf-anima-stable-connectivity-10] 598 Eckert, T., Behringer, M., "Using Autonomic Control Plane 599 for Stable Connectivity of Network OAM", draft-ietf-anima- 600 stable-connectivity-10, February 2018. 602 [I-D.ietf-anima-reference-model] 603 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 604 Pierre P., Liu, B., Nobre, J., and J. Strassner, "A 605 Reference Model for Autonomic Networking", draft-ietf- 606 anima-reference-model-05, October 2017. 608 [I-D.du-anima-an-intent] 609 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 610 Behringer, "ANIMA Intent Policy and Format", draft- 611 duanima-an-intent-05 (work in progress), February 2017. 613 [I-D.ietf-anima-grasp-api] 614 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 615 Autonomic Signaling Protocol Application Program Interface 616 (GRASP API)", draft-ietf-anima-grasp-api-00 (work in 617 progress), December 2017. 619 [3GPP.29.500] 620 3GPP, "Technical Realization of Service Based 621 Architecture", 3GPP TS 29.500 15.1.0, 09 2018 623 [3GPP.23.501] 624 3GPP, "System Architecture for the 5G System", 3GPP TS 625 23.501 15.2.0, 6 2018, 626 . 628 [3GPP.23.502] 629 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 630 15.2.0, 6 2018, . 633 [5GAA.use.cases] 634 White Paper "Toward fully connected vehicles: Edge 635 computing for advanced automotive communications", 5GAA 636 639 Appendix A. 641 GRASP includes flooding criteria together with the delivered 642 information so that every node will process and act according to the 643 criteria specified in the message. An example of extending GRASP with 644 selective criteria can be: 646 o Matching condition: "Device role=IPRAN_RSG" 648 o Matching objective: "Neighbors" 650 o Action: "Forward" 652 This example means: only distributing the information to the 653 neighbors who are IPRAN_RSG. 655 Authors' Addresses 657 Bing Liu 658 Huawei Technologies 659 Q27, Huawei Campus 660 No.156 Beiqing Road 661 Hai-Dian District, Beijing 100095 662 P.R. China 664 Email: leo.liubing@huawei.com 666 Sheng Jiang 667 Huawei Technologies 668 Q27, Huawei Campus 669 No.156 Beiqing Road 670 Hai-Dian District, Beijing 100095 671 P.R. China 673 Email: jiangsheng@huawei.com 675 Xun Xiao 676 Munich Research Center 677 Huawei technologies 678 Riesstr. 25, 80992, Muenchen, Germany 680 Emails: xun.xiao@huawei.com 682 Artur Hecker 683 Munich Research Center 684 Huawei technologies 685 Riesstr. 25, 80992, Muenchen, Germany 687 Emails: artur.hecker@huawei.com 689 Zoran Despotovic 690 Munich Research Center 691 Huawei technologies 692 Riesstr. 25, 80992, Muenchen, Germany 694 Emails: zoran.despotovic@huawei.com 695 Appendix A Real-world Use Cases of Information Distribution 697 The requirement analysis in Section 3 shows that generally 698 information distribution should be better of as an infrastructure 699 layer module, which provides to upper layer utilizations. In this 700 section, we review some use cases from the real-world where an 701 information distribution module with powerful functions do plays a 702 critical role there. 704 A.1 Service-Based Architecture (SBA) in 3GPP 5G 706 In addition to Internet, the telecommunication network (i.e. carrier 707 mobile wireless networks) is another world-wide networking system. 708 The architecture of the upcoming 5G mobile networks from 3GPP has 709 already been defined to follow a service-based architecture (SBA) 710 where any network function (NF) can be dynamically associated with 711 any other NF(s) when needed to compose a network service. Note that 712 one NF can simultaneously associate with multiple other NFs, instead 713 of being physically wired as in the previous generations of mobile 714 networks. NFs communicate with each other over service-based 715 interface (SBI), which is also standardized by 3GPP [3GPP.23.501]. 717 In order to realize an SBA network system, detailed requirements are 718 further defined to specify how NFs should interact with each other 719 with information exchange over the SBI. We now list three 720 requirements that are related to information distribution here. 722 1) NF Pub/Sub: Any NF should be able to expose its service status 723 to the network and any NF should be able to subscribe the service 724 status of an NF and get notified if the status is available. An 725 concrete example is that a session management function (SMF) can 726 subscribe the REGISTER notification from an access management 727 function (AMF) if there is a new user entity trying to access the 728 mobile network [3GPP.23.502]. 730 2) Network Exposure Function (NEF): A particular network function 731 that is required to manage the event exposure and distributions. 732 In specific, SBA requires such a functionality to register network 733 events from the other NFs (e.g. AMF, SMF and so on), classify the 734 events and properly handle event distributions accordingly in 735 terms of different criteria (e.g. priorities) [3GPP.23.502]. 737 3) Network Repository Function (NRF): A particular network 738 function where all service status information is stored for the 739 whole network. An SBA network system requires all NFs to be 740 stateless so as to improve the resilience as well as agility of 741 providing network services. Therefore, the information of the 742 available NFs and the service status generated by those NFs will 743 be globally stored in NRF as a repository of the system. This 744 clearly implies storage capability that keeps the information in 745 the network and provides those information when needed. A concrete 746 example is that whenever a new NF comes up, it first of all 747 registers itself at NRF with its profile. When a network service 748 requires a certain NF, it first inquires NRF to retrieve the 749 availability information and decides whether or not there is an 750 available NF or a new NF must be instantiated [3GPP.23.502]. 752 (Note: 3GPP CT might finally adopt HTTP2.0/JSON to be the protocol 753 communicating between NFs, but autonomic networks can also load 754 HTTP2.0 with in ACP.) 756 A.2 Vehicle-to-Everything 758 Carrier networks On-boarding services of vertical industries are also 759 one of some blooming topics that are heavily discussed. Connected car 760 is clearly one of the important scenarios interested in automotive 761 manufacturers, carriers and vendors. 5G Automotive Alliance - an 762 industry collaboration organization defines many promising use cases 763 where services from car industry should be supported by the 5G mobile 764 network. Here we list two examples as follows [5GAA.use.cases]. 766 1) Software/Firmware Update: Car manufacturers expect that the 767 software/firmware of their car products can be remotely 768 updated/upgraded via 5G network in future, instead of onsite 769 visiting their 4S stores/dealers offline as nowadays. This 770 requires the network to provide a mechanism for vehicles to 771 receive the latest software updates during a certain period of 772 time. In order to run such a service for a car manufacturer, the 773 network shall not be just like a network pipe anymore. Instead, 774 information data have to be stored in the network, and delivered 775 in a publishing/subscribing fashion. For example, the latest 776 release of a software will be first distributed and stored at the 777 access edges of the mobile network, after that, the updates can be 778 pushed by the car manufacturer or pulled by the car owner as 779 needed. 781 2) Real-time HD Maps: Autonomous driving clearly requires much 782 finer details of road maps. Finer details not only include the 783 details of just static road and streets, but also real-time 784 information on the road as well as the driving area for both local 785 urgent situations and intelligent driving scheduling. This asks 786 for situational awareness at critical road segments in cases of 787 changing road conditions. Clearly, a huge amount of traffic data 788 that are real-time collected will have to be stored and shared 789 across the network. This clearly requires the storage capability, 790 data synchronization and event notifications in urgent cases from 791 the network, which are still missing at the infrastructure layer. 793 A.3 Summary 795 Through the general analysis and the concrete examples from the real- 796 world, we realize that the ways information are exchanged in the 797 coming new scenarios are not just short and instant anymore. More 798 advanced as well as diverse information distribution capabilities are 799 required and should be generically supported from the infrastructure 800 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 801 utilize such a unified mechanism for their own services.