Skip to main content
Content Delivery Protocols and Tools

ROUTE

At a glance
  • What it is: a protocol for robust delivery of application objects, including objects with real-time constraints such as DASH or HLS segments.
  • Status: an Informational, independent submission (April 2022); it is not an IETF specification and has no IETF consensus.
  • Relation to FLUTE: aligned with FLUTE; ATSC 3.0 and DVB-MABR profile it, while 3GPP TS 26.346 and TS 26.517 do not use it.

What it delivers​

ROUTE delivers application objects to receivers over a unidirectional transport (RFC 9223 section 1.1). An application object is data with a meaning to the application: a file, a DASH video segment, a WAV audio clip, a CMAF addressable resource, an MPEG-4 video clip.

  • Real-time delivery: ROUTE is designed to deliver sequences of related application objects in a timely manner, for example the DASH segments of one Representation or the CMAF addressable resources of one CMAF Track (RFC 9223 section 1.1).
  • Low latency: it supports chunked delivery of real-time objects, and low-latency delivery of DASH and HLS content with CMAF Chunks (RFC 9223 section 1.1).
  • Non-real-time content: it also delivers content not rendered as it is received, such as a downloaded application or data for a DRM client (RFC 9223 section 1.1).
  • Caching model: objects are recovered into a cache at the receiver, from which applications may fetch them with standard HTTP requests (RFC 9223 section 1.1).

ROUTE operates over UDP/IP (RFC 9223 section 1.2). Its session metadata may be delivered out of band or in band.

Data model​

  • Application Object: data that has meaning to the application using ROUTE (RFC 9223 section 1.3).
  • Delivery Object: an object on its way to the application, from the ROUTE sender to the ROUTE receiver (RFC 9223 section 1.3).
  • Transport Object: an object identified by an LCT Transport Object Identifier (TOI); a source or a repair object, depending on whether a Source Flow or a Repair Flow carries it (RFC 9223 section 1.3).
  • Transport Session: an LCT channel, identified by its Transport Session Identifier (TSI) (RFC 9223 section 1.3). For media, it typically carries one media component, such as a DASH Representation.
  • ROUTE Session: one or more Transport Sessions, associated with an IP address and port (RFC 9223 section 1.3).
  • Source Flow: a Transport Session carrying source data (RFC 9223 section 1.3). A receiver may use it without the Repair Flows.
  • Repair Flow: a Transport Session carrying repair data for one or more Source Flows (RFC 9223 section 1.3).

Delivery object modes​

The mode is signalled per object, in the LCT Codepoint (RFC 9223 section 4).

  • File Mode: an out-of-band Extended FDT (EFDT) describes the delivery objects (RFC 9223 section 4.1 and 9.1). It is optimised for DASH content using Segment Template with number substitution: a File Template in the EFDT avoids sending the metadata repeatedly.
  • Entity Mode: the object's metadata travels with it, as HTTP entity headers (RFC 9223 section 4.2 and 9.1). It suits addressing that changes with time, such as time substitution and segment timeline, and can carry part of a file with HTTP Partial Content headers.
  • Unsigned Package Mode: a group of files packaged together for delivery as Multipart MIME, which the client unpacks (RFC 9223 section 4.3).
  • Signed Package Mode: the same, with one or more signatures for validation (RFC 9223 section 4.4).

FEC and repair flows​

  • Protection of objects: the ROUTE repair protocol is FEC-based (RFC 9223 section 9.4). Unlike the FEC Framework of RFC 6363, it protects delivery objects rather than packets. As an extension to FLUTE, one source block may protect several delivery objects.
  • Separate flows: a Repair Flow protects delivery objects from one or more Source Flows (RFC 9223 section 5.5). Receivers not capable of FEC can ignore the repair packets.
  • FEC scheme: the FEC Payload ID for Repair Flows is specified in RFC 6330 (RaptorQ). In Source Flows, the FEC Payload ID of the Compact No-Code FEC scheme is a 32-bit start_offset: the octet number of the first octet of the fragment in the delivery object (RFC 9223 section 2.3; RFC 9223 section 2.4).
  • Telling source from repair: by different ROUTE sessions, by different LCT channels (TSI values), or, on the same LCT channel, by the most significant PSI bit (RFC 9223 section 9.4).

Relation to FLUTE​

ROUTE is aligned with FLUTE as defined in RFC 6726, and with the MBMS extensions to it (RFC 9223 section 1.1). It reuses several basic FLUTE protocol features, and adds optimisations and restrictions for real-time delivery of media data. It also uses some principles of FCAST (RFC 6968), for example sending object metadata and object content together in a compound object.

Among others, ROUTE enables or enhances: (RFC 9223 section 1.1)

  • real-time delivery of object-based media data; (RFC 9223 section 1.1)
  • flexible packetisation, media-aware as well as transport-aware; (RFC 9223 section 1.1)
  • independence of application objects and delivery objects: a delivery object may be part of a file, or a group of files (RFC 9223 section 1.1).

Profiles​

Services may define ROUTE profiles in their own standards organisations (RFC 9223 section 1.1 and 8). RFC 9223 names two:

  • ATSC 3.0 specifies ROUTE integrated with an ATSC 3.0 services layer (ATSC-ROUTE) (RFC 9223 section 1.1).
  • DVB has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) (RFC 9223 section 1.1 and 8).

A profile may restrict LCT header values and extensions, Codepoints and signalling attributes, and add its own (RFC 9223 section 8). It does not redefine the semantics of the ROUTE attributes RFC 9223 specifies, so that profiles stay interoperable.

Sources for this page
  • At a glance and status: RFC 9223, header, Abstract and section 1.1 (RFC 9223 header, Abstract and section 1.1).
  • What it delivers: RFC 9223, sections 1.1 and 1.2 (RFC 9223 section 1.1 and 1.2).
  • Data model: RFC 9223, section 1.3 (RFC 9223 section 1.3).
  • Delivery object modes: RFC 9223, sections 4 to 4.4 and 9.1 (RFC 9223 section 4 to 4.4 and 9.1).
  • FEC and repair flows: RFC 9223, sections 2.3, 2.4, 5.5 and 9.4 (RFC 9223 section 2.3, 2.4, 5.5 and 9.4).
  • Relation to FLUTE: RFC 9223, sections 1.1 and 9.4 (RFC 9223 section 1.1 and 9.4).
  • Profiles: RFC 9223, sections 1.1 and 8 (RFC 9223 section 1.1 and 8).
  • Not in 3GPP MBMS or MBS: "ROUTE" does not occur in TS 26.346 V19.3.0 or TS 26.517 V19.3.0.