Skip to main content

Information Distribution over GRASP
draft-ietf-anima-grasp-distribution-11

Document Type Active Internet-Draft (anima WG)
Authors Sheng Jiang , Bing Liu , Xun Xiao , Artur Hecker , Xiuli Zheng , Yanyan Zhang
Last updated 2024-03-20 (Latest revision 2024-02-12)
Replaces draft-liu-anima-grasp-distribution
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Formats
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Michael Richardson
Shepherd write-up Show Last changed 2024-02-12
IESG IESG state Publication Requested
Action Holder
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Mahesh Jethanandani
Send notices to tte@cs.fau.de, mcr+ietf@sandelman.ca
draft-ietf-anima-grasp-distribution-11
Network Working Group                                      S. Jiang, Ed.
Internet-Draft                                                      BUPT
Updates: 8990 (if approved)                                  B. Liu, Ed.
Intended status: Experimental                                    X. Xiao
Expires: 15 August 2024                                        A. Hecker
                                                                X. Zheng
                                                     Huawei Technologies
                                                                Y. Zhang
                                                              Individual
                                                           February 2024

                  Information Distribution over GRASP
                 draft-ietf-anima-grasp-distribution-11

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 4 August 2024.

Jiang, et al.            Expires 15 August 2024                 [Page 1]
Internet-Draft          Information Distribution           February 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Analysis of Information Distribution Modes and
           Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  General Modes of Information Distribution . . . . . . . .   4
     3.2.  Gaps of Current GRASP Protocol  . . . . . . . . . . . . .   5
   4.  GRASP Extensions for Information Distribution . . . . . . . .   5
     4.1.  Un-solicited Synchronization Message  . . . . . . . . . .   6
     4.2.  Selective-Flooding Option . . . . . . . . . . . . . . . .   6
     4.3.  Subscription Objective Option . . . . . . . . . . . . . .   7
     4.4.  Unsubscription Objective Option . . . . . . . . . . . . .   7
     4.5.  Publishing Objective Option . . . . . . . . . . . . . . .   7
   5.  Processing Behaviors on GRASP Nodes . . . . . . . . . . . . .   8
     5.1.  Instant Information Distribution Sub-module . . . . . . .   8
       5.1.1.  Instant P2P Communication . . . . . . . . . . . . . .   8
       5.1.2.  Instant Flooding Communication  . . . . . . . . . . .   8
     5.2.  Asynchronous Information Distribution (AID) Sub-module  .   9
       5.2.1.  Information Storage . . . . . . . . . . . . . . . . .   9
       5.2.2.  Event Queue . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Bulk Information Transfer . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Asynchronous Information Distribution Integrated with
           GRASP APIs  . . . . . . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Possible Use Cases . . . . . . . . . . . . . . . . .  18

Jiang, et al.            Expires 15 August 2024                 [Page 2]
Internet-Draft          Information Distribution           February 2024

     B.1.  In-Network Computing (INC)  . . . . . . . . . . . . . . .  18
     B.2.  Vehicle-to-Everything (V2X) Communications  . . . . . . .  19
     B.3.  Smart Home  . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

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.

Jiang, et al.            Expires 15 August 2024                 [Page 3]
Internet-Draft          Information Distribution           February 2024

   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.

Jiang, et al.            Expires 15 August 2024                 [Page 4]
Internet-Draft          Information Distribution           February 2024

   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

Jiang, et al.            Expires 15 August 2024                 [Page 5]
Internet-Draft          Information Distribution           February 2024

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.

Jiang, et al.            Expires 15 August 2024                 [Page 6]
Internet-Draft          Information Distribution           February 2024

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

Jiang, et al.            Expires 15 August 2024                 [Page 7]
Internet-Draft          Information Distribution           February 2024

      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.

Jiang, et al.            Expires 15 August 2024                 [Page 8]
Internet-Draft          Information Distribution           February 2024

   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

Jiang, et al.            Expires 15 August 2024                 [Page 9]
Internet-Draft          Information Distribution           February 2024

      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

Jiang, et al.            Expires 15 August 2024                [Page 10]
Internet-Draft          Information Distribution           February 2024

      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.

Jiang, et al.            Expires 15 August 2024                [Page 11]
Internet-Draft          Information Distribution           February 2024

   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

Jiang, et al.            Expires 15 August 2024                [Page 12]
Internet-Draft          Information Distribution           February 2024

      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.

Jiang, et al.            Expires 15 August 2024                [Page 13]
Internet-Draft          Information Distribution           February 2024

   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.

Jiang, et al.            Expires 15 August 2024                [Page 14]
Internet-Draft          Information Distribution           February 2024

6.  Security Considerations

   The distribution source authentication could be done at multiple
   layers:

   *  Outer layer authentication: the GRASP communication is within the
      GRASP security and transport substrate, such as peer-to-peer TLS
      connections for unicast and hop-by-hop TLS for flooding of GRASP
      messages.  This is the default GRASP behavior.

   *  Inner layer authentication: the GRASP communication might not use
      a sufficient security and transport substrate, then there should
      be embedded protection in distribution information itself through
      authenticated GRASP messages.

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

Jiang, et al.            Expires 15 August 2024                [Page 15]
Internet-Draft          Information Distribution           February 2024

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, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
              DOI 10.17487/RFC5424, March 2009,
              <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, June 2011,
              <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,
              May 2017, <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,
              June 2019, <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, December 2020,
              <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, May 2021,
              <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, May 2021,
              <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

Jiang, et al.            Expires 15 August 2024                [Page 16]
Internet-Draft          Information Distribution           February 2024

              (CBOR)-based Serialization Format for the Software Updates
              for Internet of Things (SUIT) Manifest", Work in Progress,
              Internet-Draft, draft-ietf-suit-manifest-25, 5 February
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              suit-manifest-25>.

   [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, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC7991]  Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
              RFC 7991, DOI 10.17487/RFC7991, December 2016,
              <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,
              May 2021, <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, May 2021,
              <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,
              May 2021, <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, February 2019,
              <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.

Jiang, et al.            Expires 15 August 2024                [Page 17]
Internet-Draft          Information Distribution           February 2024

   *  Storing and publishing information: This action involves both IS
      and EQ modules where a node that can store the information will be
      discovered first and related event will e published to the
      network.  For this, GRASP APIs discover(), synchronize() and
      flood() are combined to compose such a procedure.  In specific,
      discover() call will specify its objective to be "store_data" and
      the return parameters could be either an ASA_locator that will
      accept to store the data, or an error code indicating that no one
      could afford such data; after that, synchronize() call will send
      the data to the specified ASA_locator and the data will be stored
      at that node, with return of processing results like
      store_data_ack; meanwhile, such a successful event (i.e. data is
      stored successfully) will be flooded via a flood() call to
      interesting parties (such a multicast group existed).

   *  Subscribing and getting information: This action involves both IS
      and EQ modules as well where a node that is interested in a topic
      will subscribe the topic by triggering EQ module and if the topic
      is ready IS module will retrieve the content of the topic (i.e.
      the data).  GRASP APIs such as register_objective(), flood(),
      synchronize() are combined to compose the procedure.  In specific,
      any subscription action received by EQ module will be translated
      to register_objective() call where the interested topic will be
      the parameter inside of the call; the registration will be
      (selectively) flooded to the network by an API call of flood()
      with the option we extended in this draft; once a matched topic is
      found (because of the previous procedure), the node finding such a
      match will call API synchronize() to send the stored data to the
      subscriber.

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.

Jiang, et al.            Expires 15 August 2024                [Page 18]
Internet-Draft          Information Distribution           February 2024

   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

Jiang, et al.            Expires 15 August 2024                [Page 19]
Internet-Draft          Information Distribution           February 2024

      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.

Jiang, et al.            Expires 15 August 2024                [Page 20]
Internet-Draft          Information Distribution           February 2024

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

Jiang, et al.            Expires 15 August 2024                [Page 21]
Internet-Draft          Information Distribution           February 2024

   Sheng Jiang (editor)
   Beijing University of Posts and Telecommunications
   No. 10 Xitucheng Road
   Haidian District
   Beijing
   100083
   China
   Email: shengjiang@bupt.edu.cn

   Bing Liu (editor)
   Huawei Technologies
   Q5, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing
   100095
   P.R. China
   Email: leo.liubing@huawei.com

   Xun Xiao
   Huawei Technologies
   Munich Research Center
   Huawei Technologies
   Riesstr. 25
   80992 Muenchen
   Germany
   Email: xun.xiao@huawei.com

   Artur Hecker
   Huawei Technologies
   Munich Research Center
   Huawei Technologies
   Riesstr. 25
   80992 Muenchen
   Germany
   Email: artur.hecker@huawei.com

   Xiuli Zheng
   Huawei Technologies
   Q27, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing
   100095
   P.R. China
   Email: zhengxiuli@huawei.com

Jiang, et al.            Expires 15 August 2024                [Page 22]
Internet-Draft          Information Distribution           February 2024

   Yanyan Zhang
   Individual
   Texas
   United States of America
   Email: linna.purple@gmail.com

Jiang, et al.            Expires 15 August 2024                [Page 23]