RFC 9223: Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)

1.1. Overview

The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol can be used for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Unidirectional transport in this document has identical meaning to that in RFC 6726 [RFC6726], i.e., transport in the direction of receiver(s) from a sender. The robustness is enabled by a built-in mechanism, e.g., signaling for loss detection, enabling loss recovery, and optionally integrating application-layer Forward Error Correction (FEC).¶

Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, an MPEG Dynamic Adaptive Streaming over HTTP (DASH) [DASH] video segment, a WAV audio clip, an MPEG Common Media Application Format (CMAF) [CMAF] addressable resource, an MPEG-4 video clip, etc.¶

The ROUTE protocol is designed to enable delivery of sequences of related Application Objects in a timely manner to receivers, e.g., a sequence of DASH video segments associated to a Representation or a sequence of CMAF addressable resources associated to a CMAF Track. The applications of this protocol target services enabled on media consumption devices such as smartphones, tablets, television sets, and so on. Most of these applications are real-time in the sense that they are sensitive to and rely upon such timely reception of data. The ROUTE protocol also supports chunked delivery of real-time Application Objects to enable low-latency streaming applications (similar in its properties to chunked delivery using HTTP). The protocol also enables low-latency delivery of DASH and Apple HTTP Live Streaming (HLS) content with CMAF Chunks.¶

Content not intended for rendering in real time as it is received (e.g., a downloaded application), a file comprising continuous or discrete media and belonging to an app-based feature, or a file containing (opaque) data to be consumed by a Digital Rights Management (DRM) system client can also be delivered by ROUTE.¶

The ROUTE protocol supports a caching model where Application Objects are recovered into a cache at the receiver and may be made available to applications via standard HTTP requests from the cache. Many current day applications rely on using HTTP to access content; hence, this approach enables such applications in broadcast/multicast environments.¶

ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE) as defined in RFC 6726 [RFC6726] as well as the extensions defined in Multimedia Broadcast/Multicast Service (MBMS) [MBMS], but it also makes use of some principles of FCAST (Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols) as defined in RFC 6968 [RFC6968]; for example, object metadata and the object content may be sent together in a compound object.¶

The alignment to FLUTE is enabled since in addition to reusing several of the basic FLUTE protocol features, as referred to by this document, certain optimizations and restrictions are added that enable optimized support for real-time delivery of media data; hence, the name of the protocol. Among others, the source ROUTE protocol enables or enhances the following functionalities:¶

Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE protocol integrated with an ATSC 3.0 services layer. That specification will be referred to as ATSC-ROUTE [ATSCA331] for the remainder of this document. Digital Video Broadcasting (DVB) has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. This document specifies the Application Object delivery aspects (delivery protocol) for such services, as the corresponding delivery protocol could be used as a reference by a variety of services by specifying profiles of ROUTE in their respective fora, e.g., by adding new optional features atop or by restricting various optional features specified in this document in a specific service standard. Hence, in the context of this document, the aforementioned ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition of profiles by the services also have to give due consideration to compatibility issues, and some related guidelines are also provided in this document.¶

This document is not an IETF specification and does not have IETF consensus. It is provided here to aid the production of interoperable implementations.¶

1.2. Protocol Stack for ROUTE

ROUTE delivers Application Objects such as MPEG DASH or HLS segments and optionally the associated repair data, operating over UDP/IP networks, as depicted in Table 1. The session metadata signaling to realize a ROUTE session as specified in this document MAY be delivered out of band or in band as well. Since ROUTE delivers objects in an application cache at the receiver from where the application can access them using HTTP, an application like DASH may use its standardized unicast streaming mechanisms in conjunction with ROUTE over broadcast/multicast to augment the services.¶

1.3. Data Model

The ROUTE data model is constituted by the following key concepts.¶

Application Object:

data that has meaning to the application that uses the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, a DASH video segment, a WAV audio clip, an MPEG-4 video clip, etc.¶

Delivery Object:

an object on course of delivery to the application from the ROUTE sender to ROUTE receiver.¶

Transport Object:

an object identified by the Transport Object Identifier (TOI) in RFC 5651 [RFC5651]. It MAY be either a source or a repair object, depending on if it is carried by a Source Flow or a Repair Flow, respectively.¶

Transport Session:

a Layered Coding Transport (LCT) channel, as defined by RFC 5651 [RFC5651]. A Transport Session SHALL be uniquely identified by a unique Transport Session Identifier (TSI) value in the LCT header. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Transport Sessions are a subset of a ROUTE session. For media delivery, a Transport Session would typically carry a media component, for example, a DASH Representation. Within each Transport Session, one or more objects are carried, typically objects that are related, e.g., DASH segments associated to one Representation.¶

ROUTE Session:

an ensemble or multiplex of one or more Transport Sessions. Each ROUTE session is associated with an IP address/port combination. A ROUTE session typically carries one or more media components of streaming media e.g., Representations associated with a DASH Media Presentation.¶

Source Flow:

a Transport Session carrying source data. Source Flow is independent of the Repair Flow, i.e., the Source Flow MAY be used by a ROUTE receiver without the ROUTE Repair Flows.¶

Repair Flow:

a Transport Session carrying repair data for one or more Source Flows.¶

1.4. Architecture and Scope of Specification

The scope of the ROUTE protocol is to enable robust and real-time transport of delivery objects using LCT packets. This architecture is depicted in Figure 1.¶

The normative aspects of the ROUTE protocol focus on the following aspects:¶

                                             Application Objects
Application                                  to application
Objects from                                          ^
an application    +--------------------------------------------+
     +            |  ROUTE Receiver                   |        |
     |            |                            +------+------+ |
     |            |                            | Application | |
     |            |                            | Object Cache| |
     |            |                            +------+------+ |
     |    LCT over|    +---------------+              ^        |
     v    UDP/IP  |    | Source object |  +---------+ |        |
+----+---+        | +->+ recovery      +--+  Repair +-+        |
| ROUTE  |        | |  +---------------+  +----+----+          |
| Sender +----------+                          ^               |
+----+---+        | |                          |               |
     |            | |  +---------------+       |               |
     |            | |  | Repair object |       |               |
     |            | +->+ recovery      +-------+               |
     +----------->+    +---------------+                       |
       ROUTE      |                                            |
       Metadata   +--------------------------------------------+

1.5. Conventions Used in This Document

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

2.1. Packet Structure and Header Fields

The packet format used by ROUTE Source Flows and Repair Flows follows the ALC packet format specified in RFC 5775 [RFC5775] with the UDP header followed by the default LCT header and the source FEC Payload ID followed by the packet payload. The overall ROUTE packet format is as depicted in Figure 2.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           UDP Header                          |
|                                                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                       Default LCT header                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FEC Payload ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Payload Data                         |
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Default LCT header is as defined in the LCT building block in RFC 5651 [RFC5651].¶

The LCT packet header fields SHALL be used as defined by the LCT building block in RFC 5651 [RFC5651]. The semantics and usage of the following LCT header fields SHALL be further constrained in ROUTE as follows:¶

Version number (V):

This 4-bit field indicates the protocol version number. The version number SHALL be set to '0001', as specified in RFC 5651 [RFC5651].¶

Congestion Control flag (C) field:

This 2-bit field, as defined in RFC 5651 [RFC5651], SHALL be set to '00'.¶

Protocol-Specific Indication (PSI):

The most significant bit of this 2-bit flag is called the Source Packet Indicator (SPI) and indicates whether the current packet is a source packet or a FEC repair packet. The SPI SHALL be set to '1' to indicate a source packet and SHALL bet set to '0' to indicate a repair packet.¶

Transport Session Identifier flag (S):

This 1-bit field SHALL be set to '1' to indicate a 32-bit word in the TSI field.¶

Transport Object Identifier flag (O):

This 2-bit field SHALL be set to '01' to indicate the number of full 32-bit words in the TOI field.¶

Half-word flag (H):

This 1-bit field SHALL be set to '0' to indicate that no half-word field sizes are used.¶

Codepoint (CP):

This 8-bit field is used to indicate the type of the payload that is carried by this packet; for ROUTE, it is defined as shown below to indicate the type of delivery object carried in the payload of the associated ROUTE packet. The remaining unmapped Codepoint values can be used by a service using ROUTE. In this case, the Codepoint values SHALL follow the semantics specified in the following table. "IS" stands for Initialization Segment of the media content such as the DASH Initialization Segment [DASH]. The various modes of operation in the table (File/Entity/Package Mode) are specified in Section 4. The table also lists a Codepoint value range that is reserved for future service-specific uses.¶

Congestion Control Information (CCI):

For packets carrying DASH segments, CCI MAY convey the 32-bit earliest presentation time [DASH] of the DASH segment contained in the ROUTE packet. In this case, this information can be used by a ROUTE receiver for fast stream acquisition (details in Section 6.2). Otherwise, this field SHALL be set to 0.¶

Transport Session Identifier (TSI):

This 32-bit field identifies the Transport Session in ROUTE. The context of the Transport Session is provided by signaling metadata. The value TSI = 0 SHALL only be used for service-specific signaling.¶

Transport Object Identifier (TOI):

This 32-bit field SHALL identify the object within this session to which the payload of the current packet belongs. The mapping of the TOI field to the object is provided by the Extended File Delivery Table (FDT).¶

2.2. LCT Header Extensions

The following LCT header extensions are defined or used by ROUTE:¶

EXT_FTI:

as specified in RFC 5775.¶

EXT_TOL:

the length in bytes of the multicast transport object shall be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with 24 bits or, if required, 48 bits of Transfer Length. The frequency of using the EXT_TOL header extension is determined by channel conditions that may cause the loss of the packet carrying the Close Object flag (B) [RFC5651].¶

NOTE: The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length.¶

EXT_TIME Header:

as specified in RFC 5651 [RFC5651]. The Sender Current Time SHALL be signaled using EXT_TIME.¶

2.3. FEC Payload ID for Source Flows

The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme used in ROUTE Source Flows is a 32-bit unsigned integer value that SHALL express the start_offset as an octet number corresponding to the first octet of the fragment of the delivery object carried in this packet. The start_offset value for the first fragment of any delivery object SHALL be set to 0. Figure 3 shows the 32-bit start_offset field.¶

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         start_offset                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.4. FEC Payload ID for Repair Flows

FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330].¶

3.1. Generic Metadata

Generic metadata is applicable to both Source and Repair Flows as follows. Before a receiver can join a ROUTE session, the receiver needs to obtain this generic metadata that contains at least the following information:¶

ROUTE version number (m):

the version number of ROUTE used in this session. The version number conforming to this document SHALL be 1.¶

Connection ID (m):

the unique identifier of a Connection, usually consisting of the following 4-tuple: source IP address/source port number, destination IP address/destination port number. The IP addresses can be IPv4 or IPv6 addresses depending upon which IP version is used by the deployment.¶

3.2. Session Metadata for Source Flows

stsi (m): The LCT TSI value corresponding to the Transport Session for the Source Flow.¶

rt (o):

A Boolean flag that SHALL indicate whether the content component carried by this Source Flow corresponds to real-time streaming media or non-real-time content. When set to "true", it SHALL be an indication of real-time content, and when absent or set to "false", it SHALL be an indication of non-real-time (NRT) content.¶

minBufferSize (o):

A 32-bit unsigned integer that SHALL represent, in kilobytes, the minimum required storage size of the receiver transport buffer for the parent LCT channel of this Source Flow. The buffer holds the data belonging to a source object until its complete reception. This attribute is only applicable when rt = "true".¶

A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received data beyond its buffering capability. Such discarding of data will impact the service quality.¶

EFDT (cm):

When present, SHALL contain a single instance of an FDT-Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the optional FDT extensions as defined in Section 4.1. The optional EFDT element MAY only be present for File Mode of delivery. In File Mode, it SHALL be present if this Source Flow transports streaming media segments.¶

contentType (o):

A string that SHALL represent the media type for the media content. It SHALL obey the semantics of the Content-Type header as specified by the HTTP/1.1 protocol in RFC 7231 [RFC7231]. This document does not define any new contentType strings. In its absence, the signaling of media type for the media content is beyond the scope of this document.¶

applicationMapping (m):

A set of identifiers that provide an application-specific mapping of the received Application Objects to the Source Flows. For example, for DASH, this would provide the mapping of a Source Flow to a specific DASH Representation from a Media Presentation Description (MPD), the latter identified by its Representation and corresponding Adaptation Set and Period IDs.¶

3.3. Session Metadata for Repair Flows

minBuffSize (o):

A 32-bit unsigned integer whose value SHALL represent a required size of the receiver transport buffer for AL‑FEC decoding processing. When present, this attribute SHALL indicate the minimum buffer size that is required to handle all associated objects that are assigned to a super-object, i.e., a delivery object formed by the concatenation of multiple FEC transport objects in order to bundle these FEC transport objects for AL-FEC protection.¶

A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received repair data beyond its buffering capability. Such discarding of data will impact the service quality.¶

fecOTI (m):

A parameter consisting of the concatenation of Common and Scheme-Specific FEC Object Transmission Information (FEC OTI) as defined in Sections 3.3.2 and 3.3.3 of [RFC6330] and that corresponds to the delivery objects carried in the Source Flow to which this Repair Flow is associated, with the following qualification: the 40-bit Transfer Length (F) field may either represent the actual size of the object, or it is encoded as all zeroes. In the latter case, the FEC transport object size either is unknown or cannot be represented by this attribute. In other words, for the all-zeroes format, the delivery objects in the Source Flow correspond to streaming content, either a live Service whereby content encoding has not yet occurred at the time this session data was generated or pre-recorded streaming content whose delivery object sizes, albeit known at the time of session data generation, are variable and cannot be represented as a single value by the fecOTI attribute.¶

ptsi (m):

TSI value(s) of each Source Flow protected by this Repair Flow.¶

mappingTOIx (o):

Values of the constant X for use in deriving the TOI of the delivery object of each protected Source Flow from the TOI of the FEC (super-)object. The default value is "1". Multiple mappingTOIx values MAY be provided for each protected Source Flow depending upon the usage of FEC (super-)object.¶

mappingTOIy (o):

The corresponding constant Y to each mappingTOIx, when present, for use in deriving the parent SourceTOI value from the above equation. The default value is "0".¶

4.1. File Mode

File Mode uses an out-of-band Extended FDT (EFDT) signaling for recovery of delivery objects with the following extensions and considerations.¶

4.2. Entity Mode

For Entity Mode, the following applies:¶

4.3. Unsigned Package Mode

In this delivery mode, the delivery object consists of a group of files that are packaged for delivery only. If applied, the client is expected to unpack the package and provide each file as an independent object to the application. Packaging is supported by Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557], where objects are packaged into one document for transport, with Content-Type set to multipart/related. When binary files are included in the package, Content-Transfer-Encoding of "binary" should be used for those files.¶

4.4. Signed Package Mode

In Signed Package Mode delivery, the delivery object consists of a group of files that are packaged for delivery, and the package includes one or more signatures for validation. Signed packaging is supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects are packaged into one document for transport and the package includes objects necessary for validation of the package.¶

5.1. Usage of ALC and LCT for Source Flow

ROUTE Source Flow carries the source data as specified in RFC 5775 [RFC5775]. There are several special considerations that ROUTE introduces to the usage of the LCT building block as outlined in the following:¶

Further, the following details apply to LCT:¶

Additional extension headers MAY be used to support real-time delivery. Such extension headers are defined in Section 2.1.¶

5.2. ROUTE Packetization for Source Flow

The following description of the ROUTE sender operation on the mapping of the Application Object to the ROUTE packet payloads logically represents an extension of RFC 5445 [RFC5445], which in turn inherits the context, language, declarations, and restrictions of the FEC building block in RFC 5052 [RFC5052].¶

The data carried in the payload of a given ROUTE packet constitutes a contiguous portion of the Application Object. ROUTE source delivery can be considered as a special case of the use of the Compact No-Code Scheme associated with FEC Encoding ID = 0 according to Sections 3.4.1 and 3.4.2 of [RFC5445], in which the encoding symbol size is exactly one byte. As specified in Section 2.1, for ROUTE Source Flows, the FEC Payload ID SHALL deliver the 32-bit start_offset. All receivers are expected to support, at minimum, operation with this special case of the Compact No-Code FEC.¶

Note that in the event the source object size is greater than 2³² bytes (approximately 4.3 GB), the applications (in the broadcaster server and the receiver) are expected to perform segmentation/reassembly using methods beyond the scope of this document.¶

Finally, in some special cases, a ROUTE sender MAY need to produce ROUTE packets that do not contain any payload. This may be required, for example, to signal the end of a session. These dataless packets do not contain FEC Payload ID or payload data, but only the LCT header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the LCT header, FEC Payload ID, and payload data.¶

5.3. Timing of Packet Emission

The sender SHALL use the timing information provided by the application to time the emission of packets for a timely reception. This information may be contained in the Application Objects e.g., DASH segments and/or the presentation manifest. Hence, such packets of streaming media with real-time constraints SHALL be sent in such a way as to enable their timely reception with respect to the presentation timeline.¶

5.4. Extended FDT Encoding for File Mode Sending

For File Mode sending:¶

5.5. FEC Framework Considerations

The FEC framework uses concepts of the FECFRAME work as defined in RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052 [RFC5052], which is adopted in the existing FLUTE/ALC/LCT specifications.¶

The FEC design adheres to the following principles:¶

The FEC-specific components of the FEC framework are:¶

A receiver needs to be able to recover delivery objects from repair packets based on available FEC information.¶

5.6. FEC Transport Object Construction

In order to identify a delivery object in the context of the repair protocol, the following information is needed:¶

Typically, for real-time object delivery with smaller delivery object sizes, the first mapping is applied, i.e., the delivery object is a FEC object.¶

Assuming that the FEC object is the delivery object, for each delivery object, the associated FEC transport object is comprised of the concatenation of the delivery object, padding octets (P), and the FEC object size (F) in octets, where F is carried in a 4-octet field.¶

The FEC transport object size S, in FEC encoding symbols, SHALL be an integer multiple of the symbol size Y. S is determined from the session information and/or the repair packet headers.¶

F is carried in the last 4 octets of the FEC transport object. Specifically, let:¶

O' then constitutes the FEC transport object of size S*Y octets. Note that padding octets and the object size F are not sent in source packets of the delivery object but are only part of a FEC transport object that FEC decoding recovers in order to extract the FEC object and thus the delivery object or portion of the delivery object that constitutes the FEC object. In the above context, the FEC transport object size in symbols is S.¶

The general information about a FEC transport object that is conveyed to a FEC-enabled receiver is the source TSI, source TOI, and the associated octet range within the delivery object comprising the associated FEC object. However, as the size in octets of the FEC object is provided in the appended field within the FEC transport object, the remaining information can be conveyed as:¶

5.7. Super-Object Construction

From the FEC Repair Flow declaration, the construction of a FEC super-object as the concatenation of one or more FEC transport objects can be determined. The FEC super-object includes the general information about the FEC transport objects as described in the previous sections, as well as the placement order of FEC transport objects within the FEC super-object.¶

Let:¶

For each FEC super-object, the remaining general information that needs to be conveyed to a FEC-enabled receiver, beyond what is already carried in the FEC transport objects that constitute the FEC super-object, comprises:¶

The carriage of the FEC repair information is discussed below.¶

5.8. Repair Packet Considerations

The repair protocol is based on Asynchronous Layered Coding (ALC) as defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC5651] with the following details:¶

5.9. Summary FEC Information

For each super-object (identified by a unique TOI within a Repair Flow that is in turn identified by the TSI in the LCT header) that is generated, the following information needs to be communicated to the receiver:¶

The above information is delivered:¶

6.1. Basic Application Object Recovery for Source Flows

Upon receipt of each ROUTE packet of a Source Flow, the receiver proceeds with the following steps in the order listed.¶

1)

The ROUTE receiver is expected to parse the LCT and FEC Payload ID to verify that it is a valid header. If it is not valid, then the payload is discarded without further processing.¶

2)

All ROUTE packets used to recover a specific delivery object carry the same TOI value in the LCT header.¶

3)

The ROUTE receiver is expected to assert that the TSI and the Codepoint represent valid operation points in the signaling metadata, i.e., the signaling contains a matching entry to the TSI value provided in the packet header, as well as for this TSI, and the Codepoint field in the LCT header has a valid Codepoint mapping.¶

4)

The ROUTE receiver should process the remainder of the payload, including the appropriate interpretation of the other payload header fields, using the source FEC Payload ID (to determine the start_offset) and the payload data to reconstruct the corresponding object as follows:¶

1. For File Mode, upon receipt of the first ROUTE packet payload for an object, the ROUTE receiver uses the File@Transfer-Length attribute of the associated Extended FDT-Instance, when present, to determine the length T of the object. When the File@Transfer-Length attribute is not present in the Extended FDT-Instance, the receiver uses the maxTransportSize attribute of the associated Extended FDT-Instance to determine the maximum length T' of the object. Alternatively, and specifically for delivery modes other than File Mode, the EXT_TOL header can be used to determine the length T of the object.¶
2. The ROUTE receiver allocates buffer space for the T or T' bytes that the object will or may occupy.¶
3. The ROUTE receiver computes the length of the payload, Y, by subtracting the payload header length from the total length of the received payload.¶

4. The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or RECEIVED[0..T'-1], as appropriate, with all entries initialized to false to track received object symbols. The ROUTE receiver continuously acquires packet payloads for the object as long as all of the following conditions are satisfied:¶

   1. there is at least one entry in RECEIVED still set to false,¶
   2. the object has not yet expired, and¶

   3. the application has not given up on reception of this object.¶

      More details are provided below.¶

5. For each received ROUTE packet payload for the object (including the first payload), the steps to be taken to help recover the object are as follows:¶

   1. If the packet includes an EXT_TOL or EXT_FTI header, modify the Boolean array RECEIVED[0..T'-1] to become RECEIVED[0..T-1].¶
   2. Let X be the value of the start_offset field in the ROUTE packet header and let Y be the length of the payload, Y, computed by subtracting the LCT header size and the FEC Payload ID size from the total length of the received packet.¶
   3. The ROUTE receiver copies the data into the appropriate place within the space reserved for the object and sets RECEIVED[X ... X+Y-1] = true.¶
   4. If all T entries of RECEIVED are true, then the receiver has recovered the entire object.¶

Upon recovery of both the complete set of packet payloads for the delivery object associated with a given TOI value, and the metadata for that delivery object, the reception of the delivery object, now a fully received Application Object, is complete.¶

Given the timely reception of ROUTE packets belonging to an Application Object, the receiver SHALL make the Application Objects available to the application in a timely fashion using the application-provided timing data (e.g., the timing data signaled via the presentation manifest file). For example, HTTP/1.1 chunked transfer may need to be enabled to transfer the Application Objects if MPD@availabilityTimeOffset is signaled in the DASH presentation manifest in order to allow for the timely sending of segment data to the application.¶

6.2. Fast Stream Acquisition

When the receiver initially starts reception of ROUTE packets, it is likely that the reception does not start from the very first packet carrying the data of a multicast transport object; in this case, such a partially received object is normally discarded. However, the channel acquisition or "tune-in" times can be improved if the partially received object is usable by the application. One example realization for this is as follows:¶

6.3. Generating Extended FDT-Instance for File Mode

An Extended FDT-Instance conforming to RFC 6726 [RFC6726], is produced at the receiver using the service metadata and in-band signaling in the following steps:¶

7.1. General FEC Application Guidelines

It is up to the receiver to decide to use zero, one, or more of the FEC streams. Hence, the application assigns a recovery property to each flow, which defines aspects such as the delay and the required memory if one or the other is chosen. The receiver MAY decide whether or not to utilize Repair Flows based on the following considerations:¶

If a receiver decides to acquire a certain Repair Flow, then the receiver must receive data on all Source Flows that are protected by that Repair Flow to collect the relevant packets.¶

7.2. TOI Mapping

When mappingTOIx/mappingTOIy are used to signal X and Y values, the TOI value(s) of the one or more source objects (sourceTOI) protected by a given FEC transport object or FEC super-object with a TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y.¶

When neither mappingTOIx nor mappingTOIy is present, there is a 1:1 relationship between each delivery object carried in the Source Flow as identified by ptsi to a FEC object carried in this Repair Flow. In this case, the TOI of each of those delivery objects SHALL be identical to the TOI of the corresponding FEC object.¶

7.3. Delivery Object Reception Timeout

The permitted start and end times for the receiver to perform the file repair procedure, in case of unsuccessful broadcast file reception, and associated rules and parameters are as follows:¶

7.4. Example FEC Operation

To be able to recover the delivery objects that are protected by a Repair Flow, a receiver needs to obtain the necessary Service signaling metadata fragments that describe the corresponding collection of delivery objects that are covered by this Repair Flow. A Repair Flow is characterized by the combination of an LCT channel, a unique TSI number, as well as the corresponding protected Source Flows.¶

If a receiver acquires data of a Repair Flow, the receiver is expected to collect all packets of all protected Transport Sessions. Upon receipt of each packet, whether it is a source or repair packet, the receiver proceeds with the following steps in the order listed.¶

9.1. ROUTE Modes of Delivery

Different ROUTE delivery modes specified in Section 4 are optimized for delivery of different types of media data. For example, File Mode is specifically optimized for delivering DASH content using Segment Template with number substitution. Using File Template in EFDT avoids the need for the repeated sending of metadata as outlined in the following section. Same optimizations, however, cannot be used for time substitution and segment timeline where the addressing of each segment is time dependent and in general does not follow a fixed or repeated pattern. In this case, Entity Mode is more optimized since it carries the file location in band. Also, Entity Mode can be used to deliver a file or part of the file using HTTP Partial Content response headers.¶

9.2. File Mode Optimizations

In File Mode, the delivery object represents an Application Object. This mode replicates FLUTE as defined in RFC 6726 [RFC6726] but with the ability to send static and pre-known file metadata out of band.¶

In FLUTE, FDT-Instances are delivered in band and need to be generated and delivered in real time if objects are generated in real time at the sender. These FDT-Instances have some differences as compared to the FDT specified in Section 3.4.2 of [RFC6726] and Section 7.2.10 of MBMS [MBMS]. The key difference is that besides separated delivery of file metadata from the delivery object it describes, the FDT functionality in ROUTE may be extended by additional file metadata and rules that enable the receiver to generate the Content-Location attribute of the File element of the FDT, on the fly. This is done by using information in both the extensions to the FDT and the LCT header. The combination of pre-delivery of static file metadata and receiver self generation of dynamic file metadata avoids the necessity of continuously sending the FDT-Instances for real-time objects. Such modified FDT functionality in ROUTE is referred to as the Extended FDT.¶

9.3. In-Band Signaling of Object Transfer Length

As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header extension with 24 bits or, if required, 48 bits to signal the Transfer Length directly within the ROUTE packet.¶

The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length.¶

Applications using ROUTE for delivery of low-latency streaming content may make use of this feature for sender-end latency optimizations: the sender does not have to wait for the completion of the packaging of a whole Application Object to find its Transfer Length to be included in the FDT before the sending can start. Rather, partially encoded data can already be started to be sent via the ROUTE sender. As the time approaches when the encoding of the Application Object is nearing completion, and the length of the object becomes known (e.g., the time of writing the last CMAF Chunk of a DASH segment), only then the sender can signal the object length using the EXT TOL LCT header. For example, for a 2-second DASH segment with 100-millisecond chunks, it may result in saving up to 1.9 second latency at the sending end.¶

9.4. Repair Protocol Concepts

The ROUTE repair protocol is FEC-based and is enabled as an additional layer between the transport layer (e.g., UDP) and the object delivery layer protocol. The FEC reuses concepts of the FEC Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC Framework in RFC 6363 [RFC6363], the ROUTE repair protocol does not protect packets but instead protects delivery objects as delivered in the source protocol. In addition, as an extension to FLUTE, it supports the protection of multiple objects in one source block which is in alignment with the FEC Framework as defined in RFC 6363 [RFC6363]. Each FEC source block may consist of parts of a delivery object, as a single delivery object (similar to FLUTE) or multiple delivery objects that are bundled prior to FEC protection. ROUTE FEC makes use of FEC schemes in a similar way as those defined in RFC 5052 [RFC5052] and uses the terminology of that document. The FEC scheme defines the FEC encoding and decoding as well as the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme.¶

In ROUTE, all packets are LCT packets as defined in RFC 5651 [RFC5651]. Source and repair packets may be distinguished by:¶

11.1. Security Considerations

As noted in Section 9, ROUTE is aligned with FLUTE as specified in RFC 6726 [RFC6726] and only diverges in certain signaling optimizations, especially for the real-time object delivery case. Hence, most of the security considerations documented in RFC 6726 [RFC6726] for the data flow itself, the session metadata (session control parameters in RFC 6726 [RFC6726]), and the associated building blocks apply directly to ROUTE as elaborated in the following along with some additional considerations.¶

Both encryption and integrity protection applied either on file or packet level, as recommended in the file corruption considerations of RFC 6726 [RFC6726], SHOULD be used for ROUTE. Additionally, RFC 3740 [RFC3740] documents multicast security architecture in great detail with clear security recommendations that SHOULD be followed.¶

When ROUTE is carried over UDP and a reverse channel from receiver to sender is available, the security mechanisms provided in RFC 9147 [RFC9147] SHOULD be applied.¶

In regard to considerations for attacks against session description, this document does not specify the semantics or mechanism of delivery of session metadata, though the same threats apply for service using ROUTE as well. Hence, a service using ROUTE SHOULD take these threats into consideration and address them appropriately following the guidelines provided by RFC 6726 [RFC6726]. Additionally, to the recommendations of RFC 6726 [RFC6726], for Internet connected devices, services SHOULD enable clients to access the session description information using HTTPS with customary authentication/authorization, instead of sending this data via multicast/broadcast, since considerable security work has been done already in this unicast domain, which can enable highly secure access of session description data. Accessing via unicast, however, will have different privacy considerations, noted in Section 11.2. Note that in general the multicast/broadcast stream is delayed with respect to the unicast stream. Therefore, the session description protocol SHOULD be time synchronized with the broadcast stream, particularly if the session description contains security-related information.¶

In regard to FDT, there is one key difference for File Mode when using File Template in EFDT, which avoids repeated sending of FDT-Instances and hence, the corresponding threats noted in RFC 6726 [RFC6726] do not apply directly to ROUTE in this case. The threat, however, is shifted to the ALC/LCT headers, since they carry the additional signaling that enables determining Content-Location and File@Transfer-Length in this case. Hence, integrity protection recommendations of ALC/LCT header SHOULD be considered with higher emphasis in this case for ROUTE.¶

Finally, attacks against the congestion control building block for the case of ROUTE can impact the optional fast stream acquisition specified in Section 6.2. Receivers SHOULD have robustness against timestamp values that are suspicious, e.g., by comparing the signaled time in the LCT headers with the approximate time signaled by the MPD, and SHOULD discard outlying values. Additionally, receivers MUST adhere to the expiry timelines as specified in Section 6. Integrity protection mechanisms documented in RFC 6726 [RFC6726] SHOULD be used to address this threat.¶

11.2. Privacy Considerations

Encryption mechanisms recommended for security considerations in Section 11.1 SHOULD also be applied to enable privacy and protection from snooping attacks.¶

Since this protocol is primarily targeted for IP multicast/broadcast environments where the end user is mostly listening, identity protection and user data retention considerations are more protected than in the unicast case. Best practices for enabling privacy on IP multicast/broadcast SHOULD be applied by the operators, e.g., "Recommendations for DNS Privacy Service Operators" in RFC 8932 [RFC8932].¶

However, if clients access session description information via HTTPS, the same privacy considerations and solutions SHALL apply to this access as for regular HTTPS communication, an area that is very well studied and the concepts of which are being integrated directly into newer transport protocols such as IETF QUIC [RFC9000] enabling HTTP/3 [HTTP3]. Hence, such newer protocols SHOULD be used to foster privacy.¶

Note that streaming services MAY contain content that may only be accessed via DRM (digital rights management) systems. DRM systems can prevent unauthorized access to content delivered via ROUTE.¶