💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc9223.txt captured on 2024-05-10 at 11:38:04.
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Independent Submission W. Zia
Request for Comments: 9223 T. Stockhammer
Category: Informational Qualcomm CDMA Technologies GmbH
ISSN: 2070-1721 L. Chaponniere
G. Mandyam
Qualcomm Technologies Inc.
M. Luby
BitRipple, Inc.
April 2022
Real-Time Transport Object Delivery over Unidirectional Transport
(ROUTE)
Abstract
The Real-time Transport Object delivery over Unidirectional Transport
(ROUTE) protocol is specified for robust delivery of Application
Objects, including Application Objects with real-time delivery
constraints, to receivers over a unidirectional transport.
Application Objects consist of data that has meaning to applications
that use the ROUTE protocol for delivery of data to receivers; for
example, it can be a file, a Dynamic Adaptive Streaming over HTTP
(DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc.
The ROUTE protocol also supports low-latency streaming applications.
The ROUTE protocol is suitable for unicast, broadcast, and multicast
transport. Therefore, it can be run over UDP/IP, including multicast
IP. The ROUTE protocol can leverage the features of the underlying
protocol layer, e.g., to provide security, it can leverage IP
security protocols such as IPsec.
This document specifies the ROUTE protocol such that it could be used
by a variety of services for delivery of Application Objects by
specifying their own profiles of this protocol (e.g., by adding or
constraining some features).
This is not an IETF specification and does not have IETF consensus.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9223.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction
1.1. Overview
1.2. Protocol Stack for ROUTE
1.3. Data Model
1.4. Architecture and Scope of Specification
1.5. Conventions Used in This Document
2. ROUTE Packet Format
2.1. Packet Structure and Header Fields
2.2. LCT Header Extensions
2.3. FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows
3. Session Metadata
3.1. Generic Metadata
3.2. Session Metadata for Source Flows
3.3. Session Metadata for Repair Flows
4. Delivery Object Mode
4.1. File Mode
4.1.1. Extensions to FDT
4.1.2. Constraints on Extended FDT
4.2. Entity Mode
4.3. Unsigned Package Mode
4.4. Signed Package Mode
5. Sender Operation
5.1. Usage of ALC and LCT for Source Flow
5.2. ROUTE Packetization for Source Flow
5.2.1. Basic ROUTE Packetization
5.2.2. ROUTE Packetization for CMAF Chunked Content
5.3. Timing of Packet Emission
5.4. Extended FDT Encoding for File Mode Sending
5.5. FEC Framework Considerations
5.6. FEC Transport Object Construction
5.7. Super-Object Construction
5.8. Repair Packet Considerations
5.9. Summary FEC Information
6. Receiver Operation
6.1. Basic Application Object Recovery for Source Flows
6.2. Fast Stream Acquisition
6.3. Generating Extended FDT-Instance for File Mode
6.3.1. File Template Substitution for Content-Location
Derivation
6.3.2. File@Transfer-Length Derivation
6.3.3. FDT-Instance@Expires Derivation
7. FEC Application
7.1. General FEC Application Guidelines
7.2. TOI Mapping
7.3. Delivery Object Reception Timeout
7.4. Example FEC Operation
8. Considerations for Defining ROUTE Profiles
9. ROUTE Concepts
9.1. ROUTE Modes of Delivery
9.2. File Mode Optimizations
9.3. In-Band Signaling of Object Transfer Length
9.4. Repair Protocol Concepts
10. Interoperability Chart
11. Security and Privacy Considerations
11.1. Security Considerations
11.2. Privacy Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
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:
* Real-time delivery of object-based media data
* Flexible packetization, including enabling media-aware
packetization as well as transport-aware packetization of delivery
objects
* Independence of Application Objects and delivery objects, i.e., a
delivery object may be a part of a file or may be a group of
files.
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.
+--------------------------------------------------------+
| Application (DASH and HLS segments, CMAF Chunks, etc.) |
+--------------------------------------------------------+
| ROUTE |
+--------------------------------------------------------+
| UDP |
+--------------------------------------------------------+
| IP |
+--------------------------------------------------------+
Table 1: Protocol Layering
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:
* The format of the LCT packets that carry the transport objects.
* The robust transport of the delivery object using a repair
protocol based on Forward Error Correction (FEC).
* The definition and possible carriage of object metadata along with
the delivery objects. Metadata may be conveyed in LCT packets
and/or separate objects.
* The ROUTE session, LCT channel, and delivery object description
provided as service metadata signaling to enable the reception of
objects.
* The normative aspects (formats, semantics) of the delivery objects
conveyed as a content manifest to be delivered along with the
objects to optimize the performance for specific applications
e.g., real-time delivery. The objects and manifest are made
available to the application through an Application Object cache.
The interface of this cache to the application is not specified in
this document; however, it will typically be enabled by the
application acting as an HTTP client and the cache as the HTTP
server.
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 +--------------------------------------------+
Figure 1: Architecture/Functional Block Diagram
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. ROUTE Packet Format
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Overall ROUTE Packet Format
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.
+=================+=================================+
| Codepoint value | Semantics |
+=================+=================================+
| 0 | Reserved (not used) |
+-----------------+---------------------------------+
| 1 | Non Real Time (NRT) - File Mode |
+-----------------+---------------------------------+
| 2 | NRT - Entity Mode |
+-----------------+---------------------------------+
| 3 | NRT - Unsigned Package Mode |
+-----------------+---------------------------------+
| 4 | NRT - Signed Package Mode |
+-----------------+---------------------------------+
| 5 | New IS, timeline changed |
+-----------------+---------------------------------+
| 6 | New IS, timeline continued |
+-----------------+---------------------------------+
| 7 | Redundant IS |
+-----------------+---------------------------------+
| 8 | Media Segment, File Mode |
+-----------------+---------------------------------+
| 9 | Media Segment, Entity Mode |
+-----------------+---------------------------------+
| 10 | Media Segment, File Mode with |
| | CMAF Random Access chunk |
+-----------------+---------------------------------+
| 11 - 255 | Reserved, service-specific |
+-----------------+---------------------------------+
Table 2: Codepoint Values
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows
FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330].
3. Session Metadata
The required session metadata for Source and Repair Flows is
specified in the following sections. The list specified here is not
exhaustive; a service MAY signal more metadata to meet its needs.
The data format is also not specified beyond its cardinality; the
exact format of specifying the data is left for the service, e.g., by
using XML encoding format, as has been done by [DVBMABR] and
[ATSCA331]. It is specified in the following if an attribute is
mandatory (m), conditional mandatory (cm) or optional (o) to realize
a basic ROUTE session. A mandatory field SHALL always be present in
the session metadata, and a conditional mandatory field SHALL be
present if the specified condition is true. The delivery of the
session metadata to the ROUTE receiver is beyond the scope of this
document.
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. Delivery Object Mode
ROUTE provides several different delivery object modes, and one of
these modes may suit the application needs better for a given
Transport Session. A delivery object is self contained for the
application, typically associated with certain properties, metadata,
and timing-related information relevant to the application. The
signaling of the delivery object mode is done on an object basis
using Codepoint as specified in Section 2.1.
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.1.1. Extensions to FDT
The following extensions are specified to FDT, as specified in RFC
6726 [RFC6726]. An Extended FDT-Instance is an instance of FLUTE
FDT, as specified in [RFC6726], plus optionally one or more of the
following extensions:
efdtVersion: A value that SHALL represent the version of this
Extended FDT-Instance.
maxExpiresDelta: Let "tp" represent the wall clock time at the
receiver when the receiver acquires the first ROUTE packet
carrying data of the object described by this Extended FDT-
Instance. maxExpiresDelta, when present, SHALL represent a time
interval that when added to "tp" SHALL represent the expiration
time of the associated Extended FDT-Instance "te". The time
interval is expressed in number of seconds. When maxExpiresDelta
is not present, the expiration time of the Extended FDT-Instance
SHALL be given by the sum of a) the value of the ERT field in the
EXT_TIME LCT header extension in the first ROUTE packet carrying
data of that file, and b) the current receiver time when parsing
the packet header of that ROUTE packet. See Sections 5.4 and
6.3.3 on additional rules for deriving the Extended FDT-Instance
expiration time. Hence, te = tp + maxExpiresDelta
maxTransportSize: An attribute that SHALL represent the maximum
transport size in bytes of any delivery object described by this
Extended FDT-Instance. This attribute SHALL be present if a) the
fileTemplate is present in Extended FDT-Instance, or b) one or
more File elements, if present in this Extended FDT-Instance, do
not include the Transfer-Length attribute. When maxTransportSize
is not present, the maximum transport size is not signaled, while
other signaling such as the Transfer-Length attribute signal the
exact Transfer Length of the object.
fileTemplate: A string value, which when present and in conjunction
with parameter substitution, is used in deriving the Content-
Location attribute for the delivery object described by this
Extended FDT-Instance. It SHALL include the "$TOI$" identifier.
Each identifier MAY be suffixed as needed by specific file names
within the enclosing '