Distribution and Subscription using GRASP

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 15 April 2027.¶

Copyright Notice

Copyright (c) 2026 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

The autonomic networking infrastructure described in [RFC8993] provides a secure autonomic control plane (ACP) [RFC8994] which allows Autonomic Service Agents (ASAs) to communicate securely with minimal infrastructure dependency. A basic set of one-to-one and one-to-many communication mechanisms is provided by the GRASP protocol [RFC8990]. However, some aspects of network management, for example distribution of management intent or agent capabilities, are better suited to a publish/subscribe model, where individual ASAs can subscribe selectively to particular sets of information. One method for achieving this would be a major extension to GRASP, as proposed by [I-D.ietf-anima-grasp-distribution]. This document describes an alternative approach that is entirely constructed on top of existing GRASP mechanisms, with an additional mechanism built on the existing GRASP relay mechanism.¶

GRASP provides a basic distribution mechanism known as flooding, which allows any ASA to flood a specific GRASP Objective to the entire autonomic network. This mechanism depends on link-local broadcasts that will cause activity in every GRASP node on the network, so it should be used sparingly and only for information of very wide interest.¶

One feature of GRASP is that because it uses link-local broadcast for both flooding and discovery, each router must contain a GRASP instance that acts as a relay for M_FLOOD and M_DISCOVERY messages (see Section 2.5.6.2 of [RFC8990]). This document describes how this relay instance may be extended to support a special ASA whose function is to intercept M_FLOOD messages that carry certain GRASP objectives known as Subscribable Objectives. Instead of being relayed by link-local multicast, they will be unicasted only to other GRASP ASAs that have subscribed to them.¶

Nodes subscribe to a given Subscribable Objective by use of a specific GRASP objective "SubscribeTopic" which is described below. However, the details of this can be hidden from users by a pair of API functions, subscribe_topic() and unsubscribe_topic(). To obtain the current value of a Subscribable Objective, the user will use the existing APA function get_flood() [RFC8991].¶

2. Terminology

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.¶

3. Subscribable Objectives

The names of subscribable objectives follow the general rules for GRASP objective names (Section 2.10.1 of [RFC8990]).¶

Additionally, if they are registered with IANA they MUST start with the UTF-8 string "Sub/" followed by a UTF-8 field known as the topic, followed by "/" and then an opaque UTF-8 string that completes the objective name. An example is Sub/Intent/VoIPQoS.¶

A privately defined subscribable objective MUST use this same format following the last colon in the name, e.g., example.org:Sub/Intent/VoIPQoS.¶

These two examples define a topic Intent and a specific objective VoIPQoS within that topic.¶

A wild-card subscribable objective is allowed, e.g. Sub/Intent/ or example.org:Sub/Intent/, which matches all objectives within the indicated topic.¶

4. Subscribe Topic Objective Option

The Subscribe Topic Objective option is a GRASP Objective option conforming to the GRASP specification [RFC8990]. Its name is "SubscribeTopic", and it carries the requested subscribable objective name as part of its its value. Since GRASP is based on CBOR (Concise Binary Object Representation) [RFC8949], the format of the PrefixManager Objective option is described in the Concise Data Definition Language (CDDL) [RFC8610] as follows:¶

  objective = ["SubscribeTopic", objective-flags, loop-count,
               [active, topic, port]]

  loop-count = 0..255         ; as in the GRASP specification
  objective-flags /=          ; as in the GRASP specification
  active =  bool              ; true to start subscription, false to cancel subscription
  topic = text                ; a subscribable objective name as defined above
  port = 49152..65535         ; UDP port to receive unicast GRASP messages

This will be used in a single-step GRASP negotiation between an ASA wishing to subscribe to the given subscribable objective. The "dry run" mode of GRASP MUST NOT be used for this objective.¶

An example objective follows:¶

["SubscribeTopic", 2, 3, [true, "example.org:Sub/Intent/VoIPQoS", 65534]]

5. ASA Implementation Requirements

Any ASA that needs to subscribe to a specific subscribable objective or to all objectives in a given topic will proceed as follows:¶

1. Request GRASP to create a UDP listening port for receiving subscribed objectives.¶

2. Create a GRASP objective SubscribeTopic whose value is [true, topic, port]¶

3. Use GRASP discovery to find a remote ASA supporting that objective.¶

4. Act as a GRASP negotiation initiator by sending a GRASP M_REQ_NEG message with the same "SubscribeTopic" objective.¶

5. Wait for a corresponding GRASP M_END message to indicate success or failure.¶

These steps may be taken by an API function subscribe_objective(asa_handle, topic, timeout), following the API model described in [RFC8991].¶

The timeout parameter is the lifetime of the subscription in milliseconds. The client ASA must repeat subscribe_objective() before the lifetime expires. This is necessary to allow garbage collection of unused subscriptions.¶

An unsubscribe_objective(asa_handle, topic) function is also provided.¶

After this process, the ASA in question will receive future versions of the requested subscribable objective(s), delivered by unicast UDP. They will be processed on receipt exactly as if they had arrived by link-local multicast, using the API call get_flood(asa_handle, objective).¶

The Subscribe ASA on each relay node, and associated code in the GRASP kernel, will proceed as follows:¶

1. Register the GRASP objective "SubscribeTopic" and respond to discovery and negotiation requests for it.¶

2. Act as a GRASP negotiation responder for this objective, and upon receipt of a subscription request, make a suitable record of that request. Upon receipt of a subscription cancellation, remove the record.¶

3. Intercept each incoming GRASP M_FLOOD message and if it contains a subscribable objective, suppress the normal relay action and forward the flood as a link-local unicast to each subscriber (if any). This interception is the only change to basic GRASP operations as described in [RFC8990].¶

Note that on the network segment where a flooded subscribable objective originates, it will be multicasted as normal. However, the multicast will not be propagated on other network segments.¶

An ASA that originates a subscribable objective will send it out using the flood() function [RFC8991] as normal.¶

6. Implementation Status [RFC Editor: please remove]

A preliminary Python implementation, which certainly has loopholes, can be found at https://github.com/becarpenter/graspy/tree/master/distro.¶

7. Security Considerations

The mechanism described in this document takes place entirely within the ACP [RFC8994]. It is therefore secured by the ACP, as discussed in Section 3 of [RFC8990]. All ASAs are considered mutually trustworthy within the ACP.¶

8. IANA Considerations

This document defines one new GRASP Objective option name: "SubscribeTopic". The IANA is requested to add this to the "GRASP Objective Names" registry defined by [RFC8990].¶

Subscribable objectives and wildcard subscribable objectives, as defined in Section 3, may be registered with IANA according to the procedure defined in [RFC8990].¶

9. References

Appendix A. Change Log [RFC Editor: please remove]

Acknowledgements

Some ideas have been borrowed from the MQTT pub/sub protocol [OasisMQTT].¶

Author's Address