Internet-Draft Information Distribution December 2024
Jiang, et al. Expires 14 June 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-anima-grasp-distribution-12
Updates:
8990 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Jiang, Ed.
BUPT
B. Liu, Ed.
Huawei Technologies
X. Xiao
Huawei Technologies
A. Hecker
Huawei Technologies
X. Zheng
Huawei Technologies

Information Distribution over GRASP

Abstract

This document specifies experimental extensions to the GRASP protocol to enable information distribution capabilities. The extension has two aspects: 1) new GRASP messages and options; 2) processing behaviors on the nodes. With these extensions, the GRASP would have following new capabilities which make it a sufficient tool for general information distribution: 1) Pub-Sub model of information processing; 2) one node can actively sending data to another, without GRASP negotiation procedures; 3) selective flooding mechanism to allow the ASAs control the flooding scope.

This document updates RFC8990, the GeneRic Autonomic Signaling Protocol (GRASP)[RFC8990].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 June 2025.

▲

Table of Contents

1. Introduction

1.1. Background

The GeneRic Autonomic Signaling Protocol (GRASP)[RFC8990] is a signalling framework and protocol for software components in controlled networks. These software components can use hop-by-hop GRASP flooding and discovery mechanisms to announce and discover services and other information amonst themselves, and GRASP unicast for end-to-end, peer-to-peer communications.

Note: GRASP defines only the messaging layer, but not transport and security. It requires a "security and transport substrate" to supplement that functionality. By specifying different substrates, GRASP deployment can be adopted to the specific requirements of the controlled network and applications. For GRASP announcements and discovery, the substrate primarily needs to provide a hop-by-hop encrypted, authenticated and and reliable flooding of GRASP messages, and for GRASP peer to peer communications it requires end-to-end connectivity between GRASP nodes, such as IP or IPv6 and encrypted, authenticated and reliable transport connections, such as TLS.

In Autonomic Networks [RFC7575], the software components are called Autonomic Service Agents (ASAs) [RFC8993], and the nodes of the controlled network are called autonomic nodes. The Autonomic Networking Infrastructure (ANI, [RFC8994], [RFC8995]) provides the substrate for GRASP through Local Device IDentity (LDevID) certificates, which are zero-touch provisioned via with Bootstrapping Remote Secure Key protocol (BRSKI) [RFC8995]. The ACP automatically establishes a hop-by-hop secured connectivity for both hop-by-hop forwarding of GRASP discovery and flood messages as well as end-to-end peer-to-peer GRASP messages.

1.2. Overview

Discovery and distribution of information via GRASP as specified in [RFC8990] is intended for instantaneous consumption: sender and receiver need to active simultaneously, with only a limited degree of caching by GRASP possible, but not guaranteed.

This document defines a series of GRASP extensions in order to support an asynchronous mode of distributing information called publishing. These extensions are defined through new GRASP messages to support asynchronous distribution and mechanisms for their corresponding processing behaviors in GRASP.

In publishing for retrieval mode, information needs to be stored on GRASP nodes and must be re-distributed on-demand. Additionally, conflict resolution is also needed when stored information is updated with information from multiple sources.

This document also outlines example classes of use cases to describe different information distribution patterns supported by this document. This is done through analysis of example existing or planned mechanisms. While the explicitly analyzed use cases might have already decided upon non-GRASP based mechanisms, future instances of the same class would in the opinion to the authors fare better with the GRASP based approach in various criteria: simpler, more flexible or more scalable.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses terminology defined in [RFC7575].

3. Analysis of Information Distribution Modes and Requirements

This section summarizes the general modes of information distribution. Then Section 3.2 describes gaps of the GRASP protocol to support these modes of information distribution.

3.1. General Modes of Information Distribution

In a network (either in an Autonomic Network or any other networks), the way of distributing information could be modeled from the following two dimensions.

One dimension is from the perspective of the information distribution participants, there are two categories as below:

1)
Point-to-point (P2P) Communication: information is exchanged between two nodes.
2)
Point-to-Multi point (P2MP) Communication: information exchanges involve one source node and multiple receiving nodes.

The other dimension is from the timing perspective, also categorized as two modes as below:

1)
Instantaneous mode: a source node sends the actual content (e.g. control/management signaling, synchronization data and so on to all interested receiver(s) immediately. Generally, some pre-configurations are required, where nodes interested in this information must be already known to all nodes because any source node must be able to decide, to which node the data is to be sent.
2)
Asynchronous mode: here, a source node publishes the content in some forms in the network, which may later be looked for, found and retrieved by some other nodes. Here, depending on the size of the content, either the whole content or only its metadata might be published into the network. In the latter case the metadata (e.g. a content descriptor, e.g. a key, and a location in the network) may be used for the actual retrieval. Importantly, the source, i.e., here as a publisher, needs to be able to determine the location, where the information (or its metadata) can be stored.

Note that in both cases, the total size of transferred information can be larger than the payload size of a single message of a used transport protocol (e.g., Synchronization and Flood messages in GRASP). This document also gives support for bulk data transfer in Section 5.3.

3.2. Gaps of Current GRASP Protocol

As most of instantaneous information distribution modes and their requirements have been met by GRASP already, asynchronous information distribution modes need new functions to be supported. In publishing for retrieval mode, information needs to be stored and re-distributed on-demand; additionally, conflict resolution is also needed when stored information is updated with information from multiple sources.

To extend GRASP to support the requirements, the necessary extensions are defined in Section 4.

4. GRASP Extensions for Information Distribution

4.1. Un-solicited Synchronization Message

In [RFC8990], GRASP message headers and options are transmitted in Concise Binary Object Representation (CBOR) [RFC8949]. They are described using Concise Data Definition Language (CDDL) [RFC8610]. In this specification, an Un-solicited Synchronization message follows the pattern, in CDDL:

unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, objective]

A node SHOULD actively send a unicast Un-solicited Synchronization message with the Synchronization data, to another node. This SHOULD be sent to port GRASP_LISTEN_PORT at the destination address, which could be obtained by GRASP Discovery or other possible ways. The synchronization data are in the form of GRASP Option(s) for specific synchronization objective(s).

4.2. Selective-Flooding Option

In CDDL, a Selective-Flooding option follows the pattern:

Selective-Flooding-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, match-object, action]

O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] Obj1 = text
match-rule = GREATER / LESS / WITHIN / CONTAIN
Obj2 = text
match-object = NEIGHBOR / SELF
action = FORWARD / DROP

The option field encapsulates a match-condition option which represents the conditions regarding to continue or discontinue flooding of the current message. For the match-condition option, the Obj1 and Obj2 are two objects that need to be compared. For example, the Obj1 could be the role of the device and Obj2 could be "PE Router". The match rules between the two objects could be greater, less than, within, or contain. The match-object represents of which Obj1 belongs to, it could be the device itself or the neighbor(s) intended to be flooded. The action means, when the match rule applies, the current device just continues flood or discontinues.

4.3. Subscription Objective Option

In CDDL, a Subscription Objective Option follows the pattern:

objective = [Subscription, 2, 2, subobj]
objective-name = Subscription
objective-flags = 2
loop-count = 2
subobj = text

This option MAY be included in GRASP M_Synchronization, when included, it means this message is for a subscription to a specific object.

4.4. Unsubscription Objective Option

In fragmentary CDDL, a Unsubscription Objective Option follows the pattern:

objective = [Unsubscription, 2, 2, unsubobj]
objective-name = Unsubscription
objective-flags = 2
loop-count = 2
unsubobj = text

This option MAY be included in GRASP M_Synchronization, when included, it means this message is for a un-subscription to a specific object.

4.5. Publishing Objective Option

In fragmentary CDDL, a Publishing Objective Option follows the pattern:

objective = [Publishing, 2, 2, pubobj]
objective-name = Publishing
objective-flags = 2
loop-count = 2
pubobj = text

This option MAY be included in GRASP M_Synchronization, when included, it means this message is for active delivery of a specific object data.

5. Processing Behaviors on GRASP Nodes

This section defines how a GRASP node should behave in order to support the two identified modes of information distribution is discussed.

5.1. Instant Information Distribution Sub-module

In this case, an information sender directly specifies the information receiver(s). The instant information distribution sub-module will be the main element.

5.1.1. Instant P2P Communication

IID sub-module performs instant information transmission for ASAs The IID sub-module has to retrieve the address of the information receiver specified by an ASA, then deliver the information to the receiver. Such a delivery can be done either in a connectionless or a connection-oriented way.

Current GRASP provides the capability to support instant P2P synchronization for ASAs. A P2P synchronization is a use case of P2P information transmission. However, as mentioned in Section 3, there are some scenarios where one node needs to transmit some information to another node(s). This is different to synchronization because after transmitting the information, the local status of the information does not have to be the same as the information sent to the receiver. An extension to support instant P2P communication on GRASP is described in Section 4. A node could send a M_UNSOLIDSYNCH message to the GRASP_LISTEN_PORT of the corresponding node.

5.1.2. Instant Flooding Communication

IID sub-module finishes instant flooding for ASAs. Instant flooding is for all ASAs. An information sender has to specify a special destination address of the information and send to all GRASP neighbors. When those GRASP neighbors IID sub- module receives such a message, after checking its TTL, it forwards the message to its respective GRASP neighbors. In order to avoid looping, the existing GRASP session ID and TTL are used.

In order to avoid unnecessary flooding, a selective flooding can be done where an information sender wants to send information to multiple receivers at once. An exemplary extension to support selective flooding on GRASP is described in Section 4.

When doing this, sending information needs to contain criteria to judge on which interfaces the distributed information should and should not be sent. Specifically, the criteria contain:

  • O_MATCH- CONDITION in Selective-Flooding-option: matching condition, a set of matching rules such as addresses of recipients, node features and so on.

  • action in Selective-Flooding-option: what the node needs to do when the Matching Condition is fulfilled. For example, the action could be forwarding or dropping the distributed message.

Sent information must be included in the message with Selective-Flooding-option distributed from the sender. The receiving node reacts by first checking the carried O_MATCH- CONDITION in the message to decide who should consume the message, which could be either the node itself, some neighbors or both. If the node itself is a recipient, action in Selective-Flooding-option is followed; if a neighbor is a recipient, the message is sent accordingly.

5.2. Asynchronous Information Distribution (AID) Sub-module

In asynchronous information distribution, sender(s) and receiver(s) are not immediately specified while they may appear in an asynchronous way. First, the AID sub-module enables that the information can be stored in the network; second, the AID sub-module provides an information publication and subscription (Pub/Sub) mechanism for ASAs.

As sketched in the previous section, each GRASP node requires two modules: 1) Information Storage (IS) module and 2) Event Queue (EQ) module in the information distribution module. Details of the two modules are described in the following sections.

5.2.1. Information Storage

The Information Storage (IS) module handles how to save and retrieve information for ASAs across the network. It makes the index of information (e.g. by Distributed Hash Table) and maps the index to a certain GRASP node. Storing information should be realized through the following steps.

1)
ASA-to-IS Negotiation. An ASA calls the API provided by the information distribution module (directly supported by the IS sub-module) to request that the information is stored somewhere in the network. The IS module performs various checks of the request (e.g. permitted information size).
2)
Storing Peer Mapping. The information block MUST be handled by the IS module in order to calculate/map to a peer node in the network. Not all GRASP nodes may need to support storing capabilities. Specific implementation details depends on what information index mechanism (e.g. DHT as mentioned above) is employed.
3)
Storing Peer Negotiation Request. Negotiation request of storing the information MUST be sent from the IS module to the IS module on the destination node. The negotiation request contains parameters about the information block from the source IS module. According to the parameters as well as the local available resource, the requested storing peer will send feedback the source IS module.
4)
Storing Peer Negotiation Response. When Storing Peer Negotiation Request is received, a Negotiation response from the storing peer MUST be sent back to the source IS module. If the source IS module gets confirmation that the information can be stored, the source IS module will prepare to transfer the information block. Otherwise, if the Negotiation response indicates the information cannot be stored, a new storing peer MUST be discovered by the source IS module by using discovery GRASP API to identify a new candidate.
5)
Information Block Transfer. Before sending the information block to the storing peer that already accepts the request, the IS module of the source node MUST check if the information block can be afforded by one GRASP message. If so, the information block MUST be directly sent by calling a GRASP API ([RFC8991]). Otherwise, a bulk data transmission is needed. It can either utilize the Bulk Information Transfer defined in Section 5.3, or utilize one of existing protocols that is independent of the GRASP stack.
6)
Information Writing. Once the information block (or a smaller block) is received, the IS module of the storing peer MUST store the data block in the local storage.

Similarly, getting stored information should be realized in the following steps.

1)
ASA-to-IS Request. An ASA accesses the IS module via the APIs exposed by the information distribution module. The key/index of the interested information MUST be sent to the IS module. An assumption here is that the key/index should be known to an ASA before an ASA can ask for the information. This relates to the publishing/subscribing of the information, which are handled by other modules (e.g. Event Queue with Pub/Sub supported by GRASP).
2)
Storing Peer Mapping. IS module MUST map the key/index of the requested information to a peer that stores the information, and prepares the information request. The mapping here follows the same mechanism when the information is stored.
3)
Retrieval Negotiation Request. The source IS module MUST send a request to the storing peer and asks if such an information object is available.
4)
Retrieval Negotiation Response. The storing peer checks the key/index of the information in the request, and replies to the source IS module. If the information is found and the information block can be afforded within one GRASP message, the information MUST be sent together with the response to the source IS module; otherwise, a bulk data transmission is needed, which could be either the Bulk Information Transfer defined in Section 5.3, or utilize one of existing protocols that is independent of the GRASP stack. If the information is not found, the source IS module SHOULD re-discover an alternative peer which holds the requested information.

IS module can reuse distributed databases and key value stores like NoSQL, Cassandra, DHT technologies. Storage and retrieval of information are all event-driven responsible by the EQ module.

5.2.2. Event Queue

The Event Queue (EQ) module is to help ASAs to publish information to the network and subscribe/unsubscribe to interested information in asynchronous scenarios. Extensions to support information publishing, subscription and unsubscription on GRASP are described in Section 4. Information generated on GRASP nodes is an event labeled with an event ID, which is semantically related to the topic of the information. Key features of EQ module are summarized as follows.

1)
Event Group: An EQ module provides isolated queues for different event groups. If two groups of ASAs could have completely different purposes, the EQ module allows to create multiple queues where only ASAs interested in the same topic will be aware of the corresponding event queue.
2)
Event Prioritization: Events SHOULD support different priorities. This corresponds to how much important or urgent the event is. Some of them are more urgent than regular ones. Prioritization allows ASAs to differentiate events (i.e. information) they publish, subscribe or unsubscribe to.
3)
Event Matching: an information consumer has to be identified from the queue in order to deliver the information from the provider. Event matching keeps looking for the subscriptions in the queue to see if there is an exact published event there. Whenever a match is found, it will notify the upper layer to inform the corresponding ASAs who are the information provider and subscriber(s) respectively.

The EQ module on every network node operates as follows.

1)
Event ID Generation: If information of an ASA is ready, an event ID MUST be generated according to the content of the information. This is also related to how the information is stored/saved by the IS module introduced before.
2)
Priority Specification: According to the type of the event, the ASA SHOULD specify its priority to say how this event is to be processed.
3)
Event Enqueue: Given the event ID, event group and its priority, a queue MUST be identified locally if all criteria can be satisfied. The event SHOULD be added into the queue, otherwise a new queue will be created to accommodate such an event.
4)
Event Propagation: The published event MUST be propagated to the other GRASP nodes. A propagation algorithm SHOULD be employed to optimize the propagation efficiency of the updated event queue states.
5)
Event Match and Notification: While propagating updated event states, EQ module in parallel MUST keep matching published events and its interested consumers. Once a match is found, the provider and subscriber(s) MUST be notified for final information retrieval.

The category of event priority is defined as the following. In general, there are two event types:

1)
Network Control Event: This type of events is defined in support of operational purposes on network control. A pre-defined priority levels for required system messages is suggested. For highest level to lowest level, the priority value ranges from NC_PRIOR_HIGH to NC_PRIOR_LOW as integer values. The full set of intermediate NC_PRIOR_* values required is out of scope.
2)
Custom ASA Event: This type of events is defined by the ASAs of users. This specifies the priority of the message within a group of ASAs, therefore it is only effective among ASAs that join the same message group. Within the message group, a group header/leader has to define a list of priority levels ranging from CUST_PRIOR_HIGH to CUST_PRIOR_LOW. Such a definition completely depends on the individual purposes of the message group. When a system message is delivered, its event type and event priority value have to be both specified.

Event contains the address where the information is stored, after a subscriber is notified, it directly retrieves the information from the given location.

5.3. Bulk Information Transfer

Both cases discussed previously are limited to distributing messages containing GRASP Objective Options that cannot exceed the GRASP maximum message size of 2048 bytes. This places a limit on the size of data that can be transferred directly in a GRASP message such as a Synchronization or Flood operation for instantaneous information distribution.

There are scenarios where this restriction is a problem. One case is the distribution of network policy in lengthy YANG formats such as XML or JSON. Another case might be ASA uploading a log file to the Network Operations Center (NOC). A third case might be a supervisory system downloading a software upgrade to a network node. A related case might be installing the code of a new or updated ASA to a network node.

Naturally, an existing solution such as a secure file transfer protocol or secure HTTP might be used for this. Other management protocols such as syslog [RFC5424] or NETCONF [RFC6241] might also be used for related purposes, or might be mapped directly over GRASP. The present document, however, applies to any scenario where it is preferable to re-use the existing end-to-end connectivity and GRASP infrastructure to transfer a significant amount of data, rather than install and configure an additional mechanism.

The node behavior is to use the GRASP Negotiation process to transfer and acknowledge multiple blocks of data in successive negotiation steps, thereby overcoming the GRASP message size limitation. The emphasis is placed on simplicity rather than efficiency, high throughput, or advanced functionality. For example, if a transfer gets out of step or data packets are lost, the strategy is to abort the transfer and try again. In an enterprise network with low bit error rates, and with GRASP running over TCP or TLS, this is not considered a serious issue.

As for any GRASP operation, the two participants are considered to be ASA, and they communicate using a specific GRASP Objective Option, containing their own name, some flag bits, a loop count, and a value. In bulk transfer, we can model the ASA acting as the source of the transfer as a download server, and the destination as a download client. No changes or extensions are required to GRASP itself, but compared to a normal GRASP negotiation, the communication pattern is slightly asymmetric:

1)
The client first discovers the server by the GRASP discovery mechanism (M_DISCOVERY and M_RESPONSE messages).
2)
The client then sends a GRASP negotiation request (M_REQ_NEG message). The value of the objective expresses the requested item (e.g., a file name - see the next section for a detailed example).
3)
The server replies with a negotiation step (M_NEGOTIATE message). The value of the objective is the first section of the requested item (e.g., the first block of the requested file as a raw byte string).
4)
The client replies with a negotiation step (M_NEGOTIATE message). The value of the objective is a simple acknowledgement (e.g., the text string 'ACK').

The last two steps SHOULD be repeated until the transfer is complete. The server SHOULD signal the end by transferring an empty byte string as the final value. In this case the client responds with a normal end to the negotiation (M_END message with an O_ACCEPT option).

Errors of any kind SHOULD be handled with the normal GRASP mechanisms, in particular by an M_END message with an O_DECLINE option in either direction. In this case the GRASP session terminates. It is then the client's choice whether to retry the operation from the start, as a new GRASP session, or to abandon the transfer. The block size must be chosen such that each step does not exceed the GRASP message size limit of 2048 bits.

6. Security Considerations

The distribution source authentication could be done at multiple layers:

7. IANA Considerations

This document defines a new GRASP message named "M_UNSOLIDSYNCH" and a new option named "O_SELECTIVE_FLOOD" which need to be added to the "GRASP Messages and Options" registry defined by [RFC8990]. This document also defines three new GRASP Objectives, "Subscription", "Unsubscription" and "Publishing" which need to be added to the "GRASP Objective Names" table.

8. Acknowledgements

Valuable comments were received from Zoran Despotovic, Michael Richardson, Roland Bless, Mohamed Boucadair, Diego Lopez and other participants in the ANIMA working group.

This document was produced using the xml2rfc tool [RFC7991].

9. Contributors 

Brian Carpenter
School of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com

Toerless Eckert
Futurewei Technologies USA
Santa Clara, 95014
United States of America
Email: tte@cs.fau.de

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5424]
Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, , <https://www.rfc-editor.org/info/rfc5424>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[RFC8990]
Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, , <https://www.rfc-editor.org/info/rfc8990>.
[RFC8994]
Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, , <https://www.rfc-editor.org/info/rfc8994>.

10.2. Informative References

[I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-32, , <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-32>.
[RFC7575]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, , <https://www.rfc-editor.org/info/rfc7575>.
[RFC7991]
Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, , <https://www.rfc-editor.org/info/rfc7991>.
[RFC8991]
Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, "GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991, , <https://www.rfc-editor.org/info/rfc8991>.
[RFC8993]
Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, , <https://www.rfc-editor.org/info/rfc8993>.
[RFC8995]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <https://www.rfc-editor.org/info/rfc8995>.
[The-case-for-in-network-computing-on-demand]
Tokusashi, Y., "The case for in-network computing on demand", DOI 10.1109/RECONFIG.2018.8641696, , <https://ieeexplore.ieee.org/document/8641696>.

Appendix A. Asynchronous Information Distribution Integrated with GRASP APIs

Actions triggered to the information distribution module will eventually invoke an underlying GRASP APIs. Moreover, Event Queue and Instance Storage modules are usually correlated. When an ASA publishes information, not only such an event is translated and sent to EQ module, but also the information is indexed and stored simultaneously. Similarly, when an ASA subscribes information, not only subscribing event is triggered and sent to EQ module, but also the information will be retrieved by IS module at the same time.

Appendix B. Possible Use Cases

This section describes example classes of use cases where information distribution is required.

B.1. In-Network Computing (INC)

In-network computing (INC) has gained more and more attentions in recent years [The-case-for-in-network-computing-on-demand]. INC improves the utilization of the computing resources in the network; INC also brings the processed results closer to the users, which may potentially improves the QoS of network services.

Unlike existing network systems, INC deploys computing tasks directly in the network rather than pushing the tasks to endpoints outside the network. Therefore, a network device is not just a transport device, but a mixture of forwarding, routing and computing.

Proliferation of INC use cases will also make storage capability support in network devices supporting INC more ubiquitous. Furthermore, INC agents deployed on network nodes will have to communicate with each other by exchanging information. There are several typical applications, where information distribution capability is required, which are summarized below.

1)
Data Backup: There can be multiple computing agents that are created to serve the same purpose(s). Multiple agents can run for improved performance aspects such as service resilience, compute and storage distribution or lower latency access. Multiple agent form a service set. The instances in the service set can be deployed at different locations in the network while they need to keep synchronizing their local states for global consistency. In this case, the computing agents will have to constantly send and receive information across the network.
2)
Data Aggregation: Multiple computing agents may process different computing tasks but the derived results have to be aggregated or combined. Then a collective result can be derived. In this case, different computing agents collaborate with each other, where information data is exchanged during the processing. A popular example is distributed AI or federated learning applications, where data is stored at different places. In distributed AI model training, the training data also needs to be distributed. After that, trained models by distributed agents may need to be aggregated. Information distribution will be utilized heavily, combining with local storage.

ASAs running on network nodes are the abstraction of the distributed agents for the INC use case and can enable all scenarios described above through information distribution via GRASP.

B.2. Vehicle-to-Everything (V2X) Communications

V2X communication is an inevitable enabling technology that connects vehicles to networks, where value-added services can be provided and enhance the functionalities of a vehicle. In this section, we introduce some use cases that will be closely relevant to information distribution via GRASP.

1)
Real-time and High Definition Maps (HDM): In the era of autonomous driving, a digital map is not only for navigation, but real-time and detailed information is required when driving a vehicle. Real-time situational awareness is essential for autonomous vehicles especially at critical road segments in cases of changing road conditions (e.g. new traffic cone detected by another vehicle some time ago). In addition, the relevant high definition local maps have to be available with support from infrastructure side. In this regard, a digital map should not be considered static information stored on the vehicle, which is spontaneously updated in a periodical manner. Instead, it shall be considered a dynamic distribution based on information aggregated from the local area and such a distribution shall consider latency requirement. Clearly, the infrastructure side shall be able to hold the information in the network sufficiently close to the relevant area.
2)
In-car Infotainment: This is another popular use case where in-car data demands will increase significantly in the near future. Today, users use their mobile phone to access the Internet for retrieving data for work or entertainment purposes. There is already a consensus among OTTs, carriers and car manufacturers that vehicle will become the center of information for passengers onboard. For entertainment, typical scenarios can be stereo HD video streaming and online gaming; for business purposes, examples can be mobile conference. This therefore requires the infrastructure side to be able to schedule and deliver requested information/data to the users with quality-of-service (QoS) considerations.
3)
Software Update: Software components of connected cars will be remotely maintained in future. Therefore, software update has to be supported by the infrastructure side. Although this can be done by centralized solutions where all vehicles have access to central clouds, distributed solution where the update components can be stored in the network and delivered to endpoints in a distributed manner, cold perform better in terms of load balancing, reliability, performance and efficiency.

Note that there could be different models to support the potential use cases above. The first mode is that vehicles are not part of the GRASP deployment but simply access the edge nodes that are part of the GRASP deployment through other protocols, and those edge nodes form the GRASP deployment, which is using GRASP information distribution to provide information required by the vehicles.

An alternative model is more radical, where the vehicles also belong to the GRASP deployment, for example forwarding GRASP messages amongst themselves when forming am edge- mesh network. This model may further require that all entities, both at the network side and the end point side, must be able to establish a mutual trust, such as outlined in the introduction via LDevIDs or other type of mutually trusted credentials.

B.3. Smart Home

Smart homes are designed to make home life much easier. Smart homes refer to a convenient home setup in which appliances and devices can be remotely controlled from anywhere using a mobile or other network device over an Internet connection. Today, devices in the smart home are most often orchestrated over the Internet, allowing users to remotely control functions such as home security access, temperature, lighting, and a home theater. In this section, we present some use cases for which GRASP with information distribution could provide a better communications infrastructure.

1)
Control Information: The control equipment often sends control information to specific devices in real time. For example, smart home with lighting control enables home owners to automatically trigger lighting when and where needed, not only providing comfort to users but also reducing electricity use. Commonly, a controlling device sends adjustment instructions to group of lights according to the ambient brightness in real-time. GRASP with information distribution can provide a reliable multicast mechanism that even works when target devices are only plugged in after the original command.
2)
Multi-Device Collaboration: Media and entertainment, which covers integrated entertainment systems in the home, including access and sharing of digital content on different devices, has proved to be the most prolific. Multi-device collaboration means that multiple devices work together to complete a service. In this case, distributed shared objects allow automatic synchronization of state or digital content between two or more devices.
For example, users may watch videos concurrent or consecutively on different tablets and/or TVs in the home, and use their mobile phones to comment on and reply to the videos. Persistent watching state in GRASP can support these work flows. In this way, concurrency, collaboration, and complementarity can be achieved. In this case, devices have to synchronize the information via GRASP instantaneously or delayed to other devices.
3)
Software Upgrade: IoT devices might employ the SUIT (Software Updates for Internet of Things) technology for software upgrade. The SUIT working group has developed a manifest mechanism ([I-D.ietf-suit-manifest]) to allow the upgrade by fetching content from a packet. It is a good use of GRASP information distribution to propagate the manifest file.

Authors' Addresses

Sheng Jiang (editor)
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Haidian District
Beijing
100083
China
Bing Liu (editor)
Huawei Technologies
Q5, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
Xun Xiao
Huawei Technologies
Munich Research Center
Huawei Technologies
Riesstr. 25
80992 Muenchen
Germany
Artur Hecker
Huawei Technologies
Munich Research Center
Huawei Technologies
Riesstr. 25
80992 Muenchen
Germany
Xiuli Zheng
Huawei Technologies
Q27, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China