idnits 2.17.1 draft-ietf-anima-grasp-distribution-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-grasp], [RFC7575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2020) is 1333 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 852, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-28 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-43 == Outdated reference: A later version (-10) exists of draft-ietf-anima-grasp-api-06 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu (Ed.) 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track X. Xiao (Ed.) 5 Expires: March 5, 2021 A. Hecker 6 MRC, Huawei Technologies 7 S. Jiang 8 Huawei Technologies 9 Z. Despotovic 10 MRC, Huawei Technologies 11 B. Carpenter 12 Univ. of Auckland 13 September 1, 2020 15 Information Distribution over GRASP 16 draft-ietf-anima-grasp-distribution-01 18 Abstract 20 This document proposes a solution for information distribution in the 21 autonomic network infrastructure (ANI). Information distribution is 22 categorized into two different modes: 1) instantaneous distribution 23 and 2) publication for retrieval. In the former case, the 24 information is sent, propagated and disposed of after reception. In 25 the latter case, information needs to be stored in the network. 27 The capability to distribute information is a basic and fundamental 28 need for an autonomous network ([RFC7575]). This document describes 29 typical use cases of information distribution in ANI and requirements 30 to ANI, such that rich information distribution can be natively 31 supported. The document proposes extensions to the autonomic nodes 32 and suggests an implementation based on GRASP 33 ([I-D.ietf-anima-grasp]) extensions as a protocol on the wire. 35 Status of This Memo 37 This Internet-Draft is submitted 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). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 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." 49 This Internet-Draft will expire on March 5, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Requirements for Information Distribution in ANI . . . . . . 4 71 4. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Instant Information Distribution (IID) Sub-module . . . . 7 73 4.1.1. Instant P2P Communication . . . . . . . . . . . . . . 7 74 4.1.2. Instant Flooding Communication . . . . . . . . . . . 7 75 4.2. Asynchronous Information Distribution (AID) Sub-module . 8 76 4.2.1. Information Storage . . . . . . . . . . . . . . . . . 9 77 4.2.2. Event Queue . . . . . . . . . . . . . . . . . . . . . 11 78 4.3. Bulk Information Transfer . . . . . . . . . . . . . . . . 12 79 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Extending GRASP for Information Distribution . . . . . . . . 15 81 5.1. New M_UNSOLIDSYNCH message for Instant P2P Transmission . 15 82 5.2. New O_SELECTIVE_FLOOD option for Selective Flooding . . . 15 83 5.3. New O_SUBSCRIPTION Objective Option . . . . . . . . . . . 16 84 5.4. New O_UNSUBSCRIBE Objective Option . . . . . . . . . . . 16 85 5.5. New O_PULISH Objective Option . . . . . . . . . . . . . . 16 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Appendix A. Open Issues [RFC Editor: To Be removed before 93 becoming RFC] . . . . . . . . . . . . . . . . . . . 19 94 Appendix B. Closed Issues [RFC Editor: To Be removed before 95 becoming RFC] . . . . . . . . . . . . . . . . . . . 20 96 Appendix C. Change log [RFC Editor: To Be removed before 97 becoming RFC] . . . . . . . . . . . . . . . . . . . 20 98 Appendix D. Implementation Examples and Considerations . . . . . 20 99 D.1. GRASP Bulk Transport . . . . . . . . . . . . . . . . . . 20 100 D.2. Asynchronous ID Integrated with GRASP APIs . . . . . . . 23 101 Appendix E. Real-world Use Cases of Information Distribution . . 23 102 E.1. Pub/Sub in 3GPP 5G Networks . . . . . . . . . . . . . . . 24 103 E.2. Event Queue/Storage in Vehicle-to-Everything (V2X) . . . 25 104 E.3. Selective Flooding . . . . . . . . . . . . . . . . . . . 25 105 E.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 Appendix F. Information Distribution Module in ANI . . . . . . . 27 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 In an autonomic network, autonomic functions (AFs) running on 112 autonomic nodes constantly exchange information, e.g. AF control/ 113 management signaling or AF data exchange. This document discusses 114 the information distribution capability of such exchanges between 115 AFs. 117 Depending on the number of participants, the information can be 118 distributed in in the following scenarios: 120 1) Point-to-point (P2P) Communication: information is exchanged 121 between parties, i.e. two nodes. 123 2) One-to-Many Communication: information exchanges involve an 124 information source and multiple receivers. 126 The approaches to infrmation distribution can be mainly categorized 127 into two basic modes: 129 1) An instantaneous mode (push): a source sends the actual content 130 (e.g. control/management signaling, synchronization data and so 131 on) to all interested receiver(s) immediately. Generally, some 132 preconfiguration is required, as nodes interested in this 133 information must be already known to all nodes in the sense that 134 any receiving node must be able to decide, to which nodes this 135 data is to be sent. 137 2) An asynchronous mode (delayed pull): here, a source publishes the 138 content in some form in the network, which may later be looked 139 for, found and retrieved by some endpoints in the AN. Here, 140 depending on the size of the content, either the whole content or 141 only its metadata might be published into the AN. In the latter 142 case the metadata (e.g. a content descriptor, e.g. a key, and a 143 location in the ANI) may be used for the actual retrieval. 144 Importantly, the source, i.e. here publisher, needs to be able to 145 determine the node, where the information (or its metadata) can be 146 stored. 148 Note that in both cases, the total size of transferred information 149 can be larger than the payload size of a single GRASP message fitted 150 in one Synchronization and Flood message. In this situation, this 151 document also considers a case of bulk data transfer. To avoid 152 repetitive implementations by each AF developer, this document opts 153 for a common support for information distribution implemented as a 154 basic ANI capability, therefore available to all AFs. In fact, GRASP 155 already provides part of the capabilities. 157 Regardless, an AF may still define and implement its own information 158 distribution capability. Such a capability may then be advertised 159 using the common information distribution capability defined in this 160 document. Overall, ANI nodes and AFs may decide, which of the 161 information distribution mechanisms they want to use for which type 162 of information, according to their own preferences (e.g. semantic 163 routing table, etc.) 165 This document first analyzes requirements for information 166 distribution in autonomic networks (Section 3) and then discuss the 167 relevant node behavior (Section 4). After that, the required GRASP 168 extensions are formally introduced (Section 5). 170 and relevan 172 2. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 3. Requirements for Information Distribution in ANI 180 The question of information distribution in an autonomic network can 181 be discussed through particular use cases or more generally. 182 Depending on the situation it can be quite simple or might require 183 more complex provisions. 185 Indeed, in the most general case, the information can be sent: 187 1) at once (in one or multiple packets, in one flow), 189 2) straightaway (send-and-forget), 191 3) to all nodes. 193 For the first scenario, presuming 1), 2) and 3) hold, information 194 distribution in smaller or scarce topologies can be implemented using 195 broadcast, i.e. unconstrained flooding. For reasons well-understood, 196 this approach has its limits in larger and denser networks. In this 197 case, a graph can be constructed such that it contains every node 198 exactly once (e.g. a spanning tree), still allowing to distribute any 199 information to all nodes straightaway. Multicast tree construction 200 protocols could be used in this case. There are reasonable use cases 201 for such scenarios, as presented in Appendix E. 203 Secondly, a more complex scenario arises, if only 1) and 2) hold, but 204 the information only concerns a subset of nodes. Then, some kinds of 205 selection become required, to which nodes the given information 206 should be distributed. Here, a further distinction is necessary; 207 notably, if the selection of the target nodes is with respect to the 208 nature or position of the node, or whether it is with respect to the 209 information content. If the first, some knowledge about the node 210 types, its topological position, etc (e.g. the routing information 211 within ANI) can be used to distinguish nodes accordingly. For 212 instance, edge nodes and forwarding nodes can be distinguished in 213 this way. If the distribution scope is primarily to be defined by 214 the information elements, then a registration / join / subscription 215 or label distribution mechanism is unavoidable. This would be the 216 case, for instance, if the AFs can be dynamically deployed on nodes, 217 and the information is majorily destined to the AFs. Then, depending 218 on the current AF deployment, the distribution scope must be adjusted 219 as well. 221 Thirdly, if only 1) holds, but the information content might be 222 required again and again, or might not yet be fully available, then 223 more complex mechanisms might be required to store the information 224 within the network for later, for further redistribution, and for 225 notification of interested nodes. Examples for this include 226 distribution of reconfiguration information for different AF 227 instances, which might not require an immediate action, but only an 228 eventual update of the parameters. Also, in some situations, there 229 could be a significant delay between the occurrence of a new event 230 and the full content availability (e.g. if the processing requires a 231 lot of time). 233 Finally, none of the three might hold. Then, along with the 234 subscription and notification, the actual content might be different 235 from its metadata, i.e. some descriptions of the content and, 236 possibly, its location. The fetching can then be implemented in 237 different, appropriate ways, if necessary as a complex transport 238 session. 240 In essence, as flooding is usually not an option, and the interest of 241 nodes for particular information elements can change over time, ANI 242 should support autonomics also for the information distribution. 244 This calls for autonomic mechanisms in the ANI, allowing 245 participating nodes to 1) advertise/publish, 2) look for/subscribe to 246 3) store, 4) fetch/retrieve and 5) instantaneously push data 247 information. 249 In the following cases, situations depicting complicated ways of 250 information distribution are discussed. 252 1) Long Communication Intervals. The actual sending of the 253 information is not necessarily instantaneous with some events. 254 Sophisticated AFs may involve into longer jobs/tasks (e.g. 255 database lookup, validations, etc.) when processing requests, and 256 might not be able to reply immediately. Instead of actively 257 waiting for the reply, a better way for an interested AF might be 258 to get notified, when the reply is finally available. 260 2) Common Interest Distribution. AFs may share information that is a 261 common interest. For example, the network intent will be 262 distributed to network nodes enrolled, which is usually one-to- 263 many scenario. Intent distribution can also be performed by an 264 instant flooding (e.g. via GRASP) to every network node. However, 265 because of network changes, not every node can be just ready at 266 the moment when the network intent is broadcast. Also, a flooding 267 often does not cover all network nodes as there is usually a 268 limitation on the hop number. In fact, nodes may join in the 269 network sequentially. In this situation, an asynchronous 270 communication model could be a better choice where every (newly 271 joining) node can subscribe the intent information and will get 272 notified if it is ready (or updated). 274 3) Distributed Coordination. With computing and storage resources on 275 autonomic nodes, alive AFs not only consume but also generate data 276 information. An example is AFs coordinating with each other as 277 distributed schedulers, responding to service requests and 278 distributing tasks. It is critical for those AFs to make correct 279 decisions based on local information, which might be asymmetric as 280 well. AFs may also need synthetic/aggregated data information 281 (e.g. statistic info, like average values of several AFs, etc.) 282 to make decisions. In these situations, AFs will need an 283 efficient way to form a global view of the network (e.g. about 284 resource consumption, bandwidth and statistics). Obviously, 285 purely relying on instant communication model is inefficient, 286 while a scalable, common, yet distributed data layer, on which AFs 287 can store and share information in an asynchronous way, should be 288 a better choice. 290 Therefore, for ANI, in order to support various communication 291 scenarios, an information distribution module is required, and both 292 instantaneous and asynchronous communication models should be 293 supported. Some real-world use cases are introduced in Appendix E. 295 4. Node Behaviors 297 In this section, how a node should behave in order to support the two 298 identified modes of information distribution is discussed. An ANI is 299 a distributed system, so the information distribution module must be 300 implemented in a distributed way as well. 302 4.1. Instant Information Distribution (IID) Sub-module 304 In this case, an information sender directly specifies the 305 information receiver(s). The instant information distribution sub- 306 module will be the main element. 308 4.1.1. Instant P2P Communication 310 IID sub-module performs instant information transmission for ASAs 311 running in an ANI. In specific, IID sub-module will have to retrieve 312 the address of the information receiver specified by an ASA, then 313 deliver the information to the receiver. Such a delivery can be done 314 either in a connectionless or a connection-oriented way. 316 Current GRASP provides the capability to support instant P2P 317 synchronization for ASAs. A P2P synchronization is a use case of P2P 318 information transmission. However, as mentioned in Section 3, there 319 are some scenarios where one node needs to transmit some information 320 to another node(s). This is different to synchronization because 321 after transmitting the information, the local status of the 322 information does not have to be the same as the information sent to 323 the receiver. This is not directly support by existing GRASP. 325 4.1.2. Instant Flooding Communication 327 IID sub-module finishes instant flooding for ASAs in an ANI. Instant 328 flooding is for all ASAs in an ANI. An information sender has to 329 specify a special destination address of the information and 330 broadcast to all interfaces to its neighbors. When another IID sub- 331 module receives such a broadcast, after checking its TTL, it further 332 broadcast the message to the neighbors. In order to avoid flooding 333 storms in an ANI, usually a TTL number is specified, so that after a 334 pre-defined limit, the flooding message will not be further broadcast 335 again. 337 In order to avoid unnecessary flooding, a selective flooding can be 338 done where an information sender wants to send information to 339 multiple receivers at once. When doing this, sending information 340 needs to contain criteria to judge on which interfaces the 341 distributed information should and should not be sent. Specifically, 342 the criteria contain: 344 o Matching Condition: a set of matching rules such as addresses of 345 recipients, node features and so on. 347 o Matching object: the object that the match condition would be 348 applied to. For example, the matching object could be node itself 349 or its neighbors. 351 o Action: what the node needs to do when the Matching Condition is 352 fulfilled. For example, the action could be forwarding or 353 discarding the distributed message. 355 Sent information must be included in the message distributed from the 356 sender. The receiving node reacts by first checking the carried 357 Matching Condition in the message to decide who should consume the 358 message, which could be either the node itself, some neighbors or 359 both. If the node itself is a recipient, Action field is followed; 360 if a neighbor is a recipient, the message is sent accordingly. 362 An exemplary extension to support selective flooding on GRASP is 363 described in Section 5. 365 4.2. Asynchronous Information Distribution (AID) Sub-module 367 In asynchronous information distribution, sender(s) and receiver(s) 368 are not immediately specified while they may appear in an 369 asynchronous way. Firstly, AID sub-module enables that the 370 information can be stored in the network; secondly, AID sub-module 371 provides an information publication and subscription (Pub/Sub) 372 mechanism for ASAs. 374 As sketched in the previous section, in general each node requires 375 two modules: 1) Information Storage (IS) module and 2) Event Queue 376 (EQ) module in the information distribution module. Details of the 377 two modules are described in the following sections. 379 4.2.1. Information Storage 381 IS module handles how to save and retrieve information for ASAs 382 across the network. The IS module uses a syntax to index 383 information, generating the hash index value (e.g. a hash value) of 384 the information and mapping the hash index to a certain node in ANI. 385 Note that, this mechanism can use existing solutions. Specifically, 386 storing information in an ANIMA network will be realized in the 387 following steps. 389 1) ASA-to-IS Negotiation. An ASA calls the API provided by 390 information distribution module (directly supported by IS sub- 391 module) to request to store the information somewhere in the 392 network. The IS module performs various checks of the request 393 (e.g. permitted information size). 395 2) Storing Peer Mapping. The information block will be handled by 396 the IS module in order to calculate/map to a peer node in the 397 network. Since ANIMA network is a peer-to-peer network, a typical 398 way is to use distributed hash table (DHT) to map information to a 399 unique index identifier. For example, if the size of the 400 information is reasonable, the information block itself can be 401 hashed, otherwise, some meta-data of the information block can be 402 used to generate the mapping. 404 3) Storing Peer Negotiation Request. Negotiation request of storing 405 the information will be sent from the IS module to the IS module 406 on the destination node. The negotiation request contains 407 parameters about the information block from the source IS module. 408 According to the parameters as well as the local available 409 resource, the requested storing peer will send feedback the source 410 IS module. 412 4) Storing Peer Negotiation Response. Negotiation response from the 413 storing peer is sent back to the source IS module. If the source 414 IS module gets confirmation that the information can be stored, 415 source IS module will prepare to transfer the information block; 416 otherwise, a new storing peer must be discovered (i.e. going to 417 step 7). 419 5) Information Block Transfer. Before sending the information block 420 to the storing peer that already accepts the request, the IS 421 module of the source node will check if the information block can 422 be afforded by one GRASP message. If so, the information block 423 will be directly sent by calling a GRASP API 424 ([I-D.ietf-anima-grasp-api]). Otherwise, a bulk data transmission 425 is needed. For that, there are multiple ways to do it. The first 426 option is to utilize one of existing protocols that is independent 427 of the GRASP stack. For example, a session connectivity can be 428 established to the storing peer, and over the connection the bulky 429 data can be transmitted part by part. In this case, the IS module 430 should support basic TCP-based session protocols such as HTTP(s) 431 or native TCP. The second option is to directly use GRASP itself 432 for bulky data transferring [I-D.carpenter-anima-grasp-bulk]. 434 6) Information Writing. Once the information block (or a smaller 435 block) is received, the IS module of the storing peer will store 436 the data block in the local storage is accessible. 438 7) (Optional) New Storing Peer Discovery. If the previously selected 439 storing peer is not available to store the information block, the 440 source IS module will have to identify a new destination node to 441 start a new negotiation. In this case, the discovery can be done 442 by using discovery GRASP API to identify a new candidate, or more 443 complex mechanisms can be introduced. 445 Similarly, Getting information from an ANI will be realized in the 446 following steps. 448 1) ASA-to-IS Request. An ASA accesses the IS module via the APIs 449 exposed by the information distribution module. The key/index of 450 the interested information will be sent to the IS module. An 451 assumption here is that the key/index should be known to an ASA 452 before an ASA can ask for the information. This relates to the 453 publishing/subscribing of the information, which are handled by 454 other modules (e.g. Event Queue with Pub/Sub supported by GRASP). 456 2) Storing Peer Mapping. IS module maps the key/index of the 457 requested information to a peer that stores the information, and 458 prepares the information request. The mapping here follows the 459 same mechanism when the information is stored. 461 3) Retrieval Negotiation Request. The source IS module sends a 462 request to the storing peer and asks if such an information object 463 is available. 465 4) Retrieval Negotiation Response. The storing peer checks the key/ 466 index of the information in the request, and replies to the source 467 IS module. If the information is found and the information block 468 can be afforded within one GRASP message, the information will be 469 sent together with the response to the source IS module. 471 5) (Optional) New Destination Request. If the information is not 472 found after the source IS module gets the response from the 473 originally identified storing peer, the source IS module will have 474 to discover the location of the requested information. 476 IS module can reuse distributed databases and key value stores like 477 NoSQL, Cassandra, DHT technologies. storage and retrieval of 478 information are all event-driven responsible by the EQ module. 480 4.2.2. Event Queue 482 The Event Queue (EQ) module is to help ASAs to publish information to 483 the network and subscribe to interested information in asynchronous 484 scenarios. In an ANI, information generated on network nodes is an 485 event labeled with an event ID, which is semantically related to the 486 topic of the information. Key features of EQ module are summarized 487 as follows. 489 1) Event Group: An EQ module provides isolated queues for different 490 event groups. If two groups of AFs could have completely 491 different purposes, the EQ module allows to create multiple queues 492 where only AFs interested in the same topic will be aware of the 493 corresponding event queue. 495 2) Event Prioritization: Events can have different priorities in ANI. 496 This corresponds to how much important or urgent the event 497 implies. Some of them are more urgent than regular ones. 498 Prioritization allows AFs to differentiate events (i.e. 499 information) they publish or subscribe to. 501 3) Event Matching: an information consumer has to be identified from 502 the queue in order to deliver the information from the provider. 503 Event matching keeps looking for the subscriptions in the queue to 504 see if there is an exact published event there. Whenever a match 505 is found, it will notify the upper layer to inform the 506 corresponding ASAs who are the information provider and 507 subscriber(s) respectively. 509 The EQ module on every network node operates as follows. 511 1) Event ID Generation: If information of an ASA is ready, an event 512 ID is generated according to the content of the information. This 513 is also related to how the information is stored/saved by the IS 514 module introduced before. Meanwhile, the type of the event is 515 also specified where it can be of control purpose or user plane 516 data. 518 2) Priority Specification: According to the type of the event, the 519 ASA may specify its priority to say how this event is to be 520 processed. By considering both aspects, the priority of the event 521 will be determined. 523 3) Event Enqueue: Given the event ID, event group and its priority, a 524 queue is identified locally if all criteria can be satisfied. If 525 there is such a queue, the event will be simply added into the 526 queue, otherwise a new queue will be created to accommodate such 527 an event. 529 4) Event Propagation: The published event will be propagated to the 530 other network nodes in the ANIMA domain. A propagation algorithm 531 can be employed to optimize the propagation efficiency of the 532 updated event queue states. 534 5) Event Match and Notification: While propagating updated event 535 states, EQ module in parallel keeps matching published events and 536 its interested consumers. Once a match is found, the provider and 537 subscriber(s) will be notified for final information retrieval. 539 The category of event priority is defined as the following. In 540 general, there are two event types: 542 1) Network Control Event: This type of events are defined by the ANI 543 for operational purposes on network control. A pre-defined 544 priority levels for required system messages is suggested. For 545 highest level to lowest level, the priority value ranges from 546 NC_PRIOR_HIGH to NC_PRIOR_LOW as integer values. The NC_PRIOR_* 547 values will be defined later according to the total number system 548 events required by the ANI. 550 2) Custom ASA Event: This type of events are defined by the ASAs of 551 users. This specifies the priority of the message within a group 552 of ASAs, therefore it is only effective among ASAs that join the 553 same message group. Within the message group, a group header/ 554 leader has to define a list of priority levels ranging from 555 CUST_PRIOR_HIGH to CUST_PRIOR_LOW. Such a definition completely 556 depends on the individual purposes of the message group. When a 557 system message is delivered, its event type and event priority 558 value have to be both specified. 560 Event contains the address where the information is stored, after a 561 subscriber is notified, it directly retrieves the information from 562 the given location. 564 4.3. Bulk Information Transfer 566 In both cases discussed previously, they are limited to distributing 567 GRASP Objective Options contained in messages that cannot exceed the 568 GRASP maximum message size of 2048 bytes. This places a limit on the 569 size of data that can be transferred directly in a GRASP message such 570 as a Synchronization or Flood operation for instantaneous information 571 distribution. 573 There are scenarios in autonomic networks where this restriction is a 574 problem. One example is the distribution of network policy in 575 lengthy formats such as YANG or JSON. Another case might be an 576 Autonomic Service Agent (ASA) uploading a log file to the Network 577 Operations Center (NOC). A third case might be a supervisory system 578 downloading a software upgrade to an autonomic node. A related case 579 might be installing the code of a new or updated ASA to a target 580 node. 582 Naturally, an existing solution such as a secure file transfer 583 protocol or secure HTTP might be used for this. Other management 584 protocols such as syslog [RFC5424] or NETCONF [RFC6241] might also be 585 used for related purposes, or might be mapped directly over GRASP. 586 The present document, however, applies to any scenario where it is 587 preferable to re-use the autonomic networking infrastructure itself 588 to transfer a significant amount of data, rather than install and 589 configure an additional mechanism. 591 The node behavior is to use the GRASP Negotiation process to transfer 592 and acknowledge multiple blocks of data in successive negotiation 593 steps, thereby overcoming the GRASP message size limitation. The 594 emphasis is placed on simplicity rather than efficiency, high 595 throughput, or advanced functionality. For example, if a transfer 596 gets out of step or data packets are lost, the strategy is to abort 597 the transfer and try again. In an enterprise network with low bit 598 error rates, and with GRASP running over TCP, this is not considered 599 a serious issue. Clearly, a more sophisticated approach could be 600 designed but if the application requires that, existing protocols 601 could be used, as indicated in the preceding paragraph. 603 As for any GRASP operation, the two participants are considered to be 604 Autonomic Service Agents (ASAs) and they communicate using a specific 605 GRASP Objective Option, containing its own name, some flag bits, a 606 loop count, and a value. In bulk transfer, we can model the ASA 607 acting as the source of the transfer as a download server, and the 608 destination as a download client. No changes or extensions are 609 required to GRASP itself, but compared to a normal GRASP negotiation, 610 the communication pattern is slightly asymmetric: 612 1) The client first discovers the server by the GRASP discovery 613 mechanism (M_DISCOVERY and M_RESPONSE messages). 615 2) The client then sends a GRASP negotiation request (M_REQ_NEG 616 message). The value of the objective expresses the requested item 617 (e.g., a file name - see the next section for a detailed example). 619 3) The server replies with a negotiation step (M_NEGOTIATE message). 620 The value of the objective is the first section of the requested 621 item (e.g., the first block of the requested file as a raw byte 622 string). 624 4) The client replies with a negotiation step (M_NEGOTIATE message). 625 The value of the objective is a simple acknowledgement (e.g., the 626 text string 'ACK'). 628 The last two steps repeat until the transfer is complete. The server 629 signals the end by transferring an empty byte string as the final 630 value. In this case the client responds with a normal end to the 631 negotiation (M_END message with an O_ACCEPT option). 633 Errors of any kind are handled with the normal GRASP mechanisms, in 634 particular by an M_END message with an O_DECLINE option in either 635 direction. In this case the GRASP session terminates. It is then 636 the client's choice whether to retry the operation from the start, as 637 a new GRASP session, or to abandon the transfer. The block size must 638 be chosen such that each step does not exceed the GRASP message size 639 limit of 2048 bits. 641 GRASP bulk transport function doesn't require new GRASP messages/ 642 options (as specified in Section 5) to be difined. An implementation 643 example is given in Appendix D.1 . 645 4.4. Summary 647 In summary, the general requirements for the information distribution 648 module on each autonomic node are realized by two sub-modules 649 handling instant communications and asynchronous communications, 650 respectively. For instantaneous mode, node requirements are simple, 651 calling for support for additional signaling. With minimum efforts, 652 reusing the existing GRASP is possible. 654 For asynchronous mode, information distribution module uses new 655 primitives on the wire, and implements an event queue and an 656 information storage mechanism. An architectural consideration on ANI 657 with the information distribution module is briefly discussed in 658 Appendix F. 660 In both cases, a scenario of bulk information transfer is considered 661 where the retrieved information cannot be fitted in one GRASP 662 message. Based on GRASP Negotiation operation, multiple 663 transmissions can be repeatedly done in order to transfer bulk 664 informtion piece by piece. 666 5. Extending GRASP for Information Distribution 668 5.1. New M_UNSOLIDSYNCH message for Instant P2P Transmission 670 This could be a new message in GRASP. In fragmentary CDDL, an Un- 671 solicited Synchronization message follows the pattern: 673 unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, 674 objective] 676 A node MAY actively send a unicast Un-solicited Synchronization 677 message with the Synchronization data, to another node. This MAY be 678 sent to port GRASP_LISTEN_PORT at the destination address, which 679 might be obtained by GRASP Discovery or other possible ways. The 680 synchronization data are in the form of GRASP Option(s) for specific 681 synchronization objective(s). 683 5.2. New O_SELECTIVE_FLOOD option for Selective Flooding 685 Since normal flooding is already supported by GRASP, this section 686 only defines the selective flooding extension. 688 In fragmentary CDDL, the selective flooding follows the pattern: 690 selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, 691 match-object, action] 693 O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] 694 Obj1 = text 696 match-rule = GREATER / LESS / WITHIN / CONTAIN 698 Obj2 = text 700 match-object = NEIGHBOR / SELF 702 action = FORWARD / DROP 704 The option field encapsulates a match-condition option which 705 represents the conditions regarding to continue or discontinue flood 706 the current message. For the match-condition option, the Obj1 and 707 Obj2 are to objects that need to be compared. For example, the Obj1 708 could be the role of the device and Obj2 could be "RSG". The match 709 rules between the two objects could be greater, less than, within, or 710 contain. The match-object represents of which Obj1 belongs to, it 711 could be the device itself or the neighbor(s) intended to be flooded. 712 The action means, when the match rule applies, the current device 713 just continues flood or discontinues. 715 Some exaples of specific O_SELECTIVE_FLOOD option definitions 716 according to some use cases, are described in Appendix E.3 . 718 5.3. New O_SUBSCRIPTION Objective Option 720 In fragmentary CDDL, a Subscription Objective Option follows the 721 pattern: 723 subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] 724 objective-name = SUBSCRIPTION 726 objective-flags = 2 728 loop-count = 2 730 subobj = text 732 This option MAY be included in GRASP M_Synchronization, when 733 included, it means this message is for a subscription to a specific 734 object. 736 5.4. New O_UNSUBSCRIBE Objective Option 738 In fragmentary CDDL, a Un_Subscribe Objective Option follows the 739 pattern: 741 Unsubscribe-objection-option = [UNSUBSCRIB, 2, 2, unsubobj] 743 objective-name = SUBSCRIPTION 745 objective-flags = 2 747 loop-count = 2 749 unsubobj = text 751 This option MAY be included in GRASP M_Synchronization, when 752 included, it means this message is for a un-subscription to a 753 specific object. 755 5.5. New O_PULISH Objective Option 757 In fragmentary CDDL, a Publish Objective Option follows the pattern: 759 publish-objection-option = [PUBLISH, 2, 2, pubobj] 761 objective-name = PUBLISH 762 objective-flags = 2 764 loop-count = 2 766 pubobj = text 768 This option MAY be included in GRASP M_Synchronization, when 769 included, it means this message is for a publish of a specific object 770 data. 772 6. Security Considerations 774 The distribution source authentication could be done at multiple 775 layers: 777 o Outer layer authentication: the GRASP communication is within ACP 778 ([I-D.ietf-anima-autonomic-control-plane]). This is the default 779 GRASP behavior. 781 o Inner layer authentication: the GRASP communication might not be 782 within a protected channel, then there should be embedded 783 protection in distribution information itself. Public key 784 infrastructure might be involved in this case. 786 7. IANA Considerations 788 TBD. 790 8. Acknowledgements 792 Valuable comments were received from Michael Richardson, Roland 793 Bless, Mohamed Boucadair, Diego Lopez, Toerless Eckert, Joel Halpern 794 and other participants in the ANIMA working group. 796 This document was produced using the xml2rfc tool [RFC2629]. 798 9. References 800 9.1. Normative References 802 [I-D.ietf-anima-grasp] 803 Bormann, C., Carpenter, B., and B. Liu, "A Generic 804 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 805 grasp-15 (work in progress), July 2017. 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, 809 DOI 10.17487/RFC2119, March 1997, 810 . 812 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 813 DOI 10.17487/RFC2629, June 1999, 814 . 816 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 817 Definition Language (CDDL): A Notational Convention to 818 Express Concise Binary Object Representation (CBOR) and 819 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 820 June 2019, . 822 9.2. Informative References 824 [I-D.carpenter-anima-grasp-bulk] 825 Carpenter, B., Jiang, S., and B. Liu, "Transferring Bulk 826 Data over the GeneRic Autonomic Signaling Protocol 827 (GRASP)", draft-carpenter-anima-grasp-bulk-05 (work in 828 progress), January 2020. 830 [I-D.du-anima-an-intent] 831 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 832 Behringer, "ANIMA Intent Policy and Format", draft-du- 833 anima-an-intent-05 (work in progress), February 2017. 835 [I-D.ietf-anima-autonomic-control-plane] 836 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 837 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 838 plane-28 (work in progress), July 2020. 840 [I-D.ietf-anima-bootstrapping-keyinfra] 841 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 842 and K. Watsen, "Bootstrapping Remote Secure Key 843 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 844 keyinfra-43 (work in progress), August 2020. 846 [I-D.ietf-anima-grasp-api] 847 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 848 Autonomic Signaling Protocol Application Program Interface 849 (GRASP API)", draft-ietf-anima-grasp-api-06 (work in 850 progress), June 2020. 852 [I-D.ietf-anima-reference-model] 853 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 854 and J. Nobre, "A Reference Model for Autonomic 855 Networking", draft-ietf-anima-reference-model-10 (work in 856 progress), November 2018. 858 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 859 DOI 10.17487/RFC5424, March 2009, 860 . 862 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 863 and A. Bierman, Ed., "Network Configuration Protocol 864 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 865 . 867 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 868 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 869 Networking: Definitions and Design Goals", RFC 7575, 870 DOI 10.17487/RFC7575, June 2015, 871 . 873 Appendix A. Open Issues [RFC Editor: To Be removed before becoming RFC] 875 1. More reference to the use cases in the introduction. 877 2. Better explanation of the required context of the Connected-Car 878 case: Not applicable unless the ACP will be extended to the car, 879 which may not be desirable with the current ACP design, but maybe 880 refocussing on an "autonomous fleet" use-case (e.g.: all cars 881 operated by some taxi like service). 883 3. Consider use-case/example of firmware update. By abstracting the 884 location of the firmware from the name of the firmware, while 885 providing a way to notify about it, this significantly supports 886 distribution of firmware updates. References to SUIT would 887 appropriate. 889 4. Issues discussed in https://mailarchive.ietf.org/arch/msg/ 890 anima/_0fYQPBcLPt8xzQee7P4dILsn3A 892 5. Rethink/refine terminology, e.g.: "module" seems to be too 893 prescriptive. Refine proposed extensions. 895 6. Provide more protocol behavior description instead of only 896 implementation / software module architecture description. 897 Reduce the latter or provide better justification for their 898 presence due to explained interoperability requirements. 900 7. Better motivation in sections 1..4 of the proposed extensions 902 8. Consider moving examples from appendices into core-text . Ideally 903 craft a single use-case showing/applying all extensions (most 904 simple use case that uses them all). 906 9. Refine terminology to better match/reuse-the established 907 terminology from the pre-existing ANIMA documents. 909 Appendix B. Closed Issues [RFC Editor: To Be removed before becoming 910 RFC] 912 Appendix C. Change log [RFC Editor: To Be removed before becoming RFC] 914 draft-ietf-anima-grasp-distribution-01, 2020-09-01: 916 Merged some essential content of draft-carpenter-anima-grasp-bulk-05. 917 __ 919 Adjusted appendix structure and content. 921 draft-ietf-anima-grasp-distribution-00, 2020-02-25: 923 File name changed following WG adoption. 925 __Added appendix A&B for open/closed issues. The open issues were 926 comments received during the adoption call. 928 Appendix D. Implementation Examples and Considerations 930 D.1. GRASP Bulk Transport 932 Example for file transfer: this example describes a client ASA 933 requesting a file download from a server ASA. 935 Firstly we define a GRASP objective informally: ["411:mvFile", 3, 6, 936 value] 938 The formal CDDL definition [RFC8610] is: 940 o mvfile-objective = ["411:mvFile", objective-flags, loop-count, 941 value] 943 o objective-flags = ; as in the GRASP specification loop-count = ; 944 as in the GRASP specification value = any 946 The objective-flags field is set to indicate negotiation. Dry run 947 mode must not be used. The loop-count is set to a suitable value to 948 limit the scope of discovery. A suggested default value is 6. 950 The value takes the following forms: 952 o In the initial request from the client, a UTF-8 string containing 953 the requested file name (with file path if appropriate). 955 o In negotiation steps from the server, a byte string containing at 956 most 1024 bytes. However: 958 * If the file does not exist, the first negotiation step will 959 return an M_END, O_DECLINE response. 961 * After sending the last block, the next and final negotiation 962 step will send an empty byte string as the value. 964 o In negotiation steps from the client, the value is the UTF-8 965 string 'ACK'. 967 Note that the block size of 1024 is chosen to guarantee not only that 968 each GRASP message is below the size limit, but also that only one 969 TCP data packet will be needed, even on an IPv6 network with a 970 minimum link MTU. 972 We now present outline pseudocode for the client and the server ASA. 973 The API documented in [I-D.ietf-anima-grasp-api] is used in a 974 simplified way, and error handling is not shown in detail. 976 Pseudo code for client ASA (request and receive a file): 978 requested_obj = objective('411:mvFile') 979 locator = discover(requested_obj) 980 requested_obj.value = 'etc/test.json' 981 received_obj = request_negotiate(requested_obj, locator) 982 if error_code == declined: 983 #no such file 984 exit 986 file = open(requested_obj.value) 987 file.write(received_obj.value) #write to file 988 eof = False 989 while not eof: 990 received_obj.value = 'ACK' 991 received_obj.loop_count = received_obj.loop_count + 1 992 received_obj = negotiate_step(received_obj) 993 if received_obj.value == null: 994 end_negotiate(True) 995 file.close() 996 eof = True 997 else: 998 file.write(received_obj.value) #write to file 1000 #file received 1001 exit 1003 Pseudo code for server ASA (await request and send a file): 1005 supported_obj = objective('411:mvFile') 1006 requested_obj = listen_negotiate(supported_obj) 1007 file = open(requested_obj.value) #open the source file 1008 if no such file: 1009 end_negotiate(False) #decline negotiation 1010 exit 1012 eof = False 1013 while not eof: 1014 chunk = file.read(1024) #next block of file 1015 requested_obj.value = chunk 1016 requested_obj.loop_count = requested_obj.loop_count + 1 1017 requested_obj = negotiate_step(requested_obj) 1018 if chunk == null: 1019 file.close() 1020 eof = True 1021 end_negotiate(True) 1022 exit 1023 if requested_obj.value != 'ACK': 1024 #unexpected reply... 1026 D.2. Asynchronous ID Integrated with GRASP APIs 1028 Actions triggered to the information distribution module will 1029 eventually invoke underlying GRASP APIs. Moreover, EQ and IS modules 1030 are usually correlated. When an AF(ASA) publishes information, not 1031 only such an event is translated and sent to EQ module, but also the 1032 information is indexed and stored simultaneously. Similarly, when an 1033 AF(ASA) subscribes information, not only subscribing event is 1034 triggered and sent to EQ module, but also the information will be 1035 retrieved by IS module at the same time. 1037 o Storing and publishing information: This action involves both IS 1038 and EQ modules where a node that can store the information will be 1039 discovered first and related event will e published to the 1040 network. For this, GRASP APIs discover(), synchronize() and 1041 flood() are combined to compose such a procedure. In specific, 1042 discover() call will specific its objective being to "store_data" 1043 and the return parameters could be either an ASA_locator who will 1044 accept to store the data, or an error code indicating that no one 1045 could afford such data; after that, synchronize() call will send 1046 the data to the specified ASA_locator and the data will be stored 1047 at that node, with return of processing results like 1048 store_data_ack; meanwhile, such a successful event (i.e. data is 1049 stored successfully) will be flooded via a flood() call to 1050 interesting parties (such a multicast group existed). 1052 o Subscribing and getting information: This action involves both IS 1053 and EQ modules as well where a node that is interested in a topic 1054 will subscribe the topic by triggering EQ module and if the topic 1055 is ready IS module will retrieve the content of the topic (i.e. 1056 the data). GRASP APIs such as register_objective(), flood(), 1057 synchronize() are combined to compose the procedure. In specific, 1058 any subscription action received by EQ module will be translated 1059 to register_objective() call where the interested topic will be 1060 the parameter inside of the call; the registration will be 1061 (selectively) flooded to the network by an API call of flood() 1062 with the option we extended in this draft; once a matched topic is 1063 found (because of the previous procedure), the node finding such a 1064 match will call API synchronize() to send the stored data to the 1065 subscriber. 1067 Appendix E. Real-world Use Cases of Information Distribution 1069 The requirement analysis in Section 3 shows that generally 1070 information distribution should be better of as an infrastructure 1071 layer module, which provides to upper layer utilizations. In this 1072 section, we review some use cases from the real-world where an 1073 information distribution module with powerful functions do plays a 1074 critical role there. 1076 E.1. Pub/Sub in 3GPP 5G Networks 1078 In addition to Internet, the telecommunication network (i.e. carrier 1079 mobile wireless networks) is another world-wide networking system. 1080 The architecture of the 5G mobile networks from 3GPP has been defined 1081 to follow a service-based architecture (SBA) where any network 1082 function (NF) can be dynamically associated with any other NF(s) when 1083 needed to compose a network service. Note that one NF can 1084 simultaneously associate with multiple other NFs, instead of being 1085 physically wired as in the previous generations of mobile networks. 1086 NFs communicate with each other over service-based interface (SBI), 1087 which is also standardized by 3GPP [3GPP.23.501]. 1089 In order to realize an SBA network system, detailed requirements are 1090 further defined to specify how NFs should interact with each other 1091 with information exchange over the SBI. We now list three 1092 requirements that are related to information distribution here. 1094 1) NF Pub/Sub: Any NF should be able to expose its service status to 1095 the network and any NF should be able to subscribe the service 1096 status of an NF and get notified if the status is available. A 1097 concrete example is that a session management function (SMF) can 1098 subscribe to the REGISTER notification from an access management 1099 function (AMF) if there is a new user equipment trying to access 1100 the mobile network [3GPP.23.502]. 1102 2) Network Exposure Function (NEF): A particular network function 1103 that is required to manage the event exposure and distributions. 1104 Specifically, SBA requires such a functionality to register 1105 network events from the other NFs (e.g. AMF, SMF and so on), 1106 classify the events and properly handle event distributions 1107 accordingly in terms of different criteria (e.g. priorities) 1108 [3GPP.23.502]. 1110 3) Network Repository Function (NRF): A particular network function 1111 where all service status information is stored for the whole 1112 network. An SBA network system requires all NFs to be stateless 1113 so as to improve the resilience as well as agility of providing 1114 network services. Therefore, the information of the available NFs 1115 and the service status generated by those NFs will be globally 1116 stored in NRF as a repository of the system. This clearly implies 1117 storage capability that keeps the information in the network and 1118 provides those information when needed. A concrete example is 1119 that whenever a new NF comes up, it first of all registers itself 1120 at NRF with its profile. When a network service requires a 1121 certain NF, it first inquires NRF to retrieve the availability 1122 information and decides whether or not there is an available NF or 1123 a new NF must be instantiated [3GPP.23.502]. 1125 (Note: 3GPP CT adopted HTTP2.0/JSON to be the protocol communicating 1126 between NFs, but autonomic networks can also load HTTP2.0 within 1127 ACP.) 1129 E.2. Event Queue/Storage in Vehicle-to-Everything (V2X) 1131 Connected car is one of scenarios interested in automotive 1132 manufacturers, carriers and vendors. 5G Automotive Alliance - an 1133 industry collaboration organization defines many promising use cases 1134 where services from car industry should be supported by the 5G mobile 1135 network. Here we list two examples as follows [5GAA.use.cases]. 1137 1) Software/Firmware Update: Car manufacturers expect that the 1138 software/firmware of their car products can be remotely updated/ 1139 upgraded via 5G network, instead of onsite visiting their 4S 1140 stores/dealers offline as nowadays. This requires the network to 1141 provide a mechanism for vehicles to receive the latest software 1142 updates during a certain period of time. In order to run such a 1143 service for a car manufacturer, the network shall not be just like 1144 a network pipe anymore. Instead, information data have to be 1145 stored in the network, and delivered in a publishing/subscribing 1146 fashion. For example, the latest release of a software will be 1147 first distributed and stored at the access edges of the mobile 1148 network, after that, the updates can be pushed by the car 1149 manufacturer or pulled by the car owner as needed. 1151 2) Real-time HD Maps: Autonomous driving clearly requires much finer 1152 details of road maps. Finer details not only include the details 1153 of just static road and streets, but also real-time information on 1154 the road as well as the driving area for both local urgent 1155 situations and intelligent driving scheduling. This asks for 1156 situational awareness at critical road segments in cases of 1157 changing road conditions. Clearly, a huge amount of traffic data 1158 that are real-time collected will have to be stored and shared 1159 across the network. This clearly requires the storage capability, 1160 data synchronization and event notifications in urgent cases from 1161 the network, which are still missing at the infrastructure layer. 1163 E.3. Selective Flooding 1165 Example 1: Selected flooding in hierarchical network: 1167 o E.g. IPRAN network, which is normally highly hierarchical: large 1168 amount of access gateways (CSG) at the low layer, but limited 1169 aggregation gateways (ASG) and core network gateways (RSG) at the 1170 upper layer. 1172 o Some information is not necessary to flood to the CSGs. (E.g. a 1173 network policy of VPN mechanisms selection) 1175 In this case, the Selective Flooding Criteria could be defined as: 1177 o Matching condition: Role=RSG or ASG 1179 o Matching object: Neighbor devices 1181 o Action: 1183 * If the one neighbor device's "Role" matches the Matching 1184 Condition, which is "RSG or ASG", then the node would forward 1185 the message to that neighbor. 1187 * If not, then the node would discard the message for that 1188 neighbor. 1190 Example 2: Selected flooding within a deterministic path: 1192 o E.g. flood within a MPLS LSP 1194 o The LSP has been set up 1196 o One node distributes the information to all the LSRs of the LSP. 1197 (e.g. adjust the reserved bandwidth) 1199 In this case, the Selective Flooding Criteria could be defined as: 1201 o Matching condition: vpn-instance=WCDMA-VPN 1203 o Matching object: interfaces 1205 o Action: 1207 * If the interface's "vpn-instance" matches the Matching 1208 Condition, which is "WCDMA-VPN", then the node would forward 1209 the message to that interface. 1211 * If not, then the node would discard the message for that 1212 interface. 1214 Example 3: Selected flooding for ACP set up: 1216 o ACP topology should align with the physical topology as much as 1217 possible 1219 o An Anima-Enabled switch should not forwarding the ACP discovery to 1220 the nodes attached to it 1222 In this case, the Selective Flooding Criteria could be defined as: 1224 o Matching condition: Role=switch 1226 o Matching object: self 1228 o Action: 1230 * If the "Role" of the node itself matches the Matching 1231 Condition, which is "switch", then the node would discard the 1232 message. 1234 * If not, then the node would continue the flood. 1236 E.4. Summary 1238 Through the general analysis and the concrete examples from the real- 1239 world, we realize that the ways information are exchanged in the 1240 coming new scenarios are not just short and instant anymore. More 1241 advanced as well as diverse information distribution capabilities are 1242 required and should be generically supported from the infrastructure 1243 layer. Upper layer applications (e.g. ASAs in ANIMA) access and 1244 utilize such a unified mechanism for their own services. 1246 Appendix F. Information Distribution Module in ANI 1248 This appendix describes how the information distribution module fits 1249 into the ANI and what extensions of GRASP are required. 1251 (preamble) 1253 +-------------------+ 1254 | ASAs | 1255 +-------------------+ 1256 ^ 1257 | 1258 v 1259 +-------------Info-Dist. APIs--------------+ 1260 | +---------------+ +--------------------+ | 1261 | | Instant Dist. | | Asynchronous Dist. | | 1262 | +---------------+ +--------------------+ | 1263 +------------------------------------------+ 1264 ^ 1265 | 1266 v 1267 +---GRASP APIs----+ 1268 | ACP | 1269 +-----------------+ 1271 Figure E.1 Information Distribution Module and GRASP Extension. 1273 As the Fig 1 shows, the information distribution module two sub- 1274 modules for instant and asynchronous information distributions, 1275 respectively, and provides APIs to ASAs. Specific Behaviors of 1276 modules are described in Section 5. 1278 Authors' Addresses 1280 Bing Liu 1281 Huawei Technologies 1282 Q5, Huawei Campus 1283 No.156 Beiqing Road 1284 Hai-Dian District, Beijing 100095 1285 P.R. China 1287 Email: leo.liubing@huawei.com 1289 Xun Xiao 1290 MRC, Huawei Technologies 1291 German Research Center 1292 Huawei Technologies 1293 Riesstr. 25 1294 Muenchen 80992 1295 Germany 1297 Email: xun.xiao@huawei.com 1298 Artur Hecker 1299 MRC, Huawei Technologies 1300 German Research Center 1301 Huawei Technologies 1302 Riesstr. 25 1303 Muenchen 80992 1304 Germany 1306 Email: artur.hecker@huawei.com 1308 Sheng Jiang 1309 Huawei Technologies 1310 Q27, Huawei Campus 1311 No.156 Beiqing Road 1312 Hai-Dian District, Beijing 100095 1313 P.R. China 1315 Email: jiangsheng@huawei.com 1317 Zoran Despotovic 1318 MRC, Huawei Technologies 1319 German Research Center 1320 Huawei Technologies 1321 Riesstr. 25 1322 Muenchen 80992 1323 Germany 1325 Email: zoran.despotovic@huawei.com 1327 Brian E. Carpenter 1328 University of Auckland 1329 School of Computer Science 1330 PB 92019 1331 Auckland 1142 1332 New Zealand 1334 Email: brian.e.carpenter@gmail.com