rfc9223xml2.original.xml   rfc9223.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc [
C.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY zwsp "&#8203;">
C.8174.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC5651 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY wj "&#8288;">
C.5651.xml">
<!ENTITY RFC5775 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5775.xml">
<!ENTITY RFC6726 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6726.xml">
<!ENTITY RFC6330 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6330.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3986.xml">
<!ENTITY RFC1952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1952.xml">
<!ENTITY RFC2557 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2557.xml">
<!ENTITY RFC8551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8551.xml">
<!ENTITY RFC5445 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5445.xml">
<!ENTITY RFC5052 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5052.xml">
<!ENTITY RFC6363 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6363.xml">
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7231.xml">
<!ENTITY RFC6968 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6968.xml">
<!ENTITY RFC3740 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3740.xml">
<!ENTITY I-D.ietf-quic-http SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/
reference.I-D.ietf-quic-http.xml">
<!ENTITY RFC9000 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9000.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6347.xml">
<!ENTITY RFC8932 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8932.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-tls-dtls13.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-zia-route-06" category="info" ipr="tru
st200902">
<!-- Generated by id2xml 1.5.0 on 2022-02-11T22:53:42Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc toc="yes"?>
<front>
<title abbrev="ROUTE">Real-time Transport Object delivery over Unidirecti
onal Transport (ROUTE)</title>
<author initials="W" surname="Zia" fullname="Waqar Zia"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" cat
<organization>Qualcomm CDMA Technologies GmbH</organization> egory="info" docName="draft-zia-route-06" number="9223" ipr="trust200902" obsole
<address> tes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true"
<postal> version="3">
<street>Anzinger Str. 13</street>
<city>Munich</city>
<region></region>
<code>81671</code>
<country>Germany</country>
</postal>
<phone></phone>
<email>wzia@qti.qualcomm.com</email>
<uri></uri>
</address>
</author>
<author initials="T" surname="Stockhammer" fullname="Thomas Stockhammer"> <front>
<organization>Qualcomm CDMA Technologies GmbH</organization> <title abbrev="ROUTE">Real-Time Transport Object Delivery over Unidirectiona
<address> l Transport (ROUTE)</title>
<postal> <seriesInfo name="RFC" value="9223"/>
<street>Anzinger Str. 13</street> <author initials="W" surname="Zia" fullname="Waqar Zia">
<city>Munich</city> <organization>Qualcomm CDMA Technologies GmbH</organization>
<region></region> <address>
<code>81671</code> <postal>
<country>Germany</country> <street>Anzinger Str. 13</street>
<city>Munich</city>
<region/>
<code>81671</code>
<country>Germany</country>
</postal> </postal>
<phone></phone> <phone/>
<email>tsto@qti.qualcomm.com</email> <email>wzia@qti.qualcomm.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<author initials="T" surname="Stockhammer" fullname="Thomas Stockhammer">
<author initials="L" surname="Chaponniere" fullname="Lenaig Chaponniere"> <organization>Qualcomm CDMA Technologies GmbH</organization>
<organization>Qualcomm Technologies Inc.</organization> <address>
<address> <postal>
<postal> <street>Anzinger Str. 13</street>
<street>5775 Morehouse Drive</street> <city>Munich</city>
<city>San Diego</city> <region/>
<region>CA</region> <code>81671</code>
<code>92121</code> <country>Germany</country>
<country>USA</country>
</postal> </postal>
<phone></phone> <phone/>
<email>lguellec@qti.qualcomm.com</email> <email>tsto@qti.qualcomm.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<author initials="L" surname="Chaponniere" fullname="Lenaig Chaponniere">
<author initials="G" surname="Mandyam" fullname="Giridhar Mandyam"> <organization>Qualcomm Technologies Inc.</organization>
<organization>Qualcomm Technologies Inc.</organization> <address>
<address> <postal>
<postal> <street>5775 Morehouse Drive</street>
<street>5775 Morehouse Drive</street> <city>San Diego</city>
<city>San Diego</city> <region>CA</region>
<region>CA</region> <code>92121</code>
<code>92121</code> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone></phone> <phone/>
<email>mandyam@qti.qualcomm.com</email> <email>lguellec@qti.qualcomm.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<author initials="G" surname="Mandyam" fullname="Giridhar Mandyam">
<author initials="M" surname="Luby" fullname="Michael Luby"> <organization>Qualcomm Technologies Inc.</organization>
<organization>BitRipple, Inc.</organization> <address>
<address> <postal>
<postal> <street>5775 Morehouse Drive</street>
<street>1133 Miller Ave</street> <city>San Diego</city>
<city>Berkeley</city> <region>CA</region>
<region>CA</region> <code>92121</code>
<code>94708</code> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone></phone> <phone/>
<email>luby@bitripple.com</email> <email>mandyam@qti.qualcomm.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<author initials="M" surname="Luby" fullname="Michael Luby">
<date year="2022" month="February"/> <organization>BitRipple, Inc.</organization>
<address>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) <postal>
for use on https://www.rfc-editor.org/search. --> <street>1133 Miller Ave</street>
<city>Berkeley</city>
<region>CA</region>
<code>94708</code>
<country>United States of America</country>
</postal>
<phone/>
<email>luby@bitripple.com</email>
<uri/>
</address>
</author>
<date month="April" year="2022"/>
<keyword>example</keyword> <keyword>Multicast
</keyword>
<keyword>Broadcast
</keyword>
<keyword>FEC
</keyword>
<keyword>DASH
</keyword>
<keyword>HLS
</keyword>
<keyword>FLUTE
</keyword>
<abstract><t> <abstract>
<t>
The Real-time Transport Object delivery over Unidirectional Transport The Real-time Transport Object delivery over Unidirectional Transport
protocol (ROUTE protocol) is specified for robust delivery of (ROUTE) protocol is specified for robust delivery of Application Objects,
Application Objects, including Application Objects with real-time including Application Objects with real-time delivery constraints, to
delivery constraints, to receivers over a unidirectional transport. receivers over a unidirectional transport. Application Objects consist of
Application Objects consist of data that has meaning to applications data that has meaning to applications that use the ROUTE protocol for
that use the ROUTE protocol for delivery of data to receivers, for delivery of data to receivers; for example, it can be a file, a Dynamic
example, it can be a file, or a DASH or HLS segment, a WAV audio Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a
clip, etc. The ROUTE protocol also supports low-latency streaming WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming
applications.</t> applications.</t>
<t>
<t>
The ROUTE protocol is suitable for unicast, broadcast, and multicast The ROUTE protocol is suitable for unicast, broadcast, and multicast
transport. Therefore, it can be run over UDP/IP including multicast transport. Therefore, it can be run over UDP/IP, including multicast
IP. The ROUTE protocol can leverage the features of the underlying IP. The ROUTE protocol can leverage the features of the underlying
protocol layer, e.g. to provide security it can leverage IP security protocol layer, e.g., to provide security, it can leverage IP security
protocols such as IPSec.</t> protocols such as IPsec.</t>
<t>
<t>
This document specifies the ROUTE protocol such that it could be used This document specifies the ROUTE protocol such that it could be used
by a variety of services for delivery of Application Objects by by a variety of services for delivery of Application Objects by
specifying their own profiles of this protocol (e.g. by adding or specifying their own profiles of this protocol (e.g., by adding or
constraining some features).</t> constraining some features).</t>
<t>
<t>
This is not an IETF specification and does not have IETF consensus.</t> This is not an IETF specification and does not have IETF consensus.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><section title="Overview" a <section anchor="sect-1.1" numbered="true" toc="default">
nchor="sect-1.1"><t> <name>Overview</name>
<t>
The Real-time Transport Object delivery over Unidirectional Transport The Real-time Transport Object delivery over Unidirectional Transport
protocol (ROUTE protocol) can be used for robust delivery of (ROUTE) protocol can be used for robust delivery of
Application Objects, including Application Objects with real-time Application Objects, including Application Objects with real-time
delivery constraints, to receivers over a unidirectional transport. delivery constraints, to receivers over a unidirectional transport.
Unidirectional transport in this document has identical meaning as in Unidirectional transport in this document has identical meaning to that in
RFC 6726 <xref target="RFC6726"/>, i.e., transport in the direction of receiv RFC 6726 <xref target="RFC6726" format="default"/>, i.e., transport in the di
er(s) rection of receiver(s)
from a sender. The robustness is enabled by a built-in mechanism e.g. from a sender. The robustness is enabled by a built-in mechanism, e.g.,
signaling for loss detection, enabling loss recovery, and optionally signaling for loss detection, enabling loss recovery, and optionally
integrating application-layer Forward Error Correction (FEC).</t> integrating application-layer Forward Error Correction (FEC).</t>
<t>
<t>
Application Objects consist of data that has meaning to applications Application Objects consist of data that has meaning to applications
that use the ROUTE protocol for delivery of data to receivers, e.g., that use the ROUTE protocol for delivery of data to receivers, e.g.,
an Application Object can be a file, or an MPEG Dynamic Adaptive an Application Object can be a file, an MPEG Dynamic Adaptive
Streaming over HTTP (DASH)[DASH] video segment, a WAV audio clip, an Streaming over HTTP (DASH) <xref target="DASH"/> video segment, a WAV audio c
MPEG Common Media Application Format (CMAF) [CMAF] addressable lip, an
MPEG Common Media Application Format (CMAF) <xref target="CMAF"/> addressable
resource, an MPEG-4 video clip, etc.</t> resource, an MPEG-4 video clip, etc.</t>
<t> <t>
The ROUTE protocol is designed to enable delivery of sequences of The ROUTE protocol is designed to enable delivery of sequences of
related Application Objects in a timely manner to receivers, e.g., a 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 DASH video segments associated to a Representation or a
sequence of CMAF addressable resources associated to a CMAF Track. sequence of CMAF addressable resources associated to a CMAF Track.
The applications of this protocol target services enabled on media The applications of this protocol target services enabled on media
consumption devices such as smartphones, tablets, television sets and consumption devices such as smartphones, tablets, television sets, and
so on. Most of these applications are real-time in the sense that so on. Most of these applications are real-time in the sense that
they are sensitive to and reply upon such timely reception of data. they are sensitive to and rely upon such timely reception of data.
The ROUTE protocol also supports chunked delivery of real-time The ROUTE protocol also supports chunked delivery of real-time
Application Objects to enable low latency streaming applications Application Objects to enable low-latency streaming applications
(similar in its properties to chunked delivery using HTTP). The (similar in its properties to chunked delivery using HTTP). The
protocol also enables low-latency delivery of DASH and Apple HTTP protocol also enables low-latency delivery of DASH and Apple HTTP
Live Streaming (HLS) content with CMAF Chunks.</t> Live Streaming (HLS) content with CMAF Chunks.</t>
<t>
<t>
Content not intended for rendering in real time as it is received Content not intended for rendering in real time as it is received
e.g. a downloaded application, or a file comprising continuous or (e.g., a downloaded application), a file comprising continuous or
discrete media and belonging to an app-based feature, or a file discrete media and belonging to an app-based feature, or a file
containing (opaque) data to be consumed by a Digital Rights containing (opaque) data to be consumed by a Digital Rights
Management (DRM) system client can also delivered by ROUTE.</t> Management (DRM) system client can also be delivered by ROUTE.</t>
<t> <t>
The ROUTE protocol supports a caching model, where Application The ROUTE protocol supports a caching model where Application
Objects are recovered into a cache at the receiver and may be made Objects are recovered into a cache at the receiver and may be made
available to applications via standard HTTP requests from the cache. available to applications via standard HTTP requests from the cache.
Many current day applications rely on using HTTP to access content, Many current day applications rely on using HTTP to access content;
and hence this approach enables such applications in hence, this approach enables such applications in
broadcast/multicast environments.</t> broadcast/multicast environments.</t>
<t>
ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE)
as defined in RFC 6726 <xref target="RFC6726" format="default"/> as well as
the extensions defined in Multimedia Broadcast/Multicast Service (MBMS)
<xref target="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 <xr
ef
target="RFC6968" format="default"/>; for example, object metadata and the
object content may be sent together in a compound object.</t>
<t> <t>
ROUTE is aligned with FLUTE as defined in RFC 6726 <xref target="RFC6726"/> a
s well
as the extensions defined in MBMS [MBMS], but also makes use of some
principles of FCAST (Object Delivery for the ALC and NACK-Oriented
Reliable Multicast Protocols) as defined in RFC 6968 <xref target="RFC6968"/>
; for
example, object metadata and the object content may be sent together
in a compound object.</t>
<t>
The alignment to FLUTE is enabled since in addition to reusing The alignment to FLUTE is enabled since in addition to reusing
several of the basic FLUTE protocol features, as referred to by this several of the basic FLUTE protocol features, as referred to by this
document, certain optimizations and restrictions are added that document, certain optimizations and restrictions are added that
enable optimized support for real-time delivery of media data; hence, enable optimized support for real-time delivery of media data; hence,
the name of the protocol. Among others, the source ROUTE protocol the name of the protocol. Among others, the source ROUTE protocol
enables or enhances the following functionalities:</t> enables or enhances the following functionalities:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Real-time delivery of object-based media data <li>Real-time delivery of object-based media data</li>
</t> <li>Flexible packetization, including enabling media-aware
<t>Flexible packetization, including enabling media-aware
packetization as well as transport-aware packetization of delivery packetization as well as transport-aware packetization of delivery
objects</t> objects</li>
<li>Independence of Application Objects and delivery objects, i.e., a
<t>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 delivery object may be a part of a file or may be a group of
files.</t> files.</li>
</ul>
</list> <t>
</t>
<t>
Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE
protocol integrated with an ATSC 3.0 services layer. That protocol integrated with an ATSC 3.0 services layer. That
specification will be referred to as ATSC-ROUTE [ATSCA331] for the specification will be referred to as ATSC-ROUTE <xref target="ATSCA331"/> for
remainder of this document. DVB has specified a profile of ATSC-ROUTE 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) in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR)
[DVBMABR]. This document specifies the Application Object delivery <xref target="DVBMABR"/>. This document specifies the Application Object deli very
aspects (delivery protocol) for such services, as the corresponding aspects (delivery protocol) for such services, as the corresponding
delivery protocol could be used as a reference by a variety of delivery protocol could be used as a reference by a variety of
services by specifying profiles of ROUTE in their respective fora, services by specifying profiles of ROUTE in their respective fora,
e.g. by adding new optional features atop or by restricting various e.g., by adding new optional features atop or by restricting various
optional features specified in this document in a specific service optional features specified in this document in a specific service
standard. Hence in the context of this document, the aforementioned standard. Hence, in the context of this document, the aforementioned
ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition
of profiles by the services also have to give due consideration to of profiles by the services also have to give due consideration to
compatibility issues, and some related guidelines are also provided compatibility issues, and some related guidelines are also provided
in this document.</t> in this document.</t>
<t>
<t>
This document is not an IETF specification and does not have IETF This document is not an IETF specification and does not have IETF
consensus. It is provided here to aid the production of interoperable consensus. It is provided here to aid the production of interoperable
implementations.</t> implementations.</t>
</section>
<section anchor="sect-1.2" numbered="true" toc="default">
<name>Protocol Stack for ROUTE</name>
</section> <t>
<section title="Protocol Stack for ROUTE" anchor="sect-1.2"><t>
ROUTE delivers Application Objects such as MPEG DASH or HLS segments ROUTE delivers Application Objects such as MPEG DASH or HLS segments
and optionally the associated repair data, operating over UDP/IP and optionally the associated repair data, operating over UDP/IP
networks, as depicted in Figure 1. The session metadata signaling to networks, as depicted in <xref target="protocol-layering"/>. The session meta
realize ROUTE session as specified in this document MAY be delivered data signaling to
out-of-band or in-band as well. Since ROUTE delivers objects in an realize a ROUTE session as specified in this document <bcp14>MAY</bcp14> be d
elivered
out of band or in band as well. Since ROUTE delivers objects in an
application cache at the receiver from where the application can application cache at the receiver from where the application can
access them using HTTP, an application like DASH may use its access them using HTTP, an application like DASH may use its
standardized unicast streaming mechanisms in conjunction with ROUTE standardized unicast streaming mechanisms in conjunction with ROUTE
over broadcast/multicast to augment the services. </t> over broadcast/multicast to augment the services. </t>
<figure title="Protocol Layering" anchor="fig-1"> <table anchor="protocol-layering">
<artwork><![CDATA[ <name>Protocol Layering</name>
+-----------------------------------+ <tbody>
|Application (DASH and HLS segments,|
| CMAF chunks etc.) |
+-----------------------------------+
| ROUTE |
+-----------------------------------+
| UDP |
+-----------------------------------+
| IP |
+-----------------------------------+
]]>
</artwork>
</figure>
</section> <tr>
<td align="center">Application (DASH and HLS segments, CMAF Chun
ks, etc.)
</td>
</tr>
<section title="Data Model" anchor="sect-1.3"><t> <tr>
The ROUTE data model is constituted by the following key concepts. <td align="center">ROUTE
</td>
</tr>
<list style="hanging" hangIndent="6"> <tr>
<td align="center">UDP
</td>
</tr>
<t hangText="Application Object:"> data that has meaning to the application t <tr>
hat <td align="center">IP
uses the ROUTE protocol for delivery of data to receivers, e.g., an </td>
Application Object can be a file, or a DASH video segment, a WAV </tr>
audio clip, an MPEG-4 video clip, etc.</t>
<t hangText="Delivery Object:"> An object on course of delivery to the applic </tbody>
ation </table>
from the ROUTE sender to ROUTE receiver.</t>
<t hangText="Transport Object:"> an object identified by the Transport Object </section>
Identifier (TOI)in RFC 5651 <xref target="RFC5651"/>. It MAY be a either a so <section anchor="sect-1.3" numbered="true" toc="default">
urce <name>Data Model</name>
or a repair object, if it is carried by a Source Flow or a Repair <t>
Flow, respectively.</t> The ROUTE data model is constituted by the following key concepts.
<t hangText="Transport Session:"> An Layered Coding Transport (LCT) channel, </t>
as <dl newline="false" spacing="normal" indent="6">
defined by RFC 5651 <xref target="RFC5651"/>. Transport session SHALL be uniq <dt>Application Object:</dt>
uely <dd> 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.</dd>
<dt>Delivery Object:</dt>
<dd> an object on course of delivery to the application
from the ROUTE sender to ROUTE receiver.</dd>
<dt>Transport Object:</dt>
<dd> an object identified by the Transport Object Identifier (TOI)
in RFC 5651 <xref target="RFC5651" format="default"/>. It
<bcp14>MAY</bcp14> be either a source or a repair object, depending on
if it is
carried by a Source Flow or a Repair Flow, respectively.</dd>
<dt>Transport Session:</dt>
<dd>a Layered Coding Transport (LCT) channel, as
defined by RFC 5651 <xref target="RFC5651" format="default"/>. A Transport Se
ssion <bcp14>SHALL</bcp14> be uniquely
identified by a unique Transport Session Identifier (TSI) value in identified by a unique Transport Session Identifier (TSI) value in
the LCT header. The TSI is scoped by the IP address of the sender, 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 and the IP address of the sender together with the TSI uniquely
identify the session. Transport sessions are a subset of a ROUTE identify the session. Transport Sessions are a subset of a ROUTE
session. For media delivery, a Transport Session would typically session. For media delivery, a Transport Session would typically
carry a media component, for example a DASH Representation. Within carry a media component, for example, a DASH Representation. Within
each transport session, one or more objects are carried, typically each Transport Session, one or more objects are carried, typically
objects that are related, e.g. DASH Segments associated to one objects that are related, e.g., DASH segments associated to one
Representation.</t> Representation.</dd>
<t hangText="ROUTE Session:"> An ensemble or multiplex of one or more
Transport Sessions. Each ROUTE Session is 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.</t>
<t hangText="Source Flow:"> Transport session carrying source data. Source Fl
ow is
independent of the repair Flow, i.e. the Source Flow MAY be used by
a ROUTE receiver without the ROUTE Repair Flows.</t>
<t hangText="Repair Flow:"> Transport session carrying repair data for one
or more Source Flows.</t>
</list>
</t>
</section>
<section title="Architecture and Scope of Specification" anchor="sect-1.4 <dt>ROUTE Session:</dt>
"><t> <dd>an ensemble or multiplex of one or more
The scope of the ROUTE protocol is robust and real-time transport of Transport Sessions. Each ROUTE session is associated with an IP
delivery objects using LCT packets. This architecture is depicted in address/port combination. A ROUTE session typically carries one or more media
Figure 2.</t> components of streaming media e.g., Representations associated with a DASH
Media Presentation.</dd>
<dt>Source Flow:</dt>
<dd>a Transport Session carrying source data. Source Flow is
independent of the Repair Flow, i.e., the Source Flow <bcp14>MAY</bcp14> be u
sed by
a ROUTE receiver without the ROUTE Repair Flows.</dd>
<dt>Repair Flow:</dt>
<dd>a Transport Session carrying repair data for one
or more Source Flows.</dd>
</dl>
</section>
<section anchor="sect-1.4" numbered="true" toc="default">
<name>Architecture and Scope of Specification</name>
<t> <t>
The scope of the ROUTE protocol is to enable robust and real-time transport o
f
delivery objects using LCT packets. This architecture is depicted in
<xref target="architecture-diagram"/>.</t>
<t>
The normative aspects of the ROUTE protocol focus on the following The normative aspects of the ROUTE protocol focus on the following
aspects:</t> aspects:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The format of the LCT packets that carry the <li>The format of the LCT packets that carry the transport objects.</l
transport objects.</t> i>
<li>The robust transport of the delivery object using a repair
<t>The robust transport of the delivery object using a repair protocol based on Forward Error Correction (FEC).</li>
protocol based on Forward Error Correction (FEC).</t> <li>The definition and possible carriage of object metadata along with
<t>The definition and possible carriage of object metadata along with
the delivery objects. Metadata may be conveyed in LCT packets the delivery objects. Metadata may be conveyed in LCT packets
and/or separate objects.</t> and/or separate objects.</li>
<li>The ROUTE session, LCT channel, and delivery object description
<t>The ROUTE session, LCT channel and delivery object description
provided as service metadata signaling to enable the reception of provided as service metadata signaling to enable the reception of
objects.</t> objects.</li>
<li>The normative aspects (formats, semantics) of the delivery
<t>The normative aspects (formats, semantics) of the delivery objects objects conveyed as a content manifest to be delivered along with
conveyed as a content manifest to be delivered along with the the objects to optimize the performance for specific applications
objects to optimize the performance for specific applications; e.g., real-time delivery. The objects and manifest are made
e.g., real-time delivery. The objects and manifest are made available to the application through an Application Object cache.
available to the application through an Application Object cache. The interface of this cache to the application is not specified in
The interface of this cache to the application is not specified in this document; however, it will typically be enabled by the
this document, however it will typically be enabled by the application acting as an HTTP client and the cache as the HTTP
application acting as an HTTP Client and the cache as the HTTP server.</li>
server.</t> </ul>
<figure anchor="architecture-diagram">
</list> <name>Architecture/Functional Block Diagram</name>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="Architecture/functional block diagram" anchor="fig-2"><art
work><![CDATA[
Application Objects Application Objects
Application to application Application to application
Objects from ^ Objects from ^
an application +--------------------------------------------+ an application +--------------------------------------------+
+ | ROUTE Receiver | | + | ROUTE Receiver | |
| | +------+------+ | | | +------+------+ |
| | | Application | | | | | Application | |
| | | Object Cache| | | | | Object Cache| |
| | +------+------+ | | | +------+------+ |
| LCT over| +---------------+ ^ | | LCT over| +---------------+ ^ |
skipping to change at line 391 skipping to change at line 375
| ROUTE | | | +---------------+ +----+----+ | | ROUTE | | | +---------------+ +----+----+ |
| Sender +----------+ ^ | | Sender +----------+ ^ |
+----+---+ | | | | +----+---+ | | | |
| | | +---------------+ | | | | | +---------------+ | |
| | | | Repair object | | | | | | | Repair object | | |
| | +->+ recovery +-------+ | | | +->+ recovery +-------+ |
+----------->+ +---------------+ | +----------->+ +---------------+ |
ROUTE | | ROUTE | |
Metadata +--------------------------------------------+ Metadata +--------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section title="Intellectual Property" anchor="sect-1.5"><t>
The protocol described in this document may be subject to
intellectual property rights disclosed to the IETF in accordance with
BCP 78 and recorded in the datatracker entry for this document.</t>
</section>
<section title="Conventions used in this document" anchor="sect-1.6"><t>
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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the
y appear in all
capitals, as shown here.</t>
</section> <section anchor="sect-1.6" numbered="true" toc="default">
<name>Conventions Used in This Document</name>
</section> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="ROUTE Packet Format" anchor="sect-2"><section title="Pack </section>
et Structure and Header Fields" anchor="sect-2.1"><t> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>ROUTE Packet Format</name>
<section anchor="sect-2.1" numbered="true" toc="default">
<name>Packet Structure and Header Fields</name>
<t>
The packet format used by ROUTE Source Flows and Repair Flows follows The packet format used by ROUTE Source Flows and Repair Flows follows
the ALC packet format specified in RFC 5775 <xref target="RFC5775"/>, with th e UDP the ALC packet format specified in RFC 5775 <xref target="RFC5775" format="de fault"/> with the UDP
header followed by the default LCT header and the source FEC Payload header followed by the default LCT header and the source FEC Payload
ID followed by the packet payload. The overall ROUTE packet format is ID followed by the packet payload. The overall ROUTE packet format is
as depicted in Figure 3 below.</t> as depicted in <xref target="route-packet-format"/>.</t>
<figure anchor="route-packet-format">
<figure title="Overall ROUTE packet format" anchor="fig-3"><artwork><![CD <name>Overall ROUTE Packet Format</name>
ATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | UDP Header |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header | | Default LCT header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID | | FEC Payload ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data | | Payload Data |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The Default LCT header is as defined in the LCT building block in RFC The Default LCT header is as defined in the LCT building block in RFC
5651 <xref target="RFC5651"/>.</t> 5651 <xref target="RFC5651" format="default"/>.</t>
<t>
<t> The LCT packet header fields <bcp14>SHALL</bcp14> be used as defined by the L
The LCT packet header fields SHALL be used as defined by the LCT CT
building block in RFC 5651 <xref target="RFC5651"/>. The semantics and usage building block in RFC 5651 <xref target="RFC5651" format="default"/>. The sem
of the antics and usage of the
following LCT header fields SHALL be further constrained in ROUTE as following LCT header fields <bcp14>SHALL</bcp14> be further constrained in RO
UTE as
follows: follows:
<list style="hanging" hangIndent="6"> </t>
<dl newline="false" spacing="normal">
<dt>Version number (V):</dt>
<dd> This 4-bit field indicates the protocol
version number. The version number <bcp14>SHALL</bcp14> be set to '0001', as
specified in
RFC 5651 <xref target="RFC5651" format="default"/>.</dd>
<dt>Congestion Control flag (C) field:</dt>
<dd> This 2-bit field, as
defined in RFC 5651 <xref target="RFC5651" format="default"/>, <bcp14>SHALL</
bcp14> be set to '00'.</dd>
<dt>Protocol-Specific Indication (PSI):</dt>
<dd> 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
<bcp14>SHALL</bcp14> be set to '1' to indicate a source packet and
<bcp14>SHALL</bcp14> bet set to '0' to indicate a repair
packet.</dd>
<dt>Transport Session Identifier flag (S):</dt>
<dd> This 1-bit field
<bcp14>SHALL</bcp14> be set to '1' to indicate a 32-bit word in the TSI field
.</dd>
<dt>Transport Object Identifier flag (O):</dt>
<dd> This 2-bit field <bcp14>SHALL</bcp14>
be set to '01' to indicate the number of full 32-bit words in the TOI
field.</dd>
<dt>Half-word flag (H):</dt>
<dd> This 1-bit field <bcp14>SHALL</bcp14> be set to '0' to
indicate that no half-word field sizes are used.</dd>
<dt>Codepoint (CP):</dt>
<dd> 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 <bcp14>SHALL</bcp14> follow the semantics specified
in the following table. "IS" stands for Initialization Segment of
the media content such as the DASH Initialization Segment
<xref target="DASH"/>. The various modes of operation in the table
(File/Entity/Package Mode) are specified in <xref target="sect-4"
format="default"/>. The table also lists a Codepoint value range
that is reserved for future service-specific uses.</dd>
</dl>
<table anchor="codepoint-values">
<name>Codepoint Values</name>
<t hangText="Version number (V):"> This 4-bit field indicates the protocol <thead>
version number. The version number SHALL be set to '0001', as specified in <tr>
RFC 5651 <xref target="RFC5651"/>.</t> <th>Codepoint value
</th>
<th>Semantics
</th>
</tr>
</thead>
<tbody>
<tr>
<td>0
</td>
<td>Reserved (not used)
</td>
<t hangText="Congestion Control flag (C) field:"> This 2-bit field, as </tr>
defined in RFC 5651 <xref target="RFC5651"/>, SHALL be set to '00'.</t>
<t hangText="Protocol-Specific Indication (PSI):"> The most significant bit <tr>
of this two bit flag is called the Source Packet Indicator (SPI) and <td>1
indicates whether the current packet is a source packet or an FEC repair </td>
packet. The SPI SHALL be set to '1' to indicate a source packet, and SHALL <td>Non Real Time (NRT) - File Mode
bet set to '0' to indicate a repair packet.</t> </td>
<t hangText="Transport Session Identifier flag (S):"> This 1-bit field </tr>
SHALL be set to '1' to indicate a 32-bit word in the TSI field.</t> <tr>
<td>2
</td>
<td>NRT - Entity Mode
</td>
<t hangText="Transport Object Identifier flag (O):"> This 2-bit field SHALL </tr>
be set to '01' to indicate the number of full 32-bit words in the TOI
field.</t>
<t hangText="Half-word flag (H):"> This 1-bit field SHALL be set to '0' to <tr>
indicate that no half-word field sizes are used.</t> <td>3
</td>
<td>NRT - Unsigned Package Mode
</td>
<t hangText="Codepoint (CP):"> This 8-bit field is used to indicate the </tr>
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
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 <xref
target="sect-4"/>. The table also lists a Codepoint value range that is
reserved for future service-specific uses.</t>
</list> <tr>
</t> <td>4
</td>
<td>NRT - Signed Package Mode
</td>
<figure><artwork><![CDATA[ </tr>
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
]]></artwork>
</figure>
<t> <tr>
<list style="hanging" hangIndent="6"> <td>5
</td>
<td>New IS, timeline changed
</td>
<t hangText="Congestion Control Information (CCI):"> For packets carrying </tr>
DASH segments, 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 <xref target="sect-6.2"/>). Otherwise this field SHALL be set
to 0.</t>
<t hangText="Transport Session Identifier (TSI):"> This 32-bit field <tr>
identifies the Transport Session in ROUTE. The context of the Transport <td>6
Session is provided by signaling metadata. The value TSI = 0 SHALL only be </td>
used for service-specific signaling.</t> <td>New IS, timeline continued
</td>
<t hangText="Transport Object Identifier (TOI):"> This 32-bit field SHALL </tr>
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).</t>
</list> <tr>
</t> <td>7
</section> </td>
<td>Redundant IS
</td>
<section title="LCT Header Extensions" anchor="sect-2.2"><t> </tr>
The following LCT header extensions are defined or used by ROUTE:
<list style="hanging" hangIndent="6"> <tr>
<td>8
</td>
<td>Media Segment, File Mode
</td>
<t hangText="EXT_FTI:"> as specified in RFC 5775.</t> </tr>
<t hangText="EXT_TOL:"> The length in bytes of the multicast transport <tr>
object shall be signaled using EXT_TOL as specified by ATSC-ROUTE <td>9
[ATSCA331] with 24 bits or, if required, 48 bits of Transfer Length. The </td>
frequency of using the EXT_TOL header extension is determined by channel <td>Media Segment, Entity Mode
conditions that may cause the loss of the packet carrying Close Object (B) </td>
flag <xref target="RFC5651"/>.</t>
<t> </tr>
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)
flag. However, if this packet is lost, then the EXT_TOL information
can be used by the receiver to determine the transport object length.</t>
<t hangText="EXT_TIME Header:"> as specified in RFC 5651 <xref <tr>
target="RFC5651"/>. The Sender Current Time SHALL be signaled using <td>10
EXT_TIME.</t> </td>
<td>Media Segment, File Mode with CMAF Random Access chunk
</td>
</list> </tr>
</t>
</section> <tr>
<td>11 - 255
</td>
<td>Reserved, service-specific
</td>
<section title="FEC Payload ID for Source Flows" anchor="sect-2.3"><t> </tr>
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 4 shows the 32-bit
start_offset field.</t>
<figure title="FEC Payload ID for Source Flows." anchor="fig-4."><artwork </tbody>
><![CDATA[ </table>
<dl newline="false" spacing="normal">
<dt>Congestion Control Information (CCI):</dt>
<dd> For packets carrying DASH segments, CCI <bcp14>MAY</bcp14> convey
the 32-bit earliest presentation time <xref target="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 <xref target="sect-6.2"
format="default"/>). Otherwise, this field <bcp14>SHALL</bcp14> be
set to 0.</dd>
<dt>Transport Session Identifier (TSI):</dt>
<dd> 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 <bcp14>SHALL</bc
p14> only be
used for service-specific signaling.</dd>
<dt>Transport Object Identifier (TOI):</dt>
<dd> This 32-bit field <bcp14>SHALL</bcp14>
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).</dd>
</dl>
</section>
<section anchor="sect-2.2" numbered="true" toc="default">
<name>LCT Header Extensions</name>
<t>
The following LCT header extensions are defined or used by ROUTE:
</t>
<dl newline="false" spacing="normal">
<dt>EXT_FTI:</dt>
<dd> as specified in RFC 5775.</dd>
<dt>EXT_TOL:</dt>
<dd> the length in bytes of the multicast transport object shall be
signaled using EXT_TOL as specified by ATSC-ROUTE <xref
target="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) <xref target="RFC5651"
format="default"/>.</dd>
<dt/>
<dd>
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.</dd>
<dt>EXT_TIME Header:</dt>
<dd> as specified in RFC 5651 <xref target="RFC5651" format="default"/
>. The Sender Current Time <bcp14>SHALL</bcp14> be signaled using
EXT_TIME.</dd>
</dl>
</section>
<section anchor="sect-2.3" numbered="true" toc="default">
<name>FEC Payload ID for Source Flows</name>
<t>
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
<bcp14>SHALL</bcp14> 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 <bcp14>SHALL</bcp14> be set to 0. <xref
target="start_offset"/> shows the 32-bit start_offset field.</t>
<figure anchor="start_offset">
<name>FEC Payload ID for Source Flows</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | start_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sect-2.4" numbered="true" toc="default">
<section title="FEC Payload ID for Repair Flows" anchor="sect-2.4"><t> <name>FEC Payload ID for Repair Flows</name>
FEC Payload ID for Repair Flows is specified in RFC 6330 <xref target="RFC633 <t>
0"/>.</t> FEC Payload ID for Repair Flows is specified in RFC 6330 <xref target="RFC633
0" format="default"/>.</t>
</section> </section>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Session Metadata</name>
<section title="Session Metadata" anchor="sect-3"><t> <t>
The required session metadata for Source and Repair Flows is The required session metadata for Source and Repair Flows is
specified in the following sections. The list specified here is not specified in the following sections. The list specified here is not
exhaustive; a service MAY signal more metadata to meet its needs. The exhaustive; a service <bcp14>MAY</bcp14> signal more metadata to meet its nee ds. The
data format is also not specified beyond its cardinality; the exact 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 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]. XML encoding format, as has been done by <xref target="DVBMABR"/> and <xref t
arget="ATSCA331"/>.
It is specified in the following if an attribute is mandatory (m), It is specified in the following if an attribute is mandatory (m),
conditional mandatory (cm) or optional (o) to realize a basic ROUTE conditional mandatory (cm) or optional (o) to realize a basic ROUTE
session. A mandatory filed SHALL always be present in the session session. A mandatory field <bcp14>SHALL</bcp14> always be present in the sess
metadata, and a conditional mandatory field SHALL be present if the ion
metadata, and a conditional mandatory field <bcp14>SHALL</bcp14> be present i
f the
specified condition is true. The delivery of the session metadata to specified condition is true. The delivery of the session metadata to
the ROUTE receiver is beyond scope of this document.</t> the ROUTE receiver is beyond the scope of this document.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section title="Generic Metadata" anchor="sect-3.1"><t> <name>Generic Metadata</name>
<t>
Generic metadata is applicable to both Source and Repair Flows as Generic metadata is applicable to both Source and Repair Flows as
follows. Before a receiver can join a ROUTE session, the receiver follows. Before a receiver can join a ROUTE session, the receiver
needs to obtain this generic metadata that contains at least the needs to obtain this generic metadata that contains at least the
following information: following information:
<list style="hanging" hangIndent="6">
<t hangText="ROUTE version number (m):"> The version number of ROUTE used
in this session. The version number conforming to this document SHALL be
1.</t>
<t hangText="Connection ID (m):"> unique identifier of a Connection,
usually consisting of 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.</t>
</list>
</t> </t>
</section> <dl newline="false" spacing="normal">
<dt>ROUTE version number (m):</dt>
<section title="Session Metadata for Source Flows" anchor="sect-3.2"><t> <dd> the version number of ROUTE used
stsi (m): LCT TSI value corresponding to the transport session for in this session. The version number conforming to this document <bcp14>SHALL<
/bcp14> be
1.</dd>
<dt>Connection ID (m):</dt>
<dd> the unique identifier of a Connection,
usually consisting of the following 4-tuple: source IP address/source port nu
mber,
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.</dd>
</dl>
</section>
<section anchor="sect-3.2" numbered="true" toc="default">
<name>Session Metadata for Source Flows</name>
<t>
stsi (m): The LCT TSI value corresponding to the Transport Session for
the Source Flow. the Source Flow.
<list style="hanging" hangIndent="6"> </t>
<dl newline="false" spacing="normal">
<t hangText="rt (o):"> A Boolean flag which SHALL indicate whether the <dt>rt (o):</dt>
<dd> A Boolean flag that <bcp14>SHALL</bcp14> indicate whether the
content component carried by this Source Flow corresponds to real-time 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 streaming media or non-real-time content. When set to "true", it <bcp14>SHALL </bcp14> be
an indication of real-time content, and when absent or set to "false", it an indication of real-time content, and when absent or set to "false", it
SHALL be an indication of non-real-time (NRT) content.</t> <bcp14>SHALL</bcp14> be an indication of non-real-time (NRT) content.</dd>
<dt>minBufferSize (o):</dt>
<t hangText="minBufferSize (o):"> A 32-bit unsigned integer which SHALL <dd> A 32-bit unsigned integer that <bcp14>SHALL</bcp14>
represent, in kilobytes, the minimum required storage size of the receiver represent, in kilobytes, the minimum required storage size of the receiver
transport buffer, for the parent LCT channel of this Source Flow. The transport buffer for the parent LCT channel of this Source Flow. The
buffer holds the data belonging to a Source Object till its complete buffer holds the data belonging to a source object until its complete
reception. This attribute is only applicable when rt = "true".</t> reception. This attribute is only applicable when rt = "true".</dd>
<dt/>
<t>A service which chooses not to signal this attribute relies on <dd>A service that chooses not to signal this attribute relies on
receiver implementation, which must discard the received data beyond the receiver implementation, which must discard the received data beyond
its buffering capability. Such discarding of data will impact the its buffering capability. Such discarding of data will impact the
service quality.</t> service quality.</dd>
<dt>EFDT (cm):</dt>
<t hangText="EFDT (cm):"> when present, SHALL contain a single instance of <dd> When present, <bcp14>SHALL</bcp14> contain a single instance of
an FDT-Instance element per RFC 6726 FLUTE <xref target="RFC6726"/>, which an FDT-Instance element per RFC 6726 FLUTE <xref target="RFC6726" format="def
MAY contain the optional FDT extensions as defined in <xref ault"/>, which
target="sect-4.1"/>. The optional EFDT element MAY only be present for File <bcp14>MAY</bcp14> contain the optional FDT extensions as defined in <xref ta
Mode of delivery. In File Mode, it SHALL be present if this Source Flow rget="sect-4.1" format="default"/>. The optional EFDT element <bcp14>MAY</bcp14>
transports streaming media segments.</t> only be present for File
Mode of delivery. In File Mode, it <bcp14>SHALL</bcp14> be present if this So
<t hangText="contentType (o):"> A string that SHALL represent the media urce Flow
type for the media content. It SHALL obey the semantics of the Content-Type transports streaming media segments.</dd>
header as specified by HTTP/1.1 protocol in RFC 7231 <xref <dt>contentType (o):</dt>
target="RFC7231"/>. This document does not define any new contentType <dd> A string that <bcp14>SHALL</bcp14> represent the media
strings. In its absence, the signalling of media type for the media content type for the media content. It <bcp14>SHALL</bcp14> obey the semantics of the
is beyond the scope of this document.</t> Content-Type
header as specified by the HTTP/1.1 protocol in RFC 7231 <xref target="RFC723
1" format="default"/>. 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.</dd>
<dt>applicationMapping (m):</dt>
<dd> 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.</dd>
</dl>
</section>
<section anchor="sect-3.3" numbered="true" toc="default">
<name>Session Metadata for Repair Flows</name>
<t hangText="applicationMapping (m):"> A set of identifiers that provide an <dl>
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 a Media Presentation
Description (MPD), the latter identified by its Representation and
corresponding Adaptation Set and Period IDs.</t>
</list> <dt>minBuffSize (o):
</dt>
<dd>
<t>
A 32-bit unsigned integer whose value <bcp14>SHALL</bcp14>
represent a required size of the receiver transport buffer for
AL&nbhy;FEC decoding processing. When present, this attribute
<bcp14>SHALL</bcp14> 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.
</t> </t>
<t>
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.</t>
</dd>
</section> <dt>fecOTI (m):
</dt>
<section title="Session metadata for Repair Flows" anchor="sect-3.3"><t> <dd>A parameter consisting of the concatenation of Common and
minBuffSize (o): A 32-bit unsigned integer whose value SHALL Scheme-Specific FEC Object Transmission Information (FEC OTI) as
represent a required size of the receiver transport buffer for AL-FEC defined in Sections <xref target="RFC6330" sectionFormat="bare"
decoding processing. When present, this attribute SHALL indicate the section="3.3.2"/> and <xref target="RFC6330" sectionFormat="bare"
minimum buffer size that is required to handle all associated objects section="3.3.3"/> of <xref target="RFC6330" format="default"/> and
that are assigned to a super-object i.e. a delivery object formed by that corresponds to the delivery objects carried in the Source Flow
the concatenation of multiple FEC transport objects in order to to which this Repair Flow is associated, with the following
bundle these FEC transport objects for AL-FEC protection.</t> qualification: the 40-bit Transfer Length (F) field may either
represent the actual size of the object, or it is encoded as all
<t> zeroes. In the latter case, the FEC transport object size either is
A service which chooses not to signal this attribute relies on unknown or cannot be represented by this attribute. In other words,
receiver implementation, which must discard the received repair data for the all-zeroes format, the delivery objects in the Source Flow
beyond its buffering capability. Such discarding of data will impact correspond to streaming content, either a live Service whereby
the service quality.</t> content encoding has not yet occurred at the time this session data
was generated or pre-recorded streaming content whose delivery
<t> object sizes, albeit known at the time of session data generation,
fecOTI (m): A parameter consisting of the concatenation of Common are variable and cannot be represented as a single value by the
and Scheme-Specific FEC Object Transmission Information (FEC OTI) as fecOTI attribute.
defined in Sections 3.3.2 and 3.3.3 of RFC 6330 <xref target="RFC6330"/>, and </dd>
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
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.
<list style="hanging" hangIndent="6">
<t hangText="ptsi (m):"> TSI value(s) of each Source Flow protected by this
Repair Flow.</t>
<t hangText="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.</t>
<t hangText="mappingTOIy (o):"> The corresponding constant Y to each <dt>ptsi (m):
mappingTOIx, when present, for use in deriving the parent SourceTOI value </dt>
from the above equation. The default value is "0".</t> <dd>TSI value(s) of each Source Flow protected by this Repair Flow.
</dd>
</list> <dt>mappingTOIx (o):
</t> </dt>
<dd>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 <bcp14>MAY</bcp14> be provided for each protected Source
Flow depending upon the usage of FEC (super-)object.
</dd>
</section> <dt>mappingTOIy (o):
</dt>
<dd>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".
</dd>
</dl>
</section> </section>
</section>
<section title="Delivery Object Mode" anchor="sect-4"><t> <section anchor="sect-4" numbered="true" toc="default">
<name>Delivery Object Mode</name>
<t>
ROUTE provides several different delivery object modes, and one of ROUTE provides several different delivery object modes, and one of
these modes may suite the application needs better for a given these modes may suit the application needs better for a given
transport session. A delivery object is self-contained for the Transport Session. A delivery object is self contained for the
application, typically associated with certain properties, metadata application, typically associated with certain properties, metadata,
and timing-related information that are of relevance for the and timing-related information relevant to the
application. The signaling of the delivery object mode is done on an application. The signaling of the delivery object mode is done on an
object based using Codepoint as specified in <xref target="sect-2.1"/>.</t> object basis using Codepoint as specified in <xref target="sect-2.1" format="
default"/>.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="File Mode" anchor="sect-4.1"><t> <name>File Mode</name>
File mode uses an out-of-band Extended FDT (EDFT) signaling for <t>
File Mode uses an out-of-band Extended FDT (EFDT) signaling for
recovery of delivery objects with the following extensions and recovery of delivery objects with the following extensions and
considerations.</t> considerations.</t>
<section anchor="sect-4.1.1" numbered="true" toc="default">
<name>Extensions to FDT</name>
<t>
The following extensions are specified to FDT, as specified in RFC 6726
<xref target="RFC6726" format="default"/>. An Extended FDT-Instance is an
instance of FLUTE FDT, as specified in <xref target="RFC6726"
format="default"/>, plus optionally one or more of the following
extensions:
<section title="Extensions to FDT" anchor="sect-4.1.1"><t> </t>
Following extensions are specified to FDT specified in RFC 6726 <dl newline="false" spacing="normal">
<xref target="RFC6726"/>. An Extended FDT Instance is an instance of FLUTE FD <dt>efdtVersion:</dt>
T as <dd> A value that <bcp14>SHALL</bcp14> represent the version of
specified in <xref target="RFC6726"/>, plus optionally one or more of the fol this Extended FDT-Instance.</dd>
lowing <dt>maxExpiresDelta:</dt>
extensions. <dd>Let "tp" represent the wall clock time at
<list style="hanging" hangIndent="6">
<t hangText="efdtVersion:"> A value that SHALL represent the version of
this Extended FDT Instance.</t>
<t hangText="maxExpiresDelta:"> Let "tp" represent the wall clock time at
the receiver when the receiver acquires the first ROUTE packet carrying the receiver when the receiver acquires the first ROUTE packet carrying
data of the object described by this Extended FDT Instance. data of the object described by this Extended FDT-Instance.
maxExpiresDelta, when present, SHALL represent a time interval which when maxExpiresDelta, when present, <bcp14>SHALL</bcp14> represent a time interval
added to "tp" SHALL represent the expiration time of the associated that when
Extended FDT Instance "te". The time interval is expressed in number of added to "tp" <bcp14>SHALL</bcp14> represent the expiration time of the assoc
iated
Extended FDT-Instance "te". The time interval is expressed in number of
seconds. When maxExpiresDelta is not present, the expiration time of the 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 Extended FDT-Instance <bcp14>SHALL</bcp14> be given by the sum of a) the valu e of the ERT
field in the EXT_TIME LCT header extension in the first ROUTE packet 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 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 the packet header of that ROUTE packet. See Sections <xref target="sect-5.4"
additional rules for deriving the Extended FDT Instance expiration format="counter"/> and <xref target="sect-6.3.3" format="counter"/> on
time. Hence te__= tp + maxExpiresDelta</t> additional rules for deriving the Extended FDT-Instance expiration
time. Hence, <tt>te = tp + maxExpiresDelta</tt>
</dd>
<t hangText="maxTransportSize:"> An attribute that SHALL represent the <dt>maxTransportSize:</dt>
<dd> An attribute that <bcp14>SHALL</bcp14> represent the
maximum transport size in bytes of any delivery object described by this maximum transport size in bytes of any delivery object described by this
Extended FDT Instance. This attribute SHALL be present if a) the Extended FDT-Instance. This attribute <bcp14>SHALL</bcp14> be present if a) t
fileTemplate is present in Extended FDT-Instance; or b) one or more File he
elements, if present in this Extended FDT Instance, do not include 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 Transfer-Length attribute. When maxTransportSize is not present, the
maximum transport size is not signaled, while other signalling such as the maximum transport size is not signaled, while other signaling such as the
Transfer-Length attribute signal the exact transfer length of the Transfer-Length attribute signal the exact Transfer Length of the
object.</t> object.</dd>
<dt>fileTemplate:</dt>
<t hangText="fileTemplate:"> A string value, which when present and in <dd>A string value, which when present and in
conjunction with parameter substitution, is used in deriving the conjunction with parameter substitution, is used in deriving the
Content-Location attribute, for the delivery object described by this Content-Location attribute for the delivery object described by this
Extended FDT Instance. It SHALL include the "$TOI$" identifier. Each Extended FDT-Instance. It <bcp14>SHALL</bcp14> include the "$TOI$" identifier
identifier MAY be suffixed as needed by specific file names, within the . Each
enclosing '$' characters following this prototype: %0[width]d</t> identifier <bcp14>MAY</bcp14> be suffixed as needed by specific file names wi
thin the
</list> enclosing '$' characters following this prototype: <tt>%0[width]d</tt>
</t> </dd>
</dl>
<t> <t>
The width parameter is an unsigned integer that provides the minimum The width parameter is an unsigned integer that provides the minimum
number of characters to be printed. If the value to be printed is number of characters to be printed. If the value to be printed is
shorter than this number, the result SHALL be padded with leading shorter than this number, the result <bcp14>SHALL</bcp14> be padded with lead ing
zeroes. The value is not truncated even if the result is larger. When 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 no format tag is present, a default format tag with width=1 <bcp14>SHALL</bcp 14> be
used.</t> used.</t>
<t>
<t> Strings other than identifiers <bcp14>SHALL</bcp14> only contain characters t
Strings other than identifiers SHALL only contain characters that are hat are
permitted within URIs according to RFC 3986 <xref target="RFC3986"/>.</t> permitted within URIs according to RFC 3986 <xref target="RFC3986" format="de
fault"/>.</t>
<t> <t>
$$ Is an escape sequence in fileTemplate value, i.e. "$$" is <tt>$$</tt> is an escape sequence in fileTemplate value, i.e., "$$" is
non-recursively replaced with a single "$"</t> non-recursively replaced with a single "$".</t>
<t>
<t>
The usage of fileTemplate is described in Sender and Receiver The usage of fileTemplate is described in Sender and Receiver
operations in Sections 5.4 and 6.3, respectively.</t> operations in Sections <xref target="sect-5.4" format="counter"/> and <xref t
arget="sect-6.3" format="counter"/>, respectively.</t>
</section> </section>
<section anchor="sect-4.1.2" numbered="true" toc="default">
<section title="Constraints on Extended FDT" anchor="sect-4.1.2"><t> <name>Constraints on Extended FDT</name>
The Extended FDT Instance SHALL conform to an FDT Instance according <t>
to RFC 6726 <xref target="RFC6726"/>, with the following constraints: at leas The Extended FDT-Instance <bcp14>SHALL</bcp14> conform to an FDT-Instance acc
t one ording
File element and the @Expires attribute SHALL be present.</t> to RFC 6726 <xref target="RFC6726" format="default"/> with the following cons
traints: at least one
<t> File element and the @Expires attribute <bcp14>SHALL</bcp14> be present.</t>
Content encoding MAY be used for delivery of any file described by an <t>
FDT-Instance.File element in the Extended FDT Instance. The content Content encoding <bcp14>MAY</bcp14> be used for delivery of any file describe
encoding defined in the present document is gzip <xref target="RFC1952"/>. Wh d by an
en content FDT-Instance.File element in the Extended FDT-Instance. The content
encoding defined in the present document is gzip <xref target="RFC1952" forma
t="default"/>. When content
encoding is used, the File@Content-Encoding and File@Content-Length encoding is used, the File@Content-Encoding and File@Content-Length
attributes SHALL be present in the Extended FDT Instance.</t> attributes <bcp14>SHALL</bcp14> be present in the Extended FDT-Instance.</t>
</section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
</section> <name>Entity Mode</name>
<t>
<section title="Entity Mode" anchor="sect-4.2"><t>
For Entity Mode, the following applies:</t> For Entity Mode, the following applies:</t>
<t><list style="symbols"><t>Delivery Object metadata SHALL be expressed i <ul spacing="normal">
n the form of entity <li>Delivery object metadata <bcp14>SHALL</bcp14> be expressed in
headers as defined in HTTP/1.1, and which correspond to one or the form of entity headers as defined in HTTP/1.1, which correspond
more of the representation header fields, payload header fields to one or more of the representation header fields, payload header
and response header fields as defined in Sections 3.1, 3.3 and 7, fields, and response header fields as defined in Sections <xref
respectively, of RFC 7231. Additionally, a Digest HTTP response target="RFC7231" section="3.1" sectionFormat="bare"/>, <xref
header <xref target="RFC7231"/> MAY be included to enable a receiver to ve target="RFC7231" section="3.3" sectionFormat="bare"/>, and <xref
rify target="RFC7231" section="7" sectionFormat="bare"/>, respectively, of
the integrity of the multicast transport object.</t> <xref target="RFC7231"/>.</li>
<li>The entity headers sent along with the delivery object provide all
<t>The entity headers sent along with the delivery object provide all information about that multicast transport object.</li>
information about that multicast transport object.</t> <li>
<t>Sending a media object (if the object is chunked) in Entity Mode
<t>Sending a media object (if the object is chunked) in Entity Mode may result in one of the following options:</t>
may result in one of the following options:<list style="symbols"><t>If the <ul spacing="normal">
length of the chunked object is known at sender, the <li><t>If the length of the chunked object is known at the sender,
ROUTE Entity Mode delivery object MAY be sent without using the
HTTP/1.1 chunked transfer coding, i.e. the object starts with ROUTE Entity Mode delivery object <bcp14>MAY</bcp14> be sent without usi
an HTTP header containing the Content Length field, followed ng
by the concatenation of CMAF chunks:</t> HTTP/1.1 chunked transfer coding, i.e., the object starts with
an HTTP header containing the Content Length field followed
</list> by the concatenation of CMAF Chunks:</t>
</t>
</list>
</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk -- |HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
--||---chunk ----| --||---chunk ----|
]]></artwork> ]]></artwork>
-||---chunk ----| </li>
</figure> <li>
<t><list style="empty" hangIndent="3"> <t>If the length of the chunked object is unknown at the sender wh
<t><list style="symbols"><t>If the length of the chunked object is unknow en
n at sender when
starting to send the object, HTTP/1.1 chunked transfer coding starting to send the object, HTTP/1.1 chunked transfer coding
format SHALL be used:</t> format <bcp14>SHALL</bcp14> be used:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
</list> |HTTP Header||Separator+Length||---chunk ----
</t> ||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0|
</list>
</t>
<figure><artwork><![CDATA[
|HTTP Header||Separator+Length||---chunk ----
||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0|
]]></artwork> ]]></artwork>
---||Separator+Length||---chunk ----||Separator+Length=0|
</figure>
<t><list style="hanging" hangIndent="5"><t>
Note, however, that it is not required to send a CMAF chunk in
exactly one HTTP chunk.</t>
</list> <t>Note, however, that it is not required to send a CMAF Chunk in
</t> exactly one HTTP chunk.</t>
</li>
</section> </ul>
</li>
</ul>
</section>
<section title="Unsigned Package Mode" anchor="sect-4.3"><t> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Unsigned Package Mode</name>
<t>
In this delivery mode, the delivery object consists of a group of In this delivery mode, the delivery object consists of a group of
files that are packaged for delivery only. If applied, the client is files that are packaged for delivery only. If applied, the client is
expected to unpack the package and provide each file as an expected to unpack the package and provide each file as an
independent object to the application. Packaging is supported by independent object to the application. Packaging is supported by
Multipart Multipurpose Internet Mail Extensions (MIME) <xref target="RFC2557" />, Multipart Multipurpose Internet Mail Extensions (MIME) <xref target="RFC2557" format="default"/>,
where objects are packaged into one document for transport, with where objects are packaged into one document for transport, with
Content-Type set to multipart/related. When binary files are Content-Type set to multipart/related. When binary files are
included in the package, Content-Transfer-Encoding of "binary" included in the package, Content-Transfer-Encoding of "binary"
should be used for those files.</t> should be used for those files.</t>
</section>
</section> <section anchor="sect-4.4" numbered="true" toc="default">
<name>Signed Package Mode</name>
<section title="Signed Package Mode" anchor="sect-4.4"><t> <t>
In Signed Package Mode delivery, the delivery object consists of a In Signed Package Mode delivery, the delivery object consists of a
group of files that are packaged for delivery, and the package group of files that are packaged for delivery, and the package
includes one or more signatures for validation. Signed packaging is includes one or more signatures for validation. Signed packaging is
supported by RFC 8551 Secure MIME (S/MIME) <xref target="RFC8551"/>, where ob jects supported by RFC 8551 Secure MIME (S/MIME) <xref target="RFC8551" format="def ault"/>, where objects
are packaged into one document for transport and the package includes are packaged into one document for transport and the package includes
objects necessary for validation of the package.</t> objects necessary for validation of the package.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>Sender Operation</name>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="Sender Operation" anchor="sect-5"><section title="Usage o <name>Usage of ALC and LCT for Source Flow</name>
f ALC and LCT for Source Flow" anchor="sect-5.1"><t> <t>
ROUTE Source Flow carry the source data as specified in RFC 5775 ROUTE Source Flow carries the source data as specified in RFC 5775
<xref target="RFC5775"/>. There are several special considerations that ROUTE <xref target="RFC5775" format="default"/>. There are several special consider
ations that ROUTE
introduces to the usage of the LCT building block as outlined in the introduces to the usage of the LCT building block as outlined in the
following:</t> following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>ROUTE limits the usage of the LCT building bl <li>ROUTE limits the usage of the LCT building block to a single
ock to a single channel per session. Congestion control is thus sender driven in
channel per session. Congestion control is thus sender-driven in ROUTE. It also signifies that there is no specific congestion-control-relat
ROUTE. It also signifies that there is no specific congestion ed signaling from the sender to the receiver; the CCI
control related signalling from sender to the receiver; the CCI
field is either set to 0 or used for other purposes as specified field is either set to 0 or used for other purposes as specified
in <xref target="sect-2.1"/>. The functionality of receiver-driven layered in <xref target="sect-2.1" format="default"/>. The functionality of receive r-driven layered
multicast may still be offered by the application, allowing the multicast may still be offered by the application, allowing the
receiver application to select the appropriate delivery session receiver application to select the appropriate delivery session
based on the bandwidth requirement of that session.</t> based on the bandwidth requirement of that session.</li>
</ul>
</list> <t>
</t> Further, the following details apply to LCT:</t>
<ul spacing="normal">
<t> <li>
Further, following details apply to LCT:</t> <t>The Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 <xref target="RFC5651" format="default"/> is used with the followi
<t><list style="symbols"><t>The Layered Coding Transport (LCT) Building B ng constraints:</t>
lock as defined in <ul spacing="normal">
RFC 5651 <xref target="RFC5651"/> is used with the following constraints:<l <li>The TSI in the LCT header <bcp14>SHALL</bcp14> be set equal to
ist style="symbols"><t>The TSI in the LCT header SHALL be set equal to the value the value of
of the stsi attribute in <xref target="sect-3.2" format="default"/>.</li>
the stsi attribute in <xref target="sect-3.2"/>.</t> <li>The Codepoint (CP) in the LCT header <bcp14>SHALL</bcp14> be u
sed to signal
<t>The Codepoint (CP) in the LCT header SHALL be used to signal the applied formatting as defined in the signaling metadata.</li>
the applied formatting as defined in the signaling metadata.</t> <li>
<t>In accordance with ALC, a source FEC Payload ID header is use
<t>In accordance to ALC, a source FEC Payload ID header is used to d to
identify, for FEC purposes, the encoding symbols of the identify, for FEC purposes, the encoding symbols of the
delivery object, or a portion thereof, carried by the delivery object, or a portion thereof, carried by the
associated ROUTE packet. This information may be sent in associated ROUTE packet. This information may be sent in
several ways: several ways:
<list style="symbols"> </t>
<ul spacing="normal">
<t>As a simple new null FEC scheme with the following usage: <li>
<t>As a simple new null FEC scheme with the following usage:
<list style="symbols">
<t>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
</t>
<t>The value of the source FEC Payload ID header SHALL be set as a </t>
<ul spacing="normal">
<li>The value of the source FEC Payload ID header <bcp14>S
HALL</bcp14> be set to
0 in case the ROUTE packet contains the entire delivery object, or
</li>
<li>The value of the source FEC Payload ID header <bcp14>S
HALL</bcp14> be set as a
direct address (start offset) corresponding to the starting byte direct address (start offset) corresponding to the starting byte
position of the portion of the object carried in this packet using a position of the portion of the object carried in this packet using a
32-bit field. </t> 32-bit field. </li>
</ul>
</list> </li>
</t> <li>In a compatible manner to RFC 6330 <xref target="RFC6330"/
> where the SBN and ESI
<t>In a compatible manner to RFC 6330 [RFC6330] where the SBN and ESI defines the start offset together with the symbol size T.</li>
defines the start offset together with the symbol size T.</t> <li>The signaling metadata provides the appropriate parameters
to
<t>The signaling metadata provides the appropriate parameters to indicate any of the above modes using the srcFecPayloadId attribute.</li>
indicate any of the above modes using the srcFecPayloadId attribute.</t> </ul>
</li>
</list> </ul>
</t> </li>
<li>
</list> <t>The LCT Header EXT_TIME extension as defined in RFC 5651 <xref ta
</t> rget="RFC5651" format="default"/>
<bcp14>MAY</bcp14> be used by the sender in the following manner:</t>
<t>The LCT Header EXT_TIME extension as defined in RFC 5651 <xref target= <ul spacing="normal">
"RFC5651"/> <li>The Sender Current Time (SCT), depending on the application,
MAY be used by the sender in the following manner:<list style="symbols"><t> <bcp14>MAY</bcp14> be used to occasionally or frequently signal the send
The Sender Current Time (SCT), depending on the application, er
MAY be used to occasionally or frequently signal the sender current time possibly for reliever time synchronization.</li>
current time, possibly for reliever time synchronization.</t> <li>The Expected Residual Time (ERT) <bcp14>MAY</bcp14> be used to
indicate the
<t>The Expected Residual Time (ERT) MAY be used to indicate the
expected remaining time for transmission of the current expected remaining time for transmission of the current
object, to optimize detection of a lost delivery object.</t> object in order to optimize detection of a lost delivery object.</li>
<li>The Sender Last Changed (SLC) flag is typically not utilized
<t>The Sender Last Changed (SLC) flag is typically not utilized, but <bcp14>MAY</bcp14> be used to indicate the addition/removal of Segme
but MAY be used to indicate addition/removal of Segments.</t> nts.</li>
</ul>
</list> </li>
</t> </ul>
<t>
</list> Additional extension headers <bcp14>MAY</bcp14> be used to support real-time
</t> delivery. Such extension headers are defined in <xref target="sect-2.1" forma
t="default"/>.</t>
<t> </section>
Additional extension headers MAY be used to support real-time <section anchor="sect-5.2" numbered="true" toc="default">
delivery. Such extension headers are defined in <xref target="sect-2.1"/>.</t <name>ROUTE Packetization for Source Flow</name>
> <t>
</section>
<section title="ROUTE Packetization for Source Flow" anchor="sect-5.2"><t
>
The following description of the ROUTE sender operation on the The following description of the ROUTE sender operation on the
mapping of the Application Object to the ROUTE packet payloads mapping of the Application Object to the ROUTE packet payloads
logically represents an extension of RFC 5445 <xref target="RFC5445"/>, which logically represents an extension of RFC 5445 <xref target="RFC5445" format="
in default"/>, which in
turn inherits the context, language, declarations and restrictions of turn inherits the context, language, declarations, and restrictions of
the FEC building block in RFC 5052 <xref target="RFC5052"/>.</t> the FEC building block in RFC 5052 <xref target="RFC5052" format="default"/>.
</t>
<t> <t>
The data carried in the payload of a given ROUTE packet constitute a The data carried in the payload of a given ROUTE packet constitutes a
contiguous portion of the Application Object. ROUTE source delivery contiguous portion of the Application Object. ROUTE source delivery
can be considered as a special case of the use of the Compact No-Code 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 Scheme associated with FEC Encoding ID = 0 according to Sections
3.4.1 and 3.4.2 of RFC 5445 <xref target="RFC5445"/>, in which the encoding s <xref target="RFC5445" sectionFormat="bare" section="3.4.1" /> and <xref targ
ymbol et="RFC5445" sectionFormat="bare" section="3.4.2"/> of <xref target="RFC5445" fo
size is exactly one byte. As specified in <xref target="sect-2.1"/>, for ROUT rmat="default"/>, in which the encoding symbol
E size is exactly one byte. As specified in <xref target="sect-2.1" format="def
Source Flows, the FEC Payload ID SHALL deliver the 32-bit ault"/>, for ROUTE
Source Flows, the FEC Payload ID <bcp14>SHALL</bcp14> deliver the 32-bit
start_offset. All receivers are expected to support, at minimum, start_offset. All receivers are expected to support, at minimum,
operation with this special case of the Compact No-Code FEC.</t> operation with this special case of the Compact No-Code FEC.</t>
<t>
<t> Note that in the event the source object size is greater than 2<sup>32</sup>
Note that in the event the source object size is greater than 2^32 bytes bytes
(approximately 4.3 GB), the applications (in the broadcaster server and the (approximately 4.3 GB), the applications (in the broadcaster server and the
receiver) are expected to perform segmentation/re-assembly using methods receiver) are expected to perform segmentation/reassembly using methods
beyond the scope of this document.</t> beyond the scope of this document.</t>
<t>
<t> Finally, in some special cases, a ROUTE sender <bcp14>MAY</bcp14> need to pro
Finally, in some special cases a ROUTE sender MAY need to produce duce
ROUTE packets that do not contain any payload. This may be required, ROUTE packets that do not contain any payload. This may be required,
for example, to signal the end of a session. These data-less packets for example, to signal the end of a session. These dataless packets
do not contain FEC Payload ID or payload data, but only the LCT do not contain FEC Payload ID or payload data, but only the LCT
header fields. The total datagram length, conveyed by outer protocol header fields. The total datagram length, conveyed by outer protocol
headers (e.g., the IP or UDP header), enables receivers to detect the headers (e.g., the IP or UDP header), enables receivers to detect the
absence of the LCT header, FEC Payload ID and payload data.</t> absence of the LCT header, FEC Payload ID, and payload data.</t>
<section anchor="sect-5.2.1" numbered="true" toc="default">
<section title="Basic ROUTE Packetization" anchor="sect-5.2.1"><t> <name>Basic ROUTE Packetization</name>
<t>
In the basic operation, it is assumed that the Application Object is In the basic operation, it is assumed that the Application Object is
fully available at the ROUTE sender.</t> fully available at the ROUTE sender.</t>
<ol spacing="normal" type="1"><li>The amount of data to be sent in a s
<t><list style="numbers"><t>The amount of data to be sent in a single ROU ingle ROUTE packet is limited
TE packet is limited
by the maximum transfer unit of the data packets or the size of by the maximum transfer unit of the data packets or the size of
the remaining data of the Application Object being sent, whichever the remaining data of the Application Object being sent, whichever
is smaller. The transfer unit is determined either by knowledge of is smaller. The transfer unit is determined either by knowledge of
underlying transport block sizes or by other constraints.</t> underlying transport block sizes or by other constraints.</li>
<li>The start_offset field in the LCT header of the ROUTE packet
<t>The start_offset field in the LCT header of the ROUTE packet
indicates the byte offset of the carried data in the Application indicates the byte offset of the carried data in the Application
Object being sent.</t> Object being sent.</li>
<li>The Close Object flag (B) is set to 1 if this is the last ROUTE
<t>The Close Object (B) flag is set to 1 if this is the last ROUTE packet carrying the data of the Application Object.</li>
packet carrying the data of the Application Object.</t> </ol>
<t>
</list>
</t>
<t>
The order of packet delivery is arbitrary, but in the absence of The order of packet delivery is arbitrary, but in the absence of
other constraints delivery with increasing start_offset value is other constraints, delivery with increasing start_offset value is
recommended.</t> recommended.</t>
</section>
</section> <section anchor="sect-5.2.2" numbered="true" toc="default">
<name>ROUTE Packetization for CMAF Chunked Content</name>
<section title="ROUTE Packetization for CMAF Chunked Content" anchor="sec <t>
t-5.2.2"><t> The following additional guidelines should be followed for ROUTE
Following additional guidelines should be followed for ROUTE packetization of CMAF Chunked Content in addition to the guidelines of
packetization of CMAF Chunked Content in addition to the guideline of <xref target="sect-5.2.1"/>:</t>
Section 5.2.1:</t> <ol spacing="normal" type="1"><li>If it is the first ROUTE packet carr
ying a CMAF Random Access
<t><list style="numbers"><t>If it is the first ROUTE packet carrying a CM chunk, except for the first CMAF Chunk in the segment, the
AF Random Access Codepoint value <bcp14>MAY</bcp14> be set to 10, as specified in the Codep
chunk, except for the first CMAF chunk in the segment, the oint
Codepoint value MAY be set to 10, as specified in the Codepoint value table in <xref target="sect-2.1" format="default"/>. The receiver <b
value table in <xref target="sect-2.1"/>. The receiver MAY use this inform cp14>MAY</bcp14> use this information
ation for optimization of random access.</li>
for optimization of random access.</t> <li>As soon as the total length of the media object is known,
potentially with the packaging of the last CMAF Chunk of a
<t>As soon as the total length of the media object is known, segment, the EXT_TOL extension header <bcp14>MAY</bcp14> be added to the L
potentially with the packaging of the last CMAF chunk of a CT
segment, the EXT_TOL extension header MAY be added to the LCT
header to signal the Transfer Length, so that the receiver may header to signal the Transfer Length, so that the receiver may
know this information in a timely fashion.</t> know this information in a timely fashion.</li>
</ol>
</list> </section>
</t> </section>
<section anchor="sect-5.3" numbered="true" toc="default">
</section> <name>Timing of Packet Emission</name>
<t>
</section> The sender <bcp14>SHALL</bcp14> use the timing information provided by the
<section title="Timing of Packet Emission" anchor="sect-5.3"><t>
The sender SHALL use the timing information provided by the
application to time the emission of packets for a timely reception. application to time the emission of packets for a timely reception.
This information may be contained in the Application Objects e.g. This information may be contained in the Application Objects e.g.,
DASH Segments and/or the presentation manifest. Hence such packets of DASH segments and/or the presentation manifest. Hence, such packets of
streaming media with real time constraints SHALL be sent in such a streaming media with real-time constraints <bcp14>SHALL</bcp14> be sent in su
way to enable their timely reception with respect to the presentation ch a
way as to enable their timely reception with respect to the presentation
timeline.</t> timeline.</t>
</section>
</section> <section anchor="sect-5.4" numbered="true" toc="default">
<name>Extended FDT Encoding for File Mode Sending</name>
<section title="Extended FDT Encoding for File Mode Sending" anchor="sect <t>
-5.4"><t> For File Mode sending:</t>
For File Mode Sending:</t> <ul spacing="normal">
<li>The TOI field in the ROUTE packet header <bcp14>SHALL</bcp14> be s
<t><list style="symbols"><t>The TOI field in the ROUTE packet header SHAL et such that
L be set such that
Content-Location can be derived at the receiver according to File Content-Location can be derived at the receiver according to File
Template substitution specified in <xref target="sect-6.3.1"/>.</t> Template substitution specified in <xref target="sect-6.3.1" format="defau
lt"/>.</li>
<t>After sending the first packet with a given TOI value, none of the <li>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 packets pertaining to this TOI <bcp14>SHALL</bcp14> be sent later than the
wall
clock time as derived from maxExpiresDelta. The EXT_TIME header clock time as derived from maxExpiresDelta. The EXT_TIME header
with Expected Residual Time (ERT) MAY be used in order to convey with Expected Residual Time (ERT) <bcp14>MAY</bcp14> be used in order to c
more accurate expiry time.</t> onvey
more accurate expiry time.</li>
</list> </ul>
</t> </section>
<section anchor="sect-5.5" numbered="true" toc="default">
</section> <name>FEC Framework Considerations</name>
<t>
<section title="FEC Framework Considerations" anchor="sect-5.5"><t>
The FEC framework uses concepts of the FECFRAME work as defined in The FEC framework uses concepts of the FECFRAME work as defined in
RFC 6363 <xref target="RFC6363"/>, as well as the FEC building block, RFC 505 RFC 6363 <xref target="RFC6363" format="default"/>, as well as the FEC buildi
2 ng block, RFC 5052
<xref target="RFC5052"/>, which is adopted in the existing FLUTE/ALC/LCT <xref target="RFC5052" format="default"/>, which is adopted in the existing F
LUTE/ALC/LCT
specifications.</t> specifications.</t>
<t>
<t>
The FEC design adheres to the following principles:</t> The FEC design adheres to the following principles:</t>
<ul spacing="normal">
<t><list style="symbols"><t>FEC-related information is provided only wher <li>FEC-related information is provided only where needed.</li>
e needed.</t> <li>Receivers not capable of this framework can ignore repair packets.
</li>
<t>Receivers not capable of this framework can ignore repair packets.</t> <li>The FEC is symbol based with fixed symbol size per protected
Source Flow. The ALC protocol and existing FEC schemes are reused.</li>
<t>The FEC is symbol-based with fixed symbol size per protected <li>A FEC Repair Flow provides protection of delivery objects from one
Source Flow. The ALC protocol and existing FEC schemes are reused.</t> or more Source Flows.</li>
</ul>
<t>A FEC Repair Flow provides protection of delivery objects from one <t>
or more Source Flows.</t>
</list>
</t>
<t>
The FEC-specific components of the FEC framework are:</t> The FEC-specific components of the FEC framework are:</t>
<ul spacing="normal">
<li>FEC Repair Flow declaration including all FEC-specific
information.</li>
<t><list style="symbols"><t>FEC Repair Flow declaration including all FEC <li>A FEC transport object that is the concatenation of a delivery obj
-specific ect,
information.</t> padding octets, and size information in order to form a chunk of data that
has a size in symbols of N, where N &gt;= 1.</li>
<t>FEC transport object that is the concatenation of a delivery object, <li>A FEC super-object that is the concatenation of one or more FEC
padding octets and size information in order to form an N-symbol-sized
chunk of data, where N &gt;= 1.</t>
<t>FEC super-object that is the concatenation of one or more FEC
transport objects in order to bundle FEC transport objects for FEC transport objects in order to bundle FEC transport objects for FEC
protection.</t> protection.</li>
<li>A FEC protocol and packet structure.</li>
<t>FEC protocol and packet structure.</t> </ul>
<t>
</list>
</t>
<t>
A receiver needs to be able to recover delivery objects from repair A receiver needs to be able to recover delivery objects from repair
packets based on available FEC information.</t> packets based on available FEC information.</t>
</section>
</section> <section anchor="sect-5.6" numbered="true" toc="default">
<name>FEC Transport Object Construction</name>
<section title="FEC Transport Object Construction" anchor="sect-5.6"><t> <t>
In order to identify a delivery object in the context of the Repair In order to identify a delivery object in the context of the repair
protocol, the following information is needed:</t> protocol, the following information is needed:</t>
<ul spacing="normal">
<t><list style="symbols"><t>TSI and TOI of the delivery object. In this c <li>TSI and TOI of the delivery object. In this case, the FEC object
ase, the FEC object corresponds to the (entire) delivery object.</li>
corresponds to the (entire) delivery object.</t> <li>Octet range of the delivery object, i.e., start offset within the
delivery
<t>Octet range of the delivery object, i.e. start offset within the deliv
ery
object and number of subsequent and contiguous octets of delivery object object and number of subsequent and contiguous octets of delivery object
that constitutes the FEC object (i.e., the FEC-protected portion of the 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 source object). In this case, the FEC object corresponds to a contiguous
byte range portion of the delivery object.</t> byte range portion of the delivery object.</li>
</ul>
</list> <t>
</t>
<t>
Typically, for real-time object delivery with smaller delivery object Typically, for real-time object delivery with smaller delivery object
sizes, the first mapping is applied; i.e., the delivery object is an sizes, the first mapping is applied, i.e., the delivery object is a
FEC object.</t> FEC object.</t>
<t>
<t>
Assuming that the FEC object is the delivery object, for each Assuming that the FEC object is the delivery object, for each
delivery object, the associated FEC transport object is comprised of delivery object, the associated FEC transport object is comprised of
the concatenation of the delivery object, padding octets (P) and the 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.</t> FEC object size (F) in octets, where F is carried in a 4-octet field.</t>
<t>
<t> The FEC transport object size S, in FEC encoding symbols, <bcp14>SHALL</bcp14
The FEC transport object size S, in FEC encoding symbols, SHALL be an > be an
integer multiple of the symbol size Y. S is determined from the session integer multiple of the symbol size Y. S is determined from the session
information and/or the repair packet headers.</t> information and/or the repair packet headers.</t>
<t>
<t>
F is carried in the last 4 octets of the FEC transport object. F is carried in the last 4 octets of the FEC transport object.
Specifically, let:</t> Specifically, let:</t>
<ul spacing="normal">
<t><list style="symbols"><t>F be the size of the delivery object in octet <li>F be the size of the delivery object in octets,</li>
s,</t> <li>F' be the F octets of data of the delivery object,</li>
<li>f' denote the four octets of data carrying the value of F in
<t>F' be the F octets of data of the delivery object,</t> network octet order (high-order octet first),</li>
<li>S be the size of the FEC transport object with S=ceil((F+4)/Y),
<t>f' denote the four octets of data carrying the value of F in
network octet order (high-order octet first),</t>
<t>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 where the ceil() function rounds the result upward to its nearest
integer,</t> integer,</li>
<li>P' be S*Y-4-F octets of data, i.e., padding placed between the
<t>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 delivery object and the 4-byte field conveying the value of F and
located at the end of the FEC transport object, and</t> located at the end of the FEC transport object, and</li>
<li>O' be the concatenation of F', P', and f'.</li>
<t>O' be the concatenation of F', P' and f'.</t> </ul>
<t>
</list>
</t>
<t>
O' then constitutes the FEC transport object of size S*Y octets. Note 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 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 packets of the delivery object but are only part of a FEC transport
object that FEC decoding recovers in order to extract the FEC object object that FEC decoding recovers in order to extract the FEC object
and thus the delivery object or portion of the delivery object that and thus the delivery object or portion of the delivery object that
constitutes the FEC object. In the above context, the FEC transport constitutes the FEC object. In the above context, the FEC transport
object size in symbols is S.</t> object size in symbols is S.</t>
<t>
<t> The general information about a FEC transport object that is
The general information about an FEC transport object that is conveyed to a FEC-enabled receiver is the source TSI, source TOI, and
conveyed to an FEC-enabled receiver is the source TSI, source TOI and
the associated octet range within the delivery object comprising the the associated octet range within the delivery object comprising the
associated FEC object. However, as the size in octets of the FEC associated FEC object. However, as the size in octets of the FEC
object is provided in the appended field within the FEC transport object is provided in the appended field within the FEC transport
object, the remaining information can be conveyed as:</t> object, the remaining information can be conveyed as:</t>
<ul spacing="normal">
<t><list style="symbols"><t>TSI and TOI of the delivery object from which <li>The TSI and TOI of the delivery object from which the FEC object
the FEC object associated with the FEC transport object is generated</li>
associated with the FEC transport object is generated</t> <li>The start octet within the delivery object for the associated FEC
object</li>
<t>Start octet within delivery object for the associated FEC object</t> <li>The size in symbols of the FEC transport object, S</li>
</ul>
<t>Size in symbols of the FEC transport object, S</t> </section>
<section anchor="sect-5.7" numbered="true" toc="default">
</list> <name>Super-Object Construction</name>
</t> <t>
From the FEC Repair Flow declaration, the construction of a FEC
</section>
<section title="Super-Object Construction" anchor="sect-5.7"><t>
From the FEC Repair Flow declaration, the construction of an FEC
super-object as the concatenation of one or more FEC transport super-object as the concatenation of one or more FEC transport
objects can be determined. The FEC super-object includes the general objects can be determined. The FEC super-object includes the general
information about the FEC transport objects as described in the information about the FEC transport objects as described in the
previous sections, as well as the placement order of FEC transport previous sections, as well as the placement order of FEC transport
objects within the FEC super-object.</t> objects within the FEC super-object.</t>
<t>
<t>
Let:</t> Let:</t>
<ul spacing="normal">
<t><list style="symbols"><t>N be the total number of FEC transport object <li>N be the total number of FEC transport objects for the FEC super-o
s for the FEC super-object bject
construction.</t> construction.</li>
<li>For i = 0, ..., N-1, let S[i] be the size in symbols of FEC
<t>For i = 0,..., N-1, let S[i] be the size in symbols of FEC transport object i.</li>
transport object i.</t> <li>B' be the FEC super-object that is the concatenation of the FEC
<t>B' be the FEC super-object which is the concatenation of the FEC
transport objects in numerical order, comprised of K = Sum of N transport objects in numerical order, comprised of K = Sum of N
source symbols, each symbol denoted as S[i].</t> source symbols, each symbol denoted as S[i].</li>
</ul>
</list> <t>
</t>
<t>
For each FEC super-object, the remaining general information that For each FEC super-object, the remaining general information that
needs to be conveyed to an FEC-enabled receiver, beyond what is needs to be conveyed to a FEC-enabled receiver, beyond what is
already carried in the FEC transport objects that constitute the FEC already carried in the FEC transport objects that constitute the FEC
super-object, comprises:</t> super-object, comprises:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The total number of FEC transport objects N.< <li>The total number of FEC transport objects N.</li>
/t> <li>
<t>For each FEC transport object:</t>
<t>For each FEC transport object, the:<list style="symbols"><t>TSI and TO <ul spacing="normal">
I of the delivery object from which the FEC object <li>The TSI and TOI of the delivery object from which the FEC obje
associated with the FEC transport object is generated,</t> ct
associated with the FEC transport object is generated,</li>
<t>Start octet within delivery object for the associated FEC <li>The start octet within the delivery object for the associated
object, and</t> FEC
object, and</li>
<t>Size in symbols of the FEC transport object.</t> <li>The size in symbols of the FEC transport object.</li>
</ul>
</list> </li>
</t> </ul>
<t>
</list>
</t>
<t>
The carriage of the FEC repair information is discussed below.</t> The carriage of the FEC repair information is discussed below.</t>
</section>
</section> <section anchor="sect-5.8" numbered="true" toc="default">
<name>Repair Packet Considerations</name>
<section title="Repair Packet Considerations" anchor="sect-5.8"><t> <t>
The repair protocol is based on Asynchronous Layered Coding (ALC) as The repair protocol is based on Asynchronous Layered Coding (ALC) as
defined in RFC 5775 <xref target="RFC5775"/> and the Layered Coding Transport defined in RFC 5775 <xref target="RFC5775" format="default"/> and the Layered
(LCT) Coding Transport (LCT)
Building Block as defined in RFC 5651 <xref target="RFC5651"/> with the follo Building Block as defined in RFC 5651 <xref target="RFC5651" format="default"
wing /> with the following
details:</t> details:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The Layered Coding Transport (LCT) Building B <li>
lock as defined in <t>The Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 <xref target="RFC5651"/> is used as defined in Asynchronous Layere RFC 5651 <xref target="RFC5651" format="default"/> is used as defined in As
d ynchronous Layered
Coding (ALC), <xref target="sect-2.1"/>. In addition, the following constra Coding (ALC), <xref target="sect-2.1" format="default"/>. In addition, the
ints following constraint
apply:<list style="symbols"><t>The TSI in the LCT header SHALL identify the applies:</t>
Repair Flow to <ul spacing="normal">
which this packet applies, by the matching value of the ptsi <li>The TSI in the LCT header <bcp14>SHALL</bcp14> identify the Re
pair Flow to
which this packet applies by the matching the value of the ptsi
attribute in the signaling metadata among the LCT channels attribute in the signaling metadata among the LCT channels
carrying Repair Flows.</t> carrying Repair Flows.</li>
</ul>
</list> </li>
</t> <li>
<t>The FEC building block is used according to RFC 6330 <xref target
<t>The FEC building block is used according to RFC 6330 <xref target="RFC ="RFC6330" format="default"/>,
6330"/>, but only repair packets are delivered.</t>
but only repair packets are delivered.<list style="symbols"><t>Each repair <ul spacing="normal">
packet within the scope of the Repair Flow (as indicated <li>Each repair packet within the scope of the Repair Flow (as ind
by the TSI field in the LCT header) SHALL carry the repair symbols for icated
by the TSI field in the LCT header) <bcp14>SHALL</bcp14> carry the repai
r symbols for
a corresponding FEC transport object/super-object as identified by its a corresponding FEC transport object/super-object as identified by its
TOI. The repair object/super- object TOI SHALL be unique for each FEC TOI. The repair object/super- object TOI <bcp14>SHALL</bcp14> be unique
super-object that is created within the scope of the TSI.</t> for each FEC
super-object that is created within the scope of the TSI.</li>
</list> </ul>
</t> </li>
</ul>
</list> </section>
</t> <section anchor="sect-5.9" numbered="true" toc="default">
<name>Summary FEC Information</name>
</section> <t>
<section title="Summary FEC Information" anchor="sect-5.9"><t>
For each super-object (identified by a unique TOI within a Repair 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 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 generated, the following information needs to be communicated to the
receiver:</t> receiver:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The FEC configuration consisting of:<list sty <li>
le="symbols"><t>FEC Object Transmission Information (OTI) per RFC 5052 <t>The FEC configuration consisting of:</t>
<xref target="RFC5052"/>.</t> <ul spacing="normal">
<li>FEC Object Transmission Information (OTI) per RFC 5052
<t>Additional FEC information (see <xref target="sect-3.3"/>).</t> <xref target="RFC5052" format="default"/>.</li>
<li>Additional FEC information (see <xref target="sect-3.3" format
<t>The total number of FEC objects included in the FEC super-object, N.</ ="default"/>).</li>
t> <li>The total number of FEC objects included in the FEC super-obje
ct, N.</li>
</list> </ul>
</t> </li>
<li>
<t>For each FEC transport object:<list style="symbols"><t>TSI and TOI of <t>For each FEC transport object:</t>
the delivery object used to generate the FEC <ul spacing="normal">
object associated with the FEC transport object,</t> <li>TSI and TOI of the delivery object used to generate the FEC
object associated with the FEC transport object,</li>
<t>Start octet within the delivery object of the associated FEC <li>The start octet within the delivery object of the associated F
object, if applicable, and</t> EC
object, if applicable, and</li>
<t>The size in symbols of the FEC transport object, S.</t> <li>The size in symbols of the FEC transport object, S.</li>
</ul>
</list> </li>
</t> </ul>
<t>
</list>
</t>
<t>
The above information is delivered:</t> The above information is delivered:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Statically in the session metadata as defined <li>Statically in the session metadata as defined in <xref target="sec
in <xref target="sect-3.3"/>, and</t> t-3.3" format="default"/>, and</li>
<li>Dynamically in an LCT extension header.</li>
<t>Dynamically in an LCT extension header.</t> </ul>
</section>
</list> </section>
</t> <section anchor="sect-6" numbered="true" toc="default">
<name>Receiver Operation</name>
</section> <t>
</section>
<section title="Receiver operation" anchor="sect-6"><t>
The receiver receives packets and filters those packets according to The receiver receives packets and filters those packets according to
the following. From the ROUTE session and each contained LCT channel, the following. From the ROUTE session and each contained LCT channel,
the receiver regenerates delivery objects from the ROUTE session and the receiver regenerates delivery objects from the ROUTE session and
each contained LCT channel.</t> each contained LCT channel.</t>
<t>
<t>
In the event that the receiver receives data that does not conform to In the event that the receiver receives data that does not conform to
the ROUTE protocol specified in this document, the receiver SHOULD the ROUTE protocol specified in this document, the receiver <bcp14>SHOULD</bc
attempt to recover gracefully by e.g. informing the application about p14>
attempt to recover gracefully by e.g., informing the application about
the issues using means beyond the scope of this document. The ROUTE the issues using means beyond the scope of this document. The ROUTE
Packetization specified in <xref target="sect-5.2.1"/> implies that the recei packetization specified in <xref target="sect-5.2.1" format="default"/> impli
ver es that the receiver
SHALL NOT receive overlapping data: if such a condition is <bcp14>SHALL NOT</bcp14> receive overlapping data; if such a condition is
encountered at the receiver, the packet SHALL be assumed to be encountered at the receiver, the packet <bcp14>SHALL</bcp14> be assumed to be
corrupted.</t> corrupted.</t>
<t>
<t> The basic receiver operation is provided below (it assumes an error-free
The basic receiver operation is provided below, it assumes an error-free scenario), while repair considerations are provided in <xref target="sect-7"
scenario, while repair considerations are provided in <xref target="sect-7"/> format="default"/>.</t>
.</t> <section anchor="sect-6.1" numbered="true" toc="default">
<name>Basic Application Object Recovery for Source Flows</name>
<section title="Basic Application Object Recovery for Source Flows" ancho <t>
r="sect-6.1"><t>
Upon receipt of each ROUTE packet of a Source Flow, the receiver Upon receipt of each ROUTE packet of a Source Flow, the receiver
proceeds with the following steps in the order listed.</t> proceeds with the following steps in the order listed.</t>
<ol spacing="normal" type="%d)"><li>The ROUTE receiver is expected to pa
<t><list style="numbers"> rse the LCT and FEC Payload ID to
<t>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 verify that it is a valid header. If it is not valid, then the payload is
discarded without further processing.</t> discarded without further processing.</li>
<li>All ROUTE packets used to recover a specific delivery object carry
<t>All ROUTE packets used to recover a specific delivery object carry the the
same TOI value in the LCT header.</t> same TOI value in the LCT header.</li>
<li>The ROUTE receiver is expected to assert that the TSI and the
<t>The ROUTE receiver is expected to assert that the TSI and the
Codepoint represent valid operation points in the signaling metadata, Codepoint represent valid operation points in the signaling metadata,
i.e. the signaling contains a matching entry to the TSI value provided in 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 the packet header, as well as for this TSI, and the Codepoint field in the
LCT header has a valid Codepoint mapping.</t> LCT header has a valid Codepoint mapping.</li>
<li>
<t>The ROUTE receiver should process the remainder of the payload, <t>The ROUTE receiver should process the remainder of the payload,
including the appropriate interpretation of the other payload header including the appropriate interpretation of the other payload header
fields, and using the source FEC Payload ID (to determine the fields, using the source FEC Payload ID (to determine the
start_offset) and the payload data to reconstruct the corresponding start_offset) and the payload data to reconstruct the corresponding
object as follows: object as follows:
<list style="letters"><t>For File Mode, upon receipt of the first ROUTE p </t>
acket <ol spacing="normal" type="a"><li>For File Mode, upon receipt of the
first ROUTE packet
payload for an object, the ROUTE receiver uses the payload for an object, the ROUTE receiver uses the
File@Transfer-Length attribute of the associated Extended FDT File@Transfer-Length attribute of the associated Extended FDT-Instance,
Instance, when present, to determine the length T of the when present, to determine the length T of the
object. When the File@Transfer-Length attribute is not object. When the File@Transfer-Length attribute is not
present in the Extended FDT Instance, the receiver uses the present in the Extended FDT-Instance, the receiver uses the
maxTransportSize attribute of the associated Extended FDT maxTransportSize attribute of the associated Extended FDT-Instance to d
Instance to determine the maximum length T' of the object. etermine the maximum length T' of the object.
Alternatively, and specifically for delivery modes other than Alternatively, and specifically for delivery modes other than
File Mode, EXT_TOL header can be used to determine the length File Mode, the EXT_TOL header can be used to determine the length
T of the object.</t> T of the object.</li>
<li>The ROUTE receiver allocates buffer space for the T or T'
<t>The ROUTE receiver allocates buffer space for the T or T' bytes that the object will or may occupy.</li>
bytes that the object will or may occupy.</t> <li>The ROUTE receiver computes the length of the payload, Y, by
<t>The ROUTE receiver computes the length of the payload, Y, by
subtracting the payload header length from the total length subtracting the payload header length from the total length
of the received payload.</t> of the received payload.</li>
<li><t>The ROUTE receiver allocates a Boolean array RECEIVED[0..T-
<t>The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or 1] or
RECEIVED[0..T'-1], as appropriate, with all entries initialized to RECEIVED[0..T'-1], as appropriate, with all entries initialized to
false to track received object symbols. The ROUTE receiver false to track received object symbols. The ROUTE receiver
continuously acquires packet payloads for the object as long as all continuously acquires packet payloads for the object as long as all
of the following conditions are satisfied: i) there is at least one of the following conditions are satisfied:</t>
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.
</t>
<t>For each received ROUTE packet payload for the object <ol type="i">
(including the first payload), the steps to be taken to help <li>there is at least one entry in RECEIVED still set to false,
recover the object are as follows: </li>
<li>the object has not yet expired, and</li>
<li><t>the application has not given up on reception of this object.</
t>
<list style="letters"> <t>More details are provided below. </t>
<t>If the packet includes an EXT_TOL or EXT_FTI header, modify the </li>
Boolean array RECEIVED[0..T'-1] to become RECEIVED[0..T-1].</t> </ol>
<t>Let X be the value of the start_offset field in the ROUTE </li>
<li>
<t>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:
</t>
<ol spacing="normal" type="i"><li>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].</li>
<li>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 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 by subtracting the LCT header size and the FEC Payload ID size
from the total length of the received packet.</t> from the total length of the received packet.</li>
<li>The ROUTE receiver copies the data into the appropriate pl
<t>The ROUTE receiver copies the data into the appropriate place ace
within the space reserved for the object and sets RECEIVED[X within the space reserved for the object and sets RECEIVED[X
... X+Y-1] = true.</t> ... X+Y-1] = true.</li>
<li>If all T entries of RECEIVED are true, then the receiver h
<t>If all T entries of RECEIVED are true, then the receiver has as
recovered the entire object.</t> recovered the entire object.</li>
</ol>
</list> </li>
</t> </ol>
</li>
</list> </ol>
</t> <t>
</list>
</t>
<t>
Upon recovery of both the complete set of packet payloads for the Upon recovery of both the complete set of packet payloads for the
delivery object associated with a given TOI value, and the metadata delivery object associated with a given TOI value, and the metadata
for that delivery object, the reception of the delivery object, now a for that delivery object, the reception of the delivery object, now a
fully received Application Object, is complete.</t> fully received Application Object, is complete.</t>
<t>
<t>
Given the timely reception of ROUTE packets belonging to an Given the timely reception of ROUTE packets belonging to an
Application Object, the receiver SHALL make the Application Objects Application Object, the receiver <bcp14>SHALL</bcp14> make the Application Ob
available to the application in a timely fashion, using the jects
application-provided timing data (e.g. the timing data signaled via available to the application in a timely fashion using the
application-provided timing data (e.g., the timing data signaled via
the presentation manifest file). For example, HTTP/1.1 chunked the presentation manifest file). For example, HTTP/1.1 chunked
transfer may need to be enabled to transfer the Application Objects transfer may need to be enabled to transfer the Application Objects
if MPD@availabilityTimeOffset is signaled in the DASH presentation if MPD@availabilityTimeOffset is signaled in the DASH presentation
manifest, to allow for timely sending of segment data to the manifest in order to allow for the timely sending of segment data to the
application.</t> application.</t>
</section>
</section> <section anchor="sect-6.2" numbered="true" toc="default">
<name>Fast Stream Acquisition</name>
<section title="Fast Stream Acquisition" anchor="sect-6.2"><t> <t>
When the receiver initially starts reception of ROUTE packets, it is When the receiver initially starts reception of ROUTE packets, it is likely
likely that the reception does not start from the very first packet that the reception does not start from the very first packet carrying the
carrying the data of a multicast transport object, and in this case data of a multicast transport object; in this case, such a partially
such a partially received object is normally discarded. However, the received object is normally discarded. However, the channel acquisition or
channel acquisition or "tune-in" times can be improved if the "tune-in" times can be improved if the partially received object is usable
partially received object is usable by the application. by the application. One example realization for this is as follows:</t>
One example realization for this is as follows:</t> <ul spacing="normal">
<li>The receiver checks for the first received packet with the
<t><list style="symbols"><t>The receiver checks for the first received pa
cket with the
Codepoint value set to 10, indicating the start of a CMAF Random Codepoint value set to 10, indicating the start of a CMAF Random
Access chunk.</t> Access chunk.</li>
<li>The receiver <bcp14>MAY</bcp14> make the partially received object
<t>The receiver MAY make the partially received object (a partial (a partial
DASH segment starting from the packet above) available to the DASH segment starting from the packet above) available to the
application for fast stream acquisition.</t> application for fast stream acquisition.</li>
<li>It <bcp14>MAY</bcp14> recover the earliest presentation time of th
<t>It MAY recover the earliest presentation time of this CMAF Random is CMAF Random
Access chunk from the ROUTE packet LCT Congestion Control Access chunk from the ROUTE packet LCT Congestion Control
Information (CCI) field as specified in <xref target="sect-2.1"/> to be abl e to Information (CCI) field as specified in <xref target="sect-2.1" format="def ault"/> to be able to
add a new Period element in the MPD exposed to the application add a new Period element in the MPD exposed to the application
containing just the partially received DASH segment with period containing just the partially received DASH segment with period
continuity signaling.</t> continuity signaling.</li>
</ul>
</list> </section>
</t> <section anchor="sect-6.3" numbered="true" toc="default">
<name>Generating Extended FDT-Instance for File Mode</name>
</section> <t>
An Extended FDT-Instance conforming to RFC 6726 <xref target="RFC6726"
<section title="Generating Extended FDT Instance for File Mode" anchor="s format="default"/>, is produced at the receiver using the service metadata
ect-6.3"><t> and in-band signaling in the following steps:</t>
An Extended FDT Instance conforming to RFC 6726 <xref target="RFC6726"/>, is <section anchor="sect-6.3.1" numbered="true" toc="default">
produced at the receiver using the service metadata and in band <name>File Template Substitution for Content-Location Derivation</name
signaling in the following steps:</t> >
<t>
<section title="File Template Substitution for Content-Location Derivatio
n" anchor="sect-6.3.1"><t>
The Content-Location element of the Extended FDT for a specific The Content-Location element of the Extended FDT for a specific
Application Object is derived as follows:</t> Application Object is derived as follows:</t>
<t>
<t>
"$TOI$" is substituted with the unique TOI value in the LCT header of "$TOI$" is substituted with the unique TOI value in the LCT header of
the ROUTE packets used to recover the given delivery object (as the ROUTE packets used to recover the given delivery object (as
specified in <xref target="sect-6.1"/>).</t> specified in <xref target="sect-6.1" format="default"/>).</t>
<t>
<t> After the substitution, the fileTemplate <bcp14>SHALL</bcp14> be a valid URL
After the substitution, the fileTemplate SHALL be a valid URL
corresponding to the Content-Location attribute of the associated corresponding to the Content-Location attribute of the associated
Application Object.</t> Application Object.</t>
<t>
<t>
An example @fileTemplate using a width of 5 is: An example @fileTemplate using a width of 5 is:
fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with
exactly five digits in the number portion. The Media Segment file exactly five digits in the number portion. The Media Segment file
name for TOI=33 using this template is myVideo00033.mps.</t> name for TOI=33 using this template is myVideo00033.mps.</t>
</section>
</section> <section anchor="sect-6.3.2" numbered="true" toc="default">
<name>File@Transfer-Length Derivation</name>
<section title="File@Transfer-Length Derivation" anchor="sect-6.3.2"><t> <t>
Either the EXT_FTI header (per RFC 5775 <xref target="RFC5775"/>) or the EXT_ Either the EXT_FTI header (per RFC 5775 <xref target="RFC5775" format="defaul
TOL t"/>) or the EXT_TOL
header, when present, is used to derive the Transport Object Length header, when present, is used to derive the Transport Object Length
(TOL) of the File. If the File@Transfer-Length parameter in the (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 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 or EXT_FTI header <bcp14>SHALL</bcp14> be present. Note that a header contain
ing the
transport object length (EXT_TOL or EXT_FTI) need not be present in 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 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 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 EXT_FTI header <bcp14>SHALL</bcp14> be included in at least the last packet o f the
file and should be included in the last few packets of the transfer.</t> file and should be included in the last few packets of the transfer.</t>
</section>
</section> <section anchor="sect-6.3.3" numbered="true" toc="default">
<name>FDT-Instance@Expires Derivation</name>
<section title="FDT-Instance@Expires Derivation" anchor="sect-6.3.3"><t> <t>
When present, the maxExpiresDelta attribute SHALL be used to generate When present, the maxExpiresDelta attribute <bcp14>SHALL</bcp14> be used to g
enerate
the value of the FDT-Instance@Expires attribute. The receiver is the value of the FDT-Instance@Expires attribute. The receiver is
expected to add this value to its wall clock time when acquiring the 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 first ROUTE packet carrying the data of a given delivery object to
obtain the value for @Expires.</t> obtain the value for @Expires.</t>
<t>
<t>
When maxExpiresDelta is not present, the EXT_TIME header with When maxExpiresDelta is not present, the EXT_TIME header with
Expected Residual Time (ERT) SHALL be used to derive the expiry time Expected Residual Time (ERT) <bcp14>SHALL</bcp14> be used to derive the expir
of the Extended FDT Instance. When both maxExpiresDelta and the ERT y 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 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 as the incremental time interval to be added to the receiver's
current time to generate the effective value for @Expires. When current time to generate the effective value for @Expires. When
neither maxExpiresDelta nor the ERT field of the EXT_TIME header is neither maxExpiresDelta nor the ERT field of the EXT_TIME header is
present, then the expiration time of the Extended FDT Instance is present, then the expiration time of the Extended FDT-Instance is
given by its @Expires attribute.</t> given by its @Expires attribute.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-7" numbered="true" toc="default">
<name>FEC Application</name>
</section> <section anchor="sect-7.1" numbered="true" toc="default">
<name>General FEC Application Guidelines</name>
<section title="FEC Application" anchor="sect-7"><section title="General <t>
FEC Application Guidelines" anchor="sect-7.1"><t> It is up to the receiver to decide to use zero, one, or more of the
It is up to the receiver to decide to use zero, one or more of the
FEC streams. Hence, the application assigns a recovery property to FEC streams. Hence, the application assigns a recovery property to
each flow, which defines aspects such as the delay and the required each flow, which defines aspects such as the delay and the required
memory if one or the other is chosen. The receiver MAY decide whether memory if one or the other is chosen. The receiver <bcp14>MAY</bcp14> decide whether
or not to utilize Repair Flows based on the following considerations:</t> or not to utilize Repair Flows based on the following considerations:</t>
<ul spacing="normal">
<t><list style="symbols"><t>The desired start-up and end-to-end latency. <li>The desired start-up and end-to-end latency. If a Repair Flow
If a Repair Flow
requires a significant amount of buffering time to be effective, requires a significant amount of buffering time to be effective,
such Repair Flow might only be used in time-shift operations or in such Repair Flow might only be used in time-shift operations or in
poor reception conditions, since use of such Repair Flow trades poor reception conditions, since use of such Repair Flow trades
off end-to-end latency against DASH Media Presentation quality.</t> off end-to-end latency against DASH Media Presentation quality.</li>
<li>FEC capabilities, i.e., the receiver <bcp14>MAY</bcp14> pick only
<t>FEC capabilities, i.e. the receiver MAY pick only the FEC the FEC
algorithm that it supports.</t> algorithm that it supports.</li>
<li>Which Source Flows are being protected; for example, if the Repair
<t>Which Source Flows are being protected; for example, if the Repair
Flow protects Source Flows that are not selected by the receiver, Flow protects Source Flows that are not selected by the receiver,
then the receiver may not select the Repair Flow.</t> then the receiver may not select the Repair Flow.</li>
<li>Other considerations such as available buffer size, reception
<t>Other considerations such as available buffer size, reception conditions, etc.</li>
conditions, etc.</t> </ul>
<t>
</list> If a receiver decides to acquire a certain Repair Flow, then the
</t>
<t>
If a receiver decides to acquire a certain Repair Flow then the
receiver must receive data on all Source Flows that are protected by receiver must receive data on all Source Flows that are protected by
that Repair Flow to collect the relevant packets.</t> that Repair Flow to collect the relevant packets.</t>
</section>
</section> <section anchor="sect-7.2" numbered="true" toc="default">
<name>TOI Mapping</name>
<section title="TOI Mapping" anchor="sect-7.2"><t> <t>
When mappingTOIx/mappingTOIy are used to signal X and Y values, then When mappingTOIx/mappingTOIy are used to signal X and Y values, the TOI
the TOI value(s) of the one or more source objects (sourceTOI) value(s) of the one or more source objects (sourceTOI) protected by a given
protected by a given FEC transport object or FEC super-object with a FEC transport object or FEC super-object with a TOI value rTOI is derived
TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y.</t> through an equation sourceTOI = X*rTOI + Y.</t>
<t>
<t> When neither mappingTOIx nor mappingTOIy is present, there is a 1:1
When neither mappingTOIx nor mappingTOIy is present there is a 1:1
relationship between each delivery object carried in the Source Flow relationship between each delivery object carried in the Source Flow
as identified by ptsi to an FEC object carried in this Repair Flow. as identified by ptsi to a FEC object carried in this Repair Flow.
In this case the TOI of each of those delivery objects SHALL be In this case, the TOI of each of those delivery objects <bcp14>SHALL</bcp14>
be
identical to the TOI of the corresponding FEC object.</t> identical to the TOI of the corresponding FEC object.</t>
</section>
</section> <section anchor="sect-7.3" numbered="true" toc="default">
<name>Delivery Object Reception Timeout</name>
<section title="Delivery Object Reception Timeout" anchor="sect-7.3"><t> <t>
The permitted start and end times for the receiver to perform the The permitted start and end times for the receiver to perform the
file repair procedure, in case of unsuccessful broadcast file file repair procedure, in case of unsuccessful broadcast file
reception, and associated rules and parameters are as follows:</t> reception, and associated rules and parameters are as follows:</t>
<ul spacing="normal">
<li>The latest time that the file repair procedure may start is bound
by the @Expires attribute of the FDT-Instance.</li>
<li>
<t>The receiver may choose to start the file repair procedure
earlier if it detects the occurrence of any of the following
events:</t>
<ul spacing="normal">
<li>Presence of the Close Object flag (B) in the LCT header
<xref target="RFC5651" format="default"/> for the file of interest;</li>
<li>Presence of the Close Session flag (A) in the LCT header
<xref target="RFC5651" format="default"/> before the nominal expiration
of the Extended FDT-Instance as defined by the @Expires attribute.</li>
<t><list style="symbols"><t>The latest time that the file repair procedur </ul>
e may start is bound </li>
by the @Expires attribute of the FDT-Instance.</t> </ul>
</section>
<t>The receiver may choose to start the file repair procedure <section anchor="sect-7.4" numbered="true" toc="default">
earlier, if it detects the occurrence of any of the following <name>Example FEC Operation</name>
events:<list style="symbols"><t>Presence of the Close Object flag (B) in th <t>
e LCT header To be able to recover the delivery objects that are protected by a Repair
<xref target="RFC5651"/> for the file of interest;</t> Flow, a receiver needs to obtain the necessary Service signaling metadata
fragments that describe the corresponding collection of delivery objects
<t>Presence of the Close Session flag (A) in the LCT header that are covered by this Repair Flow. A Repair Flow is characterized by
<xref target="RFC5651"/> before the nominal expiration of the Extended F the combination of an LCT channel, a unique TSI number, as well as the
DT corresponding protected Source Flows.</t>
Instance as defined by the @Expires attribute.</t> <t>
If a receiver acquires data of a Repair Flow, the receiver is expected to
</list> collect all packets of all protected Transport Sessions. Upon receipt of
</t> each packet, whether it is a source or repair packet, the receiver proceeds
with the following steps in the order listed.</t>
</list> <ol spacing="normal" type="1"><li>The receiver is expected to parse
</t> the packet header and verify that it is a valid header. If it is not
valid, then the packet <bcp14>SHALL</bcp14> be discarded without
</section> further processing.</li>
<li>The receiver is expected to parse the TSI field of the packet
<section title="Example FEC Operation" anchor="sect-7.4"><t> header and verify that a matching value exists in the Service
To be able to recover the delivery objects that are protected by a signaling for the Repair Flow or the associated Protected Source
Repair Flow, a receiver needs to obtain the necessary Service Flow. If no match is found, the packet <bcp14>SHALL</bcp14> be
signaling metadata fragments that describe the corresponding discarded without further processing.</li>
collection of delivery objects that are covered by this Repair Flow. <li>
A Repair Flow is characterized by the combination of an LCT channel, <t>The receiver processes the remainder of the packet, including
a unique TSI number, as well as the corresponding protected Source interpretation of the other header fields, and using the source
Flows.</t> FEC Payload ID (to determine the start_offset byte position within
the source object), the Repair FEC Payload ID, as well as the
<t> payload data, reconstructs the decoding blocks corresponding to a
If a receiver acquires data of a Repair Flow, the receiver is FEC super-object as follows:</t>
expected to collect all packets of all protected Transport Sessions. <ol spacing="normal" type="a"><li>For a source packet, the
Upon receipt of each packet, whether it is a source or repair packet, receiver identifies the delivery object to which the received
the receiver proceeds with the following steps in the order listed.</t> packet is associated using the session information and the TOI
carried in the payload header. Similarly, for a repair object, the
<t><list style="numbers"><t>The receiver is expected to parse the packet receiver identifies the FEC super-object to which the received
header and verify packet is associated using the session information and the TOI
that it is a valid header. If it is not valid, then the packet carried in the payload header.</li>
SHALL be discarded without further processing.</t> <li>For source packets, the receiver collects the data for each
FEC super-object and recovers FEC super-objects in the same way
<t>The receiver is expected to parse the TSI field of the packet as a Source Flow in <xref target="sect-6.1"
header and verify that a matching value exists in the Service format="default"/>. The received FEC super-object is then mapped
signaling for the Repair Flow or the associated Protected Source to a source block and the corresponding encoding symbols are
Flow. If no match is found, the packet SHALL be discarded without generated.</li>
further processing.</t> <li>With the reception of the repair packets, the FEC
super-object can be recovered.</li>
<t>The receiver processes the remainder of the packet, including <li>Once the FEC super-object is recovered, the individual
interpretation of the other header fields, and using the source delivery objects can be extracted.</li>
FEC Payload ID (to determine the start_offset byte position within </ol>
the source object), the Repair FEC Payload ID, as well as the </li>
payload data, reconstructs the decoding blocks corresponding to a </ol>
FEC super-object as follows:<list style="letters"><t>For a source packet, </section>
the receiver identifies the delivery </section>
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.</t>
<t>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 <xref target="sect-6.1"/>. The received FEC super-obj
ect
is then mapped to a source block and the corresponding
encoding symbols are generated.</t>
<t>With the reception of the repair packets, the FEC super-object can
be recovered.</t>
<t>Once the FEC super-object is recovered, the individual
delivery objects can be extracted.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Considerations for Defining ROUTE Profiles" anchor="sect-
8"><t>
Services (e.g. ATSC-ROUTE [ATSCA331], DVB-MABR [DVBMABR] etc.) may
define specific ROUTE "profiles" based on this document in their
respective standards organizations. An example is noted in the
overview section: DVB has specified a profile of ATSC-ROUTE in DVB
Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. The
definition with the following considerations. Services MAY</t>
<t><list style="symbols"><t>Restrict the signaling certain values signale
d in the LCT header
and/or provision unused fields in the LCT header.</t>
<t>Restrict using certain LCT header extensions and/or add new LCT
header extensions.</t>
<t>Restrict or limit usage of some Codepoints, and/or assign
semantics to service-specific Codepoints marked as reserved in
this document.</t>
<t>Restrict usage of certain service signaling attributes and/or add
own service metadata.</t>
</list> <section anchor="sect-8" numbered="true" toc="default">
</t> <name>Considerations for Defining ROUTE Profiles</name>
<t> <t>
Services SHALL NOT redefine the semantics of any of the ROUTE Services (e.g., ATSC-ROUTE <xref target="ATSCA331"/>, DVB-MABR <xref
attributes in LCT headers and extension, and service signaling target="DVBMABR"/>, etc.) may define specific ROUTE "profiles" based
on this document in their respective standards organizations. An example is
noted in the overview section: DVB has specified a profile of ATSC-ROUTE in
DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) <xref
target="DVBMABR"/>. The definition has the following
considerations. Services <bcp14>MAY</bcp14></t>
<ul spacing="normal">
<li>Restrict the signaling of certain values signaled in the LCT header
and/or provision unused fields in the LCT header.</li>
<li>Restrict using certain LCT header extensions and/or add new LCT
header extensions.</li>
<li>Restrict or limit usage of some Codepoints and/or assign semantics
to service-specific Codepoints marked as reserved in this
document.</li>
<li>Restrict usage of certain Service signaling attributes and/or add
their own service metadata.</li>
</ul>
<t>
Services <bcp14>SHALL NOT</bcp14> redefine the semantics of any of the ROUTE
attributes in LCT headers and extensions, as well as Service signaling
attributes already specified in this document.</t> attributes already specified in this document.</t>
<t>
<t>
By following these guidelines, services can define profiles that are By following these guidelines, services can define profiles that are
interoperable.</t> interoperable.</t>
</section>
</section> <section anchor="sect-9" numbered="true" toc="default">
<name>ROUTE Concepts</name>
<section title="ROUTE Concepts" anchor="sect-9"><section title="ROUTE Mod <section anchor="sect-9.1" numbered="true" toc="default">
es of Delivery" anchor="sect-9.1"><t> <name>ROUTE Modes of Delivery</name>
Different ROUTE delivery modes specified in <xref target="sect-4"/> are optim <t>
ized Different ROUTE delivery modes specified in <xref target="sect-4"
for delivery of different types of media data. For example, File Mode format="default"/> are optimized for delivery of different types of media
is specifically optimized for delivering DASH content using Segment data. For example, File Mode is specifically optimized for delivering DASH
Template with number substitution. Using File Template in EFDT avoids content using Segment Template with number substitution. Using File
the need of repeated sending of metadata as outlined in the following Template in EFDT avoids the need for the repeated sending of metadata as
section. Same optimizations however cannot be used for time outlined in the following section. Same optimizations, however, cannot be
substitution and segment timeline where the addressing of each used for time substitution and segment timeline where the addressing of
segment is time dependent and in general does not follow a fixed or 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 repeated pattern. In this case, Entity Mode is more optimized since it carrie
carries the file location in band. Also, Entity mode can be used to s the
deliver a file or part of the file using HTTP Partial Content file location in band. Also, Entity Mode can be used to deliver
response headers.</t> a file or part of the file using HTTP Partial Content response headers.</t>
</section>
</section> <section anchor="sect-9.2" numbered="true" toc="default">
<name>File Mode Optimizations</name>
<section title="File Mode Optimizations" anchor="sect-9.2"><t> <t>
In the file mode, the delivery object represents an Application In File Mode, the delivery object represents an Application Object. This
Object. This mode replicates FLUTE as defined in RFC 6726 <xref target="RFC67 mode replicates FLUTE as defined in RFC 6726 <xref target="RFC6726"
26"/>, format="default"/> but with the ability to send static and pre-known file
but with the ability to send static and pre-known file metadata out metadata out of band.</t>
of band.</t> <t>
In FLUTE, FDT-Instances are delivered in band and need to be generated and
<t> delivered in real time if objects are generated in real time at the
In FLUTE, FDT Instances are delivered in-band and need to be generated and sender. These FDT-Instances have some differences as compared to the FDT
delivered in real-time if objects are generated in real-time at the specified in <xref target="RFC6726" sectionFormat="of" section="3.4.2"/> and
sender. These FDT Instances have some differences as compared to the FDT Section 7.2.10 of MBMS
specified in Section 3.4.2 of RFC 6726 <xref target="RFC6726"/> and Section 7 <xref target="MBMS"/>. The key difference is that besides separated delivery
.2.10 of MBMS of file
[MBMS]. The key difference is that besides separated delivery of file
metadata from the delivery object it describes, the FDT functionality in metadata from the delivery object it describes, the FDT functionality in
ROUTE may be extended by additional file metadata and rules that enable the 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 receiver to generate the Content-Location attribute of the File element of
the FDT, on-the-fly. This is done by using information in both the the FDT, on the fly. This is done by using information in both the
extensions to the FDT and the LCT header. The combination of pre-delivery extensions to the FDT and the LCT header. The combination of pre-delivery
of static file metadata and receiver self-generation of dynamic file of static file metadata and receiver self generation of dynamic file
metadata avoids the necessity of continuously sending the FDT Instances for metadata avoids the necessity of continuously sending the FDT-Instances for
real-time objects. Such modified FDT functionality in ROUTE is referred to real-time objects. Such modified FDT functionality in ROUTE is referred to
as the Extended FDT.</t> as the Extended FDT.</t>
</section>
</section> <section anchor="sect-9.3" numbered="true" toc="default">
<name>In-Band Signaling of Object Transfer Length</name>
<section title="In Band Signaling of Object Transfer Length" anchor="sect <t>
-9.3"><t>
As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header 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 extension with 24 bits or, if required, 48 bits to signal the Transfer
Transfer Length directly within the ROUTE packet.</t> Length directly within the ROUTE packet.</t>
<t> <t>
The transport object length can also be determined without the use of 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. 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 However, if this packet is lost, then the EXT_TOL information can be
used by the receiver to determine the transport object length.</t> used by the receiver to determine the transport object length.</t>
<t>
Applications using ROUTE for delivery of low-latency streaming content may
make use of this feature for sender-end latency optimizations: the sender
does not have to wait for the completion of the packaging of a whole
Application Object to find its Transfer Length to be included in the FDT
before the sending can start. Rather, partially encoded data can already
be started to be sent via the ROUTE sender. As the time approaches when the
encoding of the Application Object is nearing completion, and the length of
the object becomes known (e.g., the time of writing the last CMAF Chunk of
a DASH segment), only then the sender can signal the object length using
the EXT TOL LCT header. For example, for a 2-second DASH segment with
100-millisecond chunks, it may result in saving up to 1.9 second latency at
the sending end.</t>
<t> </section>
Applications using ROUTE for delivery of low-latency streaming <section anchor="sect-9.4" numbered="true" toc="default">
content may make use of this feature for sender-end latency <name>Repair Protocol Concepts</name>
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.</t>
</section> <t>
The ROUTE repair protocol is FEC-based and is enabled as an additional
layer between the transport layer (e.g., UDP) and the object delivery layer
protocol. The FEC reuses concepts of the FEC Framework defined in RFC 6363
<xref target="RFC6363" format="default"/>, but in contrast to the FEC
Framework in RFC 6363 <xref target="RFC6363" format="default"/>, the ROUTE
repair protocol does not protect packets but instead protects delivery
objects as delivered in the source protocol. In addition, as an extension
to FLUTE, it supports the protection of multiple objects in one source
block which is in alignment with the FEC Framework as defined in RFC 6363
<xref target="RFC6363" format="default"/>. 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 <xref target="RFC5052" format="default"/> 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.</t>
<t>
In ROUTE, all packets are LCT packets as defined in RFC 5651
<xref target="RFC5651" format="default"/>. Source and repair packets may be d
istinguished by:</t>
<ul spacing="normal">
<li>Different ROUTE sessions, i.e., they are carried on different
UDP/IP port combinations.</li>
<li>Different LCT channels, i.e., they use different TSI values in the
LCT header.</li>
<li>The most significant PSI bit in the LCT, if carried in the same LC
T
channel. This mode of operation is mostly suitable for FLUTE-compatible
deployments.</li>
</ul>
</section>
</section>
<section anchor="sect-10" numbered="true" toc="default">
<name>Interoperability Chart</name>
<t>
As noted in prevision sections, ATSC-ROUTE <xref target="ATSCA331"/> and DVB-
MABR
<xref target="DVBMABR"/> are considered services using this document that con
strain
specific features as well as add new ones. In this context, the
following table is an informative comparison of the interoperability
of ROUTE as specified in this document with ATSC-ROUTE
<xref target="ATSCA331"/> and DVB-MABR <xref target="DVBMABR"/>:</t>
<section title="Repair Protocol Concepts" anchor="sect-9.4"><t> <table anchor="interoperability" align="center">
The ROUTE repair protocol is FEC-based and is enabled as an <name>Interoperability Chart</name>
additional layer between the transport layer (e.g., UDP) and the <thead>
object delivery layer protocol. The FEC reuses concepts of FEC <tr>
Framework defined in RFC 6363 <xref target="RFC6363"/>, but in contrast to th <th align="left" rowspan="1" colspan="1">Element</th>
e FEC <th align="left" rowspan="1" colspan="1">ATSC-ROUTE</th>
Framework in RFC 6363 <xref target="RFC6363"/> the ROUTE repair protocol does <th align="left" rowspan="1" colspan="1">This Document</th>
not <th align="left" rowspan="1" colspan="1">DVB-MABR</th>
protect packets, but instead it protects delivery objects as </tr>
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 <xref target="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 <xref target="RFC5052"/> and uses the terminology of that documen
t. 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.</t>
<t> </thead>
In ROUTE all packets are LCT packets as defined in RFC 5651 <tbody>
<xref target="RFC5651"/>. Source and repair packets may be distinguished by:<
/t>
<t><list style="symbols"><t>Different ROUTE sessions; i.e., they are carr <tr>
ied on different <td align="left" rowspan="2" colspan="1">LCT header field</td>
UDP/IP port combinations.</t> <td align="left" rowspan="1" colspan="1">PSI&nbsp;LSB set to 0 for Source
Flow</td>
<td align="left" rowspan="1" colspan="1">Not defined</td>
<td align="left" rowspan="1" colspan="1">Set to 1 for Source Flow for CMAF
Random Access chunk</td>
</tr>
<t>Different LCT channels; i.e., they use different TSI values in the <tr>
LCT header.</t> <td align="left" rowspan="1" colspan="1">CCI may be set to 0</td>
<td align="left" rowspan="1" colspan="2">CCI may be set to EPT for Source
Flow</td>
</tr>
<t>The most significant PSI bit in the LCT, if carried in the same LCT <tr>
channel. This mode of operation is mostly suitable for FLUTE-compatible <td align="left" rowspan="2" colspan="1">LCT header extensions</td>
deployments.</t> <td align="left" rowspan="1" colspan="1">EXT_ROUTE_&zwsp;PRESENTATION_TIME
Header used for Media Delivery Event (MDE) mode</td>
<td align="left" rowspan="1" colspan="1">Not defined; may be added by a pr
ofile.</td>
<td align="left" rowspan="1" colspan="1">Shall not be used.</td>
</tr>
</list> <tr>
</t> <td align="left" rowspan="1" colspan="1">EXT_TIME Header linked to MDE mod
e in Annex A.3.7.2 <xref target="ATSCA331"/></td>
<td align="left" rowspan="1" colspan="2">EXT_TIME Header may be used regar
dless (for FDT-Instance@Expires calculation)</td>
</tr>
</section> <tr>
<td align="left" rowspan="1" colspan="1">Codepoints</td>
<td align="left">Full set</td>
<td align="left">Does not specify range 11 - 255 (leaves to profiles)</td>
<td align="left">Restricted to 5 - 9</td>
</tr>
</section> <tr>
<td align="left" rowspan="1" colspan="1">Session metadata</td>
<td align="left">Full set</td>
<td align="left">Only defines a small subset of data necessary for setting
up Source and
Repair Flows. Does not define format or encoding of data except if data is
integral/alphanumerical. Leaves rest to profiles.</td>
<td align="left">Reuses A/331 metadata, duplicated from its own Service si
gnaling.</td>
</tr>
<section title="Interoperability Chart" anchor="sect-10"><t> <tr>
As noted in prevision sections, ATSC-ROUTE [ATSCA331] and DVB-MABR <td align="left" rowspan="2" colspan="1">Extended FDT</td>
[DVBMABR] are considered services using this document that constrain <td align="left">Instance shall not be sent with Source Flow</td>
specific features as well as add new ones. In this context, the <td align="left">Not restricted, may be restricted by a profile.</td>
following table is an informative comparison of the interoperability <td align="left">Instance shall not be sent with Source Flow</td>
of ROUTE as specified in this document, with the ATSC-ROUTE </tr>
[ATSCA331] and DVB-MABR [DVBMABR]:</t> <tr>
<td align="left">No restriction</td>
<td align="center" rowspan="1" colspan="2">Only allowed in File Mode</td>
</tr>
<figure><artwork><![CDATA[ <tr>
+---------------+---------------+--------------------+-----------------+ <td align="left" rowspan="1" colspan="1">Delivery Object Mode</td>
| Element | ATSC-ROUTE | This Document | DVB-MABR | <td align="center" rowspan="1" colspan="2">File, Entity, Signed/unsigned pac
| | | | | kage</td>
+--------+------+---------------+--------------------+-----------------+ <td align="left">Signed/unsigned package not allowed</td>
| LCT |PSI | Set to 0 | Not defined | Set to 1 for | </tr>
| header |least | for Source | | Source Flow for |
| fields |signi-| Flow. | | CMAF Random |
| |ficant| | | access chunk |
| |bit | | | |
| +------+---------------+--------------------------------------+
| |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 11 - 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 |
| 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 |
+---------------+---------------+--------------------------------------+
]]></artwork>
</figure>
</section>
<section title="Security and Privacy Considerations" anchor="sect-11"><se <tr>
ction title="Security Considerations" anchor="sect-11.1"><t> <td align="left" rowspan="1" colspan="1">Sender operation: Packetization</td
As noted in <xref target="sect-9"/>, ROUTE is aligned with FLUTE as specified >
in <td align="left">Defined for DASH segment</td>
RFC 6726 <xref target="RFC6726"/> (see <xref target="sect-9"/>), and only div <td align="center" colspan="2">Defined for DASH segment and CMAF Chunks
erges in certain </td>
signaling optimizations, especially for the real-time object delivery </tr>
case. Hence most of the security considerations documented in RFC
6726 <xref target="RFC6726"/> for the data flow itself, the session metadata
(session control parameters in RFC 6726 <xref target="RFC6726"/>), and the
associated building blocks apply directly to ROUTE, as elaborated in
the following along with some additional considerations.</t>
<t> <tr>
Both encryption and integrity protection applied either on file or <td align="left" rowspan="2" colspan="1">Receiver object recovery</td>
packet level, as recommended in file corruption considerations of RFC <td align="left">Object handed to application upon complete reception</td>
6726 <xref target="RFC6726"/> SHOULD be used for ROUTE. Additionally, RFC 374 <td align="center" rowspan="1" colspan="2">Object may be handed before compl
0 etion if MPD@availabilityTimeOffset signaled</td>
<xref target="RFC3740"/> documents multicast security architecture in great d </tr>
etail
with clear security recommendations which SHOULD be followed.</t>
<t> <tr>
When ROUTE is carried over UDP and a reverse channel from receiver to <td align="center">-</td>
sender is available, the security mechanisms provided in RFC 6347 <td align="center" colspan="2">Fast Stream acquisition guidelines provided</
<xref target="RFC6347"/> SHALL apply. At the time, draft DTLS 1.3 based on TS td>
L 1.3 </tr>
<xref target="I-D.ietf-tls-dtls13"/> is pending publication, and may be consi
dered as the
alternate means for security post publication.</t>
<t> </tbody>
In regard to considerations for attacks against session description, </table>
this document does not specify the semantics or mechanism of delivery
of session metadata, though the same threats apply for service using
ROUTE as well. Hence a service using ROUTE SHOULD take these threats
into consideration and address them appropriately following the
guideline provided by RFC 6726 <xref target="RFC6726"/>. Additionally to the
recommendations of RFC 6726 <xref target="RFC6726"/>, for Internet connected
devices, services SHOULD enable clients to access the session
description information using HTTPS with customary
authentication/authorization, instead of sending this data via
multicast/broadcast, since considerable security work has been done
already in this unicast domain which can enable highly secure access
of session description data. Accessing via unicast however will have
different privacy considerations, noted in <xref target="sect-11.2"/>. Note t
hat in
general the multicast/broadcast stream is delayed with respect to the
unicast stream. Therefore, the session description protocol SHOULD
be time-synchronized with the broadcast stream, particularly if the
session description contains security-related information.</t>
<t> </section>
In regard to FDT, there is one key difference for File Mode when <section anchor="sect-11" numbered="true" toc="default">
using File Template in EFDT, which avoids repeated sending of FDT <name>Security and Privacy Considerations</name>
instance and hence the corresponding threats noted in RFC 6726 <section anchor="sect-11.1" numbered="true" toc="default">
<xref target="RFC6726"/> do not apply directly to ROUTE in this case. The thr <name>Security Considerations</name>
eat
however is shifted to the ALC/LCT headers, since they carry the
additional signaling that enables determining Content-Location and
File@Transfer-Length in this case. Hence integrity protection
recommendations of ALC/LCT header SHOULD be considered with higher
emphasis in this case for ROUTE.</t>
<t> <t>
As noted in <xref target="sect-9" format="default"/>, ROUTE is aligned with
FLUTE as specified in RFC 6726 <xref target="RFC6726" format="default"/>
and only diverges in certain signaling optimizations, especially for the
real-time object delivery case. Hence, most of the security considerations
documented in RFC 6726 <xref target="RFC6726" format="default"/> for the
data flow itself, the session metadata (session control parameters in RFC
6726 <xref target="RFC6726" format="default"/>), and the associated
building blocks apply directly to ROUTE as elaborated in the following
along with some additional considerations.</t>
<t>
Both encryption and integrity protection applied either on file or
packet level, as recommended in the file corruption considerations of RFC
6726 <xref target="RFC6726" format="default"/>, <bcp14>SHOULD</bcp14> be used
for ROUTE. Additionally, RFC 3740
<xref target="RFC3740" format="default"/> documents multicast security archit
ecture in great detail
with clear security recommendations that <bcp14>SHOULD</bcp14> be followed.</
t>
<t>
When ROUTE is carried over UDP and a reverse channel from receiver to
sender is available, the security mechanisms provided in RFC 9147
<xref target="RFC9147" format="default"/> <bcp14>SHOULD</bcp14> be applied.</
t>
<t>
In regard to considerations for attacks against session description, this
document does not specify the semantics or mechanism of delivery of session
metadata, though the same threats apply for service using ROUTE as
well. Hence, a service using ROUTE <bcp14>SHOULD</bcp14> take these threats
into consideration and address them appropriately following the guidelines
provided by RFC 6726 <xref target="RFC6726"
format="default"/>. Additionally, to the recommendations of RFC 6726 <xref
target="RFC6726" format="default"/>, for Internet connected devices,
services <bcp14>SHOULD</bcp14> enable clients to access the session
description information using HTTPS with customary
authentication/authorization, instead of sending this data via
multicast/broadcast, since considerable security work has been done already
in this unicast domain, which can enable highly secure access of session
description data. Accessing via unicast, however, will have different privacy
considerations, noted in <xref target="sect-11.2" format="default"/>. Note
that in general the multicast/broadcast stream is delayed with respect to
the unicast stream. Therefore, the session description protocol
<bcp14>SHOULD</bcp14> be time synchronized with the broadcast stream,
particularly if the session description contains security-related
information.</t>
<t>
In regard to FDT, there is one key difference for File Mode when using File
Template in EFDT, which avoids repeated sending of FDT-Instances and hence,
the corresponding threats noted in RFC 6726 <xref target="RFC6726"
format="default"/> do not apply directly to ROUTE in this case. The threat,
however, is shifted to the ALC/LCT headers, since they carry the additional
signaling that enables determining Content-Location and
File@Transfer-Length in this case. Hence, integrity protection
recommendations of ALC/LCT header <bcp14>SHOULD</bcp14> be considered with
higher emphasis in this case for ROUTE.</t>
<t>
Finally, attacks against the congestion control building block for Finally, attacks against the congestion control building block for
the case of ROUTE can impact the optional fast stream acquisition the case of ROUTE can impact the optional fast stream acquisition
specified in <xref target="sect-6.2"/>. Receivers SHOULD have robustness agai specified in <xref target="sect-6.2" format="default"/>. Receivers <bcp14>SHO
nst ULD</bcp14> have robustness against
timestamp values that are suspicious, e.g. by comparing the signaled timestamp values that are suspicious, e.g., by comparing the signaled
time in the LCT headers with the approximate time signaled by the time in the LCT headers with the approximate time signaled by the
MPD, and SHOULD discard outlying values. Additionally, receivers MUST MPD, and <bcp14>SHOULD</bcp14> discard outlying values. Additionally, receive
adhere to the expiry timelines as specified in <xref target="sect-6"/>. Integ rs <bcp14>MUST</bcp14>
rity adhere to the expiry timelines as specified in <xref target="sect-6" format="
protection mechanisms documented in RFC 6726 <xref target="RFC6726"/> SHOULD default"/>. Integrity
be used protection mechanisms documented in RFC 6726 <xref target="RFC6726" format="d
efault"/> <bcp14>SHOULD</bcp14> be used
to address this threat.</t> to address this threat.</t>
</section>
</section> <section anchor="sect-11.2" numbered="true" toc="default">
<name>Privacy Considerations</name>
<section title="Privacy Considerations" anchor="sect-11.2"><t> <t>
Encryption mechanisms recommended for security considerations in Encryption mechanisms recommended for security considerations in
<xref target="sect-11.1"/> SHOULD also be applied to enable privacy and prote ction <xref target="sect-11.1" format="default"/> <bcp14>SHOULD</bcp14> also be app lied to enable privacy and protection
from snooping attacks.</t> from snooping attacks.</t>
<t>
<t>
Since this protocol is primarily targeted for IP multicast/broadcast Since this protocol is primarily targeted for IP multicast/broadcast
environment where the end user is mostly listening, identity environments where the end user is mostly listening, identity
protection and user data retention considerations are more protected protection and user data retention considerations are more protected
than in the unicast case. Best practices for enabling privacy on IP than in the unicast case. Best practices for enabling privacy on IP
multicast/broadcast SHOULD be applied by the operators, e.g. multicast/broadcast <bcp14>SHOULD</bcp14> be applied by the operators, e.g.,
Recommendations for DNS Privacy Service Operators in RFC 8932 "<xref target="RFC8932" format="title"/>" in RFC 8932
<xref target="RFC8932"/>.</t> <xref target="RFC8932" format="default"/>.</t>
<t>
<t>
However, if clients access session description information via HTTPS, However, if clients access session description information via HTTPS,
the same privacy considerations and solutions SHALL apply to this the same privacy considerations and solutions <bcp14>SHALL</bcp14> apply to t
access as for regular HTTPS communication, an area which is very well his
access as for regular HTTPS communication, an area that is very well
studied and the concepts of which are being integrated directly into studied and the concepts of which are being integrated directly into
newer transport protocols such as IETF QUIC <xref target="RFC9000"/> enabling newer transport protocols such as IETF QUIC <xref target="RFC9000" format="de
HTTP/3 fault"/> enabling HTTP/3
<xref target="I-D.ietf-quic-http"/>. Hence such newer protocols SHOULD be use <xref target="I-D.ietf-quic-http" format="default"/>. Hence, such newer proto
d to foster privacy.</t> cols <bcp14>SHOULD</bcp14> be used to foster privacy.</t>
<t>
<t> Note that streaming services <bcp14>MAY</bcp14> contain content that may only
Note that streaming services MAY contain content that may only be be
accessed via DRM (digital rights management) systems. DRM systems accessed via DRM (digital rights management) systems. DRM systems
can prevent unauthorized access to content delivered via ROUTE.</t> can prevent unauthorized access to content delivered via ROUTE.</t>
</section>
</section>
<section anchor="sect-12" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.
</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-quic-http" to="HTTP3"/>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5651.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6726.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2557.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5445.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5052.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6363.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7231.xml"/>
<section title="IANA Considerations" anchor="sect-12"><t> <reference anchor="ATSCA331">
This document makes no requests for IANA action.</t> <front>
<title>Signaling, Delivery, Synchronization, and
Error Protection</title>
<author>
<organization>Advanced Television Systems Committee</organization>
</author>
<date month="March" year="2022"/>
</front>
<seriesInfo name="ATSC Standard" value="A/331:2022-03"/>
</reference>
</section> </references>
<references>
<name>Informative References</name>
</middle> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6968.xml"/>
<back> <reference anchor="DVBMABR">
<references title="Normative References"> <front>
&RFC2119; <title>
&RFC8174; Digital Video Broadcasting (DVB); Adaptive media streaming over IP
&RFC5651; multicast
&RFC5775; </title>
&RFC6726; <author>
&RFC6330; <organization>ETSI</organization>
&RFC3986; </author>
&RFC1952; <date month="November" year="2020"/>
&RFC2557; </front>
&RFC8551; <seriesInfo name="ETSI TS" value="103 769"/>
&RFC5445; <refcontent>version 1.1.1</refcontent>
&RFC5052;
&RFC6363;
&RFC7231;
<!-- </reference>
draft-zia-route-06-manual.txt(1823): Warning: Failed parsing a reference. Ar
e
all elements separated by commas (not periods, not just spaces)?:
[ATSCA331] ATSC A/331:2019, "ATSC Standard: Signaling, Delivery,
Synchronization, and Error Protection", June 2019.
-->
</references> <reference anchor="DASH" target="https://www.iso.org/standard/79329.html">
<references title="Informative References"> <front>
&RFC6968; <title>Information technology - Dynamic adaptive streaming over
HTTP (DASH) - Part 1: Media presentation description and segment
formats</title>
<author>
<organization>International Organization for Standardization</orga
nization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name="ISO/IEC" value="23009-1:2019"/>
<refcontent>Fourth edition</refcontent>
</reference>
<!-- <reference anchor="CMAF" target="https://www.iso.org/standard/71975.html">
draft-zia-route-06-manual.txt(1833): Warning: Failed parsing a reference. Ar <front>
e <title>Information technology -- Multimedia application format
all elements separated by commas (not periods, not just spaces)?: (MPEG-A) -- Part 19: Common media application format (CMAF) for
[DVBMABR] ETSI: "Digital Video Broadcasting (DVB); Adaptive media segmented media</title>
streaming over IP multicast", ETSI TS 103 769 V1.1.1 (2020-11) <author>
November 2020. <organization>International Organization for Standardization</organi
--> zation>
</author>
<date month="January" year="2018" />
</front>
<seriesInfo name="ISO/IEC FDIS" value="23000-19"/>
<refcontent>First edition</refcontent>
</reference>
<!-- <reference anchor="MBMS">
draft-zia-route-06-manual.txt(1837): Warning: Failed parsing a reference. Ar <front>
e <title>Universal Mobile Telecommunications Systems (UMTS); LTE; 5G;
all elements separated by commas (not periods, not just spaces)?: Multimedia Broadcast/Multicast Service (MBMS); Protocols and
[DASH] ISO/IEC 23009-1:2019: "Information technology - Dynamic codecs</title>
adaptive streaming over HTTP (DASH) - Part 1: Media presentation <author>
description and segment formats", Fourth edition, December 2019. <organization>ETSI</organization>
--> </author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="ETSI TS" value="126 346"/>
<refcontent>version 16.9.1</refcontent>
</reference>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
draft-zia-route-06-manual.txt(1841): Warning: Failed parsing a reference. Ar C.3740.xml"/>
e
all elements separated by commas (not periods, not just spaces)?:
[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.
-->
<!-- <reference anchor="I-D.ietf-quic-http">
draft-zia-route-06-manual.txt(1845): Warning: Failed parsing a reference. Ar <front>
e <title>Hypertext Transfer Protocol Version 3 (HTTP/3)
all elements separated by commas (not periods, not just spaces)?: </title>
[MBMS] ETSI: "Universal Mobile Telecommunications Systems (UMTS); <author fullname="Mike Bishop" role="editor"> </author>
LTE; Multimedia Broadcast/Multicast Service (MBMS); Protocols and <date month="February" day="2" year="2021"/>
codecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126 </front>
346 v13.3.0 (2016-01), European Telecommunications Standards <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
Institute, January 2016. <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-quic-http-
--> 34.txt"/>
</reference>
&RFC3740; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.ietf-quic-http; FC.9147.xml"/>
&RFC9000; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC6347; FC.9000.xml"/>
&RFC8932; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.ietf-tls-dtls13; FC.8932.xml"/>
</references>
<section title="Acknowledgments" anchor="sect-14"><t> </references>
As outlined in the introduction and in ROUTE concepts in <xref target="sect-9 </references>
"/>, <section anchor="sect-14" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
As outlined in the introduction and in ROUTE concepts in <xref target="sect-9
" format="default"/>,
the concepts specified in this document are the culmination of the the concepts specified in this document are the culmination of the
collaborative work of several experts and organizations over the collaborative work of several experts and organizations over the
years. The authors would especially like to acknowledge the work and years. The authors would especially like to acknowledge the work and
efforts of the following people and organizations to help realize the efforts of the following people and organizations to help realize the
technologies described in this document (in no specific order): Mike technologies described in this document (in no specific order): <contact full
Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm name="Mike
Luby"/>, <contact fullname="Kent Walker"/>, <contact fullname="Charles Lo"/>,
and other colleagues from Qualcomm
Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&amp;D.</t> Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&amp;D.</t>
</section>
</section> </back>
</rfc>
</back>
</rfc>
 End of changes. 302 change blocks. 
1791 lines changed or deleted 1860 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/