Autonomic Networking Integrated Model and Approach B. E. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational 12 October 2026 Expires: 15 April 2027 Publish/Subscribe Telemetry for Autonomic Networks draft-carpenter-anima-mqtt-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-anima-mqtt/. Discussion of this document takes place on the Autonomic Networking Integrated Model and Approach Working Group mailing list (mailto:anima@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at https://www.ietf.org/mailman/listinfo/anima/. 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. Carpenter Expires 15 April 2027 [Page 1] Internet-Draft Pub/Sub Telemetry October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Brief Introduction to MQTT . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Using MQTT in the Autonomic Control Plane . . . . . . . . . . 3 5. Implementation Status [RFC Editor: please remove] . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Change Log [RFC Editor: please remove] . . . . . . . 6 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The autonomic networking infrastructure described in [RFC8993] provides a secure autonomic control plane [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]. 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. Carpenter Expires 15 April 2027 [Page 2] Internet-Draft Pub/Sub Telemetry October 2026 2. 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 [OasisMQTT]. 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*. 3. 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. 4. 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) [RFC8610] definition of the flood message, using definitions from [RFC8990], is: Carpenter Expires 15 April 2027 [Page 3] Internet-Draft Pub/Sub Telemetry October 2026 flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["MQTT_broker", objective-flags, loop-count, objective-value] ttl = 180000 ; 180,000 ms (3 minutes) initiator = ACP address to contact broker objective-flags = sync-only ; as in RFC 8990 sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 1..255 ; determines radius of flooding objective-value = any ; none necessary locator-option = [ O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number ] ipv6-address = the v6address of the broker $transport-proto /= IPPROTO_TCP ; note that this can be any value ; from the IANA protocol registry, ; as per RFC 8990, Section 2.9.5.1, ; Note 3. port-number = selected by broker 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. 5. Implementation Status [RFC Editor: please remove] See https://github.com/becarpenter/graspy/tree/master/mqtt 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. 6. 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 [RFC8994]. 7. 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 [RFC8990]. Carpenter Expires 15 April 2027 [Page 4] Internet-Draft Pub/Sub Telemetry October 2026 8. References 8.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, . [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, . 8.2. Informative References [I-D.ietf-anima-grasp-distribution] Jiang, S., Liu, B., Xiao, X., Hecker, A., and X. Zheng, "Information Distribution over GRASP", Work in Progress, Internet-Draft, draft-ietf-anima-grasp-distribution-12, 11 December 2024, . [OasisMQTT] Andrew Banks (Ed ), Ed Briggs (Ed ), Ken Borgendale (Ed ), Rahul Gupta (Ed ), and OASIS, "MQTT Version 5.0", March 2019, . [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, . Carpenter Expires 15 April 2027 [Page 5] Internet-Draft Pub/Sub Telemetry October 2026 Appendix A. Change Log [RFC Editor: please remove] A.1. Draft-00 * Original version Acknowledgements Prof. Antje Neve introduced the author to MQTT and provided some valuable code samples. Author's Address Brian E. Carpenter The University of Auckland School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Carpenter Expires 15 April 2027 [Page 6]