Using GRASP as an Agent Rendezvous Mechanism
draft-carpenter-anima-grasp-rendezvous-01

Autonomic Networking Integrated Model and Approach       B. E. Carpenter
Internet-Draft                                         Univ. of Auckland
Updates: 8990 (if approved)                                 26 July 2026
Intended status: Informational                                          
Expires: 27 January 2027

              Using GRASP as an Agent Rendezvous Mechanism
               draft-carpenter-anima-grasp-rendezvous-01

Abstract

   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

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://becarpenter.github.io/grasp-rendezvous/draft-carpenter-anima-
   grasp-rendezvous.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-carpenter-anima-
   grasp-rendezvous/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/becarpenter/grasp-rendezvous.

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

Carpenter                Expires 27 January 2027                [Page 1]
Internet-Draft              GRASP Rendezvous                   July 2026

   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 27 January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Rendezvous procedures . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Simple rendezvous . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Rendezvous via brief GRASP negotiation  . . . . . . . . .   5
   3.  Implementation Status [RFC Editor: please remove] . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
     A.1.  Draft-00  . . . . . . . . . . . . . . . . . . . . . . . .   8
     A.2.  Draft-01  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The GeneRic Autonomic Signaling Protocol (GRASP) is specified in
   [RFC8990], and an API is described in [RFC8991].  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 [I-D.eckert-anima-ai4an].  This document
   addresses how such agents may discover each other and establish

Carpenter                Expires 27 January 2027                [Page 2]
Internet-Draft              GRASP Rendezvous                   July 2026

   communication.  It extends [RFC8990] by adding a transport identifier
   registry in Section 5.

   For the general model of an autonomic network, and for terminology
   not otherwise defined here or in RFC 8990, see [RFC8993].  General
   considerations for ASAs are discussed in [RFC9222].

   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 [I-D.farrel-dawn-terminology].

   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 [I-D.king-dawn-requirements].  More
   generally, they may need to perform agent-to-agent (A2A)
   communication as discussed in documents such as
   [I-D.zeng-opsawg-applicability-mcp-a2a],
   [I-D.zhao-nmop-network-management-agent],
   [I-D.rosenberg-agentproto-usecases] and https://a2a-protocol.org/dev/
   specification/ (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.

2.  Rendezvous procedures

   There are two methods for an ASA to use GRASP discovery to establish
   a communications channel.

Carpenter                Expires 27 January 2027                [Page 3]
Internet-Draft              GRASP Rendezvous                   July 2026

   The choice between the two methods will be fixed as part of the
   definition of the GRASP objective concerned (see Section 2.10 of
   [RFC8990]).

2.1.  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 [RFC8991].  First the client ASA issues a discovery
   call, e.g.,

   obj1 = objective("example.org:translate_english_french")
   discover(asa_handle1, obj1, timeout, minimum_TTL)

   The client will receive in return a list of locators for ASAs that
   support the given objective.  According to Section 2.9.5 of [RFC8990]
   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.,

   obj2 = objective("example.org:translate_english_french")
   register(asa_handle2, obj2)

   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 [RFC8990]) includes only TCP and UDP, expressed in
   fragmentary CDDL [RFC8610] as:

     transport-proto = IPPROTO_TCP / IPPROTO_UDP
     IPPROTO_TCP = 6
     IPPROTO_UDP = 17

   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 [RFC8990], this requires a new
   registry, defined in Section 5.

Carpenter                Expires 27 January 2027                [Page 4]
Internet-Draft              GRASP Rendezvous                   July 2026

2.2.  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 [RFC8990], 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 [RFC8949].  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 [RFC8994] security).

3.  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
   (https://github.com/becarpenter/graspy).  This amounted to about 60
   lines of Python code.

4.  Security Considerations

   The security considerations of [RFC8990] apply.  The normal
   deployment scenario for GRASP is to run over a secure Autonomic
   Control Plane [RFC8994], 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.

Carpenter                Expires 27 January 2027                [Page 5]
Internet-Draft              GRASP Rendezvous                   July 2026

   When an ASA registers itself as described in Section 2.1, 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.

5.  IANA Considerations

   For considerations about naming and registering GRASP objectives, see
   Section 2.10.1 of [RFC8990].

   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 [RFC8126].  The following initial values are
   assigned by this document:

   Value   Transport ID   REFERENCE

   256     PROTO_TLS      RFC8446
   257     PROTO_DTLS     RFC9147
   258     PROTO_QUIC     RFC9369
   259     PROTO_HTTP     RFC9110

6.  References

6.1.  Normative References

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Carpenter                Expires 27 January 2027                [Page 6]
Internet-Draft              GRASP Rendezvous                   July 2026

   [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, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

6.2.  Informative References

   [I-D.eckert-anima-ai4an]
              Eckert, T. T. and A. Clemm, "AI for Autonomous
              Networking", Work in Progress, Internet-Draft, draft-
              eckert-anima-ai4an-01, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-eckert-anima-
              ai4an-01>.

   [I-D.farrel-dawn-terminology]
              Farrel, A., Yao, K., Schott, R., and N. Williams,
              "Terminology for the Discovery of Agents, Workloads, and
              Named Entities (DAWN)", Work in Progress, Internet-Draft,
              draft-farrel-dawn-terminology-04, 5 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
              terminology-04>.

   [I-D.king-dawn-requirements]
              King, D. and A. Farrel, "Requirements for the Discovery of
              Agents, Workloads, and Named Entities (DAWN)", Work in
              Progress, Internet-Draft, draft-king-dawn-requirements-01,
              28 April 2026, <https://datatracker.ietf.org/doc/html/
              draft-king-dawn-requirements-01>.

   [I-D.rosenberg-agentproto-usecases]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in

Carpenter                Expires 27 January 2027                [Page 7]
Internet-Draft              GRASP Rendezvous                   July 2026

              Progress, Internet-Draft, draft-rosenberg-agentproto-
              usecases-00, 4 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-rosenberg-
              agentproto-usecases-00>.

   [I-D.zeng-opsawg-applicability-mcp-a2a]
              Zeng, G., Mao, J., Liu, B., Geng, N., Shang, X., Gao, Q.,
              and Z. Li, "When NETCONF Is Not Enough: Applicability of
              MCP and A2A for Advanced Network Management Scenarios",
              Work in Progress, Internet-Draft, draft-zeng-opsawg-
              applicability-mcp-a2a-00, 2 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-zeng-opsawg-
              applicability-mcp-a2a-00>.

   [I-D.zhao-nmop-network-management-agent]
              XingZhao, Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and
              J. Zhou, "AI based Network Management Agent(NMA): Concepts
              and Architecture", Work in Progress, Internet-Draft,
              draft-zhao-nmop-network-management-agent-05, 5 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-zhao-nmop-
              network-management-agent-05>.

   [RFC8991]  Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
              "GeneRic Autonomic Signaling Protocol Application Program
              Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
              May 2021, <https://www.rfc-editor.org/info/rfc8991>.

   [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,
              <https://www.rfc-editor.org/info/rfc8993>.

   [RFC9222]  Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso,
              "Guidelines for Autonomic Service Agents", RFC 9222,
              DOI 10.17487/RFC9222, March 2022,
              <https://www.rfc-editor.org/info/rfc9222>.

Appendix A.  Change Log

A.1.  Draft-00

   *  Original version

A.2.  Draft-01

   *  Added transport_id registry

Carpenter                Expires 27 January 2027                [Page 8]
Internet-Draft              GRASP Rendezvous                   July 2026

Acknowledgements

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

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 27 January 2027                [Page 9]