| Internet-Draft | LLT Protocol v1.0 | June 2026 |
| Benazzouz | Expires 11 December 2026 | [Page] |
Large Language Transport (LLT) v1.0 is a specialized application-layer and transport-layer protocol designed to support real-time streaming, routing, and processing of Large Language Model (LLM) cognitive outputs. Unlike traditional serialization formats or line-based text stream layouts, LLT represents structured cognitive steps—such as internal thoughts, incremental execution tokens, self-revising contextual markers, tool coordination, and conversational state controls—as discrete, prioritizable, cryptographic transport frames. LLT v1.0 defines standard transport semantics over TCP, UDP broadcasts, and QUIC multiplexing to support highly efficient, low-latency, multi-agent cognitive synchronization across decentralized network topographies.¶
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 11 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Modern Large Language Model (LLM) interactions rely heavily on Server-Sent Events (SSE) or simple WebSocket text channels streaming unstructured token buffers. While suitable for simple consumer-facing chatbots, these systems suffer from deep architectural limitations when coordinating advanced agentic and cognitive multi-agent workflows:¶
The Large Language Transport (LLT) Protocol solves these problems by elevating LLM cognitive steps into native, typed, multiplexed protocol frames. By defining a robust binary framing layer, an explicit cognitive state-machine, and modern transport-to-stream bindings (such as QUIC multiplexed streams), LLT makes agent reasoning fully predictable, secure, and low-latency.¶
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.¶
LLT models LLM interactions as active, stateful cognitive streams. An LLT stream does not merely carry text tokens; it models the active internal thought trajectory of an agentic entity as it reasons, coordinates, calls external systems, and formulates terminal responses.¶
+---------------------------------------------+
| LLT Agent Web |
+---------------------------------------------+
|
[Goal Input Frame]
v
+---------------------------------------------+
| Cognitive Router Engine |
+---------------------------------------------+
| (Resolve Semantic Uri / agent://planner)
v
+-----------------------+ +-----------------------+
| Agent: NLP Planner | QUIC | Agent: Executor |
| State: THINKING <====================> State: WAITING_FOR_TOOL|
+-----------------------+ Streams +-----------------------+
¶
Every LLT frame MUST conform strictly to one of the following message type profiles. The numeric values designated below are binding and MUST NOT be dynamically reassigned:¶
PAUSE (temporarily halts processing during long-running tool executions), RESUME (restores processing), and CANCEL (instantly aborts calculation).¶
An LLT Agent is modeled as a state transition machine. Permitted transitions are illustrated in the diagram below:¶
+------------+
| THINKING | <---------+
+------------+ |
| | Tool Result
v |
+------------+ +-------------------+
| STREAMING | --> | WAITING_FOR_TOOL |
+------------+ +-------------------+
| |
v v
+------------+ +-------------------+
| REVISING | --> | INTERRUPTED | (Error/Cancel)
+------------+ +-------------------+
| |
v v
+------------+ |
| COMPLETED | <-------------+
+------------+
¶
The states are defined as follows:¶
To maintain high reliability in multi-agent environments, LLT designates four distinct cognitive error classifications:¶
LLT MUST support both JSON Framing and Binary Framing encoding profiles. Client and server systems MUST negotiate the active framing profile during the initial network handshake.¶
A standard LLT JSON packet IS structured as a single, valid JSON object. It MUST contain the following outer keys:¶
{
"type": 3,
"stream_id": 412,
"flags": 1,
"sender_uri": "agent://nlp_planner",
"recipient_uri": "agent://diagnostician",
"payload": {
"text": "Initiating physical diagnostics..."
},
"signature": "d3b07384d113ed..."
}
¶
Where:¶
type: Integer representing the cognitive frame type (e.g. 3 for TOKEN).¶
stream_id: Big-endian unsigned 16-bit integer designating multiplexed channels.¶
flags: Integer bitmask carrying protocol modifiers (SIGNED=0x01, MULTIPLEXED=0x02, COMPRESSED=0x04, FINAL=0x08).¶
sender_uri: A UTF-8 semantic string identifier of the originating agent/service.¶
recipient_uri: UTF-8 semantic string identifier of the target destination.¶
payload: An arbitrary JSON dictionary conforming to the payload requirements of the frame's type.¶
signature: Optional 64-byte hex-encoded Ed25519 cryptographic signature (present only if flags & 0x01 is true).¶
To maintain microsecond latency constraints, the binary encoding profile enforces a strict 16-byte fixed-width header followed by variable-length fields:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Header: 'LLT\x01' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type 1B | Flags 1B | Stream ID 2B (BE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Len 2B (BE) | Recipient Len 2B (BE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length 4B (BE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Header layout fields are defined as:¶
0x4C 0x4C 0x54 0x01 (ASCII bytes "LLT" paired with version byte 0x01).¶
To support dynamic capability resolution without static network endpoints, LLT formalizes the LLT Discovery Protocol (LLT-DP). This sub-protocol defines how cooperative agent nodes locate, advertise, and bind system capabilities over physical channels.¶
An active agent node MUST register its capability utilizing the REGISTER (0x01) message type. The payload of a REGISTER frame MUST conform to the following JSON schema:¶
{
"uri": "agent://appliance-identifier",
"port": 8001,
"capability_name": "identify household appliances",
"capability_description": "Translates vague descriptive user context (e.g. 'washing machine kept rattling') into precise hardware make/model series and specifications."
}
¶
The properties are defined as:¶
uri: The canonical semantic identifier URI of the registered agent (MUST be unique within the cooperative cluster).¶
port: The local active TCP or UDP port number the registering agent is listening on.¶
capability_name: A short, human-readable name string describing the provided skill.¶
capability_description: A detailed descriptive paragraph containing key semantic contexts to support fuzzy neural classification and routing matches.¶
A searching node (such as an XML Planner) initiates query resolution by dispatching a DISCOVER (0x02) frame. The payload of the DISCOVER frame MUST conform to the following JSON schema:¶
{
"description": "identify household appliances"
}
¶
Where description serves as the semantic target string. The matching node or central capability registry MUST evaluate the semantic affinity (either using mechanical substring checks or LLM-based embeddings and classifications) and reply with a CAPABILITY_RESPONSE (0x0B) frame conforming to this schema:¶
{
"match_found": true,
"uri": "agent://appliance-identifier",
"port": 8001,
"capability_name": "identify household appliances"
}
¶
If no registered capabilities match the semantic target, the responder MUST return a CAPABILITY_RESPONSE where match_found is set to false, and the address details are omitted.¶
Discovery frames are highly susceptible to malicious activity. Therefore:¶
For point-to-point connections where reliability is guaranteed by the OS TCP engine. Implements standard connection backpressure mechanics, delaying token-generation and processing loops when the local socket output descriptors block or overflow.¶
Agents SHOULD employ standard UDP broadcast channels (defaulting to Port 5005) to scan nearby subnets for active capabilities. The discovery protocol flow MUST execute as follows:¶
DISCOVER frame containing the semantic goal to port 5005.¶
CAPABILITY_RESPONSE containing physical host information and capability metadata back to the initiator's port and source IP address.¶
LLT over QUIC [RFC9000] represents the recommended gold-standard transport binding. It bypasses head-of-line blocking by mapping separate cognitive frames to isolated virtual sub-streams (e.g., Stream Index 10 for Thoughts, Stream Index 20 for Final Tokens) over a single physical QUIC socket.¶
To ensure seamless operational continuity, LLT over QUIC implementations MUST support dynamic connection migration, allowing agents to transition between host gateways, cell providers, or local network routers without interrupting on-going multi-turn reasoning cycles or resetting conversation state blocks.¶
LLT operates inside a decentralized peer-to-peer or server-client topology. Security is established through Ed25519 Cryptographic Signatures and a feedback-driven Trust Score System.¶
When the SIGNED (0x01) modifier flag is set in the header, the sender MUST append exactly 64 bytes of Ed25519 signature [RFC8032] directly at the absolute end of the transmission (following the payload).¶
The signature is computed over the serialized representation of the binary payload or the canonicalized representation of the JSON outer packet sorted alphabetically (no padding, carriage returns, or spacing characters), ensuring robust end-to-end payload integrity and non-repudiation.¶
Every participant node on an LLT network MUST maintain a local trust database pairing peer URIs with numeric scores configured within the range:¶
Score Scope: [0.0 - 1.0]
¶
Implementations MUST initialize a peer node's trust score to exactly 0.5 upon receiving its first frame, unless explicitly overridden by local administration parameters. Correct and verified cryptographic packets, accurate schema formatting, and logical coherence yield progressive score modifications (incremental +0.02 awards), while cryptographically broken payloads or persistent logical contradictions MUST triggers instant score penalty deducts (-0.15 deductions), paving the way for adaptive firewalls and routing isolations.¶
This document requests IANA to establish a new registry for "Large Language Transport (LLT) Cognitive Message Types" on the "Large Language Transport (LLT) Parameters" page.¶
The initial values of this registry are:¶
In addition, dynamic registration of specialized capabilities or extensions MAY register value extensions within the range 0xC0 to 0xFF via experimental RFCs or designated expert reviews.¶
LLT networks are susceptible to standard transport-layer attacks as well as unique cognitive and semantic manipulation vectors. Implementations MUST apply the following security profiles to mitigate risks:¶
Attackers may intercept signed cognitive frames (e.g., a TOOL_CALL authorizing a financial transaction) and replay them over active socket joints. To mitigate this threat, every payload MUST incorporate a monotonically increasing sequence ID paired with a precision Unix timestamp. Receiving nodes MUST drop any arrived packet where the sequence ID is less than or equal to the maximum verified historical ID of that stream, or where the timestamp variance exceeds 5.0 seconds.¶
Malicious intermediate nodes could intercept frames and clear the SIGNED (0x01) or COMPRESSED (0x04) modifier flags in the header to force recipients into parsing unsecure or unoptimized text branches. Since flags are housed inside the header bytes, headers MUST be included in the signed digest computation. Any signature verification MUST fail if the header attributes are tampered with.¶
In local UDP configurations, rogue nodes can broadcast fake DISCOVER_RESPONSE or REGISTER frames to hijack capability queries and route agent logic to malicious endpoints. Implementations MUST require discovery responders to include their cryptographic host key certificate. Initiators MUST verify the certificate chain against structured anchor trust stores before executing dynamic connections.¶
If signature verification fails during transit, the receiver MUST immediately discard the packet, terminate the physical connection, and deduct exactly 0.25 from the sender's local Trust Score. The event SHOULD be logged prominently in diagnostic streams.¶
Malicious nodes could artificially inflate their trust metrics by executing rapid sequences of insignificant, correct placeholder transfers, only to subsequently inject corrupted cognitive payload blocks once high status is acquired. Algorithms MUST apply decay models favoring long-term interaction history, and enforce irreversible trust score ceilings for nodes with volatile transfer behaviors.¶
Rogue agents may attempt to hijack active streams during connection migration by spoofing source IP and CID details. Under QUIC bindings, systems MUST use standard QUIC path-validation procedures, verifying ownership of the new address through random 64-bit cryptographic challenge tokens before restoring active cognitive streams.¶
Unencrypted LLT streams expose cognitive thoughts (THOUGHT) and target skill descriptions (DISCOVER), conveying sensitive behavioral contexts and systemic configurations to intercepting entities. Therefore, LLT transmissions MUST be wrapped inside TLS-encrypted tunnels (such as standard TLS v1.3 inside TCP or QUIC).¶
Client Core Server Core
| |
| Client Hello [CID: 0x8fa4, Cap Request] |
|------------------------------------------------------->|
| |
| Server Hello [CID: 0x9fb5, Handshake Key, Trust] |
|<-----------------------------------------------------|
| |
| Signed GOAL Frame [Stream: 10, State: thinking] |
|------------------------------------------------------->|
¶
LLM Generates Raw Token Buffer
|
v
"Here is my analysis... <thought>Index scan completed.</thought>"
|
+======> LLTCognitiveParser Processes Tags
|
+===> Emits:
1. TOKEN: "Here is my analysis... "
2. THOUGHT: "Index scan completed."
¶