]> 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 how devices authorized to join an autonomic control plane as defined in RFC 8994 may use the OASIS MQTT Publish/Subscribe Telemetry mechanism to share arbitrary information. An MQTT message broker is required for this process and may be announced by the GRASP (RFC 8990) flooding mechanism. 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 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 . An alternative is to use an existing solution. This document describes how one existing solution, widely used in smart manufacturing and elsewhere already, could readily be added to the autonomic control plane.

Brief Introduction to MQTT Historically, MQTT may be interpreted as "Message Queuing Telemetry Transport" but that is not accurately descriptive. Originating in industry, it is now an OASIS standard . There are three components in an MQTT deployment - a broker, any number of publishers, and any number of subscribers. The broker provides common storage for current messages about any number of user-defined topics. The protocol is very simple and can run over TCP or TLS. There are even simpler variants for constrained devices. Messages are typically expressed as UTF-8 strings. In the autonomic networking context, for example, MQTT could be used to distribute network intent or agent cards, in JSON format, separated into appropriate shared and named topics so that ASAs could subscribe to relevant material only. Currently MQTT version 5 is RECOMMENDED.

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.

Using MQTT in the Autonomic Control Plane A given ACP will require at least one MQTT broker. In principle there can be a small group of collaborating brokers, but from the user's viewpoint they are all equivalent. Any ASA that may wish to publish or subscribe (or both) to MQTT requires to acquire the address, port, and transport protocol of the broker. In an ACP deployment, these data MUST be periodically announced by a GRASP M_FLOOD message to all ASAs, embedding a GRASP objective named MQTT_broker. The formal Concise Data Definition Language (CDDL) definition of the flood message, using definitions from , is: This flooded announcement is all that is required for any ASA in the network to discover the broker and become a subscriber or publisher. Existing standard software libraries for MQTT transactions are readily available.

Implementation Status [RFC Editor: please remove] See for a proof of concept that works across Windows and Linux. It includes Broker.py which announces an off-the-shelf MQTT broker, and Publisher.py and Subscriber.py which illustrate broker discovery, and show how a JSON-formatted example of network intent can be distributed via MQTT.

Security Considerations MQTT deployed as described, in the address space of the ACP, will inherit the security posture of the ACP. All MQTT transactions SHOULD be performed via TLS in accordance with Section 6.1 of .

IANA Considerations This document defines one new GRASP Objective option name: "MQTT_broker". The IANA is requested to add this to the "GRASP Objective Names" registry defined by .

References Normative References 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 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 Prof. Antje Neve introduced the author to MQTT and provided some valuable code samples.