idnits 2.17.1 draft-liu-anima-grasp-distribution-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 192 has weird spacing: '...ced AFs may r...' -- The document date (July 2, 2018) is 2118 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 142, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp-api' is defined on line 667, 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: 0 errors (**), 0 flaws (~~), 8 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: January 3, 2019 X. Xiao 6 A. Hecker 7 Z. Despotovic 8 MRC, Huawei Technologies 9 July 2, 2018 11 Information Distribution in Autonomic Networking 12 draft-liu-anima-grasp-distribution-06 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 realizing 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. Real-world Use Case Examples . . . . . . . . . . . . . . . . . . 6 77 4.1 Service-Based Architecture (SBA) in 3GPP 5G . . . . . . . . 6 78 4.2 Vehicle-to-Everything . . . . . . . . . . . . . . . . . . . 7 79 4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.1 Instant Information Distribution . . . . . . . . . . . . . . 8 82 5.1.1 Instant P2P and Flooding Communications . . . . . . . . 8 83 5.1.2 Instant Selective Flooding Communication . . . . . . . 8 84 5.2 Asynchronous Information Distribution . . . . . . . . . . . 9 85 5.2.1 Event Queue . . . . . . . . . . . . . . . . . . . . . 10 86 5.2.2 Information Storage . . . . . . . . . . . . . . . . . 10 87 5.2.3 Interface between IS and EQ Modules . . . . . . . . . 11 88 5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 6. Protocol Specification (GRASP extension) . . . . . . . . . . . 12 90 6.1 Un-solicited Synchronization Message (A new GRASP Message) 12 91 6.2 Selective Flooding Option . . . . . . . . . . . . . . . . 12 92 6.3 Subscription Objective Option . . . . . . . . . . . . . . 13 93 6.4 Un_Subscription Objective Option . . . . . . . . . . . . . 13 94 6.5 Publishing Objective Option . . . . . . . . . . . . . . . 13 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 97 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 98 10. Informative References . . . . . . . . . . . . . . . . . . . 14 99 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 102 1 Introduction 104 In autonomic networking, autonomic functions (AFs) running on 105 autonomic nodes utilize autonomic control plane (ACP) to realize 106 various control purposes [RFC7575]. Due to the distributed nature of 107 a network system, AFs need to exchange information constantly, either 108 for control plane signaling, for data plane service or for both. 110 This document discusses the information distribution capability of an 111 autonomic network. We classify information distribution scenarios 112 into the following two models: 114 1) An instant communication model where a sender directly connects 115 and sends information data (e.g. control messages, synchronization 116 data and so on) to the receiver(s). 118 2) An asynchronous communication model where an autonomic node 119 publishes information and any other nodes that are interested in 120 the information can later subscribe that and will be notified if 121 the information become available. 123 The two communication models should be integrated within the 124 Autonomic Network Infrastructure (ANI) [I-D.behringer-anima- 125 reference-model], rather than assisted by other transport or routing 126 protocols (HTTP, BGP/IGP as bearing protocols etc.). In fact, GRASP 127 already provides some capabilities to support parts of the 128 information distribution function, utilized for stable connectivity 129 as in [I-D.ietf-anima-stable-connectivity-10]. 131 In this document, we analyze possible scenarios of information 132 distribution in autonomic networks (Section 3), and then discuss the 133 technical requirements (Section 4) that an autonomic node has to 134 fulfill. After that, the node behaviors with extensions on current 135 GRASP to realize the information distribution are introduced. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 3. Requirements of Advanced Information Distribution 145 Information distribution can occur either between two or among 146 multiple network nodes. 148 - Point-to-point (P2P) Communications: 150 This is a common scenario in most of network systems. Information are 151 exchanged between two communicating parties from one node to another 152 node. Specifically, the information can be either pushed to the 153 receiver or pulled from a sender. Therefore, we have two sub-cases: 155 1) One node acquires some information from another one. This is a 156 very common scenario that can already be covered by GRASP. 158 2) One node actively pushes some information to another one. For 159 example, when some common information are propagated to the 160 network, it is possible that some nodes are sleeping/off-line, so 161 when these nodes get online again, their neighbors could push the 162 information to them immediately. 164 - One-to-Many Communications: 166 Some information exchange involve an information source and multiple 167 receivers. This scenario can be divided into two situations: 169 1) When some information are relevant to all or most of the nodes 170 in the domain, the node that firstly handle the information should 171 use a mechanism to propagate it to all the other nodes. One 172 typical case is the Intent distribution, which is briefly 173 discussed in Section 4.7 of [I-D.ietf-anima-reference-model]. A 174 flood mechanism, which can guarantee the information could reach 175 to every node, is the most proper approach to do this. 177 2) A more general case is that some information is only relevant 178 to a specific group of nodes belonging to the same sub-domain or 179 sharing the same interests. Then, the information needs to be 180 propagated to the nodes that fit for certain conditions. This 181 could reduce some unnecessary signaling amplification. 183 Clearly, both of the two scenarios can be directly carried by the 184 instant communication model. Especially, if the information exchange 185 is simple and short, this can be done instantly. In practice, 186 however, information distribution is not always simple. As examples, 187 in the following cases, a mixture of instant and asynchronous 188 communication models is more appropriate. 190 1) Long Communication Intervals. The time interval of the 191 communication is not necessarily always short and instant. 192 Advanced AFs may rather involve heavy jobs/tasks when gearing the 193 network, so the direct mode may introduce unnecessary pending time 194 and become less efficient. For example, an AF accesses another AF 195 for a database lookup. Similar use cases include AF migration, AF 196 authentication and authorization. If simply using an instant mode, 197 the AF has to wait until the tasks finish and return. A better way 198 is that an AF instantly sends the request but switches to an 199 synchronous mode, once the jobs are finished, AFs will get 200 notified. 202 2) Common Interest Distribution. As mentioned, some information 203 are common interests among AFs. For example, the network intent is 204 distributed to network nodes enrolled, which is a typical one-to- 205 many scenario. We can also finish the intent distribution by an 206 instant flooding (e.g. via GRASP) to every network nodes across 207 the network domain. Because of network dynamic, however, not every 208 node can be just ready at the moment when the network intent is 209 flooded. Actually, nodes may join in the network sequentially. In 210 this situation, an asynchronous communication model could be a 211 better choice where every (newly joining) node can subscribe the 212 intent information and will get notified if it is ready (or 213 updated). 215 3) Distributed Coordination. With computing and storage resources 216 on autonomic nodes, alive AFs not only consumes but also generates 217 data information. For example, AFs coordinating with each other as 218 distributed schedulers, responding to service requests and 219 distributing tasks. It is critical for those AFs to make correct 220 decisions based on local information, which might be asymmetric as 221 well. AFs may also need synthetic/aggregated data information 222 (e.g. statistic info, like average values of several AFs, etc.) to 223 make decisions. In these situations, AFs will need an efficient 224 way to form a global view of the network (e.g. about resource 225 consumption, bandwidth and statistics). Obviously, purely relying 226 on instant communication model is inefficient, while a scalable, 227 common, yet distributed data layer, on which AFs can store and 228 share information in an asynchronous way, should be a better 229 choice. 231 For ANI, in order to support various communication scenarios, an 232 information distribution module is required, and both instant and 233 asynchronous communication models should be supported. 235 4. Real-world Use Case Examples 237 The requirement analysis above shows that generally information 238 distribution should be better of as an infrastructure layer module, 239 which provides to upper layer utilizations. In this section, we 240 review some use cases from the real-world where an information 241 distribution module with powerful functions do plays a critical role 242 there. 244 4.1 Service-Based Architecture (SBA) in 3GPP 5G 246 In addition to Internet, the telecommunication network (i.e. carrier 247 mobile wireless networks) is another world-wide networking system. 248 The architecture of the upcoming 5G mobile networks from 3GPP has 249 already been defined to follow a service-based architecture (SBA) 250 where any network function (NF) can be dynamically associated with 251 any other NF(s) when needed to compose a network service. Note that 252 one NF can simultaneously associate with multiple other NFs, instead 253 of being physically wired as in the previous generations of mobile 254 networks. NFs communicate with each other over service-based 255 interface (SBI), which is also standardized by 3GPP [3GPP.23.501]. 257 In order to realize an SBA network system, detailed requirements are 258 further defined to specify how NFs should interact with each other 259 with information exchange over the SBI. We now list three 260 requirements that are related to information distribution here. 262 1) NF Pub/Sub: Any NF should be able to expose its service status 263 to the network and any NF should be able to subscribe the service 264 status of an NF and get notified if the status is available. An 265 concrete example is that a session management function (SMF) can 266 subscribe the REGISTER notification from an access management 267 function (AMF) if there is a new user entity trying to access the 268 mobile network [3GPP.23.502]. 270 2) Network Exposure Function (NEF): A particular network function 271 that is required to manage the event exposure and distributions. 272 In specific, SBA requires such a functionality to register network 273 events from the other NFs (e.g. AMF, SMF and so on), classify the 274 events and properly handle event distributions accordingly in 275 terms of different criteria (e.g. priorities) [3GPP.23.502]. 277 3) Network Repository Function (NRF): A particular network 278 function where all service status information is stored for the 279 whole network. An SBA network system requires all NFs to be 280 stateless so as to improve the resilience as well as agility of 281 providing network services. Therefore, the information of the 282 available NFs and the service status generated by those NFs will 283 be globally stored in NRF as a repository of the system. This 284 clearly implies storage capability that keeps the information in 285 the network and provides those information when needed. A concrete 286 example is that whenever a new NF comes up, it first of all 287 registers itself at NRF with its profile. When a network service 288 requires a certain NF, it first inquires NRF to retrieve the 289 availability information and decides whether or not there is an 290 available NF or a new NF must be instantiated [3GPP.23.502]. 292 4.2 Vehicle-to-Everything 294 Carrier networks On-boarding services of vertical industries are also 295 one of some blooming topics that are heavily discussed. Connected car 296 is clearly one of the important scenarios interested in automotive 297 manufacturers, carriers and vendors. 5G Automotive Alliance - an 298 industry collaboration organization defines many promising use cases 299 where services from car industry should be supported by the 5G mobile 300 network. Here we list two examples as follows [5GAA.use.cases]. 302 1) Software/Firmware Update: Car manufacturers expect that the 303 software/firmware of their car products can be remotely 304 updated/upgraded via 5G network in future, instead of onsite 305 visiting their 4S stores/dealers offline as nowadays. This 306 requires the network to provide a mechanism for vehicles to 307 receive the latest software updates during a certain period of 308 time. In order to run such a service for a car manufacturer, the 309 network shall not be just like a network pipe anymore. Instead, 310 information data have to be stored in the network, and delivered 311 in a publishing/subscribing fashion. For example, the latest 312 release of a software will be first distributed and stored at the 313 access edges of the mobile network, after that, the updates can be 314 pushed by the car manufacturer or pulled by the car owner as 315 needed. 317 2) Real-time HD Maps: Autonomous driving clearly requires much 318 finer details of road maps. Finer details not only include the 319 details of just static road and streets, but also real-time 320 information on the road as well as the driving area for both local 321 urgent situations and intelligent driving scheduling. This asks 322 for situational awareness at critical road segments in cases of 323 changing road conditions. Clearly, a huge amount of traffic data 324 that are real-time collected will have to be stored and shared 325 across the network. This clearly requires the storage capability, 326 data synchronization and event notifications in urgent cases from 327 the network, which are still missing at the infrastructure layer. 329 4.3 Summary 331 Through the general analysis and the concrete examples from the real- 332 world, we realize that the ways information are exchanged in the 333 coming new scenarios are not just short and instant anymore. More 334 advanced as well as diverse information distribution capabilities are 335 required and should be generically supported from the infrastructure 336 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 337 utilize such a unified mechanism for their own services. 339 5. Node Behaviors 341 In this section, we discuss how each autonomic node should behave in 342 order to realize the information distribution module. In other words, 343 we discuss the node requirement if an information distribution module 344 is required across the ANI. Supporting the two communication models 345 that may happen in the ANI necessarily involves node interactions and 346 information data exchange. Specifically, we first introduce the node 347 requirement for the instant communication model, and after that we 348 introduce the node requirement for the asynchronous communication 349 model. 351 5.1 Instant Information Distribution 353 In this case, sender(s) and receiver(s) are explicitly and 354 immediately specified (e.g. the addresses of the receivers). 355 Information will be directly distributed from the sender(s) to the 356 receiver(s). This requires that every node is equipped by some 357 signaling/transport protocols so that they can coordinate with each 358 other and correctly deliver the information. 360 5.1.1 Instant P2P and Flooding Communications 362 We consider that current GRASP already provides some of the instant 363 P2P and flooding communications capabilities. 365 Straightforwardly, it is natural to use the GRASP Synchronization 366 message directly for P2P distribution. Furthermore, it is also 367 natural to use the GRASP Flood Synchronization message for 1-to-all 368 distribution. 370 However, as mentioned in Section 3, in some scenarios one node needs 371 to actively send some information to another. GRASP Synchronization 372 just lacks such capability. An un-solicited synchronization mechanism 373 is needed. A relevant GRASP extension is defined in Section 6. 375 5.1.2 Instant Selective Flooding Communication 376 When doing selective flooding, the distributed information needs to 377 contain the criteria for nodes to judge which interfaces should be 378 sent the distributed information and which are not. Specifically, the 379 criteria contain: 381 o Matching condition: a set of matching rules. 383 o Matching object: the object that the match condition would be 384 applied to. For example, the matching object could be node itself 385 or its neighbors. 387 o Action: what behavior the node needs to do when the matching 388 object matches or failed the matching condition. For example, the 389 action could be forwarding or discarding the distributed message. 391 The sender has to includes the criteria information in the message 392 that carries the distributed information. The receiving node decides 393 the action according to the criteria carried in the message. Still 394 considering the criteria attached with the distributed information, 395 the node behaviors can be: 397 o When the Matching Object is "Neighbors", then the node matches 398 the relevant information of its neighbors to the Matching 399 Condition. If the node finds one neighbor matches the Matching 400 Condition, then it forwards the distributed message to the 401 neighbor. If not, the node discards forwarding the message to the 402 neighbor. 404 o When the Matching Object is the node itself, then the node 405 matches the relevant inforshi mation of its own to the Matching 406 Condition. If the node finds itself matches the Matching 407 Condition, then it forwards the distributed message to its 408 neighbors; if not, the node discards forwarding the message to the 409 neighbors. 411 An example of selective flooding is briefly described in the Appendix 412 A. 414 5.2 Asynchronous Information Distribution 416 Asynchronous information distribution happens in a different way 417 where sender(s) and receiver(s) are normally not immediately 418 specified. In other words, both the sender and the receiver may come 419 up in an asynchronous way. First of all, this requires that the 420 information can be stored; secondly, it requires an information 421 publication and subscription (Pub/Sub) mechanism. (Corresponding 422 protocol specification of Pub/Sub is defined in Section 6.) 423 Specifically, an information publisher 1) receives publishing 424 requests from local AFs (also from ASAs), 2) decides where to store 425 the published information, 3) updates corresponding event queues. On 426 the other hand, an information subscriber registers its interests, 2) 427 monitors event queues in the system and 3) trigger information 428 retrieval if information of registered events are ready. 430 In general, each node requires two modules: 1) event queue (EQ) 431 module and 2) information storage (IS) module shown in Figure. 1. 432 These two modules should be integrated with the information 433 distribution module. We introduce details of the two modules in the 434 following sections. 436 +---------------------------------------+ 437 | +---------------+ +---------------+ | 438 | | Event Queue |-|-| Info. Storage | | 439 | +---------------+ +---------------+ | 440 +---------------------------------------+ 441 Figure 1. Components for asynchronous comm. 443 5.2.1 Event Queue 445 Event Queue (EQ) module is responsible for event classification, 446 event prioritization and event matching. 448 Firstly, EQ module provides isolated event queues customized for 449 different event groups. Specifically, two groups of AFs could have 450 completely different purposes or interests, therefore EQ 451 classification allows to create multiple message queues where only 452 AFs interested in the same category of events will be aware of the 453 corresponding event queue. 455 Secondly, events generated may have to be processed with different 456 priorities. Some of them are more urgent than the normal and regular 457 ones. Also between two event queues, their priorities may be 458 different. EQ prioritization allows AFs to set different priorities 459 on the information they published. Based on the priority settings in 460 the event queue, matching and delivery of them will be adjusted. EQ 461 module can provide several pre-defined priority levels for both 462 intra-queue and inter-queue prioritizations. 464 Third, events in queues will be listened and if a publishing event is 465 found and matched by a registration event, information retrieval will 466 be triggered. 468 5.2.2 Information Storage 470 Events are closely related to the information. IS module handles how 471 to efficiently save and retrieve information for AFs across the 472 network according to announced events. Any information that is 473 published by AFs will be sent to the IS module, and the IS module 474 decides where to store the information and how to index and retrieve 475 it. 477 The IS module defines a syntax to index information, not only 478 generating the hash index value (e.g. a key) for the information, but 479 also mapping the hash index to a certain network node in ANI. 481 When data information is published by an AF (i.e. publishing events), 482 it will be sent to the IS module. The IS module calculates its hash 483 index (i.e. the key) and the location responsible for storing the 484 information. The IS module confirms with the node chosen to store the 485 information by negotiation. After that, if available, the IS module 486 sends the information to there. 488 When data information has to be retrieved (i.e. subscribing events), 489 a request from an AF will be also received by the IS module. IS 490 module, by parsing the request, identifies the hash index of the 491 information, which tells the location of the information as well. 492 After that, the IS module requests the desired information and 493 retrieves it once it is ready. 495 IS module can reuse distributed databases and key value stores like 496 NoSQL, Cassandra, DHT technologies. storage and retrieval of 497 information are all event-driven responsible by the EQ module. 499 5.2.3 Interface between IS and EQ Modules 501 EQ and IS modules are correlated. When an AF publishes information, 502 not only an publishing event is translated and sent to EQ module, but 503 also the information is indexed and stored simultaneously. Similarly, 504 when an AF subscribes information, not only subscribing event is 505 triggered and sent to EQ module, but also the information will be 506 retrieved by IS module at the same time. 508 5.3 Summary 510 In summary, the general requirements for the information distribution 511 module on each autonomic node are two sub-modules handling instant 512 communications and asynchronous communications, respectively. For 513 instant communications, node requirements are simple, in which 514 signaling protocols have to be supported. With minimum efforts, 515 reusing the existing GRASP is possible. For asynchronous 516 communications, information distribution module requires event queue 517 and information storage mechanism to be supported. 519 6. Protocol Specification (GRASP extension) 521 There are multiple ways to integrate the information distribution 522 module. The principle we follow is to minimize modifications made to 523 the current ANI. 525 We consider to use GRASP as an interface to access the information 526 distribution module. The main reason is that the current version of 527 GRASP is already an information distribution module for the cases of 528 P2P and flooding. In the following discussions, we introduce how to 529 complete the missing part. 531 6.1 Un-solicited Synchronization Message (A new GRASP Message) 533 In fragmentary CDDL, a Un-solicited Synchronization message follows 534 the pattern: 536 unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] 538 A node MAY actively send a unicast Un-solicited Synchronization 539 message with the Synchronization data, to another node. This MAY be 540 sent to port GRASP_LISTEN_PORT at the destination address, which 541 might be obtained by GRASP Discovery or other possible ways. The 542 synchronization data are in the form of GRASP Option(s) for specific 543 synchronization objective(s). 545 6.2 Selective Flooding Option 547 In fragmentary CDDL, the selective flood follows the pattern: 549 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 550 match-object, action] 551 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 552 Obj1 = text 553 match-rule = GREATER / LESS / WITHIN / CONTAIN 554 Obj2 = text 555 match-object = NEIGHBOR / SELF 556 action = FORWARD / DROP 558 The selective flood option encapsulates a match-condition option 559 which represents the conditions regarding to continue or discontinue 560 flood the current message. For the match-condition option, the Obj1 561 and Obj2 are to objects that need to be compared. For example, the 562 Obj1 could be the role of the device and Obj2 could be "RSG". The 563 match rules between the two objects could be greater, less than, 564 within, or contain. The match-object represents of which Obj1 belongs 565 to, it could be the device itself or the neighbor(s) intended to be 566 flooded. The action means, when the match rule applies, the current 567 device just continues flood or discontinues. 569 6.3 Subscription Objective Option 571 In fragmentary CDDL, a Subscription Objective Option follows the 572 pattern: 574 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 575 objective-name = SUBSCRIPTION 576 objective-flags = 2 577 loop-count = 2 578 subobj = text 580 This option MAY be included in GRASP M_Synchronization, when 581 included, it means this message is for a subscription to a specific 582 object. 584 6.4 Un_Subscription Objective Option 586 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 587 pattern: 589 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 590 objective-name = SUBSCRIPTION 591 objective-flags = 2 592 loop-count = 2 593 unsubobj = text 595 This option MAY be included in GRASP M_Synchronization, when 596 included, it means this message is for a un-subscription to a 597 specific object. 599 6.5 Publishing Objective Option 601 In fragmentary CDDL, a Publish Objective Option follows the pattern: 603 publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name 604 = PUBLISH 605 objective-flags = 2 606 loop-count = 2 607 pubobj = text 609 This option MAY be included in GRASP M_Synchronization, when 610 included, it means this message is for a publish of a specific object 611 data. 613 [Editor's Note]: Detailed node behavior and processing procedures of 614 these new options will be introduced in the next version. 616 7. Security Considerations 618 The distribution source authentication could be done at multiple 619 layers: 621 o Outer layer authentication: the GRASP communication is within 622 ACP (Autonomic Control Plane, 623 [I-D.ietf-anima-autonomic-control-plane]). This is the default 624 GRASP behavior. 626 o Inner layer authentication: the GRASP communication might not 627 be within a protected channel, then there should be embedded 628 protection in distribution information itself. Public key 629 infrastructure might be involved in this case. 631 8. IANA Considerations 633 TBD. 635 9. Normative References 636 [I-D.ietf-anima-grasp] 637 Bormann, D., Carpenter, B., and B. Liu, "A Generic Autonomic 638 Signaling Protocol (GRASP)", draft-ietf-animagrasp-15 (Standard 639 Track), October 2017. 641 10. Informative References 643 [RFC7575] Behringer, M., "Autonomic Networking: Definitions and 644 Design Goals", RFC 7575, June 2015 646 [I-D.ietf-anima-autonomic-control-plane] 647 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 648 Control Plane (ACP)", draft-behringer-anima-autonomic- 649 control-plane-13, December 2017. 651 [I-D.ietf-anima-stable-connectivity-10] 652 Eckert, T., Behringer, M., "Using Autonomic Control Plane 653 for Stable Connectivity of Network OAM", draft-ietf-anima- 654 stable-connectivity-10, February 2018. 656 [I-D.ietf-anima-reference-model] 657 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 658 Pierre P., Liu, B., Nobre, J., and J. Strassner, "A 659 Reference Model for Autonomic Networking", draft-ietf- 660 anima-reference-model-05, October 2017. 662 [I-D.du-anima-an-intent] 663 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 664 Behringer, "ANIMA Intent Policy and Format", draft- 665 duanima-an-intent-05 (work in progress), February 2017. 667 [I-D.ietf-anima-grasp-api] 668 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 669 Autonomic Signaling Protocol Application Program Interface 670 (GRASP API)", draft-ietf-anima-grasp-api-00 (work in 671 progress), December 2017. 673 [3GPP.23.501] 674 3GPP, "System Architecture for the 5G System", 3GPP TS 675 23.501 15.2.0, 6 2018, 676 . 678 [3GPP.23.502] 679 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 680 15.2.0, 6 2018, . 683 [5GAA.use.cases] 684 White Paper "Toward fully connected vehicles: Edge 685 computing for advanced automotive communications", 5GAA 686 689 Appendix A. 691 GRASP includes flooding criteria together with the delivered 692 information so that every node will process and act according to the 693 criteria specified in the message. An example of extending GRASP with 694 selective criteria can be: 696 o Matching condition: "Device role=IPRAN_RSG" 698 o Matching objective: "Neighbors" 700 o Action: "Forward" 702 This example means: only distributing the information to the 703 neighbors who are IPRAN_RSG. 705 Authors' Addresses 706 Bing Liu 707 Huawei Technologies 708 Q27, Huawei Campus 709 No.156 Beiqing Road 710 Hai-Dian District, Beijing 100095 711 P.R. China 713 Email: leo.liubing@huawei.com 715 Sheng Jiang 716 Huawei Technologies 717 Q27, Huawei Campus 718 No.156 Beiqing Road 719 Hai-Dian District, Beijing 100095 720 P.R. China 722 Email: jiangsheng@huawei.com 724 Xun Xiao 725 Munich Research Center 726 Huawei technologies 727 Riesstr. 25, 80992, Muenchen, Germany 729 Emails: xun.xiao@huawei.com 731 Artur Hecker 732 Munich Research Center 733 Huawei technologies 734 Riesstr. 25, 80992, Muenchen, Germany 736 Emails: artur.hecker@huawei.com 738 Zoran Despotovic 739 Munich Research Center 740 Huawei technologies 741 Riesstr. 25, 80992, Muenchen, Germany 743 Emails: zoran.despotovic@huawei.com