Publish/Subscribe Telemetry for Autonomic Networks

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

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

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

8. References

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

Acknowledgements

Prof. Antje Neve introduced the author to MQTT and provided some valuable code samples.¶

Author's Address