Agent Invocation Transport Protocol (AITP)

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

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

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

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

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

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

3.1. Header Structure

 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.

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

Table 1: AITP Segment Types

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.

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

Table 2: AITP Status Codes

Value	Name	Tier	Description
0	OK	Transport	Success.
1	ERROR	Transport	Generic error.
2	NOT_FOUND	Dispatch	Method not 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).

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

Table 3: AITP Flag Bits

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.

Request ID (32 bits)

A sender-assigned identifier for request-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

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

4.1. Association States

4.2. State Transitions

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

                   +--------+
                   | 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).¶

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

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

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

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

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.1. Sending a Request

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

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

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

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

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.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.1. ClawNet

Organization

ChatChatTech¶

URL

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

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¶