Multicast Delivery and Endpoint Discovery for Media over QUIC

1.1. Multicast as Supplement to MoQ Unicast

Multicast delivery as defined in this document is a supplement to MoQ/QUIC unicast. Subscribers MUST establish a MoQ session first to receive the catalog, negotiate parameters, and receive initial media. Multicast MAY then be used as an optimized delivery path for ongoing media data. This ensures that codec configuration is available before multicast reception begins.¶

Exception: MMTP-packaged streams [MOQ-MMT] delivered via ATSC 3.0 broadcast or native SSM MAY operate as unidirectional data streams without a MoQ session. MMTP carries per-packet routing (packet_id), timing (timestamp), sequencing (Packet Sequence Number), and FEC framing (FEC Type, FEC payload IDs) natively, and its signaling messages identify the Assets in band: every Asset sent to a multicast endpoint is named by a PA message on its sending entity's packet_id 0 signaling sub-flow, whose MP table locates the Asset by source address, group address, port and packet_id (Section 5). A receiver without the catalog takes the FEC configuration from the AL-FEC message ([MOQ-MMT] Section 8.3) when the flow carries one. A receiver that holds the catalog takes both from the catalog, which remains authoritative for it (Section 4.1; [MOQ-FEC] Section 5.2). ATSC 3.0 and ARIB STD-B60 receivers consume MMTP over SSM as their native delivery path.¶

4.1. Multicast Endpoint Format

The multicast field is a root-level extension member of the MSF catalog; the catalog envelope for this suite is described in [MOQ-MMT] Section 12. [I-D.ietf-moq-msf] Section 5 permits producers to add fields and requires parsers to ignore fields they do not understand: parsers that do not support multicast MUST ignore it.¶

The multicast field contains an endpoints array listing one or more multicast groups. A single-endpoint deployment uses a one-element array:¶

{
  "multicast": {
    "endpoints": [{
      "sourceAddress": "198.51.100.10",
      "groupAddress": "232.0.10.1",
      "port": 8000,
      "tracks": [
        { "name": "video",        "packetId": 1 },
        { "name": "video/repair", "packetId": 2 },
        { "name": "audio",        "packetId": 3 },
        { "name": "audio/repair", "packetId": 4 }
      ],
      "bandwidth": 6500000
    }]
  }
}

Multi-group deployments (e.g., per-quality ABR tiers or separate audio/video groups) use multiple elements:¶

{
  "multicast": {
    "endpoints": [
      {
        "sourceAddress": "10.0.0.1",
        "groupAddress": "232.1.1.1",
        "port": 5004,
        "tracks": [
          { "name": "video",        "packetId": 1 },
          { "name": "video/repair", "packetId": 2 }
        ]
      },
      {
        "sourceAddress": "10.0.0.1",
        "groupAddress": "232.1.1.2",
        "port": 5004,
        "tracks": [
          { "name": "audio", "packetId": 3 }
        ]
      }
    ],
    "networkSource": [{
      "type": "amt",
      "discovery": "driad",
      "relay": "amt.example.com"
    }]
  }
}

The multicast object contains the following members:¶

endpoints (array of objects, REQUIRED): One or more multicast endpoint objects as defined below. The array MUST NOT be empty.¶

networkSource (array of objects, OPTIONAL): Network delivery configuration applying to all endpoints; see Section 4.2.¶

auth (object, OPTIONAL): Content authentication configuration for the bc-provenance profile; see Section 7.2.¶

Endpoint field definitions:¶

sourceAddress (string, OPTIONAL): SSM source IP address per [RFC4607]. Its presence selects SSM and its absence Any-Source Multicast (ASM).¶

protocol (string, OPTIONAL): "ssm" or "asm", restating that mode. An endpoint where it disagrees with sourceAddress is ignored (see below).¶

groupAddress (string, REQUIRED): Multicast group address.¶

• SSM range: 232.0.0.0/8 (IPv4), ff3x::/32 (IPv6)¶
• ASM range: 224.0.0.0/4 (IPv4), ff0x::/16 (IPv6)¶

port (integer, REQUIRED): UDP port number.¶

tracks (array, REQUIRED): Tracks available on this endpoint. Each element is an object with the following fields:¶

• name (string, REQUIRED): Track name corresponding to the track identifier used in the MoQ catalog.¶
• packetId (integer, REQUIRED): MMTP packet_id used for packet-level track routing on multicast. Maps directly to the Packet ID field in the MMTP header (Section 3.1 of [MOQ-MMT]). The value is an integer in the range 1..65535. Each value MUST denote exactly one MMTP packet sub-flow across all endpoints of the MMT sending entity (Section 2) for the lifetime of the delivery session, not merely within one (sourceAddress, groupAddress, port) tuple; two distinct sub-flows MUST NOT share a value ([ISO.23008-1] Clause 9.2.3). A sub-flow is one sequence of packets with one packet_sequence_number space. An endpoint that carries another endpoint's sub-flow packet for packet therefore carries it under the same value, and every other sub-flow takes a value of its own. The rungs of a ladder never share a value. A catalog track denotes one sub-flow: every endpoint that lists a track carries that track's one sub-flow, under one value. Media that the sending entity packetizes separately for several endpoints, such as audio packetized once per rung, MUST be published as a separate track for each packetization, with its own name, value, fec object and repair tracks, because the copies differ in the bytes that FEC protects ([MOQ-FEC] Section 7.3). packet_id 0 is reserved for the sending entity's MMTP signaling sub-flow ([MOQ-MMT] Section 3.1; Section 5), which arrives on the same tuples as the media; a publisher MUST NOT advertise it for a track.¶

bandwidth (integer, RECOMMENDED): Aggregate bandwidth of this endpoint in bits per second, defined as the sum of the UDP payload bitrates of all tracks carried on the endpoint, including repair tracks, plus the MMTP signaling sub-flow on packet_id 0 (Section 5) where the endpoint carries it; IP/UDP header overhead is excluded. Publishers SHOULD include bandwidth to enable capacity-aware join decisions. Subscribers SHOULD check available network capacity before joining high-bandwidth groups.¶

networkSource (array of objects, OPTIONAL): Network delivery configuration for this endpoint; see Section 4.2.¶

Each (sourceAddress, groupAddress, port) multicast tuple MUST be associated with at most one MoQ namespace. Publishers requiring multiple independent streams MUST use distinct multicast groups or ports. An MMT sending entity (Section 2) serves exactly one MoQ namespace, which is one MMT Package (Section 5); a publisher that serves several namespaces acts as several sending entities, each with its own endpoints, its own packetId assignment and its own packet_id 0 signaling sub-flow.¶

Receivers MUST ignore endpoints whose fields are mutually inconsistent -- for example, a protocol of "ssm" with sourceAddress omitted, a sourceAddress present with protocol of "asm", or a groupAddress outside the multicast address space. Receivers MUST likewise ignore an endpoint that lists a track packetId outside the range 1..65535, including 0, the MMTP signaling flow.¶

Subscribers receiving a catalog with multicast endpoints MAY auto-connect to the multicast group when multicast APIs are available and multicast delivery is preferred (UDP socket access, native or AMT). Multicast joins create IGMP/MLD state on intermediate routers; subscribers SHOULD only join when multicast provides a concrete benefit over unicast.¶

Joining an SSM endpoint requires source-specific group membership signaling: receivers MUST use IGMPv3 [RFC3376] (IPv4) or MLDv2 [RFC3810] (IPv6) to convey (S,G) joins. Earlier protocol versions (IGMPv2/MLDv1) cannot express source-specific joins; if the receiver's network segment operates at an earlier version (for example, due to an IGMPv2 querier or snooping switch on the segment), SSM joins fail silently. Receivers SHOULD detect the absence of multicast data following a join and fall back to MoQ/QUIC unicast (Section 6).¶

During multicast join (which may take 1-3 seconds for IGMP/MLD), subscribers SHOULD continue receiving via MoQ/QUIC. Once multicast data arrives, subscribers switch to the multicast path.¶

If multicast reception fails or degrades, subscribers fall back to MoQ/QUIC unicast per Section 6.¶

Receivers SHOULD implement hysteresis to prevent flapping between multicast and unicast paths. Switch away from multicast after sustained loss or consecutive FEC block failures; switch back only after multicast reception is stable for a sufficient period. Specific thresholds are implementation-defined and SHOULD be tunable.¶

4.2. Network Source Types

The networkSource field is an array of network-source objects describing how subscribers can reach the multicast stream when native IP multicast routing is not available. It MAY appear at the multicast level (applying to all endpoints) or on individual endpoints; a single source is expressed as a one-element array.¶

Each network-source object contains:¶

type (string, REQUIRED): Delivery technology identifier.¶

Defined types:¶

{
  "networkSource": [{
    "type": "amt",
    "relay": "198.51.100.1",
    "discovery": "driad"
  }]
}

{
  "networkSource": [{
    "type": "atsc3",
    "frequency": 533000,
    "plpId": 0,
    "serviceId": 1,
    "slsUri": "https://example.com/atsc3/sls/service1.xml"
  }]
}

{
  "networkSource": [
    { "type": "amt", "relay": "198.51.100.1", "discovery": "driad" },
    { "type": "atsc3", "frequency": 533000, "plpId": 0 }
  ]
}

6.1. Packaging Negotiation

Packaging is advertised per track in the catalog, and a subscriber subscribes by name to the tracks whose packaging it supports. The altGroup catalog field ([I-D.ietf-moq-msf] Section 5.2.12, profiled in [MOQ-MMT] Section 4.4) groups alternatives of the same content in different packaging formats.¶

6.2. Per-Block Unicast Repair

A multicast or AMT receiver repairs every FEC block in-band from the repair symbols it receives on its multicast paths. For a block that in-band FEC leaves unrecovered at its FEC deadline, a receiver that holds a MoQ session (Section 1.1) applies the receiver repair policy of [MOQ-FEC] Section 11.4, which repairs a keyframe-bearing block by a standalone FETCH [I-D.ietf-moq-transport] of the block's repair-track group. That group's ID is the block's SS_Start, from the Repair FEC Payload ID of a multicast repair packet of the block, extended to 62 bits with the wrap epoch of [MOQ-FEC] Section 7.5. A receiver that takes its repair from multicast has usually received no repair-track Group ID over MoQ, so before its first FETCH it establishes that epoch from the Largest Location that a TRACK_STATUS request for the repair track reports ([I-D.ietf-moq-transport] Section 9.13): the Group of the LARGEST_OBJECT parameter in the REQUEST_OK (TRACK_STATUS_OK) that answers the request, as [MOQ-FEC] Section 7.5 specifies, unless it has received such a Group ID or has observed the FEC instance from its first block. For lost source packets whose block it has not delimited, because it holds no repair packet of that block, the receiver instead fetches the Group range that [MOQ-FEC] Section 7.5 derives from a lost SS_ID. No other coordinate mapping is needed, and the returned symbols are deduplicated per item 1 of Section 6. A receiver without a MoQ session cannot request unicast repair; it relies on in-band FEC and, where published, the keyframe overlay ([MOQ-FEC] Section 6.4).¶

A FETCH for a repair-track group that the relay no longer retains fails or returns none of the group's objects, and the receiver then treats the block as unrecoverable. How long a relay retains repair-track groups is relay policy.¶

7.1. Multicast Security

SSM inherently limits traffic to authorized sources via (S,G) filtering. Receivers MAY detect replayed packets by tracking the MMTP Packet Sequence Number per packet_id within one (source address, groupAddress, port) tuple and discarding duplicates and packets outside a bounded reordering window. The source address is that of the received packets, the same address Section 5 matches: it equals sourceAddress on an SSM endpoint and is read from each packet on an ASM endpoint, so two sending entities that share an ASM group and each use the same packet_id are tracked separately. For AMT, trust is delegated to the relay per [RFC7450].¶

7.2. Content Authentication

Multicast UDP delivery lacks the integrity protection that QUIC provides on unicast paths. This section defines "bc-provenance", a manifest-provenance authentication profile. The publisher computes, per MoQ group per protected track, an ordered digest structure over the group's objects; signs its root with a dedicated broadcast Ed25519 key [RFC8032]; and publishes the signed manifest on a dedicated MoQ track. Receivers verify each object -- received or FEC-recovered -- against the group root before admitting it to reassembly and decode. Verification cost is one signature verification per group; all digests use BLAKE3 [BLAKE3]. Per-packet signatures suit only low-rate signaling flows; media tracks use this profile.¶

"auth": {
  "scheme": "bc-provenance",
  "hash": "blake3",
  "sig": "ed25519",
  "publicKey": "<32-byte Ed25519 public key, base64url unpadded>",
  "keyId": "v1",
  "previousKey": "<optional, prior public key during rotation>",
  "compaction": "merkle",
  "enforcement": "shadow",
  "tracks": [
    { "mediaTrack": "video/base",
      "manifestTrack": "video/manifest",
      "authScope": "<32-byte value, base64url unpadded>",
      "sourceSymbolFormat": "full-mmtp-packet" }
  ]
}

digest_i = BLAKE3(authScope;
                  0x00 || u32(object_id_i) || u32(length_i)
                       || authenticated_bytes_i)

MTH(D):                       # D = leaf digests, ascending object_id
  n = length(D)
  if n == 1: return D[0]
  k = largest power of two strictly less than n
  return BLAKE3(authScope; 0x01 || MTH(D[0:k]) || MTH(D[k:n]))

signed_message =
    "BCPV1-sig"                       # 9-octet ASCII domain tag
 || u8(manifest_format_version)       # = 1
 || u8(compaction)                    # 0 = none, 1 = merkle
 || lp16(broadcast_namespace)
 || lp16(track_name)                  # the media track name
 || u64(group_id)
 || u32(object_id_min) || u32(object_id_max)
 || lp16(keyId)
 || params_hash                       # 32 octets (below)
 || lp32(root_or_list)                # 32-octet root (merkle), or
                                      #   32*m-octet flat list (none)

params_hash = BLAKE3("BCPV1-params"
    || lp16(codec) || u32(timescale) || u32(groupDurationTicks)
    || lp16(fecAlgorithm) || u32(sourceSymbols) || u32(repairSymbols)
    || u32(symbolSize) || u32(interleaveDepthMs))

manifest_object =
    u8(manifest_format_version)       # = 1
 || u8(compaction)                    # 0 = none, 1 = merkle
 || u64(group_id)
 || u32(object_count = m)
 || m * ( u32(object_id) || u32(length) || 32-octet digest )
                                      #   in ascending object_id order
 || 64-octet Ed25519 signature

7.3. Catalog as Attack Surface

The multicast catalog extension directs receivers to join multicast groups and to dial network sources. A hostile or compromised catalog is therefore an attack vector:¶

• Join amplification: Catalog-directed joins create IGMP/MLD and multicast routing state on intermediate routers (Section 4.1). A catalog listing many endpoints, or rapidly changing endpoints, can exhaust router state or subscribe receivers to unwanted high-bandwidth traffic. Receivers MUST validate that each groupAddress falls within the multicast address ranges given in Section 4.1 before joining, and SHOULD bound the number of concurrent joins performed on behalf of a single catalog.¶

• Attacker-chosen dial-out: The relay field of an AMT network source is an address the receiver dials over UDP. A hostile catalog can direct traffic at arbitrary targets (traffic reflection) or at internal infrastructure (address-space probing). Receivers and relays MUST treat catalog-supplied endpoint and relay addresses as untrusted input and validate them against local policy (such as an allowlist of permitted relays or networks) before dialing, and SHOULD reject loopback, link-local, and otherwise non-routable relay addresses unless explicitly configured.¶