]> 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 agent discovery This document describes how the GeneRic Autonomic Signaling Protocol (GRASP) defined by RFC 8990 may be used as a rendezvous mechanism for one Autonomic Service Agent to find another, and then to establish a generic communication channel between them. Such a channel could be used for any form of agent-to-agent communication, not limited to GRASP exchanges. This document updates RFC 8990 by adding a transport identifier registry. About This Document The latest revision of this draft can be found at . 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 . Source for this draft and an issue tracker can be found at .

Introduction The GeneRic Autonomic Signaling Protocol (GRASP) is specified in , and an API is described in . Its purpose is to support discovery, data synchronization, and negotiation among Autonomic Service Agents (ASAs) in a self-managing autonomic network. A conceptual model of how AI agents might fit into an autonomic network may be found in . This document addresses how such agents may discover each other and establish communication. It extends by adding a transport identifier registry in . For the general model of an autonomic network, and for terminology not otherwise defined here or in RFC 8990, see . General considerations for ASAs are discussed in . A basic feature of GRASP is its discovery mechanism, using the M_DISCOVER and M_RESPONSE messages, which allow an Autonomic Service Agent to discover another ASA that supports a particular GRASP objective (as defined in RFC 8990). This can provide the first stage of 'discovery' as defined in . Following this discovery process, ASAs may conduct a GRASP synchronization session to share data, or a GRASP negotiation session to agree on certain parameter settings. However, in some cases the two agents may require to communicate in some other way, outside the scope of GRASP synchronization or negotiation. One example would be to complete the discovery requirements outlined in . More generally, they may need to perform agent-to-agent (A2A) communication as discussed in documents such as , , and https://a2a-protocol.org/dev/specification/. In this case, GRASP can be used purely as a generic rendezvous mechanism between agents. Note that GRASP discovery does not discover a specified agent. Instead, it discovers an agent that supports a specified objective. For example, if an agent wants to find support for an objective named "example.org:translate_english_french", it will discover one or more agents that support an objective of that name. As a result, an agent can be specialised and only support one objective, or it could support several different objectives. This is an implementation and deployment choice. A feature of GRASP discovery that may be essential during a period of network instability is that it has no dependency on any protocols above the network layer, and in particular no dependency on DNS or mDNS.

Rendezvous procedures There are two methods for an ASA to use GRASP discovery to establish a communications channel. The choice between the two methods will be fixed as part of the definition of the GRASP objective concerned (see Section 2.10 of ).

Simple rendezvous The first method is simply to perform discovery and use the resulting locators appropriately. This is most easily described in terms of the GRASP API . First the client ASA issues a discovery call, e.g., The client will receive in return a list of locators for ASAs that support the given objective. According to Section 2.9.5 of these locators may be IP addresses, FQDNs, or URIs. Each locator is returned with a transport protocol identifier and a port number, if needed. The client ASA may now use any of those locators to open a transport connection to another ASA supporting the given objective, with no other GRASP messages required. For this to operate successfully, the remote ASA must have previously registered itself, via the GRASP API, as ready to support the same objective, e.g., This method has the advantage that any type of locator could be used and any transport protocol could be used. However, both ASAs will have to support the chosen locator type and transport protocol (one as a client and the other as a server), and provide adequate security. The definition of locator options for GRASP discovery responses (Section 2.9.5 of ) includes only TCP and UDP, expressed in fragmentary CDDL as: These are values from the IANA Protocol registry. For rendezvous purposes, this needs to be extended to cover additional protocols. As noted in Section 2.9.5.1 of , this requires a new registry, defined in .

Rendezvous via brief GRASP negotiation Another approach is possible, which creates a GRASP session identifier and a vestigial GRASP negotiation session. Discovery proceeds as just described. However, following discovery, the client ASA starts a GRASP negotiation process as described in Section 2.5.5 of , using the M_REQ_NEG message. Upon receipt of an M_NEGOTIATE message in reply, instead of continuing to exchange M_NEGOTIATE messages, both ASAs switch to a straightforward transport layer communication, using the channel created by the M_REQ_NEG/M_NEGOTIATE exchange. Since GRASP is a CBOR-based protocol, messages in this case are expected to be encoded in CBOR . Since CBOR itself can very readily encode JSON and therefore YANG, this is a rather general solution. Note that although GRASP has a defined maximum message size, it will not limit these messages, as they are not GRASP messages. This method has the advantage that it can be entirely handled by GRASP mechanisms plus a simple send/receive API. However, this means that FQDN and URI locators are not supported, CBOR is required, and only the transport protocol supported by GRASP is available (normally TCP protected by Autonomic Control Plane security).

Implementation Status [RFC Editor: please remove] Rendezvous via GRASP negotiation has been implemented in the form of gsend() and grecv() primitives added to a prototype version of GRASP. This amounted to about 60 lines of Python code.

Security Considerations The security considerations of apply. The normal deployment scenario for GRASP is to run over a secure Autonomic Control Plane , which defines a strongly enforced trust boundary and protects all traffic cryptographically. All agents must lie within this trust boundary, which forms a single GRASP domain. This model does not envisage any form of multi-domain trust model, and inter-domain traffic is not supported. Edge nodes that communicate outside the domain are required to apply appropriate precautions. When an ASA registers itself as described in , this registration merely indicates that the responding ASA has successfully joined the ACP. It does not provide any authentication or authorization for the agent as such. Mutual authentication and authorization between agents are out of scope for the rendezvous mechanisms described here. They should be addressed as part of the protocol used between the agents following a successful rendezvous. GRASP supports a flooding mechanism, by which an ASA can advertise the current value of a GRASP objective to all other ASAs in the same domain. This mechanism should only be used for information that is potentially needed by all agents. It is not recommended as an alternative rendezvous mechanism.

IANA Considerations For considerations about naming and registering GRASP objectives, see Section 2.10.1 of . Not all protocols of interest have entries in the IANA Protocol registry. Therefore, IANA is requested to create a new subregistry of the "GeneRic Autonomic Signaling Protocol (GRASP) Parameters" registry, known as the "GRASP Transport Identifiers" subregistry. The values in this subregistry are names paired with decimal integers greater than 255. Future values MUST be assigned using the Expert Review policy defined by . The following initial values are assigned by this document:

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. 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 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem. Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. CAICT China Mobile Huawei Cisco Huawei ZTE The evolution from Level 3 (assisted automation) to Level 4 (closed- loop autonomy) in Autonomous Networks (AN) introduces requirements for agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, and execution coordination, which transcend the static, rule-based logic of traditional network controllers. This document defines the concept of the Network Management Agent (NMA), a network management entity with autonomous task processing capabilities designed to bridge the gap between service intent and network operations. This document describes the role of NMA in network management and control architectures, and specifies how the NMA collaborates with existing network controllers to achieve Autonomous L4 without replacing or duplicating their functions. It further defines the reference architecture, deployment modes, and logical interfaces of the NMA, including Agent-to-User (A2U), Agent-to-Agent (A2A), Agent- to-Controller (A2C), and Agent-to-Network (A2N) interactions. Huawei Huawei Huawei Huawei Huawei Huawei Huawei NETCONF provides robust configuration transactions and YANG-based data models, but falls short in scenarios requiring AI-driven semantic translation, long-lived cross-domain orchestration, multi- agent consensus, rapid DevOps iteration, or delivery of large non- configuration artifacts. This document systematically analyzes the functional gaps and presents Model Context Protocol (MCP) and Agent- to-Agent (A2A) as complementary solutions. Implementation guidance and coexistence models are also provided. Futurewei Technologies USA Individual This document builds on the architectural foundation of the IETF ANIMA "Autonomous Network Infrastructure" to propose an architecture for in-network intelligence in support of network automation. The key aspect of this architecture is the use of AI programmed and validated software running decentralized on the network. The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution.

Change Log

Draft-00

• Original version

Draft-01

• Added transport_id registry

Acknowledgements Helpful comments were made by Artur Hecker, 韩梦瑶 (Han Mengyao), ...