MAHP: Multicast Adaptive HTTP Proxy

MAHP (Multicast Adaptive HTTP Proxy) is Blockcast's high-throughput broadcast delivery protocol based on ROUTE/FLUTE (RFC 9223). It enables unmodified HTTP streaming applications — DASH/HLS players, gaming clients, software updaters — to transparently leverage one-to-many multicast distribution without any client-side changes.

MAHP works as a transparent proxy: the MAHP Sender encodes standard HTTP content (CMAF segments) into ROUTE Transport Objects for multicast delivery, and the MAHP Receiver at the edge decodes them back into standard HTTP responses served from an encrypted local cache. From the player's perspective, it's connecting to a normal HTTP CDN edge server.

---

How MAHP Works

MAHP bridges the gap between HTTP unicast and IP multicast in three stages:

1. Encoding (CAST → MAHP Sender)

The MAHP Sender is a Caddy-based service co-located with FFmpeg on each CAST node. It receives CMAF HTTP segments (DASH/HLS) from FFmpeg and re-encodes them for multicast delivery:

• ROUTE encoding: Each CMAF segment becomes a ROUTE Transport Object with an auto-incremented Transport Object Identifier (TOI). The ROUTE session multiplexes objects across Transport Session Identifier (TSI) channels — video, audio, and metadata on separate TSIs.

• FEC protection: Each Transport Object is protected with Forward Error Correction (see FEC & Authentication below) so receivers can reconstruct content even with significant packet loss.

• TESLA authentication: Every packet is signed using time-delayed key disclosure, preventing injection of forged content into the multicast stream.

• Signaling: Lower Layer Signaling (LLS) on 224.0.23.60:4937 for ATSC 3.0 service discovery, and Service Level Signaling (SLS) for manifests on TSI 0.

• File delivery: Pre-positioned content delivery via File Delivery Table (FDT) metadata for non-live assets.

Standards support: ATSC 3.0, DVB-MABR, and 3GPP MBMS.

2. Distribution (Sender → RELAY → BEACON)

Once encoded, ROUTE objects are delivered downstream through two mechanisms:

• Unicast push: The Sender pushes ROUTE objects to downstream MAHP Receivers over HTTP. This is used for the initial hop from CAST to RELAY when direct multicast peering is unavailable.

• Multicast retransmission: RELAYs re-multicast received content to downstream RELAYs and BEACONs within their coverage area via SSM groups.

RELAYs can be chained hierarchically — CAST → parent RELAY → child RELAY → BEACON — forming a multi-level distribution tree that scales coverage without overloading any single node.

3. Reception & Serving (MAHP Receiver → Player)

The MAHP Receiver on each RELAY and BEACON performs the multicast-to-HTTP conversion:

1. Joins SSM groups via IGMPv3 and receives ROUTE Transport Objects.

2. Applies FEC decoding to reconstruct any lost packets.

3. Verifies TESLA authentication to confirm packet integrity.

4. Pushes reconstructed HTTP objects (DASH/HLS segments) into the local encrypted cache.

5. Serves standard HTTP responses to connecting players — the player sees a normal CDN edge server.

The player is completely unaware of the multicast transport underneath.

---

RELAY vs. BEACON: Key Differences

Both RELAYs and BEACONs run the MAHP Receiver, but they have distinct roles in the TreeDN tree:

Capability	RELAY	BEACON
MAHP Receiver	Yes	Yes
Encrypted cache	Yes	Yes
Serve HTTP players	Yes	Yes
FEC repair server	Yes	No
Re-multicast downstream	Yes	No
Bridge multicast islands (AMT)	Yes	No
Unicast origin fallback	Yes	Via upstream RELAY

Key distinction: RELAYs operate a FEC repair server and can re-multicast to downstream nodes. BEACONs are leaf nodes only — they consume repairs from upstream RELAYs but do not serve them or carry transit traffic.

---

MAHP on RELAY Nodes

Each RELAY exposes an ALPN ingress that routes incoming HTTP connections (ALPN h2, http/1.1) to the encrypted cache. The cache is populated by the MAHP Receiver, so the player is completely unaware of the multicast transport.

MAHP Receiver + Repair Server

The MAHP Receiver on each RELAY:

• Receives multicast streams via IGMPv3 SSM join, applies FEC decoding, and pushes reconstructed HTTP objects (DASH/HLS segments) into the local encrypted cache.

• Operates a FEC repair server (port 8081): Downstream RELAYs and BEACONs can request missing FEC symbols via unicast HTTP.

• Retransmits multicast to downstream nodes within its coverage area.

Encrypted cache storage

All cached objects are encrypted at rest using per-delivery-service keys derived from CDN Controller configuration. Node operators cannot read cached content even with physical access. Standard DRM (Widevine, PlayReady, FairPlay) is preserved end-to-end — the cache stores already-encrypted DRM segments, and cache-layer encryption adds a second envelope. Key rotation is managed by the CDN Controller and distributed via SyncRPC.

Multicast island bridging

RELAYs acquire streams from CAST nodes or parent RELAYs via AMT tunneling when native multicast peering is unavailable, then re-multicast locally — extending multicast coverage across unicast-only network segments.

---

MAHP on BEACON Nodes

The MAHP BEACON is a Caddy-based multicast receiver that acts as a transparent reverse proxy at the deep network edge, combining multicast reception with HTTP serving:

• Multicast reception: Joins SSM groups via IGMPv3, receives ROUTE Transport Objects, applies FEC decoding.

• HTTP cache proxy: Serves cached content to local clients as standard HTTP/DASH/HLS responses — unmodified players connect directly.

• Encrypted cache storage: All cached objects are encrypted at rest, matching the RELAY encrypted cache model.

• Unicast repair client: Requests missing FEC symbols from an upstream RELAY's repair server via HTTP GET when multicast packets are lost. Unlike RELAYs, BEACONs do not operate a repair server — they only consume repairs.

• TESLA verification: Authenticates each packet using time-delayed key disclosure.

Deployment: Packaged as a container image, the MAHP BEACON runs on:

• ISP deep-edge modems (Purple Foundation or compatible container runtimes)

• Smart TVs and set-top boxes

• Mobile phones (Android/iOS)

• Home servers and mini-PCs

Configuration is pushed from the CDN Controller via blockcastd and can be updated without restarts.

---

Forward Error Correction & Authentication

All MAHP multicast streams are protected against packet loss and tampering.

FEC (Forward Error Correction)

Scheme	Use Case	Recovery
RaptorQ	Optimal for live video; rateless fountain code	>30% packet loss without retransmission
Reed-Solomon	Precise recovery for file delivery; MDS code	Exact symbol-count recovery
Cross-Session RaptorQ	Combines symbols across sessions for interleaved FEC	Enhanced protection for bursty loss

When FEC alone cannot recover lost data, the MAHP Receiver falls back to unicast repair requests to the nearest upstream RELAY's repair server (port 8081).

Authentication

• TESLA (Timed Efficient Stream Loss-tolerant Authentication): Time-delayed key disclosure for ROUTE/FLUTE streams. Configurable keychain length, disclosure delay, and crypto algorithms (RSA, ECDSA). This is the primary authentication mechanism for all MAHP streams.

---

Publishing Flow

This flow shows how content enters the MAHP delivery path — from the CAST node's FFmpeg encoder through ROUTE encoding to multicast transmission.

---

Standards & References

Standard	Role in MAHP
RFC 9223 (ROUTE)	Real-time object delivery over multicast — the core MAHP encoding format
RFC 9706 (TreeDN)	Tree-based CDN architecture that MAHP implements
RFC 3376 (IGMPv3)	IPv4 multicast group membership for SSM joins
ATSC 3.0	Over-the-air broadcast standard using ROUTE/FLUTE delivery
DVB-MABR	Multicast ABR delivery standard
3GPP MBMS	Mobile broadcast standard