[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Internet Draft Waqar Zia,
Thomas Stockhammer
Intended status: Informational Qualcomm Incorporated
Expires: December 2020 June 29, 2020
Real-time Transport Object delivery over Unidirectional Transport
(ROUTE)
draft-zia-route-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 29, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zia, et al. Expires December 29, 2020 [Page 1]
Internet-Draft ROUTE June 2020
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
The Real-time Transport Object delivery over Unidirectional Transport
protocol (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, or a DASH or 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 IP/UDP including multicast
IP. 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.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction...................................................4
1.1. Overview..................................................4
1.2. Protocol Stack for ROUTE..................................5
1.3. Data Model................................................5
1.4. Architecture and Scope of Specification...................6
2. ROUTE Packet Format............................................7
2.1. Packet Structure and Header Fields........................7
Zia, et al. Expires December 29, 2020 [Page 2]
Internet-Draft ROUTE June 2020
2.2. LCT header extensions.....................................9
2.3. FEC Payload ID for Source Flows..........................10
2.4. FEC Payload ID for Repair Flows..........................10
3. Session metadata..............................................11
3.1. Generic metadata.........................................11
3.2. Session metadata for Source Flows........................11
3.3. Session metadata for Repair Flows........................12
4. Delivery object mode..........................................13
4.1. File Mode................................................13
4.1.1. Extensions to FDT...................................13
4.1.2. Constraints on Extended FDT.........................15
4.2. Entity Mode..............................................15
4.3. Unsigned Package Mode....................................16
4.4. Signed Package Mode......................................16
5. Sender operation..............................................16
5.1. Usage of ALC and LCT for Source Flow.....................16
5.2. ROUTE Packetization for Source Flow......................17
5.2.1. Basic ROUTE Packetization...........................18
5.2.2. ROUTE Packetization for CMAF Chunked Content........18
5.3. Timing of Packet Emission................................19
5.4. Extended FDT Encoding for File Mode Sending..............19
5.5. FEC Framework Considerations.............................19
5.6. FEC Transport Object Construction........................20
5.7. Super-Object Construction................................21
5.8. Repair Packet Considerations.............................22
5.9. Summary FEC Information..................................22
6. Receiver operation............................................23
6.1. Basic Application Object Recovery for Source Flows.......23
6.2. Fast Stream Acquisition..................................25
6.3. Generating Extended FDT Instance for File Mode...........25
6.3.1. File Template Substitution for Content-Location
Derivation.................................................25
6.3.2. File@Transfer-Length Derivation.....................26
6.3.3. FDT-Instance@Expires Derivation.....................26
7. FEC Application...............................................26
7.1. General FEC Application Guidelines.......................26
7.2. TOI Mapping..............................................27
7.3. Delivery Object Reception Timeout........................27
7.4. Example FEC Operation....................................27
8. Considerations for Defining ROUTE Profiles....................28
9. ROUTE Concepts................................................29
9.1. ROUTE Modes of Delivery..................................29
9.2. File Mode Optimizations..................................30
9.3. In band Signaling of Object Transfer Length..............30
9.4. Repair Protocol Concepts.................................31
10. Interoperability Chart.......................................31
11. Security Considerations......................................33
Zia, et al. Expires December 29, 2020 [Page 3]
Internet-Draft ROUTE June 2020
12. IANA Considerations..........................................33
13. References...................................................33
13.1. Normative References....................................33
13.2. Informative References..................................34
14. Acknowledgments..............................................35
1. Introduction
1.1. Overview
The Real-time Transport Object delivery over Unidirectional Transport
protocol (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.
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, or a DASH [DASH] video segment,
a WAV audio clip, a CMAF [CMAF] addressable resource, an MP4 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 ROUTE Protocol 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 HLS
content with CMAF Chunks.
Content not intended for rendering in real time as it is received
e.g. a downloaded application, or 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 DRM system client can
also 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.
Profiles of ROUTE Protocol have already been specified in ATSC 3.0
[ATSCA331] and DVB Adaptive Media Streaming over IP Multicast
[DVBMABR]. Hence in the context of this RFC, the aforementioned ATSC
3.0 and DVB systems are the applications using ROUTE. This RFC serves
as a direct reference for such applications in the future and allows
for deriving specific profiles based on the protocol specified in
this RFC.
Zia, et al. Expires December 29, 2020 [Page 4]
Internet-Draft ROUTE June 2020
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 supporting IP multicast. The session metadata signaling to
realize ROUTE session as specified in this RFC MAY be delivered out-
of-band or in band as well. Additionally, the application may use
unicast delivery mechanisms over e.g. HTTP over TCP/IP in conjunction
with ROUTE to augment the services. The latter unicast delivery
aspects are beyond the scope of this RFC.
+-----------------------------------+
|Application (DASH, HLS, CMAF, etc.)|
+-----------------------------------+
| ROUTE |
+-----------------------------------+
| UDP |
+-----------------------------------+
| IP |
+-----------------------------------+
Figure 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, or a DASH video segment, a WAV
audio clip, an MP4 video clip, etc.
Delivery objects - Objects on course of delivery to the application
from the ROUTE sender to ROUTE receiver.
Transport Object - as defined by RFC 5651 [RFC5651], it MAY be a
either a source or a repair object.
Transport Session - An LCT channel, as defined by RFC 5651
[RFC5651]. 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 SHALL uniquely identify the
session. Transport sessions are a subset of a ROUTE session. For
Zia, et al. Expires December 29, 2020 [Page 5]
Internet-Draft ROUTE June 2020
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 SHALL be associated with an IP
address/port combination. ROUTE session typically carries one or more
media components of streaming media e.g. Representations associated
with a DASH Media Presentation.
Source Flows - Transport sessions carrying source data. Source Flow
is independent of the repair Flow, i.e. the Source Flows MAY be used
by a ROUTE receiver without the ROUTE Repair Flows.
Repair Flows - Transport sessions carrying repair data for one or
more Source Flows.
1.4. Architecture and Scope of Specification
The scope of the ROUTE protocol is robust and real-time transport of
delivery objects using LCT packets. This architecture is depicted in
Figure 2.
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 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 RFC, 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
Zia, et al. Expires December 29, 2020 [Page 6]
Internet-Draft ROUTE June 2020
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 2 Architecture/functional block diagram
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 3 below.
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 |
Zia, et al. Expires December 29, 2020 [Page 7]
Internet-Draft ROUTE June 2020
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 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 for this specification is '0001'. The
version number field of the LCT header SHALL be interpreted as the
ROUTE version number field. This version of ROUTE implicitly makes
use of version 1 of the LCT building block defined 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 first bit of this two bit
flag indicates whether the current packet is a source packet or an
FEC repair packet. The first bit of the Protocol Specific Indication
(PSI bit X), the Source Packet Indicator (SPI), SHALL be set to '1'
and '0' to indicate a source packet and a repair packet,
respectively.
If the payload of this packet is carrying the first part of a CMAF
Random Access chunk, except for the first CMAF chunk in a segment,
the least significant bit of the Protocol Specific Information (PSI)
field MAY be set to 1.
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, and for ROUTE, is defined as
shown below to indicate the type of delivery object carried in the
payload of the associated ROUTE packet. The remaining, unmapped
Zia, et al. Expires December 29, 2020 [Page 8]
Internet-Draft ROUTE June 2020
Codepoint values MAY be used by an application using ROUTE, as show
in the following table:
Codepoint value | Semantics
----------------------------------------------------
0 | Reserved (not used)
1 | 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 - 255 | Application specific
Congestion Control Information (CCI) - For packets carrying DASH
segments, should convey the earliest presentation time contained in
the ROUTE packet. Otherwise this field MAY be set to 0.
Transport Session Identifier (TSI) - This 32-bit field SHALL identify
the Transport Session in ROUTE. The context of the Transport Session
is provided by signaling metadata. The TSI field is constrained to a
length of 32 bits because the Transport Session Identifier flag (S)
must be set to '1' and the Half-word flag (H) must be set to '0'.
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 FDT. The TOI field is constrained to a
length of 32 bits because the Transport Object Identifier flag (O)
must be set to '01' and the Half-word flag (H) must be set to '0'.
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 - 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
Close Object (B) flag.
NOTE: The transport object length can also be determined without the
use of EXT_TOL by examining the LCT packet with the Close Object (B)
Zia, et al. Expires December 29, 2020 [Page 9]
Internet-Draft ROUTE June 2020
flag. However, if this packet is lost, then the EXT_TOL information
can be used by the receiver to determine the transport object length.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 194 | Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 5. 24-bit format of EXT_TOL Header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 67 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. 48-bit format of EXT_TOL Header.
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 SHALL be a 32-bit unsigned integer value
that expresses the start_offset, as an octet number corresponding to
the first octet of the fragment of the delivery object carried in
this packet. Figure 7 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 7 FEC Payload ID for Source Flows.
2.4. FEC Payload ID for Repair Flows
In accordance with RFC 6330 Section 3.2, the FEC Payload ID for the
RaptorQ FEC Scheme used for Repair Flows is composed of a Source
Block Number (SBN) and an Encoding Symbol ID, formatted as shown in
Figure 8.
Zia, et al. Expires December 29, 2020 [Page 10]
Internet-Draft ROUTE June 2020
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 FEC Payload ID for Repair Flows.
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; an application MAY signal more metadata to meet its
needs. The data format is also not specified beyond its cardinality,
and basic type (e.g. integral or alphanumeric data); the exact format
of specifying the data is left for the application, e.g. by using XML
encoding format. It is specified if an attribute is mandatory (m),
conditional mandatory (cm) or optional (o) to realize a basic ROUTE
session. The delivery of the session metadata to the ROUTE receiver
is beyond scope of this RFC.
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:
- Connection ID (m): unique identifier of a Connection, usually
consisting of source IP address/source port number, destination IP
address/destination port number.
3.2. Session metadata for Source Flows
stsi (m) - LCT TSI value corresponding to the transport session for
the Source Flow.
rt (o) - A Boolean flag which 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 which SHALL represent,
in kilobytes, the minimum required storage size of the receiver
transport buffer, for the parent LCT channel of this Source Flow.
This attribute SHALL only be applicable when rt = "true". When rt
Zia, et al. Expires December 29, 2020 [Page 11]
Internet-Draft ROUTE June 2020
"true" and this attribute is absent, the minimum receiver transport
buffer size is unknown.
EFDT (cm) - when present, SHALL contain a single instance of an FDT-
Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain FDT
extensions as defined in Section 4.1. The 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 media type assigned
by IANA for the media content. contentType SHALL obey the semantics
of the Content-Type header of HTTP/1.1 protocol RFC 7231 [RFC7231].
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 a Source Flow to a specific DASH representation from an MPD,
the latter identified by its Representation and corresponding
Adaptation Set and Period IDs.
3.3. Session metadata for Repair Flows
maximumDelay (o) - An integer value, when present, SHALL represent
the maximum delivery delay, in milliseconds, between any source
packet in the Source Flow and the repair packet, associated with that
source packet, in the Repair Flow. Default semantics of this
attribute, when absent, is not defined.
overhead (o) - An integer whose value SHALL represent the sum of the
AL-FEC related fields in the ROUTE repair packet relative to the size
of the repair packet size as a percentage.
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.
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 RFC 6330 [RFC6330], and which
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
Zia, et al. Expires December 29, 2020 [Page 12]
Internet-Draft ROUTE June 2020
represent the actual size of the object, or it is encoded as all
zeroes. In the latter case, it means that the FEC transport object
size is either 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 SHALL be "1".
Multiple mappingTOIx values MAY be provided for each protected Source
Flow.
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 SHALL be "0".
4. Delivery object mode
ROUTE provides several different delivery object modes, and one of
these modes may suite 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 that are of relevance for the
application. The signaling of the delivery object mode is done on an
object based using Codepoint as specified in Section 2.1.
4.1. File Mode
File mode uses an out-of-band EDFT signaling for recovery of delivery
objects with the following extensions and considerations.
4.1.1. Extensions to FDT
Following extensions are specified to FDT specified in RFC 6726
[RFC6726]. Here an Extended FDT Instance is an instance of the FLUTE
[RFC6726] FDT that includes extensions.
efdtVersion - A value that SHALL represent the version of this
Extended FDT Instance.
Zia, et al. Expires December 29, 2020 [Page 13]
Internet-Draft ROUTE June 2020
maxExpiresDelta - A value, which when present, SHALL represent a time
interval in number of seconds, which when added to 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, SHALL represent the expiration time of the associated
Extended FDT Instance. 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.
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.
fileTemplate - A string value, which when present and in conjunction
with parameter substitution, SHALL be 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, within the enclosing '$' characters
following this prototype:
%0[width]d
The width parameter is an unsigned integer that provides the minimum
number of characters to be printed. If the value to be printed is
shorter than this number, the result SHALL be padded with leading
zeroes. The value is not truncated even if the result is larger. When
no format tag is present, a default format tag with width=1 SHALL be
used.
Strings other than identifiers SHALL only contain characters that are
permitted within URIs according to RFC 3986 [RFC3986].
$$ Is an escape sequence in fileTemplate value, i.e. "$$" is non-
recursively replaced with a single "$"
The usage of fileTemplate is described in Sender and Receiver
operations in Sections 5.4 and 6.3, respectively.
Zia, et al. Expires December 29, 2020 [Page 14]
Internet-Draft ROUTE June 2020
4.1.2. Constraints on Extended FDT
The Extended FDT Instance SHALL conform to an FDT Instance according
to RFC 6726 [RFC6726], with the following constraints: at least one
File element and the @Expires attribute SHALL be present.
Content encoding MAY be used for delivery of any file described by an
FDT-Instance.File element in the Extended FDT Instance. The content
encoding defined in the present RFC is gzip [RFC1952]. When content
encoding is used, the File@Content-Encoding and File@Content-Length
attributes SHALL be present in the Extended FDT Instance.
4.2. Entity Mode
For Entity Mode, the following applies:
- Delivery object metadata SHALL be expressed in the form of entity
headers as defined in HTTP/1.1, and which correspond to one or
more of the representation header fields, payload header fields
and response header fields as defined in Sections 3.1, 3.3 and 7,
respectively, of RFC 7231. Additionally, a Digest HTTP response
header [RFC7231] MAY be included to enable a receiver to verify
the integrity of the multicast transport object.
- The entity headers sent along with the delivery object provide all
information about that multicast transport object.
Sending a media object (if the object is chunked) in Entity Mode
may result in one of the following options:
If the length of the chunked object is known at sender, the ROUTE
Entity Mode delivery object MAY be sent without using HTTP/1.1
chunked transfer coding, i.e. the object starts with an HTTP
header containing the Content Length field, followed by the
concatenation of CMAF chunks:
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk ----
||---chunk ----|
If the length of the chunked object is unknown at sender when
starting to send the object, HTTP/1.1 chunked transfer coding
format SHALL be used:
|HTTP Header||Separator+Length||---chunk ----||Separator+Length||-
--chunk ----||Separator+Length||---chunk ----||Separator+Length||-
--chunk ----||Separator+Length=0|
Zia, et al. Expires December 29, 2020 [Page 15]
Internet-Draft ROUTE June 2020
Note, however, that it is not required to send a CMAF chunk in
exactly one HTTP chunk.
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 MIME [RFC2557], where objects are packaged into one
document for transport.
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. Sender operation
5.1. Usage of ALC and LCT for Source Flow
The usage of ALC for ROUTE Source Flow is as defined 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:
- ROUTE limits the usage of the LCT building block to a single
channel per session. Congestion control is thus sender-driven in
ROUTE. The functionality of receiver-driven layered multicast may
still be offered by the application, allowing the receiver
application to select the appropriate delivery session based on
the bandwidth requirement of that session.
Further, following details apply to LCT:
- The Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 [RFC5651] is used with the following constraints:
oThe TSI in the LCT header SHALL be set equal to the value of
the stsi attribute in Section 3.2.
oThe Codepoint (CP) in the LCT header SHALL be used to signal
the applied formatting as defined in the signaling metadata.
Zia, et al. Expires December 29, 2020 [Page 16]
Internet-Draft ROUTE June 2020
oIn accordance to ALC, a source FEC Payload ID header is used to
identify, for FEC purposes, the encoding symbols of the
delivery object, or a portion thereof, carried by the
associated ROUTE packet. This information may be sent in
several ways:
. As a simple new null FEC scheme with the following usage:
. The value of the source FEC Payload ID header SHALL
be set to 0, in case the ROUTE packet contains the
entire delivery object, or
. The value of the source FEC Payload ID header SHALL
be set as a direct address (start offset)
corresponding to the starting byte position of the
portion of the object carried in this packet using
a 32-bit field.
. In a compatible manner to RFC 6330 [RFC6330] where the
SBN and ESI defines the start offset together with the
symbol size T.
. The signaling metadata provides the appropriate
parameters to indicate any of the above modes using the
srcFecPayloadId attribute.
- The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651]
MAY be used by the sender in the following manner:
oThe Sender Current Time (SCT), depending on the application,
MAY be used to occasionally or frequently signal the sender
current time.
oThe Expected Residual Time (ERT) MAY be used to indicate the
expected remaining time for transmission of the current
object.
oThe Sender Last Changed (SLC) flag is typically not utilized,
but MAY be used to indicate addition/removal of Segments.
- 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 constitute 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 RFC 5445 [RFC5445], in which the encoding symbol
Zia, et al. Expires December 29, 2020 [Page 17]
Internet-Draft ROUTE June 2020
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^32
bytes (approximately 4.3 GB), the applications (in the broadcaster
server and the receiver) are expected to perform segmentation/re-
assembly using methods beyond the scope of this transport Standard.
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 or to convey congestion
control information. These data-less 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.2.1. Basic ROUTE Packetization
In the basic operation, it is assumed that the application object is
fully available at the ROUTE sender.
1. The amount of data to be sent in a single ROUTE packet is limited
by the maximum transfer unit of the data packets or the size of the
remaining data of the application object being sent, whichever is
smaller. The transfer unit is determined either by knowledge of
underlying transport block sizes or by other constraints.
2. The start_offset field in the LCT header of the ROUTE packet
indicates the byte offset of the carried data in the application
object being sent.
3. The Close Object (B) flag is set to 1 if this is the last ROUTE
packet carrying the data of the application object.
The order of packet delivery is arbitrary, but in the absence of
other constraints delivery with increasing start_offset value is
recommended.
5.2.2. ROUTE Packetization for CMAF Chunked Content
Following additional guidelines should be followed for ROUTE
packetization of CMAF Chunked Content in addition to the guideline of
Section 5.2.1:
1. As specified in Section 2.1, if it is the first ROUTE packet
carrying a CMAF Random Access chunk, except for the first CMAF chunk
Zia, et al. Expires December 29, 2020 [Page 18]
Internet-Draft ROUTE June 2020
in the segment, the least significant bit of the Protocol Specific
Information (PSI) field in the LCT header MAY be set to 1. The
receiver MAY use this information for optimization of random access.
2. As soon as the total length of the media object is known,
potentially with the packaging of the last CMAF chunk of a segment,
the EXT_TOL extension header MAY be added to the LCT header to signal
the Transfer Length.
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 to enable their timely reception with respect to the presentation
timeline.
5.4. Extended FDT Encoding for File Mode Sending
For File Mode Sending:
- The TOI field in the ROUTE packet header SHALL be set such that
Content-Location can be derived at the receiver according to File
Template substitution specified in Section 6.3.1.
- After sending the first packet with a given TOI value, none of the
packets pertaining to this TOI SHALL be sent later than the wall
clock time as derived from maxExpiresDelta. The EXT_TIME header
with Expected Residual Time (ERT) MAY be used in order to convey
more accurate expiry time.
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:
- FEC-related information is provided only where needed.
- Receivers not capable of this framework can ignore repair packets.
- The FEC is symbol-based with fixed symbol size per protected
Repair Flow. The ALC protocol and existing FEC schemes are reused.
- A FEC Repair Flow provides protection of delivery objects from one
or more Source Flows.
The FEC-specific components of the FEC framework are:
- FEC Repair Flow declaration including all FEC-specific
information.
Zia, et al. Expires December 29, 2020 [Page 19]
Internet-Draft ROUTE June 2020
- FEC transport object that is the concatenation of a delivery
object, padding octets and size information in order to form an N-
symbol-sized chunk of data, where N >= 1.
- FEC super-object that is the concatenation of one or more FEC
transport objects in order to bundle FEC transport objects for FEC
protection.
- FEC protocol and packet structure.
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:
- TSI and TOI of the delivery object. In this case, the FEC object
corresponds to the (entire) delivery object.
- Octet range of the delivery object, i.e. start offset within the
delivery object and number of subsequent and contiguous octets of
delivery object that constitutes the FEC object (i.e., the FEC-
protected portion of the source object). In this case, the FEC
object corresponds to a contiguous byte range portion of the
delivery object.
Typically, the first mapping is applied; i.e., the delivery object is
an 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:
- F be the size of the delivery object in octets,
- F' be the F octets of data of the delivery object,
- f' denote the four octets of data carrying the value of F in
network octet order (high-order octet first),
- S be the size of the FEC transport object with S=ceil((F+4)/Y),
where the ceil() function rounds the result upward to its nearest
integer,
- P' be S*Y-4-F octets of data, i.e. padding placed between the
delivery object and the 4-byte field conveying the value of F and
located at the end of the FEC transport object, and
Zia, et al. Expires December 29, 2020 [Page 20]
Internet-Draft ROUTE June 2020
- O' be the concatenation of F', P' and f'.
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 an 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 an FEC transport object that is
conveyed to an 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:
- TSI and TOI of the delivery object from which the FEC object
associated with the FEC transport object is generated
- Start octet within delivery object for the associated FEC object
- Size in symbols of the FEC transport object, S
5.7. Super-Object Construction
From the FEC Repair Flow declaration, the construction of an 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:
- N be the total number of FEC transport objects for the FEC super-
object construction.
- For i = 0,..., N-1, let S[i] be the size in symbols of FEC
transport object i.
- B' be the FEC super-object which is the concatenation of the FEC
transport objects in numerical order, comprised of K =
.((i=0)to(N-1))S[i] source symbols.
For each FEC super-object, the remaining general information that
needs to be conveyed to an FEC-enabled receiver, beyond what is
already carried in the FEC transport objects that constitute the FEC
super-object, comprises:
- The total number of FEC transport objects N.
- For each FEC transport object, the:
Zia, et al. Expires December 29, 2020 [Page 21]
Internet-Draft ROUTE June 2020
oTSI and TOI of the delivery object from which the FEC object
associated with the FEC transport object is generated,
oStart octet within delivery object for the associated FEC
object, and
oSize in symbols of the FEC transport object.
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:
- The Layered Coding Transport (LCT) Building Block as defined in RFC
5651 [RFC5651] is used as defined in Asynchronous Layered Coding
(ALC), Section 2.1. In addition, the following constraints apply:
- The TSI in the LCT header SHALL identify the Repair Flow to
which this packet applies, by the matching value of the ptsi
attribute in the signaling metadata among the LCT channels
carrying Repair Flows.
- The FEC building block is used according to RFC 6330 [RFC6330], but
only repair packets are delivered.
- Each repair packet within the scope of the Repair Flow (as
indicated by the TSI field in the LCT header) SHALL carry the
repair symbols for a corresponding FEC transport object/super-
object as identified by its TOI. The repair object/super-object
TOI SHALL be unique for each FEC super-object that is created
within the scope of the TSI.
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 FEC configuration consisting of:
oFEC Object Transmission Information (OTI) per RFC 5052
[RFC5052].
oAdditional FEC information (see Section 3.3).
. The total number of FEC objects included in the FEC super-object,
N.
. For each FEC transport object:
oTSI and TOI of the delivery object used to generate the FEC
object associated with the FEC transport object,
Zia, et al. Expires December 29, 2020 [Page 22]
Internet-Draft ROUTE June 2020
oStart octet within the delivery object of the associated FEC
object, if applicable, and
oThe size in symbols of the FEC transport object, S.
The above information is delivered:
. Statically in the session metadata as defined in Section 3.3,
and
. Dynamically in an LCT extension header.
6. Receiver operation
The receiver receives packets and filters those packets according to
the following. From the ROUTE session and each contained LCT channel,
the receiver regenerates delivery objects from the ROUTE session and
each contained LCT channel. The basic receiver information is
provided below.
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
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, and using the source FEC Payload ID (to determine
the start_offset) and the payload data to reconstruct the
corresponding object as follows:
a. 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
Zia, et al. Expires December 29, 2020 [Page 23]
Internet-Draft ROUTE June 2020
File Mode, EXT_TOL header can be used to determine the length
T of the object.
b. The ROUTE receiver allocates buffer space for the T or T'
bytes that the object will or may occupy.
c. The ROUTE receiver computes the length of the payload, Y, by
subtracting the payload header length from the total length
of the received payload.
d. 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: i) there is at least one entry in RECEIVED still
set to false; ii) the object has not yet expired; and iii)
the application has not given up on reception of this object.
More details are provided below.
e. 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:
i. 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].
ii. 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.
iii. 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.
iv. 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.
The receiver SHALL ensure making availability of application objects
in a timely fashion to the application, based on the application
provided timing data e.g. via 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, to allow for timely sending of
segment data to the application.
Zia, et al. Expires December 29, 2020 [Page 24]
Internet-Draft ROUTE June 2020
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, and 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:
- The receiver checks for the first received packet with the least
significant bit of the PSI set to 1, indicating the start of a
CMAF Random Access chunk.
- The receiver MAY make the partially received object (a partial
DASH segment starting from the packet above) available to the
application.
- It MAY recover the earliest presentation time of this CMAF Random
Access chunk from the ROUTE packet LCT Congestion Control
Information field as specified in Section 2.1 and add a new Period
element in the MPD exposed to the application containing just the
partially received DASH segment with period continuity signaling.
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 as follows:
6.3.1. File Template Substitution for Content-Location Derivation
The Content-Location of an application object is derived as follows:
"$TOI$" SHALL be substituted with the unique TOI value in the LCT
header of the ROUTE packets used to recover the given delivery object
(as specified in Section 6.1).
After the substitution, the fileTemplate SHALL be a valid URL
corresponding to the Content-Location attribute of the associated
application object.
An example @fileTemplate using a width of 5 is:
fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with
exactly five digits in the number portion. The Media Segment file
name for TOI=33 using this template is myVideo00033.mps.
Zia, et al. Expires December 29, 2020 [Page 25]
Internet-Draft ROUTE June 2020
6.3.2. File@Transfer-Length Derivation
Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL
header, when present, SHALL be used to derive the Transport Object
Length (TOL) of the File. If the File@Transfer-Length parameter in
the Extended FDT Instance is not present, then the EXT_TOL header or
the or EXT_FTI header SHALL be present. Note that a header containing
the transport object length (EXT_TOL or EXT_FTI) need not be present
in each packet header. If the broadcaster does not know the length of
the transport object at the beginning of the transfer, an EXT_TOL or
EXT_FTI header SHALL be included in at least the last packet of the
file and should be included in the last few packets of the transfer.
6.3.3. FDT-Instance@Expires Derivation
When present, the maxExpiresDelta attribute SHALL be used to generate
the value of the FDT-Instance@Expires attribute. The receiver is
expected to add this value to its wall clock time when acquiring the
first ROUTE packet carrying the data of a given delivery object to
obtain the value for @Expires.
When maxExpiresDelta is not present, the EXT_TIME header with
Expected Residual Time (ERT) SHALL be used to derive the expiry time
of the Extended FDT Instance. When both maxExpiresDelta and the ERT
of EXT_TIME are present, the smaller of the two values should be used
as the incremental time interval to be added to the receiver's
current time to generate the effective value for @Expires. When
neither maxExpiresDelta nor the ERT field of the EXT_TIME header is
present, then the expiration time of the Extended FDT Instance is
given by its @Expires attribute.
7. FEC Application
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, each flow is typically assigned an individual
recovery property, 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:
- The desired start-up and end-to-end latency. If a Repair Flow
requires a significant amount of buffering time to be effective,
such Repair Flow might only be used in time-shift operations or in
poor reception conditions, since use of such Repair Flow trades
off end-to-end latency against DASH Media Presentation quality.
Zia, et al. Expires December 29, 2020 [Page 26]
Internet-Draft ROUTE June 2020
- FEC capabilities, i.e. the receiver MAY pick only the FEC
algorithm that it supports.
- Which Source Flows are being protected; for example, if the Repair
Flow protects Source Flows that are not selected by the receiver,
then the receiver may not select the Repair Flow.
- Other considerations such as available buffer size, reception
conditions, etc.
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, then
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 an 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:
- The latest time that the file repair procedure may start is bound
by the @Expires attribute of the FDT-Instance.
- The receiver may choose to start the file repair procedure
earlier, if it detects the occurrence of any of the following
events:
o Presence of the Close Object flag (B) in the LCT header
[RFC5651] for the file of interest;
o Presence of the Close Session flag (A) in the LCT header
[RFC5651] before the nominal expiration of the Extended FDT
Instance as defined by the @Expires attribute.
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
Zia, et al. Expires December 29, 2020 [Page 27]
Internet-Draft ROUTE June 2020
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.
1) The receiver is expected to parse the packet header and verify
that it is a valid header. If it is not valid, then the packet SHALL
be discarded without further processing.
2) The receiver is expected to parse the TSI field of the packet
header and verify that a matching value exists in the Service
signaling for the Repair Flow or the associated Protected Source
Flow. If no match is found, the packet SHALL be discarded without
further processing.
3) The receiver processes the remainder of the packet, including
interpretation of the other header fields, and using the source FEC
Payload ID (to determine the start_offset byte position within the
source object), the Repair FEC Payload ID, as well as the payload
data, reconstructs the decoding blocks corresponding to a FEC super-
object as follows:
a) For a source packet, the receiver identifies the delivery object
to which the received packet is associated, using the session
information and the TOI carried in the payload header. Similarly, for
a repair object the receiver identifies the FEC super-object to which
the received packet is associated, using the session information and
the TOI carried in the payload header.
b) For source packets, the receiver collects the data for each FEC
super-object and recovers FEC super-objects in same way as Source
Flow in Section 6.1. The received FEC super-object is then mapped to
a source block and the corresponding encoding symbols are generated.
c) With the reception of the repair packets, the FEC super-object can
be recovered.
d) Once the FEC super-object is recovered, the individual delivery
objects can be extracted.
8. Considerations for Defining ROUTE Profiles
Applications may define specific ROUTE profiles based on this RFC
with the following considerations. Applications MAY
. Restrict the signaling certain values signaled in the LCT
header and/or provision unused fields in the LCT header.
. Restrict using certain LCT header extensions and/or add new LCT
header extensions.
Zia, et al. Expires December 29, 2020 [Page 28]
Internet-Draft ROUTE June 2020
. Restrict or limit certain Codepoints, and/or add of application
specific Codepoints marked as reserved in this RFC.
. Restrict usage of certain service signaling attributes and/or
add own service metadata.
Applications SHALL NOT redefine the semantics of any of the ROUTE
attributes in LCT headers and extension, and service signaling
attributes already specified in this RFC.
Following these guidelines, profiles MAY be defined that are
interoperable.
9. ROUTE Concepts
ROUTE is aligned with FLUTE as defined in RFC 6726 [RFC6726] as well
as the extensions defined in MBMS [MBMS], but also makes use of some
principles of FCAST as defined in RFC 6968 [RFC6968]; for example,
object metadata and the object content may be sent together in a
compound object.
In addition to the basic FLUTE protocol, 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.
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 of 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 which
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.
Zia, et al. Expires December 29, 2020 [Page 29]
Internet-Draft ROUTE June 2020
9.2. File Mode Optimizations
In the 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. In contrast to the FDT in RFC 6726
[RFC6726], Section 3.4.2 and MBMS [MBMS], Section 7.2.10, 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, 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 of 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 (B) flag.
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. 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 seconds DASH
segment with 100 millisecond chunks, it may result in saving up to
1.9 second latency at the sending end.
Zia, et al. Expires December 29, 2020 [Page 30]
Internet-Draft ROUTE June 2020
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 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 it 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:
- Different ROUTE sessions; i.e., they are carried on different
IP/UDP port combinations.
- Different LCT channels; i.e., they use different TSI values in the
LCT header.
- The PSI bit in the LCT, if carried in the same LCT channel. This
mode of operation is mostly suitable for FLUTE-compatible
deployments.
10. Interoperability Chart
The following table is an informative comparison of the
interoperability of ROUTE as specified in this RFC, with the ROUTE
specification in ATSC A/331 [ATSCA331] and DVB Adaptive media
streaming over IP multicast [DVBMABR]:
+---------------+---------------+--------------------+-----------------+
| Element | ATSC A/331 | IETF RFC | DVB ROUTE |
| | | | Profile |
+--------+------+---------------+--------------------+-----------------+
| LCT | PSI | Set to 0 | Set to 1 for source flow for CMAF |
| header | 2nd | for source | Random access chunk |
| fields | bit | flow, though | |
| | | not used by | |
| | | receiver. | |
| +------+---------------+--------------------------------------+
Zia, et al. Expires December 29, 2020 [Page 31]
Internet-Draft ROUTE June 2020
| | CCI | May be set | May be set to EPT for source flow |
| | | to 0 | |
+--------+------+---------------+--------------------+-----------------+
| LCT header | EXT_ROUTE_ | Not defined, | Shall not |
| extensions | PRESENTATION_ | may be added | be used |
| | TIME Header | by a profile. | |
| | used for | | |
| | MDE mode | | |
| +---------------+--------------------+-----------------+
| | EXT_TIME | EXT_TIME Header may be used |
| | Header | regardless (for |
| | linked to | FDT-Instance@Expires |
| | MDE mode | calculation) |
| | in Annex | |
| | A.3.7.2 | |
+---------------+---------------+--------------------+-----------------+
| Codepoints | Full set | Does not specify | Restricted |
| | | range 10 - 255 | to 5 - 9 |
| | | (leaves to | |
| | | profiles) | |
+---------------+---------------+--------------------+-----------------+
| Session | Full set | Only defines | Reuses A/331 |
| metadata | | a small subset | metadata, |
| | | of data necessary | duplicated |
| | | for setting up | from its own |
| | | Source and Repair | service |
| | | Flows. | signaling. |
| | | Does not define | |
| | | format or | |
| | | encoding of data | |
| | | except if data is | |
| | | integral/ | |
| | | alphanumerical. | |
| | | Leaves rest to | |
| | | profiles. | |
+---------------+---------------+--------------------+-----------------+
| Extended | Instance | Not restricted, | Instance shall |
| FDT | shall not | may be | not be sent |
| | be sent | restricted | with source |
| | with source | by a profile. | flow |
| | flow | | |
| +---------------+--------------------+-----------------+
| | No | Only allowed in File Mode |
| | restriction | |
+---------------+---------------+--------------------+-----------------+
| Delivery | File, Entity, Signed/ | Signed/ |
| Object | unsigned package | unsigned |
Zia, et al. Expires December 29, 2020 [Page 32]
Internet-Draft ROUTE June 2020
| Mode | | package not |
| | | allowed |
+---------------+---------------+--------------------+-----------------+
| Sender | Defined for | Defined for DASH segment and CMAF |
| operation: | DASH | Chunks |
| Packet- | segment | |
| ization | | |
+---------------+---------------+--------------------------------------+
| Receiver | Object | Object may be handed before |
| object | handed | completion if |
| recovery | to | MPD@availabilityTimeOffset |
| | application | signaled |
| | upon | |
| | complete | |
| | reception | |
| +---------------+--------------------------------------+
| | - | Fast Stream acquisition |
| | | guideline provided |
+---------------+---------------+--------------------------------------+
11. Security Considerations
Refer to ALC as defined in RFC 5775 [RFC5775].
12. IANA Considerations
None.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
http://tools.ietf.org/html/rfc2119
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009.
http://tools.ietf.org/html/rfc5651
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
http://tools.ietf.org/html/rfc5775
[RFC6726] Paila, T., Luby, M., Lehtonen, R., Roca, V., Walsh, R.,
"FLUTE-File Delivery over Unidirectional Transport." 2012.
http://tools.ietf.org/html/rfc6726
Zia, et al. Expires December 29, 2020 [Page 33]
Internet-Draft ROUTE June 2020
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and
Minder, L. "RaptorQ forward error correction scheme for object
delivery", 2011.
http://tools.ietf.org/html/rfc6330
[RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
Resource Identifier (URI): Generic Syntax", January 2005.
http://tools.ietf.org/html/rfc3986
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3,"
Internet Engineering Task Force, Reston, VA, May, 1996.
http://tools.ietf.org/html/rfc1952
[RFC2557] Palme, J., Hopmann, A. and Shelness, N., "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", Internet
Engineering Task Force, Reston, VA, March 1999.
http://tools.ietf.org/html/rfc2557
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner,
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message Specification," Internet Engineering Task Force, Fremont, CA,
January 2010.
https://tools.ietf.org/html/rfc8551
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes,"
Internet Engineering Task Force, Reston, VA, March, 2009.
http://tools.ietf.org/html/rfc5445
[RFC5052] Watson, M., Luby, M., and Vicisano, L., "Forward Error
Correction (FEC) Building Block," Internet Engineering Task Force,
Reston, VA, August 2007. http://tools.ietf.org/html/rfc5052
[RFC6363] Watson, M., Begen, A. and Roca, V., "Forward Error
Correction (FEC) Framework," Internet Engineering Task Force, Reston,
VA, October, 2011. http://tools.ietf.org/html/rfc6363
13.2. Informative References
[RFC7231] IETF RFC 7231 "Hypertext Transfer Protocol (HTTP/1.1):
Semantics and Content", June 2014.
http://tools.ietf.org/html/rfc7231
[RFC6968] Roca, V. and Adamson, B., "FCAST: Object Delivery for the
Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
Multicast (NORM) Protocols," Internet Engineering Task Force, Reston,
VA, July, 2013. http://tools.ietf.org/html/rfc6968
Zia, et al. Expires December 29, 2020 [Page 34]
Internet-Draft ROUTE June 2020
[ATSCA331] ATSC A/331:2019: "ATSC Standard: Signaling, Delivery,
Synchronization, and Error Protection", 20 June 2019.
[DVBMABR] DVB Document A176 (Second edition), "Adaptive media
streaming over IP multicast", March 2020.
[DASH] ISO/IEC 23009-1:2019: "Information technology - Dynamic
adaptive streaming over HTTP (DASH) - Part 1: Media presentation
description and segment formats", Fourth edition, December 2019.
[CMAF] ISO/IEC 23000-19:2018: "Information technology - Multimedia
application format (MPEG-A) - Part 19: Common media application
format (CMAF) for segmented media", First edition, January 2018.
[MBMS] ETSI: "Universal Mobile Telecommunications Systems (UMTS);
LTE; Multimedia Broadcast/Multicast Service (MBMS); Protocols and
codecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126
346 v13.3.0 (2016-01), European Telecommunications Standards
Institute, January 2016.
14. Acknowledgments
As outlined in the introduction and in ROUTE concepts, the concepts
specified in this draft are the culmination of the collaborative work
of several experts and organizations over the years. The authors
would especially like to acknowledge the work and efforts of the
following people and organizations to help realize the technologies
described in this draft (in no specific order): Mike Luby, Kent
Walker, Charles Lo, Giridhar Mandyam, and other colleagues from
Qualcomm Incorporated, LG Electronics, Nomor Research, Sony, and BBC
R&D.
Authors' Addresses
Waqar Zia
Qualcomm CDMA Technologies GmbH
Anzinger Str. 13, 81671, Munich, Germany
Email: wzia@qti.qualcomm.com
Thomas Stockhammer
Qualcomm CDMA Technologies GmbH
Anzinger Str. 13, 81671, Munich, Germany
Email: tsto@qti.qualcomm.com
Zia, et al. Expires December 29, 2020 [Page 35]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/