



Independent Submission                                           J. Song
Internet-Draft                                                     HKUST
Intended status: Experimental                                    M. Yuan
Expires: 26 September 2026                                          CUHK
                                                           25 March 2026


               Agent Invocation Transport Protocol (AITP)
                         draft-song-anp-aitp-00

Abstract

   The Agent Internet Protocol (AIP) provides best-effort, name-based
   datagram delivery between autonomous AI agents identified by agent://
   URIs.  The Agent Invocation Transport Protocol (AITP) is a message-
   framed invocation and streaming transport above AIP.

   Unlike traditional host-to-host transports (TCP, QUIC) that operate
   on socket endpoints and byte streams, AITP is natively message-
   framed, method-aware, and association-aware: its header carries a
   method name as a first-class field, and its protocol data units are
   discrete requests, responses, stream chunks, and control segments
   exchanged between named agents.  AITP is not a byte-stream transport;
   it is an agent-native invocation and streaming transport that carries
   method names, request/response correlation, flow control, and session
   semantics natively in its header — so that upper-layer agent
   protocols need not reinvent them.  AITP intentionally includes a
   minimal generic invocation outcome space (four dispatch- level status
   codes); richer application semantics belong in the response body or
   upper-layer protocols.

   Unlike transport bindings that adapt existing agent protocols to
   HTTP, gRPC, or MOQT, AITP defines a common invocation substrate
   directly above AIP, with association state, request-concurrency flow
   control, and method-aware framing as first-class transport concerns.

   AITP is best understood as a common invocation substrate above AIP,
   not as a byte-stream transport analogue.

   This document specifies the AITP segment format, segment types,
   status codes, flag bits, TLV options, association state machine,
   reliability engine, flow control, circuit-breaker mechanism,
   streaming, orderly close and abort, and interfaces to AIP below and
   application protocols above.







Song & Yuan             Expires 26 September 2026               [Page 1]

Internet-Draft                    AITP                        March 2026


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 26 September 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Relationship to Existing Transport Protocols  . . . . . .   6
       1.3.1.  Different Abstraction Objects . . . . . . . . . . . .   6
       1.3.2.  Message-Framed, Not Byte-Stream . . . . . . . . . . .   6
       1.3.3.  Complementary Layering  . . . . . . . . . . . . . . .   7
     1.4.  Positioning Among Agent Communication Approaches  . . . .   7
     1.5.  Interoperability Model  . . . . . . . . . . . . . . . . .   8
       1.5.1.  Minimum Endpoint Requirements . . . . . . . . . . . .   8
       1.5.2.  Two-Party Interoperability Conditions . . . . . . . .   8
       1.5.3.  Core versus Profile . . . . . . . . . . . . . . . . .   9
     1.6.  Design Rationale  . . . . . . . . . . . . . . . . . . . .   9
     1.7.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  10
     1.8.  Requirements Language . . . . . . . . . . . . . . . . . .  10
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  10
   3.  AITP Segment Format . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Header Structure  . . . . . . . . . . . . . . . . . . . .  11



Song & Yuan             Expires 26 September 2026               [Page 2]

Internet-Draft                    AITP                        March 2026


     3.2.  Field Definitions . . . . . . . . . . . . . . . . . . . .  12
     3.3.  TLV Options . . . . . . . . . . . . . . . . . . . . . . .  17
   4.  Association State Machine . . . . . . . . . . . . . . . . . .  19
     4.1.  Association States  . . . . . . . . . . . . . . . . . . .  19
     4.2.  State Transitions . . . . . . . . . . . . . . . . . . . .  19
     4.3.  Lazy Association Establishment  . . . . . . . . . . . . .  21
   5.  Reliability Engine  . . . . . . . . . . . . . . . . . . . . .  21
     5.1.  ACK Tracking  . . . . . . . . . . . . . . . . . . . . . .  21
     5.2.  Retransmission  . . . . . . . . . . . . . . . . . . . . .  22
     5.3.  Deduplication . . . . . . . . . . . . . . . . . . . . . .  22
   6.  Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  22
   7.  Circuit Breaker . . . . . . . . . . . . . . . . . . . . . . .  23
     7.1.  Circuit Breaker Transitions . . . . . . . . . . . . . . .  23
     7.2.  Circuit Breaker Flag Bits . . . . . . . . . . . . . . . .  24
   8.  Streaming . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     8.1.  Stream Lifecycle  . . . . . . . . . . . . . . . . . . . .  24
     8.2.  Back-Pressure . . . . . . . . . . . . . . . . . . . . . .  25
     8.3.  Large Payload Guidance  . . . . . . . . . . . . . . . . .  25
   9.  Segment Processing  . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Sending a Request . . . . . . . . . . . . . . . . . . . .  25
     9.2.  Receiving a Segment . . . . . . . . . . . . . . . . . . .  26
   10. Interfaces  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  Upper Layer Interface (Application Protocols)  . . . . .  27
     10.2.  Lower Layer Interface (AIP)  . . . . . . . . . . . . . .  28
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  28
     11.1.  Segment Authentication . . . . . . . . . . . . . . . . .  28
     11.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  29
     11.3.  Resource Exhaustion  . . . . . . . . . . . . . . . . . .  29
     11.4.  Method Authorization . . . . . . . . . . . . . . . . . .  29
     11.5.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . .  29
     11.6.  Association State Attacks  . . . . . . . . . . . . . . .  29
     11.7.  Dispatch-Level Information Leakage . . . . . . . . . . .  30
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     12.1.  AITP Segment Type Registry . . . . . . . . . . . . . . .  30
     12.2.  AITP Status Code Registry  . . . . . . . . . . . . . . .  30
     12.3.  AITP Flag Bits Registry  . . . . . . . . . . . . . . . .  30
     12.4.  AITP Option Type Registry  . . . . . . . . . . . . . . .  30
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  30
     13.1.  ClawNet  . . . . . . . . . . . . . . . . . . . . . . . .  30
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  32
     14.2.  Informative References . . . . . . . . . . . . . . . . .  32
   Appendix A.  Implementation Alignment Notes . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34







Song & Yuan             Expires 26 September 2026               [Page 3]

Internet-Draft                    AITP                        March 2026


1.  Introduction

1.1.  Problem Statement

   AIP [I-D.song-anp-aip] provides a best-effort datagram service
   between agents identified by agent:// URIs: messages may be lost,
   duplicated, or reordered.  Agent applications -- remote procedure
   calls, streaming inference, multi-turn conversations -- require
   reliable delivery with request-response correlation.

   Existing host-to-host transports (TCP, QUIC) solve this problem for
   processes bound to IP addresses and ports.  They provide reliable
   byte streams or datagrams between network endpoints, but they have no
   notion of agent:// addressing, association semantics between named
   agents, or message-level request/response framing.  Using such
   transports directly forces every upper-layer agent protocol (task
   orchestration, knowledge replication, capability advertisement) to
   independently reinvent request IDs, timeouts, retransmission, flow
   control, and orderly close.

   AITP bridges this gap.  It is an agent-to-agent transport, not a
   host-to-host transport: its endpoints are agent:// URIs, its protocol
   data unit is a self-framed message (not a byte stream), and its
   association state tracks agent conversations rather than network
   connections.  AITP accepts AIP datagrams carrying Protocol = 1 and
   provides upper-layer protocols with synchronous invocation, fire-and-
   forget messaging, and bidirectional streaming, all mediated through
   per-agent association state with request-concurrency flow control
   (counted in outstanding requests, not bytes) and circuit-breaker
   fault isolation.

1.2.  Scope

   This document is one of four core Internet-Drafts in the Agent
   Network Protocol (ANP) suite: AIP [I-D.song-anp-aip] (datagram
   delivery), AITP (this document, invocation transport), ANS
   [I-D.song-anp-ans] (name system), and ADP [I-D.song-anp-adp]
   (description and discovery).  The four drafts are designed to co-
   evolve as a self-contained protocol suite; no additional
   specification is required for baseline interoperability.  AIP's
   local-resolver semantic extension MAY be backed by an implementation
   that consults ADP discovery services for ranked capability matching;
   ANS core provides name-to-peer binding but does not itself perform
   ranked semantic discovery.

   AITP defines an experimental, lightweight invocation and streaming
   transport above AIP [I-D.song-anp-aip], intended for implementation
   and operational experimentation.



Song & Yuan             Expires 26 September 2026               [Page 4]

Internet-Draft                    AITP                        March 2026


   In one sentence: AIP delivers datagrams to agents; AITP provides a
   common invocation and streaming substrate on which those agents
   converse.

   AITP is responsible for:

   1.  Association lifecycle -- establish, maintain, orderly close, and
       abort.

   2.  Request/response exchange with correlation by Request ID.

   3.  Fire-and-forget one-way messaging (NOACK flag).

   4.  Bidirectional streaming with FIN-based termination.

   5.  Status codes for transport-level outcomes and minimal handler-
       dispatch outcomes needed for generic interoperability.

   6.  Retransmission with exponential-backoff timeout and deduplication
       of retransmitted requests.

   7.  Receiver-advertised flow control via the Window field.

   8.  Per-association circuit breaker for fault isolation.

   9.  Extensible TLV options for timeout, sequencing, timestamps,
       signatures, and metadata.

   AITP is NOT responsible for:

   1.  Naming, resolution, or agent discovery -- these belong to AIP and
       the Agent Name System (ANS).

   2.  Addressing and forwarding -- these belong to AIP.

   3.  End-to-end business semantics, task orchestration, or agent
       workflow -- these belong to upper-layer application protocols.

   4.  Economic settlement or credit systems.

   5.  Knowledge synchronisation or replication.

   6.  A general identity or authentication framework -- AITP provides
       optional segment-level signatures (SIGNED flag) and defers to AIP
       and deployment-context mechanisms for identity binding.

   7.  Payload confidentiality or end-to-end encryption -- these are
       application-layer responsibilities.



Song & Yuan             Expires 26 September 2026               [Page 5]

Internet-Draft                    AITP                        March 2026


   8.  Message fragmentation -- AITP relies on AIP's maximum message
       size (65535 octets).

   Accordingly, this document does not specify a complete agent runtime,
   workflow engine, business protocol family, or deployment profile; it
   defines only the common invocation and streaming substrate shared by
   such systems.

   Because AITP carries a Method name as a first-class header field and
   defines minimal handler-dispatch status codes, it is not a pure
   transport in the TCP/QUIC sense.  It is an agent-native invocation
   transport that unifies method dispatch, request/response correlation,
   retry, flow control, and session management into a shared substrate
   so that multiple upper-layer agent protocols (ADP, task
   orchestration, capability advertisement, knowledge sync, and future
   agent message families) need not independently reinvent these
   mechanics.  AITP is best understood as a common invocation substrate
   above AIP, rather than as a byte-stream transport analogue.

1.3.  Relationship to Existing Transport Protocols

   A natural question is: "Why not use QUIC streams with gRPC, or libp2p
   streams with a custom RPC layer?"  This section explains why AITP
   occupies a distinct position in the protocol stack.

1.3.1.  Different Abstraction Objects

   TCP and QUIC are host-to-host (or process-to-process) transports.
   Their endpoints are IP addresses and ports; their primary abstraction
   is the connection or stream between network endpoints.  They do not
   understand agent:// URIs, resolver-assisted delivery, or agent
   association semantics.

   AITP is an agent-to-agent transport.  Its endpoints are agent://
   URIs; its primary abstraction is the association between named
   agents.  An association carries not just connectivity state, but also
   request correlation, flow control windows counted in outstanding
   requests (not bytes), and a circuit breaker reflecting the remote
   agent's operational health -- concepts that have no direct
   counterpart in traditional transport protocols.

1.3.2.  Message-Framed, Not Byte-Stream

   TCP provides an unstructured byte stream; applications must impose
   their own framing.  QUIC improves on this with multiple streams but
   remains byte-oriented within each stream.





Song & Yuan             Expires 26 September 2026               [Page 6]

Internet-Draft                    AITP                        March 2026


   AITP is natively message-framed.  Every segment is a self-contained
   protocol data unit with a typed header, request ID, method name,
   status code, and body.  The transport itself understands "this is a
   request", "this is a response", "this is a stream chunk", and "this
   is a control message" -- eliminating the need for upper-layer
   protocols to define their own framing and multiplexing.

1.3.3.  Complementary Layering

   AITP does not compete with TCP or QUIC for the same layer.  The
   correct relationship is:

     Upper-layer protocols   ADP, task, knowledge, capability, ...
     ─────────────────────────────────────────────────────────────
     AITP                     agent-to-agent invocation & streaming
     ─────────────────────────────────────────────────────────────
     AIP                     agent:// datagram substrate
     ─────────────────────────────────────────────────────────────
     Link / Network          libp2p over TCP, QUIC, WebSocket, ...

   Traditional transports provide network reachability and basic
   reliable delivery at the link/network layer.  AIP provides agent-
   oriented, name-based datagram delivery above that.  AITP provides
   reliable invocation and streaming semantics above AIP.  Each layer
   has a distinct job; removing any one forces its responsibilities onto
   an adjacent layer.

   AITP does not replace lower-layer transports such as TCP or QUIC; it
   defines a reusable invocation substrate for agent://-addressed
   communication above AIP.

1.4.  Positioning Among Agent Communication Approaches

   The preceding section distinguishes AITP from host-to-host
   transports.  This section clarifies its relationship to agent-
   oriented communication approaches that operate at different layers of
   the stack.

   Several agent protocol families (e.g., A2A) define application-level
   messaging semantics — task lifecycle, capability exchange, content
   negotiation — and then bind those semantics onto existing transports
   such as HTTP or gRPC.  AITP does not define application semantics.
   It occupies a lower position: a reusable invocation and streaming
   substrate above AIP, designed to be shared by multiple upper-layer
   agent protocols rather than serving one particular protocol family.






Song & Yuan             Expires 26 September 2026               [Page 7]

Internet-Draft                    AITP                        March 2026


   Client-server agent transports such as MCP's stdio and Streamable
   HTTP provide carriage for JSON-RPC exchanges between a client and a
   server, inheriting session and flow-control semantics from the
   underlying transport or runtime environment.  AITP targets symmetric
   agent-to-agent exchanges between agent://-identified endpoints;
   association state and request-concurrency control are defined within
   the protocol itself rather than inherited from an underlying HTTP or
   process-level session.

   Deployment platforms and runtime messaging fabrics may provide
   routing, streaming, or orchestration facilities for agents.  AITP
   does not attempt to standardize such systems.  It specifies a
   protocol-layer invocation substrate that can be implemented
   independently of any particular runtime while remaining reusable
   across agent-oriented application protocols built above AIP.

1.5.  Interoperability Model

   This section summarizes the minimum requirements for implementing an
   AITP endpoint, achieving two-party interoperability, and
   distinguishing core protocol behaviour from optimization profiles.

1.5.1.  Minimum Endpoint Requirements

   A conforming AITP endpoint requires:

   1.  An AIP module providing SEND and RECEIVE primitives with Protocol
       = 1.

   2.  An association table keyed by (localURI, remoteURI) that tracks
       lifecycle state, flow control window, and circuit-breaker state.

   3.  Request ID tracking for correlation and deduplication.

   4.  A method-dispatch surface capable of mapping Method values to
       local handlers.

1.5.2.  Two-Party Interoperability Conditions

   Two implementations interoperate when they share:

   1.  The same AITP version (currently 1).

   2.  Agreed semantics for the flags, status codes, and option types
       they exchange.

   3.  Compatible compression and signature expectations, if the COMPR
       or SIGNED flags are used.



Song & Yuan             Expires 26 September 2026               [Page 8]

Internet-Draft                    AITP                        March 2026


1.5.3.  Core versus Profile

   The following are optimization profiles or implementation choices,
   not core protocol requirements:

   *  Lazy association establishment (core baseline is the explicit INIT
      handshake).

   *  Compression algorithm selection (COMPR flag).

   *  Operational telemetry and monitoring counters.

   *  Deployment-specific defaults for window size, retransmission
      parameters, and circuit-breaker thresholds.

1.6.  Design Rationale

   AITP is justified when the following conditions hold:

   1.  *Multiple upper-layer protocols share transport needs.*

       If ADP, task orchestration, knowledge sync, and capability
       advertisement each need method dispatch, request/response
       correlation, retransmission, timeout, request-concurrency flow
       control, and orderly close, factoring these into a shared
       invocation transport eliminates redundant specification and
       implementation.

   2.  *AIP remains a narrow waist.*

       If reliable delivery, association state, and request/response
       semantics were pushed down into AIP, AIP would lose its
       simplicity as a best-effort datagram layer.  AITP exists
       precisely so that AIP can stay thin.

   3.  *Agent-native addressing and conversation semantics are valued as
       an independent standard layer.*

       If a deployment is willing to fully delegate transport to an
       existing RPC framework (e.g., gRPC over QUIC), AITP is not
       required.  AITP is valuable when the community seeks a self-
       contained, agent-native invocation transport specification that
       does not depend on any specific lower-layer RPC stack.

   A practical test: if removing AITP would cause every upper-layer
   agent protocol to independently redefine method dispatch, request
   IDs, retry policies, timeout handling, flow control, and session
   close/abort, then AITP earns its place in the architecture.



Song & Yuan             Expires 26 September 2026               [Page 9]

Internet-Draft                    AITP                        March 2026


   Method is a first-class header field.  Upper-layer agent protocols
   rely on it for dispatch; AITP provides the invocation framing so that
   they do not each define their own.  This is what makes AITP an
   invocation substrate rather than a generic message bus, and is the
   primary reason its flow control counts outstanding requests rather
   than bytes.

   Because AITP is invocation-oriented rather than byte-stream-
   oriented, its flow control regulates concurrent outstanding requests
   admitted by the remote agent, not raw octet volume on the wire.

1.7.  Assumptions

   AITP assumes:

   1.  An AIP module capable of sending and receiving datagrams with
       Protocol = 1.  AITP does not require any specific AIP
       implementation beyond the SEND/RECEIVE primitives defined in
       [I-D.song-anp-aip].

   2.  Agent:// URIs are stable identifiers for the duration of an
       association.  If an agent migrates, existing associations MAY be
       invalidated.

   3.  AITP MAY be used by companion upper-layer protocols such as
       capability advertisement (ADP), task orchestration, or knowledge
       synchronisation, but does not depend on any specific upper-layer
       protocol for baseline operation.

   4.  The receiving side exposes a method-dispatch surface capable of
       mapping Method values to local handlers.  AITP does not prescribe
       how such handlers are represented internally.

1.8.  Requirements Language

   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.

2.  Terminology

   Segment  The protocol data unit of AITP.  A self-contained unit
      carrying a fixed header, method name, TLV options, and body.
      Segments are carried as AIP datagram payloads with Protocol = 1.

   Association  A stateful transport-layer relationship between two



Song & Yuan             Expires 26 September 2026              [Page 10]

Internet-Draft                    AITP                        March 2026


      agents identified by their agent:// URIs.  An association tracks
      lifecycle state, flow control windows, and circuit-breaker state.

   Request ID  A 32-bit sender-assigned identifier used to correlate
      requests with responses and to detect duplicates.  Request IDs
      MUST be unique among outstanding requests within a single
      association.  A stream is a long-lived request context identified
      by its opening Request ID.

   Method  A UTF-8 string (up to 255 octets) identifying the operation
      to be invoked on the remote agent.  Method is a first-class header
      field; upper-layer protocols rely on it for dispatch without
      defining their own invocation framing.

   Flow Control Window  A 16-bit value advertised by the receiver
      indicating the maximum number of concurrent in-flight requests it
      is willing to accept from the sender.

   Circuit Breaker  A per-association fault-isolation mechanism that
      prevents sending requests to a peer that is experiencing
      persistent failures.

3.  AITP Segment Format

   AITP segments are carried as AIP datagram payloads with Protocol = 1.
   A segment consists of a 16-octet fixed header, a variable-length
   method name (padded to a 4-octet boundary), a variable-length TLV
   options region (padded to a 4-octet boundary), and a variable-length
   body.

3.1.  Header Structure




















Song & Yuan             Expires 26 September 2026              [Page 11]

Internet-Draft                    AITP                        March 2026


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  Type |    Status     |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Body Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Method Len    |  Options Len  |            Window             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Method (UTF-8, padded to 4-octet boundary) ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Options (TLV, padded to 4-octet boundary) ...         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Body (variable)       ...                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note: one tick mark represents one bit position.

              Figure 1: AITP Segment Header (16 octets fixed)

3.2.  Field Definitions

   Version (4 bits)  Protocol version.  The current version is 1.
      Implementations MUST silently discard segments with an
      unrecognized version.

   Type (4 bits)  The segment type:






















Song & Yuan             Expires 26 September 2026              [Page 12]

Internet-Draft                    AITP                        March 2026


        +=======+==========+=========================================+
        | Value | Name     | Description                             |
        +=======+==========+=========================================+
        | 0     | REQUEST  | Invocation request.  Carries a method   |
        |       |          | name and request body.                  |
        +-------+----------+-----------------------------------------+
        | 1     | RESPONSE | Invocation response.  Carries a status  |
        |       |          | code and response body.                 |
        +-------+----------+-----------------------------------------+
        | 2     | STREAM   | Streaming data chunk.  Part of a        |
        |       |          | bidirectional stream identified by      |
        |       |          | Request ID.                             |
        +-------+----------+-----------------------------------------+
        | 3     | CONTROL  | Association lifecycle control.  Exactly |
        |       |          | one of INIT, FIN, or RST MUST be set;   |
        |       |          | invalid combinations MUST be rejected.  |
        +-------+----------+-----------------------------------------+
        | 4-15  |          | Reserved for future use.                |
        +-------+----------+-----------------------------------------+

                         Table 1: AITP Segment Types

      Implementations MUST silently discard segments with unrecognized
      Type values.

   Status (8 bits)  Result status code.  Primarily meaningful in
      RESPONSE segments; in REQUEST and STREAM segments this field
      SHOULD be set to 0 (OK).

      AITP status codes span two tiers.  Transport-processing codes
      (0-1, 3-4, 6, 9) reflect outcomes that any message-framed
      transport must report.  Handler-dispatch codes (2, 5, 7-8) report
      minimal method-invocation outcomes needed for generic
      interoperability; they allow a sender to distinguish "method not
      found" from "transport error" without requiring application-layer
      parsing.  Dispatch-level status codes are intentionally minimal
      and exist only to support generic upper-layer interoperability;
      richer application semantics belong in the response body or upper-
      layer protocols, not in the Status field.

       +========+==================+===========+=====================+
       | Value  | Name             | Tier      | Description         |
       +========+==================+===========+=====================+
       | 0      | OK               | Transport | Success.            |
       +--------+------------------+-----------+---------------------+
       | 1      | ERROR            | Transport | Generic error.      |
       +--------+------------------+-----------+---------------------+
       | 2      | NOT_FOUND        | Dispatch  | Method not          |



Song & Yuan             Expires 26 September 2026              [Page 13]

Internet-Draft                    AITP                        March 2026


       |        |                  |           | registered on the   |
       |        |                  |           | remote agent.       |
       +--------+------------------+-----------+---------------------+
       | 3      | TIMEOUT          | Transport | Request timed out   |
       |        |                  |           | (generated locally  |
       |        |                  |           | by the reliability  |
       |        |                  |           | engine).            |
       +--------+------------------+-----------+---------------------+
       | 4      | BUSY             | Transport | Remote agent is     |
       |        |                  |           | overloaded; retry   |
       |        |                  |           | later.              |
       +--------+------------------+-----------+---------------------+
       | 5      | UNAUTHORIZED     | Dispatch  | Caller lacks        |
       |        |                  |           | permission for the  |
       |        |                  |           | requested method.   |
       +--------+------------------+-----------+---------------------+
       | 6      | INVALID_REQUEST  | Transport | Malformed request   |
       |        |                  |           | (bad parameters,    |
       |        |                  |           | missing method,     |
       |        |                  |           | etc.).              |
       +--------+------------------+-----------+---------------------+
       | 7      | INTERNAL_ERROR   | Dispatch  | Unspecified         |
       |        |                  |           | internal processing |
       |        |                  |           | error on the remote |
       |        |                  |           | agent.              |
       +--------+------------------+-----------+---------------------+
       | 8      | NOT_IMPLEMENTED  | Dispatch  | Method recognized   |
       |        |                  |           | but not yet         |
       |        |                  |           | implemented.        |
       +--------+------------------+-----------+---------------------+
       | 9      | SERVICE_SHUTDOWN | Transport | Remote agent is     |
       |        |                  |           | shutting down       |
       |        |                  |           | gracefully.         |
       +--------+------------------+-----------+---------------------+
       | 10-255 |                  |           | Available for       |
       |        |                  |           | future assignment   |
       |        |                  |           | (IANA registry).    |
       +--------+------------------+-----------+---------------------+

                          Table 2: AITP Status Codes

      In summary, the four dispatch codes (NOT_FOUND, UNAUTHORIZED,
      INTERNAL_ERROR, NOT_IMPLEMENTED) form AITP's minimal generic
      invocation outcome space.  They exist so that any upper-layer
      protocol can interpret a basic method-dispatch result without
      parsing the response body.  These four outcomes are sufficient to
      distinguish transport success from basic invocation failure
      classes without committing AITP to any application-specific error



Song & Yuan             Expires 26 September 2026              [Page 14]

Internet-Draft                    AITP                        March 2026


      taxonomy; they support interoperable invocation behavior across
      heterogeneous upper-layer protocols without encoding business-
      level semantics.  Richer business semantics — task state, payment
      results, capability negotiation outcomes — MUST be carried in the
      response body or defined by upper-layer protocols, not encoded as
      AITP status codes.

   Flags (16 bits)  A bitmask of control flags:











































Song & Yuan             Expires 26 September 2026              [Page 15]

Internet-Draft                    AITP                        March 2026


        +======+========+========+==================================+
        | Bit  | Value  | Name   | Description                      |
        +======+========+========+==================================+
        | 0    | 0x0001 | ACK    | Acknowledgment.  Set in RESPONSE |
        |      |        |        | segments and CONTROL             |
        |      |        |        | acknowledgments.                 |
        +------+--------+--------+----------------------------------+
        | 1    | 0x0002 | FIN    | End of stream or association     |
        |      |        |        | close.  Signals graceful         |
        |      |        |        | termination.                     |
        +------+--------+--------+----------------------------------+
        | 2    | 0x0004 | INIT   | Association initialization       |
        |      |        |        | request.                         |
        +------+--------+--------+----------------------------------+
        | 3    | 0x0008 | RST    | Reset.  Immediately aborts the   |
        |      |        |        | association.                     |
        +------+--------+--------+----------------------------------+
        | 4    | 0x0010 | SEQ    | Sequence number present in       |
        |      |        |        | options (for ordered delivery    |
        |      |        |        | within a stream).                |
        +------+--------+--------+----------------------------------+
        | 5    | 0x0020 | NOACK  | No acknowledgment requested.     |
        |      |        |        | Used for fire-and-forget         |
        |      |        |        | semantics.                       |
        +------+--------+--------+----------------------------------+
        | 6    | 0x0040 | COMPR  | Body is compressed.  Compression |
        |      |        |        | algorithm is deployment-         |
        |      |        |        | specific.  Peers MUST either     |
        |      |        |        | agree on the compression format  |
        |      |        |        | out of band or reject compressed |
        |      |        |        | segments they cannot decode.     |
        +------+--------+--------+----------------------------------+
        | 7    | 0x0080 | SIGNED | Segment carries a cryptographic  |
        |      |        |        | signature in options.            |
        +------+--------+--------+----------------------------------+
        | 8-13 |        |        | Reserved for future use.         |
        +------+--------+--------+----------------------------------+
        | 14   | 0x4000 | CBOPEN | Circuit breaker: half-open probe |
        |      |        |        | request.                         |
        +------+--------+--------+----------------------------------+
        | 15   | 0x8000 | CBTRIP | Circuit breaker: tripped         |
        |      |        |        | notification to peer.            |
        +------+--------+--------+----------------------------------+

                           Table 3: AITP Flag Bits

   Request ID (32 bits)  A sender-assigned identifier for request-




Song & Yuan             Expires 26 September 2026              [Page 16]

Internet-Draft                    AITP                        March 2026


      response correlation and deduplication.  Each new request MUST use
      a unique Request ID among outstanding requests within the same
      association.  RESPONSE segments MUST echo the Request ID of the
      corresponding REQUEST.

      A stream-opening STREAM segment consumes a Request ID for the
      lifetime of the stream.  The ID MUST NOT be reused for another
      request or stream within the same association until the stream has
      terminated (FIN exchanged or RST received).

   Body Length (32 bits)  The length in octets of the body: the request
      body in REQUEST segments, or the response body in RESPONSE
      segments.  A Body Length of 0 is valid (e.g., for CONTROL segments
      or parameterless requests).

   Method Len (8 bits)  The length in octets of the UTF-8 method name.
      Maximum 255.  A value of 0 is permitted for CONTROL segments that
      carry no method.  The method field is padded to a 4-octet boundary
      with zero-valued octets.

   Options Len (8 bits)  The total length in octets of the TLV options
      region, including any padding.  Maximum 255.  The options region
      MUST be padded to a 4-octet boundary.

   Window (16 bits)  The sender's advertised receive window: the number
      of concurrent in-flight requests the sender is willing to accept.
      The receiver uses this value for flow control (see Section 6).
      The initial value is deployment-specific; implementations MAY
      advertise any value from 1 to 65535.

3.3.  TLV Options

   The options region carries zero or more Type-Length-Value (TLV)
   encoded options, following the same encoding as AIP options:

   +--------+--------+----------------------------+
   |  Type  | Length  |    Data (Length octets)     |
   +--------+--------+----------------------------+
     1 byte   1 byte    variable












Song & Yuan             Expires 26 September 2026              [Page 17]

Internet-Draft                    AITP                        March 2026


   +=========+===========+==========+=================================+
   | Type    | Name      | Length   | Description                     |
   +=========+===========+==========+=================================+
   | 1       | Timeout   | 4        | Request timeout in milliseconds |
   |         |           |          | (uint32, big-endian).  Included |
   |         |           |          | in REQUEST segments to advise   |
   |         |           |          | the receiver of the caller's    |
   |         |           |          | deadline.                       |
   +---------+-----------+----------+---------------------------------+
   | 2       | SeqNum    | 4        | Sequence number (uint32, big-   |
   |         |           |          | endian).  Used with the SEQ     |
   |         |           |          | flag for ordered delivery       |
   |         |           |          | within a stream.                |
   +---------+-----------+----------+---------------------------------+
   | 3       | AckNum    | 4        | Acknowledgment number (uint32,  |
   |         |           |          | big-endian).  Acknowledges      |
   |         |           |          | receipt of a specific sequence  |
   |         |           |          | number.                         |
   +---------+-----------+----------+---------------------------------+
   | 4       | Timestamp | 8        | UTC Unix timestamp in           |
   |         |           |          | microseconds (uint64, big-      |
   |         |           |          | endian).  Used for latency      |
   |         |           |          | measurement.                    |
   +---------+-----------+----------+---------------------------------+
   | 5       | Signature | variable | Cryptographic signature over    |
   |         |           |          | the segment.  Used with the     |
   |         |           |          | SIGNED flag.                    |
   +---------+-----------+----------+---------------------------------+
   | 6       | Metadata  | variable | Key-value metadata (encoding is |
   |         |           |          | application-defined).           |
   +---------+-----------+----------+---------------------------------+
   | 7-127   |           |          | Available for future assignment |
   |         |           |          | (IANA).                         |
   +---------+-----------+----------+---------------------------------+
   | 128-254 |           |          | Available for experimental /    |
   |         |           |          | private use.                    |
   +---------+-----------+----------+---------------------------------+
   | 255     |           |          | Reserved.                       |
   +---------+-----------+----------+---------------------------------+

                      Table 4: Standard AITP Options

   The entire options region MUST be padded to a 4-octet boundary.
   Implementations MUST ignore unrecognized option types (skip by
   reading Type and Length, then advancing Length octets).






Song & Yuan             Expires 26 September 2026              [Page 18]

Internet-Draft                    AITP                        March 2026


4.  Association State Machine

   An association is a stateful transport-layer relationship between two
   agents, identified by the (localURI, remoteURI) pair.  Each
   association tracks lifecycle state, flow control parameters, and
   circuit-breaker state.

4.1.  Association States

      +=======+=============+======================================+
      | Value | Name        | Description                          |
      +=======+=============+======================================+
      | 0     | CLOSED      | No association exists.  Initial and  |
      |       |             | terminal state.                      |
      +-------+-------------+--------------------------------------+
      | 1     | LISTEN      | Waiting for an incoming INIT from a  |
      |       |             | remote peer.                         |
      +-------+-------------+--------------------------------------+
      | 2     | INIT_SENT   | INIT sent; awaiting INIT+ACK from    |
      |       |             | the remote peer.                     |
      +-------+-------------+--------------------------------------+
      | 3     | INIT_RECV   | INIT received; INIT+ACK sent;        |
      |       |             | awaiting first data exchange.        |
      +-------+-------------+--------------------------------------+
      | 4     | OPEN        | Association fully established.  Data |
      |       |             | exchange is permitted.               |
      +-------+-------------+--------------------------------------+
      | 5     | HALF_CLOSED | Local side has sent or received FIN; |
      |       |             | no new requests accepted, but in-    |
      |       |             | flight responses may still arrive.   |
      +-------+-------------+--------------------------------------+
      | 6     | DRAINING    | Both sides have exchanged FIN;       |
      |       |             | draining in-flight segments before   |
      |       |             | transitioning to CLOSED.             |
      +-------+-------------+--------------------------------------+

                     Table 5: AITP Association States

4.2.  State Transitions

   The following transitions are valid.  Any other transition MUST be
   rejected as a protocol error.









Song & Yuan             Expires 26 September 2026              [Page 19]

Internet-Draft                    AITP                        March 2026


                      +--------+
                      | CLOSED |<-----------------------+
                      +--------+                        |
                       /      \                         |
               passive/        \active                  |
                     v          v                       |
              +--------+   +-----------+               |
              | LISTEN |   | INIT_SENT |               |
              +--------+   +-----------+               |
                     \          /                       |
             INIT    \        / INIT+ACK                |
             recv     v      v                          |
                 +-----------+                          |
                 | INIT_RECV |                          |
                 +-----------+                          |
                       |                                |
                       v                                |
                  +--------+                           |
                  |  OPEN  |-----------+               |
                  +--------+           |               |
                   /      \            |               |
              FIN /        \ FIN      RST              |
                 v          v          |               |
          +-------------+ +----------+|               |
          | HALF_CLOSED | | DRAINING |+               |
          +-------------+ +----------+                |
                 \            /                        |
                  \          /  all drained            |
                   v        v                          |
                      +--------+                       |
                      | CLOSED |                       |
                      +--------+-----------------------+

   Valid transitions from each state:

   CLOSED  LISTEN (passive open) or INIT_SENT (active open).

   LISTEN  INIT_RECV (INIT received) or CLOSED (abort).

   INIT_SENT  OPEN (INIT+ACK received) or CLOSED (timeout/abort).

   INIT_RECV  OPEN (handshake complete) or CLOSED (abort).

   OPEN  HALF_CLOSED (FIN sent/received), DRAINING, or CLOSED (RST).

   HALF_CLOSED  DRAINING or CLOSED.

   DRAINING  CLOSED (all segments drained).



Song & Yuan             Expires 26 September 2026              [Page 20]

Internet-Draft                    AITP                        March 2026


4.3.  Lazy Association Establishment

   The explicit INIT/INIT+ACK handshake defined in Section 4.2 is the
   fully specified, interoperable baseline.  Implementations that
   require mutual confirmation before data exchange MUST use this
   handshake.

   LISTEN exists to define the passive side of the explicit
   interoperable baseline; implementations that prefer lazy outbound
   establishment still need to accept incoming explicit INIT exchanges.

   As an optimization, implementations MAY use lazy association
   establishment: when a module needs to send a request to a peer with
   no existing association, it creates an association and transitions
   directly through INIT_SENT to OPEN without an explicit on-wire
   handshake.  This is an optimization profile for deployments whose
   lower layer (e.g., libp2p with peer authentication) already
   guarantees peer identity, making the INIT round-trip redundant.

   Implementations MUST document whether they use the explicit handshake
   or lazy establishment as their default mode, and MUST accept incoming
   INIT segments regardless of which mode they prefer for outgoing
   associations.  Interoperability claims for AITP MUST be evaluated
   against the explicit- handshake baseline.

5.  Reliability Engine

   AITP provides reliability through ACK-based tracking, retransmission
   with exponential backoff, and deduplication.  The reliability engine
   operates on a per-request basis: each outgoing REQUEST that does not
   carry the NOACK flag is tracked until a matching RESPONSE arrives or
   the request times out.

5.1.  ACK Tracking

   When a REQUEST segment is sent (without the NOACK flag), the sender
   registers the Request ID in a pending-request table.  When a RESPONSE
   segment arrives with a matching Request ID, the pending entry is
   removed and the response is delivered to the caller.

   If the NOACK flag is set, the sender does not track the request and
   does not expect a response.  The receiver SHOULD NOT send a response
   for NOACK requests, but MAY still invoke the method handler for side
   effects.







Song & Yuan             Expires 26 September 2026              [Page 21]

Internet-Draft                    AITP                        March 2026


5.2.  Retransmission

   If no RESPONSE arrives within the retransmission timeout, the sender
   retransmits the REQUEST segment.  The retransmission timeout uses
   exponential backoff:

   timeout(n) = InitialTimeout * BackoffFactor^n

   where n = retransmission attempt number (0-based)

   After MaxRetries retransmissions without a response, the reliability
   engine generates a local TIMEOUT response (Status = TIMEOUT) and
   delivers it to the caller.  Deployment-specific defaults are expected
   for InitialTimeout, MaxRetries, and BackoffFactor; implementations
   SHOULD document their default values.

5.3.  Deduplication

   Retransmitted REQUEST segments carry the same Request ID as the
   original.  The receiver MUST maintain a deduplication cache keyed by
   Request ID.  If an incoming REQUEST matches a recently-seen Request
   ID, the receiver MUST silently discard it (the response to the
   original request will serve as the acknowledgment).

   Implementations MUST bound the deduplication cache size and entry
   lifetime to prevent unbounded resource consumption; deployment-
   specific defaults are expected.

6.  Flow Control

   AITP flow control is request-concurrency based, not byte-volume
   based.  This is a key departure from traditional transports: the
   Window field counts outstanding REQUEST operations, not octets.  The
   peer MUST track the remote window and MUST NOT have more in-flight
   requests than the advertised window allows.

   Before sending a REQUEST, the sender checks that its in-flight count
   is below the peer's advertised window and that the circuit breaker
   allows sending (see Section 7).  If either check fails, the send MUST
   be rejected with an appropriate error to the upper layer.

   When a RESPONSE arrives, the sender decrements its in-flight count
   and updates the peer's window from the RESPONSE's Window field.  This
   allows the receiver to dynamically adjust its capacity.

   The initial window size is deployment-specific.  Implementations MAY
   advertise any value from 1 to 65535; a value of 16 is a reasonable
   starting point for general-purpose agents.



Song & Yuan             Expires 26 September 2026              [Page 22]

Internet-Draft                    AITP                        March 2026


   The Window field governs concurrent in-flight REQUEST operations
   only.  STREAM chunks are subject to stream- specific bounded
   buffering and back-pressure (see Section 8.2), not request-window
   accounting.  An active stream consumes one Request ID slot for its
   lifetime but does not consume additional window capacity for
   subsequent STREAM chunks.

7.  Circuit Breaker

   Each association maintains a per-peer circuit breaker to prevent
   cascading failures when a remote agent is unavailable or consistently
   failing.  The circuit breaker has three states:

     +=======+===========+===========================================+
     | Value | Name      | Description                               |
     +=======+===========+===========================================+
     | 0     | CLOSED    | Normal operation.  Requests pass through. |
     +-------+-----------+-------------------------------------------+
     | 1     | OPEN      | Tripped.  All requests are rejected       |
     |       |           | immediately without being sent.           |
     +-------+-----------+-------------------------------------------+
     | 2     | HALF_OPEN | Probing.  One request is allowed through  |
     |       |           | to test recovery.                         |
     +-------+-----------+-------------------------------------------+

                      Table 6: Circuit Breaker States

7.1.  Circuit Breaker Transitions

                     success
               +---<----------<---+
               |                  |
               v                  |
           +--------+        +----------+
           | CLOSED |------->| HALF_OPEN|
           +--------+  reset +----------+
               |        timer       |
               v                    v failure
           +--------+               |
           |  OPEN  |<--------------+
           +--------+
           (failures >= threshold)

   *CLOSED → OPEN:* When the consecutive failure count reaches the
   failure threshold, the circuit breaker transitions to OPEN.
   Implementations SHOULD use deployment-specific defaults for the
   threshold.




Song & Yuan             Expires 26 September 2026              [Page 23]

Internet-Draft                    AITP                        March 2026


   *OPEN → HALF_OPEN:* After a reset timeout elapses since the last
   failure, the circuit breaker transitions to HALF_OPEN, allowing one
   probe request.

   *HALF_OPEN → CLOSED:* If the probe request succeeds, the circuit
   breaker resets to CLOSED and the failure count is cleared.

   *HALF_OPEN → OPEN:* If the probe request fails, the circuit breaker
   returns to OPEN.

7.2.  Circuit Breaker Flag Bits

   The CBOPEN flag (bit 14) MAY be set on a probe request to inform the
   remote peer that this is a circuit-breaker probe.  The CBTRIP flag
   (bit 15) MAY be set by a peer to proactively notify the sender that
   it should trip its circuit breaker.  These flags are advisory;
   implementations are not required to honor them.

8.  Streaming

   AITP supports bidirectional streaming for long-running exchanges such
   as inference generation, file transfer, or multi-turn conversations.
   A stream is identified by its Request ID and uses STREAM segments
   (Type = 2).

8.1.  Stream Lifecycle

   1.  *Initiation.*

       The initiator sends the first STREAM segment with a fresh Request
       ID and a method name.  If the receiver has a registered stream
       handler for that method, a new stream is created.  If not, the
       receiver returns a NOT_FOUND RESPONSE.

   2.  *Data exchange.*

       Both sides send STREAM segments with the same Request ID.  Each
       segment carries a body chunk.  The SEQ flag and SeqNum option MAY
       be used for ordered delivery within a stream.

   3.  *Termination.*

       Either side sends a STREAM segment with the FIN flag to signal
       end of stream.  Upon receiving FIN, the receiving side closes its
       chunk channel.  Both sides SHOULD release stream resources after
       FIN.





Song & Yuan             Expires 26 September 2026              [Page 24]

Internet-Draft                    AITP                        March 2026


8.2.  Back-Pressure

   Stream receivers maintain a bounded buffer for incoming chunks.  If
   the buffer is full, incoming STREAM segments MAY be dropped (back-
   pressure).  The sender SHOULD use the association's flow control
   window and application-level acknowledgments to regulate sending
   rate.

8.3.  Large Payload Guidance

   AIP limits each datagram payload to 65535 octets.  Upper-layer
   protocols whose response objects may exceed this limit SHOULD use one
   of the following strategies:

   1.  *Streaming.*

       Use an AITP STREAM exchange to deliver the response
       incrementally.  This is appropriate for variable-size payloads
       such as large Agent Cards, discovery result sets, or inference
       outputs.  Each STREAM chunk carries a portion of the response;
       the receiver reassembles them in SeqNum order (when the SEQ flag
       is used) or in arrival order.

   2.  *Application-level pagination.*

       Define "offset" and "limit" parameters in the REQUEST body so
       that the caller can page through a large result set with multiple
       REQUEST/RESPONSE round trips.  This is appropriate for
       enumeration operations (e.g., ans.lookup, adp.discover) where the
       total result count may be large but each page fits in a single
       datagram.

   Upper-layer methods that are expected to return large payloads SHOULD
   document which strategy they use and whether the method's tool
   descriptor sets streaming = true.

9.  Segment Processing

   This section defines AITP's complete processing model.  The send and
   receive paths described below depend only on AIP's SEND/RECEIVE
   primitives and the local association/reliability state.  No knowledge
   of upper-layer application protocols is required to implement these
   paths.

9.1.  Sending a Request

   When the upper layer invokes SEND-REQUEST or SEND-ONEWAY:




Song & Yuan             Expires 26 September 2026              [Page 25]

Internet-Draft                    AITP                        March 2026


   1.  *Ensure association.*

       Look up or create an association for the destination agent://
       URI.  If lazy establishment is used, transition directly to OPEN.
       If explicit handshake is required, send CONTROL+INIT and wait for
       CONTROL+INIT+ACK.

   2.  *Check flow control.*

       Verify that the in-flight count is below the peer's advertised
       window and the circuit breaker allows sending.  If not, return an
       error to the caller.

   3.  *Construct the segment.*

       Build the 16-octet fixed header with Version = 1, Type = REQUEST
       (or STREAM), Status = OK, appropriate Flags, a fresh Request ID,
       Body Length, Method Len, Options Len, and the local receive
       Window.  Serialize method, options, and body.

   4.  *Register for tracking (if not NOACK).*

       Add the Request ID to the reliability engine's pending table and
       start the retransmission timer.

   5.  *Transmit via AIP.*

       Call AIP's SEND with source = local agent:// URI, destination =
       remote agent:// URI, protocol = 1 (AITP), and the serialized
       segment as payload.

9.2.  Receiving a Segment

   When AIP delivers a datagram with Protocol = 1 to the AITP module:

   1.  *Deserialize.*

       Decode the fixed header.  If the Version is unrecognized or the
       data is truncated, discard.

   2.  *Update association.*

       Look up or create the association for the source URI.  Update the
       last-seen timestamp.  If the segment carries a non-zero Window,
       update the peer's advertised window.

   3.  *Dispatch by Type.*




Song & Yuan             Expires 26 September 2026              [Page 26]

Internet-Draft                    AITP                        March 2026


       *REQUEST:* Check deduplication.  If duplicate, discard.  Look up
       the method handler.  If not found, send a RESPONSE with Status =
       NOT_FOUND.  Otherwise, invoke the handler asynchronously.  When
       the handler completes, send a RESPONSE with the handler's status
       and response body (unless NOACK).

       *RESPONSE:* Deliver to the reliability engine, which matches by
       Request ID and wakes the waiting caller.  Update flow control:
       decrement in-flight count and record circuit-breaker success/
       failure based on the status code.

       *STREAM:* If the Request ID matches an active stream, deliver the
       chunk to the stream's buffer.  If FIN is set, close the stream's
       input channel.  If no stream exists, check for a stream handler
       and create a new stream.  If no handler, send RESPONSE with
       NOT_FOUND.

       *CONTROL:* Verify that exactly one of INIT, FIN, or RST is set.
       Invalid CONTROL flag combinations MUST NOT create, mutate, or
       tear down association state; discard the segment.  INIT →
       transition association to INIT_RECV then OPEN, reply with
       CONTROL+INIT+ACK; FIN → transition to HALF_CLOSED then DRAINING,
       reply with CONTROL+FIN+ACK, then close; RST → transition
       immediately to CLOSED.

10.  Interfaces

10.1.  Upper Layer Interface (Application Protocols)

   AITP provides the following abstract service primitives to upper-
   layer protocols.  These are protocol-level abstractions; actual API
   bindings are implementation- defined.

   SEND-REQUEST(destination, method, request-body, timeout) ->
   (status, response-body)  Send a request and wait for a response.

      *  *destination* -- agent:// URI of the remote agent.

      *  *method* -- UTF-8 method name (max 255 octets).

      *  *request-body* -- opaque payload bytes.

      *  *timeout* -- optional request deadline.

      Returns: status code and response body, or a transport error.

   SEND-ONEWAY(destination, method, request-body) -> error  Send a one-




Song & Yuan             Expires 26 September 2026              [Page 27]

Internet-Draft                    AITP                        March 2026


      way message with no response expected.  Sets the NOACK flag.
      Returns only a send error, not a remote result.

   OPEN-STREAM(destination, method) -> stream  Initiate a bidirectional
      stream.  Returns a stream handle through which the caller sends
      and receives STREAM chunks.

   REGISTER-HANDLER(method, handler)  Register a handler that will be
      invoked when an incoming REQUEST arrives for the given method.

   REGISTER-STREAM-HANDLER(method, handler)  Register a handler that
      will be invoked when an incoming STREAM segment arrives for the
      given method with no active stream.

   Monitoring and statistics primitives (e.g., counters for requests
   sent, streams active) are implementation concerns and are not
   specified by this document.  Deployment-specific counters, tracing
   hooks, and operational telemetry are expected to be defined by
   implementation profiles rather than by this protocol specification.

10.2.  Lower Layer Interface (AIP)

   AITP depends on AIP for datagram delivery.  The interface consists
   of:

   AIP.SEND(source, destination, protocol=1, payload)  Sends an AITP
      segment as an AIP datagram.  AITP always uses Protocol = 1.

   AIP.RECEIVE callback (Protocol = 1)  AIP dispatches incoming
      datagrams with Protocol = 1 to AITP's HandleSegment entry point.

   Note: AIP assigns Protocol values 2 (ANS) and 3 (ADP) for potential
   future direct-datagram exchanges that bypass AITP.  In normal
   operation, ANS and ADP methods are carried as AITP segments with
   Protocol = 1.  See AIP [I-D.song-anp-aip], Section 4.

11.  Security Considerations

11.1.  Segment Authentication

   AITP defines the SIGNED flag and Signature option for segment- level
   authentication.  When the SIGNED flag is set, implementations SHOULD
   verify the signature before processing the segment.  The signature
   algorithm and key binding are defined by the deployment context; AITP
   does not mandate a specific algorithm.






Song & Yuan             Expires 26 September 2026              [Page 28]

Internet-Draft                    AITP                        March 2026


   AITP segment signatures protect invocation-layer provenance and
   segment integrity, while AIP signatures protect the enclosing
   datagram.  Deployments MAY use either layer or both, depending on
   their threat model, and SHOULD use at least one.

11.2.  Replay Attacks

   AITP's deduplication cache (Section 5.3) provides protection against
   replayed REQUEST segments.  The Timestamp option provides an
   additional freshness signal.  Implementations SHOULD reject segments
   with timestamps outside a deployment-specific freshness window.

11.3.  Resource Exhaustion

   Flow control (Section 6) limits the number of concurrent in-flight
   requests per association.  The circuit breaker (Section 7) prevents
   runaway retries to failing peers.  Implementations MUST bound the
   deduplication cache, pending-request table, and stream buffer sizes
   to prevent unbounded memory growth.

11.4.  Method Authorization

   AITP provides the UNAUTHORIZED status code (5) for method- level
   access control.  The authorization mechanism is application-defined;
   AITP does not prescribe any particular access control model.
   Implementations SHOULD document their authorization strategy.

11.5.  Privacy

   Method names and request/response bodies are visible to network
   participants that can observe AIP datagrams.  AITP does not provide
   payload confidentiality.  Applications requiring confidentiality
   SHOULD encrypt payloads at the application layer or use privacy-
   preserving lower-layer routing mechanisms.

11.6.  Association State Attacks

   Because CONTROL segments (INIT, FIN, RST) can create, close, or abort
   associations, unauthenticated control segments can induce association
   churn or exhaust the association state table.

   Deployments SHOULD authenticate peers (via AIP SIG, AITP SIGNED, or
   lower-layer mechanisms) before creating persistent association state.
   Implementations SHOULD rate-limit new association creation per source
   URI and MUST bound the total number of concurrent associations to
   prevent unbounded state growth.





Song & Yuan             Expires 26 September 2026              [Page 29]

Internet-Draft                    AITP                        March 2026


11.7.  Dispatch-Level Information Leakage

   The dispatch-level status codes NOT_FOUND (2), UNAUTHORIZED (5), and
   NOT_IMPLEMENTED (8) reveal information about the methods registered
   on the remote agent.  An adversary can enumerate supported methods by
   sending probe requests and observing which status code is returned.

   Deployments concerned with method enumeration MAY coarsen dispatch-
   level status codes into a generic ERROR or UNAUTHORIZED response for
   unrecognized or unauthorized callers, at the cost of reduced
   diagnostic fidelity for legitimate clients.

12.  IANA Considerations

   This document requests the creation of four new IANA registries.

12.1.  AITP Segment Type Registry

   Registry with 4-bit values (0-15).  Registration policy:
   Specification Required.  Initial values in Table 1.

12.2.  AITP Status Code Registry

   Registry with 8-bit values (0-255).  Registration policy:
   Specification Required for 0-127, First Come First Served for
   128-254.  Value 255 is reserved.  Initial values in Table 2.

12.3.  AITP Flag Bits Registry

   Registry with 16 bit positions (0-15).  Registration policy:
   Specification Required.  Initial values in Table 3.

12.4.  AITP Option Type Registry

   Registry with 8-bit values (0-255).  Registration policy:
   Specification Required for 0-127, First Come First Served for
   128-254, value 255 reserved.  Initial values in Table 4.

13.  Implementation Status

   Per [RFC7942], this section records known implementations.

13.1.  ClawNet

   Organization  ChatChatTech

   URL  https://github.com/ChatChatTech/ClawNet




Song & Yuan             Expires 26 September 2026              [Page 30]

Internet-Draft                    AITP                        March 2026


   Description  Go implementation of the full ANP suite.  The AITP
      module (atp/ directory) implements the 16-octet fixed header,
      segment type demux, TLV options, association state machine,
      reliability engine with exponential-backoff retransmission,
      receiver-advertised flow control, per-association circuit breaker,
      bidirectional streaming, and the full 10-code status code set.
      The reference implementation is being completed as part of the
      full ClawNet stack conforming to AIP, ANS, AITP, and ADP; protocol
      boundaries are exercised in integration tests across the stack.

   Maturity  Alpha

   Coverage  Implemented:

      *  Segment codec (16-octet header, type demux, TLV options)

      *  Association state machine (7 states, validated transitions)

      *  Reliability engine (ACK tracking, exponential-backoff
         retransmission, dedup)

      *  Receiver-advertised flow control (Window)

      *  Per-association circuit breaker (CLOSED/OPEN/HALF_OPEN)

      *  Synchronous invocation and fire-and-forget

      *  Bidirectional streaming with FIN termination

      *  Lazy association establishment

      Under integration:

      *  Segment-level signature verification (SIGNED flag)

      *  Body compression (COMPR flag)

      *  Explicit INIT/FIN handshake integration tests

      The items under integration affect robustness and efficiency only;
      they do not alter the wire format, segment semantics, or protocol
      boundaries defined in this document.

   Language  Go

   License  Open source

   Contact  ink@chatchat.space



Song & Yuan             Expires 26 September 2026              [Page 31]

Internet-Draft                    AITP                        March 2026


14.  References

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.song-anp-aip]
              Song, J., "Agent Internet Protocol (AIP)", Work in
              Progress, Internet-Draft, draft-song-anp-aip-01, March
              2026, <https://datatracker.ietf.org/doc/html/draft-song-
              anp-aip-01>.

14.2.  Informative References

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [I-D.song-anp-ans]
              Song, J., "Agent Name System (ANS)", Work in Progress,
              Internet-Draft, draft-song-anp-ans-00, March 2026,
              <https://datatracker.ietf.org/doc/html/draft-song-anp-ans-
              00>.

   [I-D.song-anp-adp]
              Song, J., "Agent Description Protocol (ADP)", Work in
              Progress, Internet-Draft, draft-song-anp-adp-00, March
              2026, <https://datatracker.ietf.org/doc/html/draft-song-
              anp-adp-00>.

Appendix A.  Implementation Alignment Notes

   This appendix documents the relationship between this specification
   and the reference implementation in the ClawNet atp/ directory.









Song & Yuan             Expires 26 September 2026              [Page 32]

Internet-Draft                    AITP                        March 2026


   +===========+==========================+===========================+
   |Spec       | Go Symbol                | Notes                     |
   |Concept    |                          |                           |
   +===========+==========================+===========================+
   |Segment    | atp.SegmentType          | TypeRequest(0),           |
   |Type       |                          | TypeResponse(1),          |
   |           |                          | TypeStream(2),            |
   |           |                          | TypeControl(3).           |
   +-----------+--------------------------+---------------------------+
   |Status Code| atp.StatusCode           | Full 10-code set:         |
   |           |                          | StatusOK(0) through       |
   |           |                          | StatusServiceShutdown(9). |
   +-----------+--------------------------+---------------------------+
   |Flags      | atp.Flags                | FlagACK(0x1),             |
   |           |                          | FlagFIN(0x2),             |
   |           |                          | FlagINIT(0x4),            |
   |           |                          | FlagRST(0x8),             |
   |           |                          | FlagSEQ(0x10),            |
   |           |                          | FlagNOACK(0x20),          |
   |           |                          | FlagCOMPR(0x40),          |
   |           |                          | FlagSIGNED(0x80),         |
   |           |                          | FlagCBOPEN(0x4000),       |
   |           |                          | FlagCBTRIP(0x8000).       |
   +-----------+--------------------------+---------------------------+
   |Fixed      | fixedHeaderSize = 16     | Byte layout per Figure 1. |
   |Header     |                          |                           |
   +-----------+--------------------------+---------------------------+
   |Options    | atp.Option,              | TLV encoding with 4-byte  |
   |           | OptTimeout..OptMetadata  | alignment.                |
   +-----------+--------------------------+---------------------------+
   |Association| atp.Association          | 7-state FSM per Table 5.  |
   +-----------+--------------------------+---------------------------+
   |Circuit    | atp.CBState              | CBClosed(0), CBOpen(1),   |
   |Breaker    |                          | CBHalfOpen(2).            |
   +-----------+--------------------------+---------------------------+
   |Reliability| atp.Reliability          | Track(), Resolve(),       |
   |           |                          | IsDuplicate(),            |
   |           |                          | retransmitLoop().         |
   +-----------+--------------------------+---------------------------+
   |Flow       | Association.AcquireSend/ | Window-based concurrency  |
   |Control    | ReleaseSend              | limiting.                 |
   +-----------+--------------------------+---------------------------+
   |Module     | atp.Module               | SEND-REQUEST → Call(),    |
   |           |                          | SEND-ONEWAY →             |
   |           |                          | FireAndForget(),          |
   |           |                          | HandleSegment(),          |
   |           |                          | REGISTER-HANDLER →        |
   |           |                          | Handle(), REGISTER-       |



Song & Yuan             Expires 26 September 2026              [Page 33]

Internet-Draft                    AITP                        March 2026


   |           |                          | STREAM-HANDLER →          |
   |           |                          | HandleStream().           |
   +-----------+--------------------------+---------------------------+
   |Stream     | atp.Stream               | Recv(), Send(), Close()   |
   |           |                          | with FIN termination.     |
   +-----------+--------------------------+---------------------------+
   |AIP        | atp.AIPSender            | SendRaw(ctx, src, dst,    |
   |Interface  |                          | proto, payload).          |
   +-----------+--------------------------+---------------------------+

                   Table 7: Spec-Implementation Mapping

Authors' Addresses

   Jinke Song
   Dept. of CSE, Hong Kong University of Science and Technology
   Email: ink@chatchat.space


   Mu Yuan
   Dept. of IE, The Chinese University of Hong Kong
   Email: muyuan@cuhk.edu.hk





























Song & Yuan             Expires 26 September 2026              [Page 34]
