# MAHP: Multicast Adaptive HTTP Proxy

MAHP (Multicast Adaptive HTTP Proxy) is Blockcast's high-throughput broadcast delivery protocol based on [ROUTE/FLUTE (RFC 9223)](https://datatracker.ietf.org/doc/rfc9223/). 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.

{% @mermaid/diagram content="flowchart LR
subgraph CAST\[CAST Node]
FF\[FFmpeg] -->|CMAF HTTP| SENDER\[MAHP Sender<br/>Caddy]
end

```
subgraph RELAY[RELAY Node]
    RX_R[MAHP Receiver] -->|push| CACHE_R[Encrypted Cache]
    REPAIR[FEC Repair Server]
    RX_R --- REPAIR
end

subgraph BEACON[BEACON Node]
    RX_B[MAHP Receiver] -->|push| CACHE_B[Encrypted Cache]
end

SENDER -->|ROUTE/FLUTE<br/>multicast| RX_R
RX_R -->|re-multicast| RX_B
RX_B -.->|repair req| REPAIR

CACHE_R -->|HTTP| P1[Player]
CACHE_B -->|HTTP| P2[Player]" %}
```

***

## 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](/main/overview/control-plane/treedn-multicast.md#cast-sender-content-source). 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](#forward-error-correction--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](/main/overview/control-plane/treedn-multicast/amt-relays.md) 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.

{% @mermaid/diagram content="sequenceDiagram
participant FF as FFmpeg (CAST)
participant SENDER as MAHP Sender
participant RELAY as RELAY MAHP Rx
participant BEACON as BEACON MAHP Rx
participant PLAYER as Player

```
FF->>SENDER: CMAF HTTP segments
SENDER->>SENDER: ROUTE encode + FEC + TESLA
SENDER->>RELAY: ROUTE/FLUTE (unicast push or multicast)
RELAY->>RELAY: FEC decode + push to cache
RELAY->>BEACON: Re-multicast (SSM)
BEACON->>BEACON: FEC decode + push to cache

opt Packet loss at BEACON
    BEACON->>RELAY: FEC repair request (HTTP 8081)
    RELAY->>BEACON: Repair symbols
end

PLAYER->>BEACON: HTTP request (DASH/HLS)
BEACON->>PLAYER: Serve from encrypted cache" %}
```

***

## Standards & References

| Standard                                                       | Role in MAHP                                                             |
| -------------------------------------------------------------- | ------------------------------------------------------------------------ |
| [RFC 9223](https://datatracker.ietf.org/doc/rfc9223/) (ROUTE)  | Real-time object delivery over multicast — the core MAHP encoding format |
| [RFC 9706](https://datatracker.ietf.org/doc/rfc9706/) (TreeDN) | Tree-based CDN architecture that MAHP implements                         |
| [RFC 3376](https://datatracker.ietf.org/doc/rfc3376/) (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                                                |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blockcast.network/main/overview/control-plane/treedn-multicast/mahp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.