MoQ Interconnect Exchange (MIX)

1.1. Why MOQT for Relay Control

MIX uses MOQT facilities where their existing semantics fit the control plane, so the request, fan-out, scheduling, and object-retrieval behavior of the control plane comes directly from MOQT. MIX does not assume that every MOQT relay caches objects or that MOQT itself supplies relay-to-relay routing.¶

• Namespace discovery and separate tracks. Relays publish MIX namespaces with PUBLISH_NAMESPACE and discover peers via SUBSCRIBE_NAMESPACE / NAMESPACE / NAMESPACE_DONE. nodes, publishers, and subscribers are independent tracks so a peer can subscribe to only the state it needs and MIX can apply distinct retention, priority, and admission policy to each.¶

• Live updates plus state repair. SUBSCRIBE carries live updates. Draft 22's FILL_PARAMETERS mechanism, when backed by a cache, recovers retained objects after a reconnect or missed update. Because MOQT caching is optional, MIX needs its own recovery for the case where a fill is incomplete (Section 6.2).¶

• Priority scheduling and delivery deadlines. MOQT subgroup streams and datagrams, publisher priorities, and OBJECT_DELIVERY_TIMEOUT / SUBGROUP_DELIVERY_TIMEOUT let MIX prioritize routing-critical state and bound how long an advertisement consumes delivery effort. Priorities influence scheduling only, and deadlines may drop state (Section 6.2).¶

• Direct use of MOQT controls. MIX uses these MOQT controls as defined, without re-encoding them in MIX messages. MIX-specific messages carry only what MOQT does not represent: originator identity, freshness, path, and target-set information.¶

1.2. Terminology

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

The following terms are used throughout this document:¶

Node:

A MIX-capable MOQT relay. Each Node is identified by a 128-bit Node ID, described in Section 3.¶

MIX Edge Node:

A Node that connects MOQT application publishers or subscribers to the inter-relay network. It originates publish and subscribe state for its local clients and injects or delivers their objects through MIX.¶

MIX Transit Node:

A Node that carries relay reachability and forwarding state and forwards objects along selected inter-relay paths. It typically does not terminate application publisher or subscriber sessions.¶

MIX Control Node:

A Node that exchanges Publisher and Subscriber Table state on behalf of other Nodes and does not forward objects. Control Nodes are used in the split deployment model (Section 12.2) and advertise type = 2 in node_info (Section 8.3.1).¶

Forwarding Node:

A MIX Edge Node or MIX Transit Node; any Node that is not a Control Node.¶

Control Session:

A QUIC connection between two Nodes used to exchange MIX control-plane tracks, including announce, nodes, publishers, and subscribers (Section 5). This connection also carries the MOQT control messages needed to establish and manage its subscriptions and publications.¶

Data Session:

A separate QUIC connection between two Nodes used to forward inter-relay data (Section 7). It also uses MOQT control messages to establish the session and its delivery-node-sets track subscription. Those MOQT messages manage the transport session; they do not make it a MIX control Session.¶

Peering:

A MIX relationship between two Nodes. It consists of a Control Session carrying the Node, Publisher, and Subscriber Table tracks in the peering's scope (Section 6.1) and, when that scope includes the Node Table and data is to be forwarded, a separate Data Session. Each connection has its own MOQT session state. An delivery-node-sets track is associated with the Data Session whose downstream targets it describes.¶

Session:

In this document, an unqualified Session means a Control Session. When the Data Session is intended, it is named explicitly.¶

Node Table:

The Nodes this Node knows about, one entry per Node ID. Each entry holds that Node's attributes and public key, and one candidate path to it from each peer. It answers "which Nodes exist, and how do I reach each one?" It is filled by NODE_INFO_ADVERTISEMENT and NODE_INFO_WITHDRAWAL.¶

Publisher Table:

The tracks that are published, one entry per originating Edge Node and track. Each entry says that the Edge Node has a local publisher for the track, and which forwarding mode it wants. It answers "where does track T come from?" It is filled by PUBLISH_INFO_ADVERTISEMENT and PUBLISH_INFO_WITHDRAWAL.¶

Subscriber Table:

The tracks that are wanted, one entry per originating Edge Node and track. Each entry says that the Edge Node has local subscribers for the track. It answers "who wants track T?" It is filled by SUBSCRIBE_INFO_ADVERTISEMENT and SUBSCRIBE_INFO_WITHDRAWAL.¶

Together, the Publisher Table says where a track comes from, the Subscriber Table says where it must go, and the Node Table says how to get between them. Full details are in Section 4.¶

Originator:

The Node that a Node, Publisher, or Subscriber Table entry describes, and the only Node that can create or withdraw it. For a Node Table entry it is the Node itself (node_info.id). For a Publisher or Subscriber Table entry it is the Edge Node whose local publisher or subscriber the entry describes (source_node_id). The originator signs the entry (Section 10); other Nodes only re-publish it. The term follows BGP route reflection [RR], where ORIGINATOR_ID names the router that injected a route.¶

Advertisement / Withdrawal:

An advertisement installs or updates an entry in a Node, Publisher, or Subscriber Table; a withdrawal removes it. Both are signed by the entry's originator. The messages for each table are defined in Section 8.1.¶

Delivery Node Set:

Forwarding state for one track on one Data Session: the Edge Nodes with subscribers for the track that it must reach by way of that Data Session's downstream Node. Each Data Session has one Delivery Node Set per track it carries. The upstream Node builds it from its Subscriber Table (who wants the track) and its Node Table (which next hop leads to each of them), and sends it on the Data Session's delivery-node-sets track. Each downstream Node splits it for its own next hops, so the set narrows at every hop and the track is copied only where paths split. For example, if track T has subscribers behind B1 and B2, both reached through Transit X, the Delivery Node Set for T on the Data Session to X lists {B1, B2}; X then sends {B1} toward B1 and {B2} toward B2. See Section 4.5.¶

Delivery Node Set Id:

A 32-bit label that the upstream Node of a Data Session assigns to one Delivery Node Set on that Data Session. In pipelined mode it travels with every forwarded object (Section 7.2), so the downstream Node can find the set without parsing the track identity. It has meaning only on one Data Session. See Section 4.5.¶

4.1. Sequence Comparison

Every advertisement and withdrawal carries two freshness fields, both set by its originator:¶

• origin_epoch (64 bits) identifies the originator's current incarnation (Section 10.2).¶

• sequence (64 bits) counts the advertisements and withdrawals the originator has published for one key in its Node, Publisher, or Subscriber Table (Section 4). It increases with every message for that key and MUST NOT wrap or be reused within an epoch.¶

An originator MUST either persist its epoch and per-key sequences across restarts or advance origin_epoch before it publishes again.¶

A receiver orders messages for the same originator and key by the pair (origin_epoch, sequence), comparing origin_epoch first. It accepts a message only if its pair is greater than the stored one, and re-floods only messages it accepts.¶

For a NODE_INFO_ADVERTISEMENT (Section 8.3), this comparison covers only the originator-signed fields of node_info. Its path is unsigned and tracked per peer (Section 4.2), so an advertisement whose pair equals the stored one is not accepted as new but still replaces the sending peer's candidate path.¶

4.2. Candidate Paths and Unreachability

A Node can usually reach another Node through more than one peer. For each Node Table entry E, it therefore keeps one candidate path per peer: the most recent path that peer advertised for E.id. Path selection (Section 4.4) chooses the best egress among these candidates. When the best one disappears, the Node fails over to the next without waiting for the originator to re-advertise.¶

A candidate changes only on one of four events, each tied to a single peer S:¶

After any of these events, the Node re-runs path selection for E and tells its own peers what changed:¶

• If the best path changed materially, it re-publishes E on its nodes track with its own element appended.¶

• If no candidate is left, E is unreachable. If the Node had advertised E, it publishes NODE_UNREACH for E.id on its nodes track, so that its peers remove their path through it.¶

The same rules then apply at each peer, so the loss of a path spreads hop by hop and stops at Nodes that still have another candidate.¶

An unreachable entry keeps its originator-signed fields for ORIGINATOR_UNREACH_HOLD (default 90 s) and is then removed. If a path returns within that time, an advertisement with the same (origin_epoch, sequence) restores a candidate without the originator having to re-advertise.¶

NODE_UNREACH needs no signature because it can only remove the candidate of the Session it arrived on, which is the path the sender itself advertised. The sender could have the same effect by never advertising that path, so accepting an unsigned NODE_UNREACH gives it no new power.¶

Holding one candidate per peer costs memory in proportion to the number of Nodes times the number of peers. A Node MAY keep fewer candidates than it has peers, at the cost of slower failover.¶

4.3. Publisher and Subscriber Table Lifetime

Publisher and Subscriber Table entries describe their originator, not the path they arrived on. A Publisher Table entry says that the originator publishes a track; a Subscriber Table entry says that the originator has subscribers for one. A Node therefore keeps an entry when the peer that delivered it goes away. It removes the entry only when the originator's statement is no longer true, or the Node can no longer count on hearing about it if it changes.¶

The originator ends an entry in one of two ways:¶

• Withdrawal. The originator sends PUBLISH_INFO_WITHDRAWAL (Section 8.5) or SUBSCRIBE_INFO_WITHDRAWAL (Section 8.6) when its last local publisher or subscriber for the track leaves. The withdrawal floods like any other message, and each Node removes the entry when it accepts the withdrawal.¶

• Restart. When a Node accepts a NODE_INFO_ADVERTISEMENT from the originator with a newer origin_epoch, it removes every Publisher and Subscriber Table entry from that originator with an older epoch. The restarted originator re-advertises the entries that are still valid.¶

A Node also ends entries on its own when it can no longer rely on hearing from the originator:¶

• Originator unreachable. While the originator's Node Table entry is unreachable (Section 4.2), the originator's entries are kept but not used for path setup. If the originator is still unreachable after ORIGINATOR_UNREACH_HOLD, they are removed.¶

• No Control Node. In a split deployment, a Forwarding Node that has had no ESTABLISHED Reflection peering for CONTROL_STALE_HOLD removes every entry it did not originate, because it may have missed withdrawals (Section 6.5).¶

These local removals are not flooded. Every Node reaches the same conclusion from its own Node Table or peering state.¶

When an unreachable originator comes back, no special recovery is needed. The Sessions that re-form across the repaired link fill from each other (Section 6.2), the Nodes there accept the originator's entries as new, and normal flooding carries the entries on.¶

4.4. Path Selection

Path selection chooses, for each destination Node E.id, the peer through which this Node sends data toward it: E's best egress. It works on E's candidates (Section 4.2), one per peer, and runs again whenever they change.¶

A candidate is eligible unless:¶

• its peer is a Control Node, which never forwards data; or¶

• it is being considered for a track whose Publisher Table entry requests pipelined mode, and some hop on its path does not set the pipelined bit (bit 1) of data_modes (Section 8.3.1). Every Forwarding Node supports native mode, so a native-mode track can use any eligible candidate.¶

Among eligible candidates, the Node prefers:¶

1. the shortest path, counted as the sum of hop_count over its elements. Without path aggregation (Section 14) this is the number of elements; then¶

2. the lowest cumulative smoothed round-trip time (sRTT): the sum of srtt_us over the path plus the Node's own sRTT to the peer that advertised it.¶

Hop count decides first, and sRTT only breaks ties.¶

The chosen peer's Session is cached on E as its best egress. The Node recomputes it when that Session closes, when its candidate is removed, or when a materially better candidate arrives. A change of best egress moves E.id from the Delivery Node Set on the old egress Data Session to the Delivery Node Set on the new one, for every track forwarded toward it (Section 7.3) and can lead the Node to re-publish E (Section 4.2).¶

To judge "materially better", implementations SHOULD round sRTT values (for example, to whole milliseconds) before comparing them, so that sub-millisecond jitter does not make the best egress, and the advertisements that depend on it, oscillate.¶

4.5. Delivery Node Sets

The Node, Publisher, and Subscriber Tables say which Nodes exist, which tracks are published, and which Edge Nodes have subscribers. To forward a track, a Node also needs to know, on each Data Session, where the objects it sends there must end up. That is the Delivery Node Set.¶

An Delivery Node Set belongs to one track on one Data Session. It names the destination Nodes, the Edge Nodes with subscribers for the track, that the track must reach through the downstream Node of that Data Session.¶

Delivery Node Sets are built hop by hop. The publisher's Edge Node takes the destinations for the track from its Subscriber Table, groups them by best egress (Section 4.4), and creates one Delivery Node Set per egress Data Session. Each downstream Node receives that Delivery Node Set, groups its destinations again by its own best egress, and creates its own Delivery Node Sets. At each hop a Delivery Node Set keeps only the destinations still ahead on that branch, so a track is copied exactly where its destinations' paths diverge:¶

   E1's Subscriber Table: track T has subscribers behind B1, B2, B3

            {B1,B2}               {B1}
   [E1] --------------> [X] ------------> [B1]
     |                   |
     |                   |         {B2}
     |                   +--------------> [B2]
     |
     |             {B3}
     +------------------------------------> [B3]

Each Delivery Node Set is labelled with an Id that the upstream Node chooses and that is unique on that Data Session. In pipelined mode every forwarded object carries the Delivery Node Set Id (Section 7.2), so the downstream Node finds the Delivery Node Set with one lookup instead of parsing the track identity. Delivery Node Set Ids have no meaning beyond their Data Session: each hop assigns its own on its egress Data Sessions.¶

An Delivery Node Set changes when a destination is added or removed (a Subscriber Table change) or when a destination's best egress changes (a Node Table change). The upstream Node then publishes the updated Delivery Node Set under the same Id, or withdraws it when no destinations remain. Delivery Node Sets are published on each Data Session's delivery-node-sets track (Section 5.1.3) as DELIVERY_NODE_SET_ADVERTISEMENT and DELIVERY_NODE_SET_WITHDRAWAL (Section 8.7). How a Node forwards objects using them is specified in Section 7.3.¶

5.1. Track Semantics

Each MIX control track specifies an Object priority value for its objects. MOQT uses lower numeric priority for higher scheduling precedence, with 0 the highest ([MoQTransport]). Priority 0 is reserved for MOQT control traffic, and MIX tracks MUST NOT use it.¶

The nodes and delivery-node-sets tracks use priority 1, because they gate forwarding: path selection cannot proceed without reachability, and data egress is held back until the target set is known. The publishers and subscribers tracks carry per-track demand that does not gate delivery, and use priority 2. The bootstrap announce track also uses priority 2; after initial discovery, its refresh is a liveness heartbeat rather than a routing decision.¶

6.1. Peering Scope

The scope of a peering is the set of Node, Publisher, and Subscriber Table tracks that each Node subscribes to from the other. Scope is set by local configuration for each peering and is not negotiated on the wire. Three scopes are defined:¶

The following rules apply regardless of deployment model:¶

• A Forwarding Node MUST NOT subscribe to the nodes track of a Control Node.¶

• A Node MUST open a Data Session to a peer only over an ESTABLISHED peering with Full or Topology scope. Path selection (Section 4.4) yields only such peers.¶

• A Control Node MUST NOT open or accept Data Sessions.¶

A Control Node's subscription to a Forwarding Node's nodes track lets the Control Node learn the public keys of every Forwarding Node that Forwarding Node can reach, which it needs to verify the Publisher and Subscriber Tables entries it receives (Section 10).¶

6.2. Subscribing to Node, Publisher, and Subscriber Tables

For the nodes, publishers, and subscribers tracks, subscribers SHOULD issue a MOQT SUBSCRIBE whose Location Filter starts at the Next Object. To also acquire retained state, the initial SUBSCRIBE SHOULD include FILL_PARAMETERS with a location filter ending at Largest Object. The fill range and the live subscription filter are distinct in draft 22. Implementations MUST process both fill-delivered and subscription-delivered objects using the same MIX freshness and duplicate-suppression rules. A relay MAY return an incomplete fill when objects are unavailable; MIX therefore requires a full-state snapshot or equivalent recovery mechanism after a cache miss (see the editor's note below).¶

The same pattern applies to the announce track and to the per-Data-Session delivery-node-sets track (Section 5.1.3). The delivery-node-sets cache lifetime SHOULD cover expected peer setup and recovery intervals.¶

Priorities influence scheduling only. A Node MUST NOT treat an advertisement whose delivery timed out under OBJECT_DELIVERY_TIMEOUT or SUBGROUP_DELIVERY_TIMEOUT ([MoQTransport]) as delivered.¶

• Editor's note: This document does not yet define how a Node recovers full state when a fill is incomplete because the publishing relay has no usable cache.¶

B performs the subscriptions to A that the peering's scope calls for (Section 6.1). For Full and Topology scope these mirror A's.¶

6.3. Simultaneous-Peer Tiebreaker

Two Nodes MAY open Control Sessions to each other at the same time. A pair of Nodes keeps at most one Control Session. Once each Node has received the other's CONNECT, the connection opened by the Node with the numerically lower Node ID is kept and the other is closed. Both directions of subscription then run over the kept connection. Closing the duplicate connection is not a peering close: neither Node removes state learned from the other (Section 6.4).¶

6.4. Peering State Machine

Each peering (an ordered pair of Nodes A and B, viewed from A's side) progresses through a small state machine. States describe the control-plane relationship only; data-plane subscriptions (Section 6 step 3) are opened independently once ESTABLISHED is reached on a peering whose scope includes the Node Table.¶

                       +---------+
                       |  INIT   |
                       +---------+
                            |
                            |  subscribe to B's announce track
                            v
                       +---------+
                       | OPENING |
                       +---------+
                            |
                            |  receive B.CONNECT object
                            v
                       +---------+
                       |  HELLO  |-------> REJECTED
                       |  RECVD  |   signature / policy reject
                       +---------+
                            |
                            |  subscribe to tracks in scope
                            |
                            v
                     +-------------+
                     | ESTABLISHED |
                     +-------------+
                       |    |    |
                       |    |    |  signature failure at ingress
                       |    |    |  / peer close / QUIC error
                       v    v    v
                     +-------------+
                     |   CLOSED    |
                     +-------------+

State transitions:¶

• INIT -> OPENING: A issues a MOQT SUBSCRIBE for B's announce track (("mix","v1","announce","<B-node-id>") / "announce").¶

• OPENING -> HELLO_RECVD: A receives B's CONNECT object on the announce track. A does not yet trust B; the object's signature MUST verify against a pubkey that either (a) is derived from B's Node ID (Section 3) or (b) was already installed as a trusted key.¶

• HELLO_RECVD -> ESTABLISHED: A applies the simultaneous-peer tiebreaker and issues MOQT SUBSCRIBE requests with FILL_PARAMETERS for the B tracks in the peering's scope (Section 6.1) as specified in Section 6.2. B receives A's advertisements through its own subscriptions to A.¶

• HELLO_RECVD -> REJECTED: signature verification failed, the peer pubkey does not match A's local pinning policy, or admission control declines the peering. A cancels its subscription to B's announce track and does not subscribe to B's Node, Publisher, or Subscriber Table tracks. The state is terminal from A's perspective; B may retry after a backoff.¶

• ESTABLISHED -> CLOSED: A observes any of (i) a MOQT PUBLISH_DONE on any control-plane track from B, an explicit cancellation of A's SUBSCRIBE, or, when the peering's scope includes Node Table, a STOP_SENDING on a Data Session to B; (ii) QUIC transport failure; (iii) sustained signature failure at ingress; or (iv) a local admin action. A connection closed by the simultaneous-peer tiebreaker (Section 6.3) does not close the peering. On entry to CLOSED, A removes every Node Table candidate it learned from B (Section 4.2). Publisher and Subscriber Table entries follow Section 4.3, and those learned over a Reflection peering also follow Section 6.5.¶

Tying a Topology or Full peering to its Data Sessions keeps Node Table and the data plane in step: a peer that can no longer forward is withdrawn from path selection rather than left as a black hole. A Reflection peering has no Data Sessions, so data-plane events never close it.¶

CLOSED is a terminal state; recovery is a fresh INIT on a new session identifier. The Node ID of the peer is unchanged, so any previously distributed originator pubkey remains valid across reconnection.¶

6.5. Loss of a Reflection Peering

Losing a Reflection peering does not by itself remove any Publisher or Subscriber Table entry. The entries are signed by their originators and stay valid while those originators are reachable (Section 4.3), and a Forwarding Node peered with more than one Control Node keeps receiving updates from the others.¶

Reachability here comes from the Node Table, not from the Control Nodes. An originator is reachable while the Node's Node Table entry for it has at least one candidate (Section 4.2). A Forwarding Node builds its Node Table over its Topology peerings with its data-plane neighbors, so it keeps tracking originators even when it has no Control Node at all. A Control Node builds its Node Table from its subscriptions to the nodes tracks of the Forwarding Nodes it serves (Section 6.1).¶

A Forwarding Node that has no ESTABLISHED Reflection peering receives no updates, and so misses any withdrawals issued in the meantime. To bound that, a Forwarding Node that has had no ESTABLISHED Reflection peering for CONTROL_STALE_HOLD removes every Publisher and Subscriber Table entry it did not originate. The default is 90 s. It SHOULD exceed the time needed to re-establish a Reflection peering and complete its fill (Section 6.2). The fill on the next Reflection peering restores the entries.¶

7.1. Forwarding Modes

MIX defines two ways to carry a track's objects between Nodes. In native mode every hop forwards whole MOQT objects. In pipelined mode every hop forwards bytes as they arrive, behind a small MIX Data Header. The track's originator picks the mode in its Publisher Table entry, and a path is usable for pipelined mode only if every hop on it supports it.¶

7.2. Data Header

In pipelined mode, every datagram and every stream between Nodes begins with a MIX Data Header. A stream also carries one before each later object on it. The header tells the receiving Node which Delivery Node Set the bytes belong to, so it can forward them before the object ends. There are three types of header, using the notation of Section 1.3 of [RFC9000]:¶

datagram_header {
  type (8) = 0x00,
  header_length (8),
  delivery_set_id (i),
  data_length (i),
}

new_stream_header {
  type (8) = 0x02,
  header_length (8),
  delivery_set_id (i),
  priority (8),
  ttl_us (i),
  data_length (i),
}

existing_stream_header {
  type (8) = 0x01,
  header_length (8),
  delivery_set_id (i),
}

type:

Which header this is. 0x00 begins a QUIC datagram. 0x02 begins a QUIC stream and precedes its first object. 0x01 precedes each later object on the same stream.¶

header_length:

The number of bytes in the header after this field. A receiver that does not need every field can use it to skip to the payload.¶

delivery_set_id:

The Id of the track's Delivery Node Set on this Data Session (Section 4.5). The receiving Node looks it up to find where to forward the bytes (Section 7.3).¶

priority:

The MOQT publisher priority of the subgroup carried on the stream ([MoQTransport]).¶

ttl_us:

A lifetime for the stream's objects, in microseconds.¶

data_length:

The number of payload bytes that follow the header: the datagram's payload, or the first object on a new stream.¶

• Editor's note: The meaning of ttl_us is not yet specified. An existing_stream_header carries no length, so a receiver cannot yet find where each later object on a stream ends.¶

Native-mode streams do not carry a MIX Data Header; they carry MOQT object frames as defined in [MoQTransport].¶

7.3. Delivery Node Set Fan-Out

Each Node derives its egress Delivery Node Sets from its ingress Delivery Node Sets as described in Section 4.5; a destination that is the Node itself is delivered locally. The result maps each ingress Delivery Node Set Id to a set of egress Data Sessions and their Delivery Node Set Ids.¶

For each ingress unidirectional stream, a Node looks up the ingress delivery_set_id in that mapping (Section 5.1.3), then opens one egress unidirectional stream per selected downstream Data Session. Egress streams are opened lazily, on the first byte of the ingress stream, so that a relay does not consume QUIC flow-control budget on peers that have no active subscribers.¶

          ingress stream for track T, delivery_set_id = 42
                          |
                          v
            +---------------------------+
            | Delivery Node Sets for    |
            | the ingress Data Session: |
            |   Id 42 -> {B2, C1}       |
            |   Id 57 -> {D1}           |
            +-------------+-------------+
                          |
                +---------+---------+
                v                   v
          egress to B2        egress to C1

Datagrams are fanned out by rewriting the Delivery Node Set Id per egress and queuing a fresh QUIC datagram frame on each downstream Data Session.¶

In native mode the Delivery Node Set is found by track (full_name_hash) rather than by Delivery Node Set Id, and selects the set of downstream Data Sessions in the same way, but the egress carries a MOQT subgroup stream (or datagram, or FETCH response) as defined by [MoQTransport] rather than a MIX Data Header stream. The relay preserves track identity and object locations on egress. Track Alias and request state are mapped to the local MOQT session.¶

8.1. Advertisement and Withdrawal Messages

The Node, Publisher, and Subscriber Tables each have one advertisement and one withdrawal message: NODE_INFO_ADVERTISEMENT and NODE_INFO_WITHDRAWAL for Node Table, PUBLISH_INFO_ADVERTISEMENT and PUBLISH_INFO_WITHDRAWAL for Publisher Table, and SUBSCRIBE_INFO_ADVERTISEMENT and SUBSCRIBE_INFO_WITHDRAWAL for Subscriber Table. The following rules apply to all six:¶

• The entry's originator creates and signs the message (Section 10) and publishes it on its own nodes, publishers, or subscribers track.¶

• A Node that accepts the message (Section 4.1) re-publishes it on its own track of the same kind without changing any signed field, unless its role rules this out: Control Nodes do not re-publish Node Table entries, and in a split deployment Forwarding Nodes do not re-publish Publisher or Subscriber Table entries (Section 12.2.1).¶

• A withdrawal uses the same body as the advertisement with its variable-length part emptied, as stated for each message below.¶

8.2. CONNECT

Announces a Node to prospective peers. Each Node publishes a CONNECT on its announce track at startup and refreshes it as described in Section 5.1.5. Peers use it to discover the Node and to learn its public key before subscribing to its Node, Publisher, and Subscriber Table tracks (Section 6).¶

The body is the Node's node_info (Section 8.3.1). CONNECT and NODE_INFO_ADVERTISEMENT share the same body and signature input (Section 10) and differ only in the tag byte and the track they appear on.¶

8.3. NODE_INFO_ADVERTISEMENT and NODE_INFO_WITHDRAWAL

A NODE_INFO_ADVERTISEMENT states that a Node exists, gives its attributes and public key, and gives one path to it. A Node originates its own NODE_INFO_ADVERTISEMENT at startup and again whenever a signed field of its node_info changes. A Forwarding Node that accepts one re-publishes it, with its own path element appended, whenever its best path to the originator changes (Section 4.2). A receiver stores the signed fields in the Node Table entry for the originator and the path as the sending peer's candidate.¶

A NODE_INFO_WITHDRAWAL states that a Node is leaving the mesh. Only the Node itself sends it, with an empty path. A receiver removes the Node Table entry and all its candidates and re-floods the withdrawal. A Node that has only lost its path to another Node sends NODE_UNREACH instead (Section 8.4).¶

node_info {
  id (128),
  type (8),
  contact_len (8),
  contact (..),
  longitude (64),
  latitude (64),
  pubkey (256),
  origin_epoch (64),
  sequence (64),
  data_modes (8),
  path_len (i),
  path (..) ...,
  origin_sig (512),
}

path_element {
  flags (8),
  node_id_or_token (128),
  srtt_us (64),
  hop_count (16),
}

8.4. NODE_UNREACH

States that the sender no longer has a path to the Node named by node_id, and retracts the path it last advertised for that Node. A Node sends it on its own behalf, not an originator's, so it is not signed. When a Node sends it and how a receiver applies it are specified in Section 4.2.¶

node_unreach {
  node_id (128),
}

node_id:

The Node ID of the Node that is no longer reachable.¶

8.5. PUBLISH_INFO_ADVERTISEMENT and PUBLISH_INFO_WITHDRAWAL

A PUBLISH_INFO_ADVERTISEMENT states that a track is available at its originator, and the forwarding mode the originator requests for it (Section 7.1). An Edge Node originates one when a local MOQT publisher makes a track available. A receiver stores it in its Publisher Table.¶

A PUBLISH_INFO_WITHDRAWAL states that the track is no longer available at the originator. The originator sends it when its local publisher stops publishing. A receiver removes the Publisher Table entry.¶

publish_info {
  sequence (64),
  source_node_id (128),
  origin_epoch (64),
  track_full_name_hash (..),
  forwarding_mode (8),
  parameters_len (i),
  parameters (..),
  origin_sig (512),
}

track_full_name_hash {
  namespace_hashes_len (16),
  namespace_hashes (128) ...,
  name_hash (128),
}

8.6. SUBSCRIBE_INFO_ADVERTISEMENT and SUBSCRIBE_INFO_WITHDRAWAL

A SUBSCRIBE_INFO_ADVERTISEMENT states that its originator has local subscribers for a track. An Edge Node originates one when its first local subscriber for the track subscribes. A receiver stores it in its Subscriber Table.¶

A SUBSCRIBE_INFO_WITHDRAWAL states that the originator no longer has subscribers for the track. The originator sends it when its last local subscriber leaves. A receiver removes the Subscriber Table entry.¶

subscribe_info {
  sequence (64),
  source_node_id (128),
  origin_epoch (64),
  track_full_name_hash (..),
  subscribe_data_len (i),
  subscribe_data (..),
  origin_sig (512),
}

8.7. DELIVERY_NODE_SET_ADVERTISEMENT and DELIVERY_NODE_SET_WITHDRAWAL

A DELIVERY_NODE_SET_ADVERTISEMENT carries one Delivery Node Set: for one track on the Data Session whose delivery-node-sets track carries it (Section 5.1.3), the destination Nodes the track must reach through the downstream Node. The upstream Node of the Data Session sends it, and a later advertisement for the same Delivery Node Set Id replaces the earlier one. A DELIVERY_NODE_SET_WITHDRAWAL removes the Delivery Node Set whose Id is given by the MOQT group it appears in; its body is empty. Both are local to one Data Session and are not signed.¶

The delivery_node_set_info structure is:¶

delivery_node_set_info {
  delivery_set_id (32),
  full_name_hash (128),
  nodes_len (i),
  nodes (128) ...,
}

delivery_set_id:

The Id this Delivery Node Set is published under (Section 4.5).¶

full_name_hash:

The track this Delivery Node Set applies to (Section 9).¶

nodes_len, nodes:

The number of destination Nodes, followed by their Node IDs.¶

9.1. Namespace and Name Hashes

MOQT track identifiers are tuples: an ordered list of namespace strings plus a name string. MIX hashes each component individually.¶

For a namespace tuple ns = (ns_0, ns_1, ..., ns_k-1) and a name string nm:¶

  namespace_hash_i = SipHash-2-4-128(MIX_SIPHASH_KEY, ns_i)
  name_hash        = SipHash-2-4-128(MIX_SIPHASH_KEY, nm)

The namespace_hashes[] field of publish_info and subscribe_info is exactly this per-component sequence.¶

For contexts that require a single value (Publisher and Subscriber Table keys, Delivery Node Set lookup), the full_name_hash is:¶

  full_name_hash = SipHash-2-4-128(
      MIX_SIPHASH_KEY,
      ns_0 || 0x00 || ns_1 || 0x00 || ... || ns_{k-1} || 0x00 || nm)

The 0x00 separator prevents boundary-injection attacks (namespaces ("ab","c") and ("a","bc") produce distinct hashes).¶

9.2. Rationale

MIX hashes identify tracks; they are not authenticators. Compared to the 64-bit FNV-1a64 used in earlier designs, SipHash-128 raises the cost of accidental or adversarial collisions by many orders of magnitude: FNV-1a64 collisions can be constructed in seconds, whereas constructing a 128-bit SipHash collision requires on the order of 2^64 work (birthday bound).¶

The SipHash key is a published constant, so MIX hashes offer no secret-key protection against chosen inputs. Authorization of advertisements is handled separately by originator signatures (Section 10) and operator-level ACLs. Implementations MUST NOT treat MIX hashes as capabilities, authenticators, or authorization tokens.¶

Implementations SHOULD validate their SipHash output against the test vectors in [SipHash].¶

10.1. Signature Input

The signature covers a canonical byte string over the immutable portion of the advertisement. The mutable portion of a NODE_INFO_ADVERTISEMENT — its path accumulated during propagation — is excluded from signature input. Specifically:¶

For CONNECT, NODE_INFO_ADVERTISEMENT, and NODE_INFO_WITHDRAWAL:¶

node_info_sig_input {
  domain_separator (..) = "MIX/node_info/v1",
  tag (8),
  id (128),
  type (8),
  contact_len (8),
  contact (..),
  longitude (64),
  latitude (64),
  pubkey (256),
  origin_epoch (64),
  sequence (64),
  data_modes (8),
}

Note that path is not part of the signature input: paths accumulate during propagation and cannot be pre-signed by the originator. Therefore, the originator signature does not protect path contents or metrics. MIX implementations MUST treat path data as an assertion by the immediate authenticated peer unless a future version defines per-hop integrity. Inter-provider deployments MUST NOT use an unsigned path as a sole authorization or policy signal. Path aggregation does not solve this integrity limitation.¶

For SUBSCRIBE_INFO_ADVERTISEMENT and SUBSCRIBE_INFO_WITHDRAWAL:¶

subscribe_info_sig_input {
  domain_separator (..) = "MIX/subscribe_info/v1",
  tag (8),
  sequence (64),
  source_node_id (128),
  origin_epoch (64),
  track_full_name_hash (..),
  subscribe_data_len (i),
  subscribe_data (..),
}

For PUBLISH_INFO_ADVERTISEMENT and PUBLISH_INFO_WITHDRAWAL:¶

publish_info_sig_input {
  domain_separator (..) = "MIX/publish_info/v1",
  tag (8),
  sequence (64),
  source_node_id (128),
  origin_epoch (64),
  track_full_name_hash (..),
  forwarding_mode (8),
  parameters_len (i),
  parameters (..),
}

Each field takes its value from the message being signed, and tag is that message's tag (Section 8). domain_separator is the ASCII string shown, with no length prefix or terminator; it prevents a signature over one message type from being reused for another. Variable-length integers appear in their shortest encoding.¶

10.2. Replay Guard

Every advertisement includes a 64-bit origin_epoch set by the originating Node. It identifies a Node incarnation and MUST increase before that Node publishes after a restart that could reuse a sequence. It MUST NOT be derived solely from an unsynchronized wall clock. The pair (origin_epoch, sequence) distinguishes a new process incarnation from successive updates in that incarnation; sequence is wide enough to avoid modular comparison and wrap handling.¶

Freshness comparison is defined in Section 4.1. Withdrawals carry the same originator, key, and freshness fields and an originator signature, so a stale withdrawal cannot erase newer state.¶

10.3. Public Key Distribution

The CONNECT object includes the Node's public key and signed node_info. A receiver MUST check both the signature and the binding between the public key and Node ID before using the key to validate advertisements. Deployments MAY also distribute trusted keys out of band.¶

An implementation MUST NOT install a signed advertisement whose signature verifies against a public key it has never confirmed for that Node ID via at least one of:¶

• A prior CONNECT object received over an authenticated, authorized MOQT session.¶

• An out-of-band configuration source (for example, a peering registry).¶

• A first-flight trust-on-first-use policy, if local policy explicitly permits it.¶

Deployments in inter-provider settings SHOULD NOT rely on trust-on-first- use.¶

12.1. Integrated model

In the integrated model, every Node is a Forwarding Node and every peering has Full scope (Section 6.1). The same pair of Nodes exchanges Node, Publisher, and Subscriber Tables over a Control Session and, when a track needs to flow, forwards objects over a separate Data Session.¶

 ---  Control Session: Node, Publisher, and Subscriber Tables
 ===  Data Session: Delivery Node Sets and objects

 +---------+   +---------+   +---------+   +---------+
 | Edge A1 |---|Transit X|---|Transit Y|---| Edge B1 |
 |         |===|         |===|         |===|         |
 +---------+   +---------+   +---------+   +---------+

 Every Node exchanges all three tables and forwards objects.

Properties:¶

• One role per Node. Each Node holds its own Node, Publisher, and Subscriber Tables and forwards objects for the Delivery Node Set Ids it is responsible for.¶

• Failure blast radius = the relay. Losing a Node withdraws its table entries and tears down its data-plane peerings together.¶

• Simplest to operate. No Control Nodes to place or provision.¶

Typical use: small-to-medium meshes within a single operator, pre-production environments, and reference implementations.¶

12.2. Split model

In the split model, a small, redundant set of Control Nodes holds and distributes Publisher and Subscriber Table state for a larger fabric of Forwarding Nodes. Forwarding Nodes exchange only their Node Tables with their data-plane neighbors, so path selection (Section 4.4) runs over the data-plane topology. Publisher and Subscriber Table entries reach Forwarding Nodes through the Control Nodes. Each entry names its originator in source_node_id, and a Forwarding Node finds the path toward that originator in its own Node Table. Control Nodes never appear in a data-plane path.¶

Peerings are configured as follows:¶

• Each Forwarding Node holds Topology peerings with its data-plane neighbors, and Reflection peerings with at least one Control Node. It SHOULD hold Reflection peerings with at least two, so that the loss of one is covered by Section 6.5.¶

• Control Nodes hold Reflection peerings with each other and with the Forwarding Nodes they serve.¶

 ---  Control Session        ===  Data Session

                    Publisher and
          +------+  Subscriber Tables +------+  Control Nodes:
          |  C1  |--------------------|  C2  |  Publisher and
          +------+                    +------+  Subscriber Tables only,
             |                           |      no objects
      +------+------+-------------+------+------+
      |             |             |             |
 +---------+   +---------+   +---------+   +---------+
 | Edge A1 |---|Transit X|---|Transit Y|---| Edge B1 |
 |         |===|         |===|         |===|         |
 +---------+   +---------+   +---------+   +---------+

 Reflection peerings (to C1 and C2): Publisher and Subscriber
 Tables, plus the Node Table toward the Control Nodes. Topology
 peerings between Forwarding Nodes: Node Table only. Data
 Sessions: Delivery Node Sets and objects.

Properties:¶

• Two roles. Control Nodes hold Publisher and Subscriber Tables for the whole domain. Forwarding Nodes hold the full Node Table, which grows only with the number of Nodes, plus the Publisher and Subscriber Table entries the Control Nodes send them.¶

• Failure blast radius is split. Losing one Control Node is covered by the remaining ones (Section 6.5). Losing a Forwarding Node closes its Topology peerings; its neighbors withdraw it from Node Table and re-run path selection without involving the Control Nodes.¶

• Independent scaling. Per-track state scales on the Control Nodes; Forwarding Nodes scale with the number of Nodes and concurrent flows. In the integrated model every Node carries both.¶

Typical use: large multi-site deployments, operators who already separate control and forwarding planes elsewhere in their stack, and inter-provider interconnects where the control-plane trust surface is intentionally smaller than the forwarding fabric.¶

Three things a split deployment needs are out of scope for this specification and are left to configuration or other specifications: how a Forwarding Node finds the Control Nodes for its domain and replaces one it has lost; how a Control Node verifies that a Forwarding Node may inject Publisher and Subscriber Table entries for its local publishers and subscribers, beyond the originator signature; and which Publisher and Subscriber Table entries a Control Node sends to which Forwarding Nodes, since sending every entry to every Forwarding Node scales poorly.¶

                      +---------+
                      | Edge A  |  originator, a client of C1
                      +---------+
                           |  publishers
                           v
                      +---------+
           +----------|   C1    |-----------+
           |          +---------+           |
           |  publishers   publishers-mesh  |
           v                                v
    +-------------+                  +-------------+
    | C1's other  |                  |   C2, C3    |
    |   clients   |                  +-------------+
    +-------------+                         |  publishers only,
                                            |  never publishers-mesh
                                            v
                                     +-------------+
                                     | C2's and    |
                                     | C3's clients|
                                     +-------------+

14.1. Aggregation Token

The aggregation token is a 128-bit HMAC-SHA-256 output truncated to the first 16 bytes so that it shares the wire slot with a Node ID:¶

  agg_token = truncate128(HMAC-SHA-256(
      key    = aggregator_secret,
      input  = "MIX/agg/v1" || aggregator_scope_id))

aggregator_secret is a per-aggregator 32-byte value SHOULD be rotated periodically. aggregator_scope_id is a 128-bit value identifying the aggregation domain (typically the aggregator's own Node ID, but a distinct value MAY be used when a single operator runs multiple disjoint aggregation domains).¶

agg_token is stable per aggregator for the lifetime of aggregator_secret, which allows a downstream Node to detect a loop that transits the aggregator twice: the same agg_token reappears in the accumulating path.¶

14.2. Construction Rules

When a Transit Node V receives a NODE_INFO_ADVERTISEMENT and re-floods it to peer P, V MAY apply aggregation:¶

1. Let interior be the contiguous suffix of path whose elements V considers part of its own aggregation domain, followed by V's own about-to-be-appended element.¶

2. If aggregation to P is permitted by local policy AND |interior| > 1, V replaces interior in the outbound path with a single element:¶

   flags            = 0x01                 ; aggregated bit set
   node_id_or_token = agg_token            ; V's aggregation token
   srtt_us          = sum(srtt_us over interior)
   hop_count        = sum(hop_count over interior)
   

   ¶

3. Otherwise, V appends its own element unchanged:¶

   flags            = 0x00
   node_id_or_token = V.node_id
   srtt_us          = observed sRTT to previous hop
   hop_count        = 1
   

   ¶

Aggregation MUST NOT re-order path elements outside the aggregated suffix. Aggregation MUST NOT alter path elements that are already aggregated by a different aggregator (recognizable by their flags being set with a different node_id_or_token).¶

14.3. Loop Detection

A receiver detects a loop as follows:¶

• For a non-aggregated element (flags bit 0 clear), the receiver checks whether node_id_or_token equals its own Node ID.¶

• For an aggregated element (flags bit 0 set), the receiver checks whether node_id_or_token equals any agg_token derived from its own aggregator_secret and any aggregator_scope_id it uses.¶

If either check matches, the advertisement is a loop: it removes the sending peer's candidate instead of adding one (Section 4.2).¶

14.4. Selection Semantics

Best-path selection (Section 4.4) SHOULD use the sum of hop_count across path elements as the "path length" comparison metric, not path_len (the number of encoded elements). This keeps aggregated and non-aggregated advertisements comparable.¶

14.5. Policy and Configurability

Aggregation is a local policy decision at each Transit Node. Implementations MUST provide operator control over:¶

• Whether aggregation is enabled at all.¶

• Which peers receive aggregated advertisements (typically peers outside the aggregator's administrative domain).¶

• The aggregator_secret and its rotation schedule.¶

A downstream Node cannot un-aggregate an aggregated path element. Its best-current selection algorithm operates on the aggregated metrics directly.¶

15.1. Timer

For each peer P and each key K (a Node ID for Node Table, or a (source_node_id, full_name_hash) pair for Publisher and Subscriber Tables), a Node maintains one timer T[P,K].¶

• On sending an advertisement to P for K, the Node records the current time as the last-send time.¶

• Before sending any subsequent advertisement to P for K, the Node checks now - last_send >= mrai_ms. If not, the send is deferred until the timer expires; only the most recent deferred state (if any) is transmitted when it does.¶

If the sent-state record (Section 11) suppresses the send outright (state unchanged from last transmitted), the timer is not restarted.¶

15.2. Withdrawal Bypass

A NODE_INFO_WITHDRAWAL, NODE_UNREACH, SUBSCRIBE_INFO_WITHDRAWAL, or PUBLISH_INFO_WITHDRAWAL MUST NOT be held by the MRAI timer. Withdrawals are sent immediately and reset T[P,K] so that a subsequent advertisement for the same key is delayed by mrai_ms (this preserves the anti-flap property even across a withdrawal-advertisement cycle).¶

15.3. Interaction With Other Mechanisms

MRAI, the sent-state record, and the token-bucket rate limiter compose:¶

1. Sent-state record: identical state → suppressed. Applied first.¶

2. MRAI: different state, timer not expired → deferred. Applied second.¶

3. Token bucket: send admitted → consume token; empty bucket → dropped without updating the sent-state record (retry on next state change).¶

15.4. Convergence Bound

For a network with maximum diameter D hops and MRAI mrai_ms, the worst-case convergence time for a single state change is D * mrai_ms + propagation. Operators SHOULD size mrai_ms with this in mind; a value larger than one round-trip across the mesh may cause observable stall during correlated failures.¶

18.1. Normative References

[MoQTransport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, 1 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-22>.

[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/rfc/rfc2119>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[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/rfc/rfc8174>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

18.2. Informative References

[BGP]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[LAPS]

"Latency-Aware Peering for Streaming (LAPS) Relay Protocol", 2025, <https://github.com/Quicr/laps/blob/main/docs/relay-protocol.md>.

[MOQ-CLUSTER]

Curley, L., "MoQ Cluster Extension", Work in Progress, Internet-Draft, draft-lcurley-moq-cluster-01, 21 September 2026, <https://datatracker.ietf.org/doc/html/draft-lcurley-moq-cluster-01>.

[RR]

Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/rfc/rfc4456>.

[SipHash]

Aumasson, J. and D. J. Bernstein, "SipHash: a fast short-input PRF", 2012, <https://www.aumasson.jp/siphash/siphash.pdf>.

A.1. draft-nandakumar-moq-mix-00

• Initial version.¶