]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Operations and Management Autonomic Networking Integrated Model and Approach MQTT GRASP MASA This document describes an approach to information distribution and subscription using GRASP. Rather than extending the GRASP protocol itself, it uses existing GRASP mechanisms to build a distribution and subscription mechanism on top. About This Document Status information for this document may be found at . Discussion of this document takes place on the Autonomic Networking Integrated Model and Approach Working Group mailing list (), which is archived at . Subscribe at .

Introduction The autonomic networking infrastructure described in provides a secure autonomic control plane (ACP) 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 . 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 . 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 ). 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() .

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 when, and only when, they appear in all capitals, as shown here.

Subscribable Objectives The names of subscribable objectives follow the general rules for GRASP objective names (Section 2.10.1 of ). 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.

Subscribe Topic Objective Option The Subscribe Topic Objective option is a GRASP Objective option conforming to the GRASP specification . 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) , the format of the PrefixManager Objective option is described in the Concise Data Definition Language (CDDL) as follows: 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:

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

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 as normal.

Implementation Status [RFC Editor: please remove] A preliminary Python implementation, which certainly has loopholes, can be found at .

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

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 . Subscribable objectives and wildcard subscribable objectives, as defined in , may be registered with IANA according to the procedure defined in .

References Normative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document is a conceptual outline of an Application Programming Interface (API) for the GeneRic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASAs) calling the GRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems. This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. Beijing University of Posts and Telecommunications Huawei Technologies Huawei Technologies Huawei Technologies Huawei Technologies 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]. OASIS

Change Log [RFC Editor: please remove]

Draft-00

• Original version

Acknowledgements Some ideas have been borrowed from the MQTT pub/sub protocol .