<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">zwsp "​"> <!ENTITYRFC5651 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5651.xml">nbhy "‑"> <!ENTITYRFC5775 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5775.xml"> <!ENTITY RFC6726 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml"> <!ENTITY RFC6330 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6330.xml"> <!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"> <!ENTITY RFC1952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml"> <!ENTITY RFC2557 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557.xml"> <!ENTITY RFC8551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"> <!ENTITY RFC5445 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5445.xml"> <!ENTITY RFC5052 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5052.xml"> <!ENTITY RFC6363 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6363.xml"> <!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"> <!ENTITY RFC6968 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6968.xml"> <!ENTITY RFC3740 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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.RFC.9000.xml"> <!ENTITY RFC6347 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"> <!ENTITY RFC8932 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8932.xml"> <!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml">wj "⁠"> ]> <rfcsubmissionType="IETF" docName="draft-zia-route-06"xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" category="info"ipr="trust200902"> <!-- 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"?>docName="draft-zia-route-06" number="9223" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <titleabbrev="ROUTE">Real-timeabbrev="ROUTE">Real-Time Transport ObjectdeliveryDelivery over Unidirectional Transport (ROUTE)</title> <seriesInfo name="RFC" value="9223"/> <author initials="W" surname="Zia" fullname="Waqar Zia"> <organization>Qualcomm CDMA Technologies GmbH</organization> <address> <postal> <street>Anzinger Str. 13</street> <city>Munich</city><region></region><region/> <code>81671</code> <country>Germany</country> </postal><phone></phone><phone/> <email>wzia@qti.qualcomm.com</email><uri></uri><uri/> </address> </author> <author initials="T" surname="Stockhammer" fullname="Thomas Stockhammer"> <organization>Qualcomm CDMA Technologies GmbH</organization> <address> <postal> <street>Anzinger Str. 13</street> <city>Munich</city><region></region><region/> <code>81671</code> <country>Germany</country> </postal><phone></phone><phone/> <email>tsto@qti.qualcomm.com</email><uri></uri><uri/> </address> </author> <author initials="L" surname="Chaponniere" fullname="Lenaig Chaponniere"> <organization>Qualcomm Technologies Inc.</organization> <address> <postal> <street>5775 Morehouse Drive</street> <city>San Diego</city> <region>CA</region> <code>92121</code><country>USA</country><country>United States of America</country> </postal><phone></phone><phone/> <email>lguellec@qti.qualcomm.com</email><uri></uri><uri/> </address> </author> <author initials="G" surname="Mandyam" fullname="Giridhar Mandyam"> <organization>Qualcomm Technologies Inc.</organization> <address> <postal> <street>5775 Morehouse Drive</street> <city>San Diego</city> <region>CA</region> <code>92121</code><country>USA</country><country>United States of America</country> </postal><phone></phone><phone/> <email>mandyam@qti.qualcomm.com</email><uri></uri><uri/> </address> </author> <author initials="M" surname="Luby" fullname="Michael Luby"> <organization>BitRipple, Inc.</organization> <address> <postal> <street>1133 Miller Ave</street> <city>Berkeley</city> <region>CA</region> <code>94708</code><country>USA</country><country>United States of America</country> </postal><phone></phone><phone/> <email>luby@bitripple.com</email><uri></uri><uri/> </address> </author> <dateyear="2022" month="February"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><t>month="April" year="2022"/> <keyword>Multicast </keyword> <keyword>Broadcast </keyword> <keyword>FEC </keyword> <keyword>DASH </keyword> <keyword>HLS </keyword> <keyword>FLUTE </keyword> <abstract> <t> The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol(ROUTE protocol)is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data toreceivers,receivers; for example, it can be a file,oraDASHDynamic Adaptive Streaming over HTTP (DASH) orHLSHTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications.</t> <t> The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run overUDP/IPUDP/IP, including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer,e.g.e.g., to providesecuritysecurity, it can leverage IP security protocols such asIPSec.</t>IPsec.</t> <t> This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol(e.g.(e.g., by adding or constraining some features).</t> <t> This is not an IETF specification and does not have IETF consensus.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><section title="Overview" anchor="sect-1.1"><t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <section anchor="sect-1.1" numbered="true" toc="default"> <name>Overview</name> <t> The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol(ROUTE protocol)can be used for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Unidirectional transport in this document has identical meaningasto that in RFC 6726 <xreftarget="RFC6726"/>,target="RFC6726" format="default"/>, i.e., transport in the direction of receiver(s) from a sender. The robustness is enabled by a built-inmechanism e.g.mechanism, e.g., signaling for loss detection, enabling loss recovery, and optionally integrating application-layer Forward Error Correction (FEC).</t> <t> Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file,oran MPEG Dynamic Adaptive Streaming over HTTP(DASH)[DASH](DASH) <xref target="DASH"/> video segment, a WAV audio clip, an MPEG Common Media Application Format (CMAF)[CMAF]<xref target="CMAF"/> addressable resource, an MPEG-4 video clip, etc.</t> <t> The ROUTE protocol is designed to enable delivery of sequences of related Application Objects in a timely manner to receivers, e.g., a sequence of DASH video segments associated to a Representation or a sequence of CMAF addressable resources associated to a CMAF Track. The applications of this protocol target services enabled on media consumption devices such as smartphones, tablets, televisionsetssets, and so on. Most of these applications are real-time in the sense that they are sensitive to andreplyrely upon such timely reception of data. The ROUTE protocol also supports chunked delivery of real-time Application Objects to enablelow latencylow-latency streaming applications (similar in its properties to chunked delivery using HTTP). The protocol also enables low-latency delivery of DASH and Apple HTTP Live Streaming (HLS) content with CMAF Chunks.</t> <t> Content not intended for rendering in real time as it is receivede.g.(e.g., a downloadedapplication, orapplication), a file comprising continuous or discrete media and belonging to an app-based feature, or a file containing (opaque) data to be consumed by a Digital Rights Management (DRM) system client can also be delivered by ROUTE.</t> <t> The ROUTE protocol supports a cachingmodel,model where Application Objects are recovered into a cache at the receiver and may be made available to applications via standard HTTP requests from the cache. Many current day applications rely on using HTTP to accesscontent, and hencecontent; hence, this approach enables such applications in broadcast/multicast environments.</t> <t> ROUTE is aligned withFLUTEFile Delivery over Unidirectional Transport (FLUTE) as defined in RFC 6726 <xreftarget="RFC6726"/>target="RFC6726" format="default"/> as well as the extensions defined inMBMS [MBMS],Multimedia Broadcast/Multicast Service (MBMS) <xref target="MBMS"/>, but it also makes use of some principles of FCAST (Object Delivery for theALCAsynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols) as defined in RFC 6968 <xreftarget="RFC6968"/>;target="RFC6968" format="default"/>; 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 several of the basic FLUTE protocol features, as referred to by this document, certain optimizations and restrictions are added that enable optimized support for real-time delivery of media data; hence, the name of the protocol. Among others, the source ROUTE protocol enables or enhances the following functionalities:</t><t><list style="symbols"><t>Real-time<ul spacing="normal"> <li>Real-time delivery of object-based mediadata</t> <t>Flexibledata</li> <li>Flexible packetization, including enabling media-aware packetization as well as transport-aware packetization of deliveryobjects</t> <t>Independenceobjects</li> <li>Independence of Application Objects and delivery objects,i.e.i.e., a delivery object may be a part of a file or may be a group offiles.</t> </list> </t>files.</li> </ul> <t> Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE protocol integrated with an ATSC 3.0 services layer. That specification will be referred to as ATSC-ROUTE[ATSCA331]<xref target="ATSCA331"/> for the remainder of this document.DVBDigital Video Broadcasting (DVB) has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR)[DVBMABR].<xref target="DVBMABR"/>. This document specifies the Application Object delivery aspects (delivery protocol) for such services, as the corresponding delivery protocol could be used as a reference by a variety of services by specifying profiles of ROUTE in their respective fora,e.g.e.g., by adding new optional features atop or by restricting various optional features specified in this document in a specific service standard.HenceHence, in the context of this document, the aforementioned ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition of profiles by the services also have to give due consideration to compatibility issues, and some related guidelines are also provided in this document.</t> <t> This document is not an IETF specification and does not have IETF consensus. It is provided here to aid the production of interoperable implementations.</t> </section> <sectiontitle="Protocolanchor="sect-1.2" numbered="true" toc="default"> <name>Protocol Stack forROUTE" anchor="sect-1.2"><t>ROUTE</name> <t> ROUTE delivers Application Objects such as MPEG DASH or HLS segments and optionally the associated repair data, operating over UDP/IP networks, as depicted inFigure 1.<xref target="protocol-layering"/>. The session metadata signaling to realize a ROUTE session as specified in this documentMAY<bcp14>MAY</bcp14> be deliveredout-of-bandout of band orin-bandin band as well. Since ROUTE delivers objects in an application cache at the receiver from where the application can access them using HTTP, an application like DASH may use its standardized unicast streaming mechanisms in conjunction with ROUTE over broadcast/multicast to augment the services. </t><figure title="Protocol Layering" anchor="fig-1"> <artwork><![CDATA[ +-----------------------------------+ |Application<table anchor="protocol-layering"> <name>Protocol Layering</name> <tbody> <tr> <td align="center">Application (DASH and HLSsegments,| |segments, CMAFchunksChunks, etc.)| +-----------------------------------+ | ROUTE | +-----------------------------------+ | UDP | +-----------------------------------+ | IP | +-----------------------------------+ ]]> </artwork> </figure> </section> <section title="Data Model" anchor="sect-1.3"><t></td> </tr> <tr> <td align="center">ROUTE </td> </tr> <tr> <td align="center">UDP </td> </tr> <tr> <td align="center">IP </td> </tr> </tbody> </table> </section> <section anchor="sect-1.3" numbered="true" toc="default"> <name>Data Model</name> <t> The ROUTE data model is constituted by the following key concepts.<list style="hanging" hangIndent="6"> <t hangText="Application Object:"></t> <dl newline="false" spacing="normal" indent="6"> <dt>Application Object:</dt> <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,ora DASH video segment, a WAV audio clip, an MPEG-4 video clip,etc.</t> <t hangText="Delivery Object:"> Anetc.</dd> <dt>Delivery Object:</dt> <dd> an object on course of delivery to the application from the ROUTE sender to ROUTEreceiver.</t> <t hangText="Transport Object:">receiver.</dd> <dt>Transport Object:</dt> <dd> an object identified by the Transport Object Identifier(TOI)in(TOI) in RFC 5651 <xreftarget="RFC5651"/>.target="RFC5651" format="default"/>. ItMAY<bcp14>MAY</bcp14> beaeither a source or a repair object, depending on if it is carried by a Source Flow or a Repair Flow,respectively.</t> <t hangText="Transport Session:"> Anrespectively.</dd> <dt>Transport Session:</dt> <dd>a Layered Coding Transport (LCT) channel, as defined by RFC 5651 <xreftarget="RFC5651"/>.target="RFC5651" format="default"/>. A Transportsession SHALLSession <bcp14>SHALL</bcp14> be uniquely identified by a unique Transport Session Identifier (TSI) value in the LCT header. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. TransportsessionsSessions are a subset of a ROUTE session. For media delivery, a Transport Session would typically carry a media component, forexampleexample, a DASH Representation. Within eachtransport session,Transport Session, one or more objects are carried, typically objects that are related,e.g.e.g., DASHSegmentssegments associated to oneRepresentation.</t> <t hangText="ROUTE Session:"> AnRepresentation.</dd> <dt>ROUTE Session:</dt> <dd>an ensemble or multiplex of one or more Transport Sessions. Each ROUTESessionsession is associated with an IP address/port combination. A ROUTE session typically carries one or more media components of streaming mediae.g.e.g., Representations associated with a DASH MediaPresentation.</t> <t hangText="Source Flow:">Presentation.</dd> <dt>Source Flow:</dt> <dd>a TransportsessionSession carrying source data. Source Flow is independent of therepairRepair Flow,i.e.i.e., the Source FlowMAY<bcp14>MAY</bcp14> be used by a ROUTE receiver without the ROUTE RepairFlows.</t> <t hangText="Repair Flow:">Flows.</dd> <dt>Repair Flow:</dt> <dd>a TransportsessionSession carrying repair data for one or more SourceFlows.</t> </list> </t>Flows.</dd> </dl> </section> <sectiontitle="Architectureanchor="sect-1.4" numbered="true" toc="default"> <name>Architecture and Scope ofSpecification" anchor="sect-1.4"><t>Specification</name> <t> The scope of the ROUTE protocol is to enable robust and real-time transport of delivery objects using LCT packets. This architecture is depicted inFigure 2.</t><xref target="architecture-diagram"/>.</t> <t> The normative aspects of the ROUTE protocol focus on the following aspects:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li>The format of the LCT packets that carry the transportobjects.</t> <t>Theobjects.</li> <li>The robust transport of the delivery object using a repair protocol based on Forward Error Correction(FEC).</t> <t>The(FEC).</li> <li>The definition and possible carriage of object metadata along with the delivery objects. Metadata may be conveyed in LCT packets and/or separateobjects.</t> <t>Theobjects.</li> <li>The ROUTE session, LCTchannelchannel, and delivery object description provided as service metadata signaling to enable the reception ofobjects.</t> <t>Theobjects.</li> <li>The normative aspects (formats, semantics) of the delivery objects conveyed as a content manifest to be delivered along with the objects to optimize the performance for specificapplications;applications e.g., real-time delivery. The objects and manifest are made available to the application through an Application Object cache. The interface of this cache to the application is not specified in thisdocument, howeverdocument; however, it will typically be enabled by the application acting as an HTTPClientclient and the cache as the HTTPserver.</t> </list> </t>server.</li> </ul> <figuretitle="Architecture/functional block diagram" anchor="fig-2"><artwork><![CDATA[anchor="architecture-diagram"> <name>Architecture/Functional Block Diagram</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Application Objects Application to application Objects from ^ an application +--------------------------------------------+ + | ROUTE Receiver | | | | +------+------+ | | | | Application | | | | | Object Cache| | | | +------+------+ | | LCT over| +---------------+ ^ | v UDP/IP | | Source object | +---------+ | | +----+---+ | +->+ recovery +--+ Repair +-+ | | ROUTE | | | +---------------+ +----+----+ | | Sender +----------+ ^ | +----+---+ | | | | | | | +---------------+ | | | | | | Repair object | | | | | +->+ recovery +-------+ | +----------->+ +---------------+ | ROUTE | | Metadata +--------------------------------------------+ ]]></artwork> </figure> </section> <sectiontitle="Intellectual Property" anchor="sect-1.5"><t> The protocol described in this document may be subject to intellectual property rights disclosed to the IETFanchor="sect-1.6" numbered="true" toc="default"> <name>Conventions Used inaccordance 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>This Document</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <sectiontitle="ROUTEanchor="sect-2" numbered="true" toc="default"> <name>ROUTE PacketFormat" anchor="sect-2"><section title="PacketFormat</name> <section anchor="sect-2.1" numbered="true" toc="default"> <name>Packet Structure and HeaderFields" anchor="sect-2.1"><t>Fields</name> <t> The packet format used by ROUTE Source Flows and Repair Flows follows the ALC packet format specified in RFC 5775 <xreftarget="RFC5775"/>,target="RFC5775" format="default"/> with the UDP header followed by the default LCT header and the source FEC Payload ID followed by the packet payload. The overall ROUTE packet format is as depicted inFigure 3 below.</t><xref target="route-packet-format"/>.</t> <figuretitle="Overallanchor="route-packet-format"> <name>Overall ROUTEpacket format" anchor="fig-3"><artwork><![CDATA[Packet Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Default LCT header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t> The Default LCT header is as defined in the LCT building block in RFC 5651 <xreftarget="RFC5651"/>.</t>target="RFC5651" format="default"/>.</t> <t> The LCT packet header fieldsSHALL<bcp14>SHALL</bcp14> be used as defined by the LCT building block in RFC 5651 <xreftarget="RFC5651"/>.target="RFC5651" format="default"/>. The semantics and usage of the following LCT header fieldsSHALL<bcp14>SHALL</bcp14> be further constrained in ROUTE as follows:<list style="hanging" hangIndent="6"> <t hangText="Version</t> <dl newline="false" spacing="normal"> <dt>Version number(V):">(V):</dt> <dd> This 4-bit field indicates the protocol version number. The version numberSHALL<bcp14>SHALL</bcp14> be set to '0001', as specified in RFC 5651 <xreftarget="RFC5651"/>.</t> <t hangText="Congestiontarget="RFC5651" format="default"/>.</dd> <dt>Congestion Control flag (C)field:">field:</dt> <dd> This 2-bit field, as defined in RFC 5651 <xreftarget="RFC5651"/>, SHALLtarget="RFC5651" format="default"/>, <bcp14>SHALL</bcp14> be set to'00'.</t> <t hangText="Protocol-Specific'00'.</dd> <dt>Protocol-Specific Indication(PSI):">(PSI):</dt> <dd> The most significant bit of thistwo bit2-bit flag is called the Source Packet Indicator (SPI) and indicates whether the current packet is a source packet orana FEC repair packet. The SPISHALL<bcp14>SHALL</bcp14> be set to '1' to indicate a sourcepacket,packet andSHALL<bcp14>SHALL</bcp14> bet set to '0' to indicate a repairpacket.</t> <t hangText="Transportpacket.</dd> <dt>Transport Session Identifier flag(S):">(S):</dt> <dd> This 1-bit fieldSHALL<bcp14>SHALL</bcp14> be set to '1' to indicate a 32-bit word in the TSIfield.</t> <t hangText="Transportfield.</dd> <dt>Transport Object Identifier flag(O):">(O):</dt> <dd> This 2-bit fieldSHALL<bcp14>SHALL</bcp14> be set to '01' to indicate the number of full 32-bit words in the TOIfield.</t> <t hangText="Half-wordfield.</dd> <dt>Half-word flag(H):">(H):</dt> <dd> This 1-bit fieldSHALL<bcp14>SHALL</bcp14> be set to '0' to indicate that no half-word field sizes areused.</t> <t hangText="Codepoint (CP):">used.</dd> <dt>Codepoint (CP):</dt> <dd> This 8-bit field is used to indicate the type of the payload that is carried by thispacket, andpacket; for ROUTE, it is defined as shown below to indicate the type of delivery object carried in the payload of the associated ROUTE packet. Theremaining,remaining unmapped Codepoint values can be used by a service using ROUTE. In this case, the Codepoint valuesSHALL<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[DASH].<xref target="DASH"/>. The various modes of operation in the table (File/Entity/Package Mode) are specified in <xreftarget="sect-4"/>.target="sect-4" format="default"/>. The table also lists a Codepoint value range that is reserved for future service-specificuses.</t> </list> </t> <figure><artwork><![CDATA[ Codepointuses.</dd> </dl> <table anchor="codepoint-values"> <name>Codepoint Values</name> <thead> <tr> <th>Codepoint value| Semantics ---------------------------------------------------- 0 | Reserved</th> <th>Semantics </th> </tr> </thead> <tbody> <tr> <td>0 </td> <td>Reserved (not used)1 | Non</td> </tr> <tr> <td>1 </td> <td>Non Real Time (NRT) - File Mode2 | NRT</td> </tr> <tr> <td>2 </td> <td>NRT - Entity Mode3 | NRT</td> </tr> <tr> <td>3 </td> <td>NRT - Unsigned Package Mode4 | NRT</td> </tr> <tr> <td>4 </td> <td>NRT - Signed Package Mode5 | New</td> </tr> <tr> <td>5 </td> <td>New IS, timeline changed6 | New</td> </tr> <tr> <td>6 </td> <td>New IS, timeline continued7 | Redundant</td> </tr> <tr> <td>7 </td> <td>Redundant IS8 | Media</td> </tr> <tr> <td>8 </td> <td>Media Segment, File Mode9 | Media</td> </tr> <tr> <td>9 </td> <td>Media Segment, Entity Mode10 | Media</td> </tr> <tr> <td>10 </td> <td>Media Segment, File Mode with CMAF Random|AccessChunk 11chunk </td> </tr> <tr> <td>11 - 255| Reserved,</td> <td>Reserved, service-specific]]></artwork> </figure> <t> <list style="hanging" hangIndent="6"> <t hangText="Congestion</td> </tr> </tbody> </table> <dl newline="false" spacing="normal"> <dt>Congestion Control Information(CCI):">(CCI):</dt> <dd> For packets carrying DASH segments,MAYCCI <bcp14>MAY</bcp14> convey the 32-bit earliest presentation time[DASH]<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 <xreftarget="sect-6.2"/>). Otherwisetarget="sect-6.2" format="default"/>). Otherwise, this fieldSHALL<bcp14>SHALL</bcp14> be set to0.</t> <t hangText="Transport0.</dd> <dt>Transport Session Identifier(TSI):">(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 = 0SHALL<bcp14>SHALL</bcp14> only be used for service-specificsignaling.</t> <t hangText="Transportsignaling.</dd> <dt>Transport Object Identifier(TOI):">(TOI):</dt> <dd> This 32-bit fieldSHALL<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).</t> </list> </t>(FDT).</dd> </dl> </section> <sectiontitle="LCTanchor="sect-2.2" numbered="true" toc="default"> <name>LCT HeaderExtensions" anchor="sect-2.2"><t>Extensions</name> <t> The following LCT header extensions are defined or used by ROUTE:<list style="hanging" hangIndent="6"> <t hangText="EXT_FTI:"></t> <dl newline="false" spacing="normal"> <dt>EXT_FTI:</dt> <dd> as specified in RFC5775.</t> <t hangText="EXT_TOL:"> The5775.</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[ATSCA331]<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(B)flag (B) <xreftarget="RFC5651"/>.</t> <t>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(B) flag.flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport objectlength.</t> <t hangText="EXT_TIME Header:">length.</dd> <dt>EXT_TIME Header:</dt> <dd> as specified in RFC 5651 <xreftarget="RFC5651"/>.target="RFC5651" format="default"/>. The Sender Current TimeSHALL<bcp14>SHALL</bcp14> be signaled usingEXT_TIME.</t> </list> </t>EXT_TIME.</dd> </dl> </section> <sectiontitle="FECanchor="sect-2.3" numbered="true" toc="default"> <name>FEC Payload ID for SourceFlows" anchor="sect-2.3"><t>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 thatSHALL<bcp14>SHALL</bcp14> express thestart_offset,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 objectSHALL<bcp14>SHALL</bcp14> be set to 0.Figure 4<xref target="start_offset"/> shows the 32-bit start_offset field.</t> <figuretitle="FECanchor="start_offset"> <name>FEC Payload ID for SourceFlows." anchor="fig-4."><artwork><![CDATA[Flows</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </section> <sectiontitle="FECanchor="sect-2.4" numbered="true" toc="default"> <name>FEC Payload ID for RepairFlows" anchor="sect-2.4"><t>Flows</name> <t> FEC Payload ID for Repair Flows is specified in RFC 6330 <xreftarget="RFC6330"/>.</t>target="RFC6330" format="default"/>.</t> </section> </section> <sectiontitle="Session Metadata" anchor="sect-3"><t>anchor="sect-3" numbered="true" toc="default"> <name>Session Metadata</name> <t> The required session metadata for Source and Repair Flows is specified in the following sections. The list specified here is not exhaustive; a serviceMAY<bcp14>MAY</bcp14> signal more metadata to meet its needs. The data format is also not specified beyond its cardinality; the exact format of specifying the data is left for the service,e.g.e.g., by using XML encoding format, as has been done by[DVBMABR]<xref target="DVBMABR"/> and[ATSCA331].<xref target="ATSCA331"/>. It is specified in the following if an attribute is mandatory (m), conditional mandatory (cm) or optional (o) to realize a basic ROUTE session. A mandatoryfiled SHALLfield <bcp14>SHALL</bcp14> always be present in the session metadata, and a conditional mandatory fieldSHALL<bcp14>SHALL</bcp14> be present if the specified condition is true. The delivery of the session metadata to the ROUTE receiver is beyond the scope of this document.</t> <sectiontitle="Generic Metadata" anchor="sect-3.1"><t>anchor="sect-3.1" numbered="true" toc="default"> <name>Generic Metadata</name> <t> Generic metadata is applicable to both Source and Repair Flows as follows. Before a receiver can join a ROUTE session, the receiver needs to obtain this generic metadata that contains at least the following information:<list style="hanging" hangIndent="6"> <t hangText="ROUTE</t> <dl newline="false" spacing="normal"> <dt>ROUTE version number(m):"> The(m):</dt> <dd> the version number of ROUTE used in this session. The version number conforming to this documentSHALL<bcp14>SHALL</bcp14> be1.</t> <t hangText="Connection1.</dd> <dt>Connection ID(m):">(m):</dt> <dd> the unique identifier of a Connection, usually consisting of the following 4-tuple: source IP address/source port number, destination IP address/destination port number. The IP addresses can be IPv4 or IPv6addresses,addresses depending upon which IP version is used by thedeployment.</t> </list> </t>deployment.</dd> </dl> </section> <sectiontitle="Sessionanchor="sect-3.2" numbered="true" toc="default"> <name>Session Metadata for SourceFlows" anchor="sect-3.2"><t>Flows</name> <t> stsi (m): The LCT TSI value corresponding to thetransport sessionTransport Session for the Source Flow.<list style="hanging" hangIndent="6"> <t hangText="rt (o):"></t> <dl newline="false" spacing="normal"> <dt>rt (o):</dt> <dd> A Boolean flagwhich SHALLthat <bcp14>SHALL</bcp14> indicate whether the content component carried by this Source Flow corresponds to real-time streamingmedia,media or non-real-time content. When set to "true", itSHALL<bcp14>SHALL</bcp14> be an indication of real-time content, and when absent or set to "false", itSHALL<bcp14>SHALL</bcp14> be an indication of non-real-time (NRT)content.</t> <t hangText="minBufferSize (o):">content.</dd> <dt>minBufferSize (o):</dt> <dd> A 32-bit unsigned integerwhich SHALLthat <bcp14>SHALL</bcp14> represent, in kilobytes, the minimum required storage size of the receiver transportbuffer,buffer for the parent LCT channel of this Source Flow. The buffer holds the data belonging to aSource Object tillsource object until its complete reception. This attribute is only applicable when rt ="true".</t> <t>A"true".</dd> <dt/> <dd>A servicewhichthat chooses not to signal this attribute relies on the receiver implementation, which must discard the received data beyond its buffering capability. Such discarding of data will impact the servicequality.</t> <t hangText="EFDT (cm):"> whenquality.</dd> <dt>EFDT (cm):</dt> <dd> When present,SHALL<bcp14>SHALL</bcp14> contain a single instance of an FDT-Instance element per RFC 6726 FLUTE <xreftarget="RFC6726"/>,target="RFC6726" format="default"/>, whichMAY<bcp14>MAY</bcp14> contain the optional FDT extensions as defined in <xreftarget="sect-4.1"/>.target="sect-4.1" format="default"/>. The optional EFDT elementMAY<bcp14>MAY</bcp14> only be present for File Mode of delivery. In File Mode, itSHALL<bcp14>SHALL</bcp14> be present if this Source Flow transports streaming mediasegments.</t> <t hangText="contentType (o):">segments.</dd> <dt>contentType (o):</dt> <dd> A string thatSHALL<bcp14>SHALL</bcp14> represent the media type for the media content. ItSHALL<bcp14>SHALL</bcp14> obey the semantics of the Content-Type header as specified by the HTTP/1.1 protocol in RFC 7231 <xreftarget="RFC7231"/>.target="RFC7231" format="default"/>. This document does not define any new contentType strings. In its absence, thesignallingsignaling of media type for the media content is beyond the scope of thisdocument.</t> <t hangText="applicationMapping (m):">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 DASHrepresentationRepresentation from a Media Presentation Description (MPD), the latter identified by its Representation and corresponding Adaptation Set and PeriodIDs.</t> </list> </t>IDs.</dd> </dl> </section> <sectiontitle="Session metadataanchor="sect-3.3" numbered="true" toc="default"> <name>Session Metadata for RepairFlows" anchor="sect-3.3"><t> minBuffSizeFlows</name> <dl> <dt>minBuffSize (o): </dt> <dd> <t> A 32-bit unsigned integer whose valueSHALL<bcp14>SHALL</bcp14> represent a required size of the receiver transport buffer forAL-FECAL&nbhy;FEC decoding processing. When present, this attributeSHALL<bcp14>SHALL</bcp14> indicate the minimum buffer size that is required to handle all associated objects that are assigned to asuper-object i.e.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-FECprotection.</t>protection. </t> <t> A servicewhichthat 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><t> fecOTI</dd> <dt>fecOTI (m):A</dt> <dd>A parameter consisting of the concatenation of Common and Scheme-Specific FEC Object Transmission Information (FEC OTI) as defined in Sections3.3.2<xref target="RFC6330" sectionFormat="bare" section="3.3.2"/> and3.3.3<xref target="RFC6330" sectionFormat="bare" section="3.3.3"/> ofRFC 6330<xreftarget="RFC6330"/>,target="RFC6330" format="default"/> andwhichthat corresponds to the delivery objects carried in the Source Flow to which this Repair Flow is associated, with the followingqualification. Thequalification: 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 thatthe FEC transport object sizeiseitherunknown,is unknown or cannot be represented by this attribute. In other words, for the all-zeroes format, the delivery objects in the SourceflowFlow correspond to streamingcontent -content, either a live Service whereby content encoding has not yet occurred at the time this session data wasgenerated,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</dd> <dt>ptsi (m): </dt> <dd>TSI value(s) of each Source Flow protected by this RepairFlow.</t> <t hangText="mappingTOIx (o):"> ValuesFlow. </dd> <dt>mappingTOIx (o): </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 valuesMAY<bcp14>MAY</bcp14> be provided for each protected SourceFlow,Flow depending upon the usage of FEC(super-)object.</t> <t hangText="mappingTOIy (o):"> The(super-)object. </dd> <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".</t> </list> </t>"0". </dd> </dl> </section> </section> <sectiontitle="Deliveryanchor="sect-4" numbered="true" toc="default"> <name>Delivery ObjectMode" anchor="sect-4"><t>Mode</name> <t> ROUTE provides several different delivery object modes, and one of these modes maysuitesuit the application needs better for a giventransport session.Transport Session. A delivery object isself-containedself contained for the application, typically associated with certain properties,metadatametadata, and timing-related informationthat are of relevance forrelevant to the application. The signaling of the delivery object mode is done on an objectbasedbasis using Codepoint as specified in <xreftarget="sect-2.1"/>.</t>target="sect-2.1" format="default"/>.</t> <sectiontitle="File Mode" anchor="sect-4.1"><t>anchor="sect-4.1" numbered="true" toc="default"> <name>File Mode</name> <t> FilemodeMode uses an out-of-band Extended FDT(EDFT)(EFDT) signaling for recovery of delivery objects with the following extensions and considerations.</t> <sectiontitle="Extensionsanchor="sect-4.1.1" numbered="true" toc="default"> <name>Extensions toFDT" anchor="sect-4.1.1"><t> FollowingFDT</name> <t> The following extensions are specified toFDTFDT, as specified in RFC 6726 <xreftarget="RFC6726"/>.target="RFC6726" format="default"/>. An ExtendedFDT InstanceFDT-Instance is an instance of FLUTEFDTFDT, as specified in <xreftarget="RFC6726"/>,target="RFC6726" format="default"/>, plus optionally one or more of the followingextensions. <list style="hanging" hangIndent="6"> <t hangText="efdtVersion:">extensions: </t> <dl newline="false" spacing="normal"> <dt>efdtVersion:</dt> <dd> A value thatSHALL<bcp14>SHALL</bcp14> represent the version of this ExtendedFDT Instance.</t> <t hangText="maxExpiresDelta:"> LetFDT-Instance.</dd> <dt>maxExpiresDelta:</dt> <dd>Let "tp" represent the wall clock time at the receiver when the receiver acquires the first ROUTE packet carrying data of the object described by this ExtendedFDT Instance.FDT-Instance. maxExpiresDelta, when present,SHALL<bcp14>SHALL</bcp14> represent a time intervalwhichthat when added to "tp"SHALL<bcp14>SHALL</bcp14> represent the expiration time of the associated ExtendedFDT InstanceFDT-Instance "te". The time interval is expressed in number of seconds. When maxExpiresDelta is not present, the expiration time of the ExtendedFDT Instance SHALLFDT-Instance <bcp14>SHALL</bcp14> be given by the sum of a) the value of the ERT field in the EXT_TIME LCT header extension in the first ROUTE packet carrying data of that file, and b) the current receiver time when parsing the packet header of that ROUTE packet. See Sections5.4<xref target="sect-5.4" format="counter"/> and6.3.3<xref target="sect-6.3.3" format="counter"/> on additional rules for deriving the ExtendedFDT InstanceFDT-Instance expiration time.Hence te__=Hence, <tt>te = tp +maxExpiresDelta</t> <t hangText="maxTransportSize:">maxExpiresDelta</tt> </dd> <dt>maxTransportSize:</dt> <dd> An attribute thatSHALL<bcp14>SHALL</bcp14> represent the maximum transport size in bytes of any delivery object described by this ExtendedFDT Instance.FDT-Instance. This attributeSHALL<bcp14>SHALL</bcp14> be present if a) the fileTemplate is present in ExtendedFDT-Instance;FDT-Instance, or b) one or more File elements, if present in this ExtendedFDT Instance,FDT-Instance, do not include the Transfer-Length attribute. When maxTransportSize is not present, the maximum transport size is not signaled, while othersignallingsignaling such as the Transfer-Length attribute signal the exacttransfer lengthTransfer Length of theobject.</t> <t hangText="fileTemplate:"> Aobject.</dd> <dt>fileTemplate:</dt> <dd>A string value, which when present and in conjunction with parameter substitution, is used in deriving the Content-Locationattribute,attribute for the delivery object described by this ExtendedFDT Instance.FDT-Instance. ItSHALL<bcp14>SHALL</bcp14> include the "$TOI$" identifier. Each identifierMAY<bcp14>MAY</bcp14> be suffixed as needed by specific filenames,names within the enclosing '$' characters following this prototype:%0[width]d</t> </list> </t><tt>%0[width]d</tt> </dd> </dl> <t> The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the resultSHALL<bcp14>SHALL</bcp14> be padded with leading zeroes. The value is not truncated even if the result is larger. When no format tag is present, a default format tag with width=1SHALL<bcp14>SHALL</bcp14> be used.</t> <t> Strings other than identifiersSHALL<bcp14>SHALL</bcp14> only contain characters that are permitted within URIs according to RFC 3986 <xreftarget="RFC3986"/>.</t>target="RFC3986" format="default"/>.</t> <t>$$ Is<tt>$$</tt> is an escape sequence in fileTemplate value,i.e.i.e., "$$" is non-recursively replaced with a single"$"</t>"$".</t> <t> The usage of fileTemplate is described in Sender and Receiver operations in Sections5.4<xref target="sect-5.4" format="counter"/> and6.3,<xref target="sect-6.3" format="counter"/>, respectively.</t> </section> <sectiontitle="Constraintsanchor="sect-4.1.2" numbered="true" toc="default"> <name>Constraints on ExtendedFDT" anchor="sect-4.1.2"><t>FDT</name> <t> The ExtendedFDT Instance SHALLFDT-Instance <bcp14>SHALL</bcp14> conform to anFDT InstanceFDT-Instance according to RFC 6726 <xreftarget="RFC6726"/>,target="RFC6726" format="default"/> with the following constraints: at least one File element and the @Expires attributeSHALL<bcp14>SHALL</bcp14> be present.</t> <t> Content encodingMAY<bcp14>MAY</bcp14> be used for delivery of any file described by an FDT-Instance.File element in the ExtendedFDT Instance.FDT-Instance. The content encoding defined in the present document is gzip <xreftarget="RFC1952"/>.target="RFC1952" format="default"/>. When content encoding is used, the File@Content-Encoding and File@Content-Length attributesSHALL<bcp14>SHALL</bcp14> be present in the ExtendedFDT Instance.</t>FDT-Instance.</t> </section> </section> <sectiontitle="Entity Mode" anchor="sect-4.2"><t>anchor="sect-4.2" numbered="true" toc="default"> <name>Entity Mode</name> <t> For Entity Mode, the following applies:</t><t><list style="symbols"><t>Delivery Object<ul spacing="normal"> <li>Delivery object metadataSHALL<bcp14>SHALL</bcp14> be expressed in the form of entity headers as defined in HTTP/1.1,andwhich correspond to one or more of the representation header fields, payload headerfieldsfields, and response header fields as defined in Sections3.1, 3.3<xref target="RFC7231" section="3.1" sectionFormat="bare"/>, <xref target="RFC7231" section="3.3" sectionFormat="bare"/>, and7,<xref target="RFC7231" section="7" sectionFormat="bare"/>, respectively, ofRFC 7231. Additionally, a Digest HTTP response header<xreftarget="RFC7231"/> MAY be included to enable a receiver to verify the integrity of the multicast transport object.</t> <t>Thetarget="RFC7231"/>.</li> <li>The entity headers sent along with the delivery object provide all information about that multicast transportobject.</t>object.</li> <li> <t>Sending a media object (if the object is chunked) in Entity Mode may result in one of the followingoptions:<list style="symbols"><t>Ifoptions:</t> <ul spacing="normal"> <li><t>If the length of the chunked object is known at the sender, the ROUTE Entity Mode delivery objectMAY<bcp14>MAY</bcp14> be sent without using HTTP/1.1 chunked transfer coding,i.e.i.e., the object starts with an HTTP header containing the Content Lengthfield,field followed by the concatenation of CMAFchunks:</t> </list> </t> </list> </t> <figure><artwork><![CDATA[Chunks:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ |HTTP Header+Length||---chunk ----||---chunk ----||---chunk -- --||---chunk ----| ]]></artwork></figure> <t><list style="empty" hangIndent="3"> <t><list style="symbols"><t>If</li> <li> <t>If the length of the chunked object is unknown at the sender when starting to send the object, HTTP/1.1 chunked transfer coding formatSHALL<bcp14>SHALL</bcp14> be used:</t></list> </t> </list> </t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ |HTTP Header||Separator+Length||---chunk ---- ||Separator+Length||---chunk ----||Separator+Length||---chunk ----||Separator+Length||---chunk ----||Separator+Length=0| ]]></artwork></figure> <t><list style="hanging" hangIndent="5"><t> Note,<t>Note, however, that it is not required to send a CMAFchunkChunk in exactly one HTTP chunk.</t></list> </t></li> </ul> </li> </ul> </section> <sectiontitle="Unsignedanchor="sect-4.3" numbered="true" toc="default"> <name>Unsigned PackageMode" anchor="sect-4.3"><t>Mode</name> <t> In this delivery mode, the delivery object consists of a group of files that are packaged for delivery only. If applied, the client is expected to unpack the package and provide each file as an independent object to the application. Packaging is supported by Multipart Multipurpose Internet Mail Extensions (MIME) <xreftarget="RFC2557"/>,target="RFC2557" format="default"/>, where objects are packaged into one document for transport, with Content-Type set to multipart/related. When binary files are included in the package, Content-Transfer-Encoding of "binary" should be used for those files.</t> </section> <sectiontitle="Signedanchor="sect-4.4" numbered="true" toc="default"> <name>Signed PackageMode" anchor="sect-4.4"><t>Mode</name> <t> In Signed Package Mode delivery, the delivery object consists of a group of files that are packaged for delivery, and the package includes one or more signatures for validation. Signed packaging is supported by RFC 8551 Secure MIME (S/MIME) <xreftarget="RFC8551"/>,target="RFC8551" format="default"/>, where objects are packaged into one document for transport and the package includes objects necessary for validation of the package.</t> </section> </section> <sectiontitle="Sender Operation" anchor="sect-5"><section title="Usageanchor="sect-5" numbered="true" toc="default"> <name>Sender Operation</name> <section anchor="sect-5.1" numbered="true" toc="default"> <name>Usage of ALC and LCT for SourceFlow" anchor="sect-5.1"><t>Flow</name> <t> ROUTE Source Flowcarrycarries the source data as specified in RFC 5775 <xreftarget="RFC5775"/>.target="RFC5775" format="default"/>. There are several special considerations that ROUTE introduces to the usage of the LCT building block as outlined in the following:</t><t><list style="symbols"><t>ROUTE<ul spacing="normal"> <li>ROUTE limits the usage of the LCT building block to a single channel per session. Congestion control is thussender-drivensender driven in ROUTE. It also signifies that there is no specificcongestion control related signallingcongestion-control-related signaling from the sender to the receiver; the CCI field is either set to 0 or used for other purposes as specified in <xreftarget="sect-2.1"/>.target="sect-2.1" format="default"/>. The functionality of receiver-driven layered multicast may still be offered by the application, allowing the receiver application to select the appropriate delivery session based on the bandwidth requirement of thatsession.</t> </list> </t>session.</li> </ul> <t> Further, the following details apply to LCT:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li> <t>The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 <xreftarget="RFC5651"/>target="RFC5651" format="default"/> is used with the followingconstraints:<list style="symbols"><t>Theconstraints:</t> <ul spacing="normal"> <li>The TSI in the LCT headerSHALL<bcp14>SHALL</bcp14> be set equal to the value of the stsi attribute in <xreftarget="sect-3.2"/>.</t> <t>Thetarget="sect-3.2" format="default"/>.</li> <li>The Codepoint (CP) in the LCT headerSHALL<bcp14>SHALL</bcp14> be used to signal the applied formatting as defined in the signalingmetadata.</t>metadata.</li> <li> <t>In accordancetowith ALC, a source FEC Payload ID header is used to identify, for FEC purposes, the encoding symbols of the delivery object, or a portion thereof, carried by the associated ROUTE packet. This information may be sent in several ways:<list style="symbols"></t> <ul spacing="normal"> <li> <t>As a simple new null FEC scheme with the following usage:<list style="symbols"> <t>The</t> <ul spacing="normal"> <li>The value of the source FEC Payload ID headerSHALL<bcp14>SHALL</bcp14> be set to0,0 in case the ROUTE packet contains the entire delivery object, or</t> <t>The</li> <li>The value of the source FEC Payload ID headerSHALL<bcp14>SHALL</bcp14> be set as a direct address (start offset) corresponding to the starting byte position of the portion of the object carried in this packet using a 32-bit field.</t> </list> </t> <t>In</li> </ul> </li> <li>In a compatible manner to RFC 6330[RFC6330]<xref target="RFC6330"/> where the SBN and ESI defines the start offset together with the symbol sizeT.</t> <t>TheT.</li> <li>The signaling metadata provides the appropriate parameters to indicate any of the above modes using the srcFecPayloadIdattribute.</t> </list> </t> </list> </t>attribute.</li> </ul> </li> </ul> </li> <li> <t>The LCT Header EXT_TIME extension as defined in RFC 5651 <xreftarget="RFC5651"/> MAYtarget="RFC5651" format="default"/> <bcp14>MAY</bcp14> be used by the sender in the followingmanner:<list style="symbols"><t>Themanner:</t> <ul spacing="normal"> <li>The Sender Current Time (SCT), depending on the application,MAY<bcp14>MAY</bcp14> be used to occasionally or frequently signal the sender currenttime,time possibly for reliever timesynchronization.</t> <t>Thesynchronization.</li> <li>The Expected Residual Time (ERT)MAY<bcp14>MAY</bcp14> be used to indicate the expected remaining time for transmission of the currentobject,object in order to optimize detection of a lost deliveryobject.</t> <t>Theobject.</li> <li>The Sender Last Changed (SLC) flag is typically notutilized,utilized butMAY<bcp14>MAY</bcp14> be used to indicate the addition/removal ofSegments.</t> </list> </t> </list> </t>Segments.</li> </ul> </li> </ul> <t> Additional extension headersMAY<bcp14>MAY</bcp14> be used to support real-time delivery. Such extension headers are defined in <xreftarget="sect-2.1"/>.</t>target="sect-2.1" format="default"/>.</t> </section> <sectiontitle="ROUTEanchor="sect-5.2" numbered="true" toc="default"> <name>ROUTE Packetization for SourceFlow" anchor="sect-5.2"><t>Flow</name> <t> The following description of the ROUTE sender operation on the mapping of the Application Object to the ROUTE packet payloads logically represents an extension of RFC 5445 <xreftarget="RFC5445"/>,target="RFC5445" format="default"/>, which in turn inherits the context, language,declarationsdeclarations, and restrictions of the FEC building block in RFC 5052 <xreftarget="RFC5052"/>.</t>target="RFC5052" format="default"/>.</t> <t> The data carried in the payload of a given ROUTE packetconstituteconstitutes a contiguous portion of the Application Object. ROUTE source delivery can be considered as a special case of the use of the Compact No-Code Scheme associated with FEC Encoding ID = 0 according to Sections3.4.1<xref target="RFC5445" sectionFormat="bare" section="3.4.1" /> and3.4.2<xref target="RFC5445" sectionFormat="bare" section="3.4.2"/> ofRFC 5445<xreftarget="RFC5445"/>,target="RFC5445" format="default"/>, in which the encoding symbol size is exactly one byte. As specified in <xreftarget="sect-2.1"/>,target="sect-2.1" format="default"/>, for ROUTE Source Flows, the FEC Payload IDSHALL<bcp14>SHALL</bcp14> deliver the 32-bit start_offset. All receivers are expected to support, at minimum, operation with this special case of the Compact No-Code FEC.</t> <t> Note that in the event the source object size is greater than2^322<sup>32</sup> bytes (approximately 4.3 GB), the applications (in the broadcaster server and the receiver) are expected to performsegmentation/re-assemblysegmentation/reassembly using methods beyond the scope of this document.</t> <t> Finally, in some specialcasescases, a ROUTE senderMAY<bcp14>MAY</bcp14> need to produce ROUTE packets that do not contain any payload. This may be required, for example, to signal the end of a session. Thesedata-lessdataless packets do not contain FEC Payload ID or payload data, but only the LCT header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the LCT header, FEC PayloadIDID, and payload data.</t> <sectiontitle="Basicanchor="sect-5.2.1" numbered="true" toc="default"> <name>Basic ROUTEPacketization" anchor="sect-5.2.1"><t>Packetization</name> <t> In the basic operation, it is assumed that the Application Object is fully available at the ROUTE sender.</t><t><list style="numbers"><t>The<ol spacing="normal" type="1"><li>The amount of data to be sent in a single ROUTE packet is limited by the maximum transfer unit of the data packets or the size of the remaining data of the Application Object being sent, whichever is smaller. The transfer unit is determined either by knowledge of underlying transport block sizes or by otherconstraints.</t> <t>Theconstraints.</li> <li>The start_offset field in the LCT header of the ROUTE packet indicates the byte offset of the carried data in the Application Object beingsent.</t> <t>Thesent.</li> <li>The Close Object(B)flag (B) is set to 1 if this is the last ROUTE packet carrying the data of the ApplicationObject.</t> </list> </t>Object.</li> </ol> <t> The order of packet delivery is arbitrary, but in the absence of otherconstraintsconstraints, delivery with increasing start_offset value is recommended.</t> </section> <sectiontitle="ROUTEanchor="sect-5.2.2" numbered="true" toc="default"> <name>ROUTE Packetization for CMAF ChunkedContent" anchor="sect-5.2.2"><t> FollowingContent</name> <t> The following additional guidelines should be followed for ROUTE packetization of CMAF Chunked Content in addition to theguidelineguidelines ofSection 5.2.1:</t> <t><list style="numbers"><t>If<xref target="sect-5.2.1"/>:</t> <ol spacing="normal" type="1"><li>If it is the first ROUTE packet carrying a CMAF Random Access chunk, except for the first CMAFchunkChunk in the segment, the Codepoint valueMAY<bcp14>MAY</bcp14> be set to 10, as specified in the Codepoint value table in <xreftarget="sect-2.1"/>.target="sect-2.1" format="default"/>. The receiverMAY<bcp14>MAY</bcp14> use this information for optimization of randomaccess.</t> <t>Asaccess.</li> <li>As soon as the total length of the media object is known, potentially with the packaging of the last CMAFchunkChunk of a segment, the EXT_TOL extension headerMAY<bcp14>MAY</bcp14> be added to the LCT header to signal the Transfer Length, so that the receiver may know this information in a timelyfashion.</t> </list> </t>fashion.</li> </ol> </section> </section> <sectiontitle="Timinganchor="sect-5.3" numbered="true" toc="default"> <name>Timing of PacketEmission" anchor="sect-5.3"><t>Emission</name> <t> The senderSHALL<bcp14>SHALL</bcp14> use the timing information provided by the application to time the emission of packets for a timely reception. This information may be contained in the Application Objectse.g.e.g., DASHSegmentssegments and/or the presentation manifest.HenceHence, such packets of streaming media withreal timereal-time constraintsSHALL<bcp14>SHALL</bcp14> be sent in such a way as to enable their timely reception with respect to the presentation timeline.</t> </section> <sectiontitle="Extendedanchor="sect-5.4" numbered="true" toc="default"> <name>Extended FDT Encoding for File ModeSending" anchor="sect-5.4"><t>Sending</name> <t> For File ModeSending:</t> <t><list style="symbols"><t>Thesending:</t> <ul spacing="normal"> <li>The TOI field in the ROUTE packet headerSHALL<bcp14>SHALL</bcp14> be set such that Content-Location can be derived at the receiver according to File Template substitution specified in <xreftarget="sect-6.3.1"/>.</t> <t>Aftertarget="sect-6.3.1" format="default"/>.</li> <li>After sending the first packet with a given TOI value, none of the packets pertaining to this TOISHALL<bcp14>SHALL</bcp14> be sent later than the wall clock time as derived from maxExpiresDelta. The EXT_TIME header with Expected Residual Time (ERT)MAY<bcp14>MAY</bcp14> be used in order to convey more accurate expirytime.</t> </list> </t>time.</li> </ul> </section> <sectiontitle="FECanchor="sect-5.5" numbered="true" toc="default"> <name>FEC FrameworkConsiderations" anchor="sect-5.5"><t>Considerations</name> <t> The FEC framework uses concepts of the FECFRAME work as defined in RFC 6363 <xreftarget="RFC6363"/>,target="RFC6363" format="default"/>, as well as the FEC building block, RFC 5052 <xreftarget="RFC5052"/>,target="RFC5052" format="default"/>, which is adopted in the existing FLUTE/ALC/LCT specifications.</t> <t> The FEC design adheres to the following principles:</t><t><list style="symbols"><t>FEC-related<ul spacing="normal"> <li>FEC-related information is provided only whereneeded.</t> <t>Receiversneeded.</li> <li>Receivers not capable of this framework can ignore repairpackets.</t> <t>Thepackets.</li> <li>The FEC issymbol-basedsymbol based with fixed symbol size per protected Source Flow. The ALC protocol and existing FEC schemes arereused.</t> <t>Areused.</li> <li>A FEC Repair Flow provides protection of delivery objects from one or more SourceFlows.</t> </list> </t>Flows.</li> </ul> <t> The FEC-specific components of the FEC framework are:</t><t><list style="symbols"><t>FEC<ul spacing="normal"> <li>FEC Repair Flow declaration including all FEC-specificinformation.</t> <t>FECinformation.</li> <li>A FEC transport object that is the concatenation of a delivery object, paddingoctetsoctets, and size information in order to forman N-symbol-sizeda chunk ofdata,data that has a size in symbols of N, where N >=1.</t> <t>FEC1.</li> <li>A FEC super-object that is the concatenation of one or more FEC transport objects in order to bundle FEC transport objects for FECprotection.</t> <t>FECprotection.</li> <li>A FEC protocol and packetstructure.</t> </list> </t>structure.</li> </ul> <t> A receiver needs to be able to recover delivery objects from repair packets based on available FEC information.</t> </section> <sectiontitle="FECanchor="sect-5.6" numbered="true" toc="default"> <name>FEC Transport ObjectConstruction" anchor="sect-5.6"><t>Construction</name> <t> In order to identify a delivery object in the context of theRepairrepair protocol, the following information is needed:</t><t><list style="symbols"><t>TSI<ul spacing="normal"> <li>TSI and TOI of the delivery object. In this case, the FEC object corresponds to the (entire) deliveryobject.</t> <t>Octetobject.</li> <li>Octet range of the delivery object,i.e.i.e., start offset within the delivery object and number of subsequent and contiguous octets of delivery object that constitutes the FEC object (i.e., the FEC-protected portion of the source object). In this case, the FEC object corresponds to a contiguous byte range portion of the deliveryobject.</t> </list> </t>object.</li> </ul> <t> Typically, for real-time object delivery with smaller delivery object sizes, the first mapping isapplied;applied, i.e., the delivery object isana FEC object.</t> <t> Assuming that the FEC object is the delivery object, for each delivery object, the associated FEC transport object is comprised of the concatenation of the delivery object, padding octets(P)(P), and the FEC object size (F) in octets, where F is carried in a 4-octet field.</t> <t> The FEC transport object size S, in FEC encoding symbols,SHALL<bcp14>SHALL</bcp14> be an integer multiple of the symbol size Y. S is determined from the session information and/or the repair packet headers.</t> <t> F is carried in the last 4 octets of the FEC transport object. Specifically, let:</t><t><list style="symbols"><t>F<ul spacing="normal"> <li>F be the size of the delivery object inoctets,</t> <t>F'octets,</li> <li>F' be the F octets of data of the deliveryobject,</t> <t>f'object,</li> <li>f' denote the four octets of data carrying the value of F in network octet order (high-order octetfirst),</t> <t>Sfirst),</li> <li>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 nearestinteger,</t> <t>P'integer,</li> <li>P' be S*Y-4-F octets of data,i.e.i.e., padding placed between the delivery object and the 4-byte field conveying the value of F and located at the end of the FEC transport object,and</t> <t>O'and</li> <li>O' be the concatenation of F',P'P', andf'.</t> </list> </t>f'.</li> </ul> <t> O' then constitutes the FEC transport object of size S*Y octets. Note that padding octets and the object size F are not sent in source packets of the deliveryobject,object but are only part ofana FEC transport object that FEC decoding recovers in order to extract the FEC object and thus the delivery object or portion of the delivery object that constitutes the FEC object. In the above context, the FEC transport object size in symbols is S.</t> <t> The general information aboutana FEC transport object that is conveyed toana FEC-enabled receiver is the source TSI, sourceTOITOI, and the associated octet range within the delivery object comprising the associated FEC object. However, as the size in octets of the FEC object is provided in the appended field within the FEC transport object, the remaining information can be conveyed as:</t><t><list style="symbols"><t>TSI<ul spacing="normal"> <li>The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object isgenerated</t> <t>Startgenerated</li> <li>The start octet within the delivery object for the associated FECobject</t> <t>Sizeobject</li> <li>The size in symbols of the FEC transport object,S</t> </list> </t>S</li> </ul> </section> <sectiontitle="Super-Object Construction" anchor="sect-5.7"><t>anchor="sect-5.7" numbered="true" toc="default"> <name>Super-Object Construction</name> <t> From the FEC Repair Flow declaration, the construction ofana FEC super-object as the concatenation of one or more FEC transport objects can be determined. The FEC super-object includes the general information about the FEC transport objects as described in the previous sections, as well as the placement order of FEC transport objects within the FEC super-object.</t> <t> Let:</t><t><list style="symbols"><t>N<ul spacing="normal"> <li>N be the total number of FEC transport objects for the FEC super-objectconstruction.</t> <t>Forconstruction.</li> <li>For i =0,...,0, ..., N-1, let S[i] be the size in symbols of FEC transport objecti.</t> <t>B'i.</li> <li>B' be the FEC super-objectwhichthat is the concatenation of the FEC transport objects in numerical order, comprised of K = Sum of N source symbols, each symbol denoted asS[i].</t> </list> </t>S[i].</li> </ul> <t> For each FEC super-object, the remaining general information that needs to be conveyed toana FEC-enabled receiver, beyond what is already carried in the FEC transport objects that constitute the FEC super-object, comprises:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li>The total number of FEC transport objectsN.</t>N.</li> <li> <t>For each FEC transportobject, the:<list style="symbols"><t>TSIobject:</t> <ul spacing="normal"> <li>The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object isgenerated,</t> <t>Startgenerated,</li> <li>The start octet within the delivery object for the associated FEC object,and</t> <t>Sizeand</li> <li>The size in symbols of the FEC transportobject.</t> </list> </t> </list> </t>object.</li> </ul> </li> </ul> <t> The carriage of the FEC repair information is discussed below.</t> </section> <sectiontitle="Repairanchor="sect-5.8" numbered="true" toc="default"> <name>Repair PacketConsiderations" anchor="sect-5.8"><t>Considerations</name> <t> The repair protocol is based on Asynchronous Layered Coding (ALC) as defined in RFC 5775 <xreftarget="RFC5775"/>target="RFC5775" format="default"/> and the Layered Coding Transport (LCT) Building Block as defined in RFC 5651 <xreftarget="RFC5651"/>target="RFC5651" format="default"/> with the following details:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li> <t>The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 <xreftarget="RFC5651"/>target="RFC5651" format="default"/> is used as defined in Asynchronous Layered Coding (ALC), <xreftarget="sect-2.1"/>.target="sect-2.1" format="default"/>. In addition, the followingconstraints apply:<list style="symbols"><t>Theconstraint applies:</t> <ul spacing="normal"> <li>The TSI in the LCT headerSHALL<bcp14>SHALL</bcp14> identify the Repair Flow to which this packetapplies,applies by the matching the value of the ptsi attribute in the signaling metadata among the LCT channels carrying RepairFlows.</t> </list> </t>Flows.</li> </ul> </li> <li> <t>The FEC building block is used according to RFC 6330 <xreftarget="RFC6330"/>,target="RFC6330" format="default"/>, but only repair packets aredelivered.<list style="symbols"><t>Eachdelivered.</t> <ul spacing="normal"> <li>Each repair packet within the scope of the Repair Flow (as indicated by the TSI field in the LCT header)SHALL<bcp14>SHALL</bcp14> carry the repair symbols for a corresponding FEC transport object/super-object as identified by its TOI. The repair object/super- object TOISHALL<bcp14>SHALL</bcp14> be unique for each FEC super-object that is created within the scope of theTSI.</t> </list> </t> </list> </t>TSI.</li> </ul> </li> </ul> </section> <sectiontitle="Summaryanchor="sect-5.9" numbered="true" toc="default"> <name>Summary FECInformation" anchor="sect-5.9"><t>Information</name> <t> For each super-object (identified by a unique TOI within a Repair Flow that is in turn identified by the TSI in the LCT header) that is generated, the following information needs to be communicated to the receiver:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li> <t>The FEC configuration consistingof:<list style="symbols"><t>FECof:</t> <ul spacing="normal"> <li>FEC Object Transmission Information (OTI) per RFC 5052 <xreftarget="RFC5052"/>.</t> <t>Additionaltarget="RFC5052" format="default"/>.</li> <li>Additional FEC information (see <xreftarget="sect-3.3"/>).</t> <t>Thetarget="sect-3.3" format="default"/>).</li> <li>The total number of FEC objects included in the FEC super-object,N.</t> </list> </t>N.</li> </ul> </li> <li> <t>For each FEC transportobject:<list style="symbols"><t>TSIobject:</t> <ul spacing="normal"> <li>TSI and TOI of the delivery object used to generate the FEC object associated with the FEC transportobject,</t> <t>Startobject,</li> <li>The start octet within the delivery object of the associated FEC object, if applicable,and</t> <t>Theand</li> <li>The size in symbols of the FEC transport object,S.</t> </list> </t> </list> </t>S.</li> </ul> </li> </ul> <t> The above information is delivered:</t><t><list style="symbols"><t>Statically<ul spacing="normal"> <li>Statically in the session metadata as defined in <xreftarget="sect-3.3"/>, and</t> <t>Dynamicallytarget="sect-3.3" format="default"/>, and</li> <li>Dynamically in an LCT extensionheader.</t> </list> </t>header.</li> </ul> </section> </section> <sectiontitle="Receiver operation" anchor="sect-6"><t>anchor="sect-6" numbered="true" toc="default"> <name>Receiver Operation</name> <t> The receiver receives packets and filters those packets according to the following. From the ROUTE session and each contained LCT channel, the receiver regenerates delivery objects from the ROUTE session and each contained LCT channel.</t> <t> In the event that the receiver receives data that does not conform to the ROUTE protocol specified in this document, the receiverSHOULD<bcp14>SHOULD</bcp14> attempt to recover gracefully bye.g.e.g., informing the application about the issues using means beyond the scope of this document. The ROUTEPacketizationpacketization specified in <xreftarget="sect-5.2.1"/>target="sect-5.2.1" format="default"/> implies that the receiverSHALL NOT<bcp14>SHALL NOT</bcp14> receive overlappingdata:data; if such a condition is encountered at the receiver, the packetSHALL<bcp14>SHALL</bcp14> be assumed to be corrupted.</t> <t> The basic receiver operation is providedbelow, itbelow (it assumes an error-freescenario,scenario), while repair considerations are provided in <xreftarget="sect-7"/>.</t>target="sect-7" format="default"/>.</t> <sectiontitle="Basicanchor="sect-6.1" numbered="true" toc="default"> <name>Basic Application Object Recovery for SourceFlows" anchor="sect-6.1"><t>Flows</name> <t> Upon receipt of each ROUTE packet of a Source Flow, the receiver proceeds with the following steps in the order listed.</t><t><list style="numbers"> <t>The<ol spacing="normal" type="%d)"><li>The ROUTE receiver is expected to parse the LCT and FEC Payload ID to verify that it is a valid header. If it is not valid, then the payload is discarded without furtherprocessing.</t> <t>Allprocessing.</li> <li>All ROUTE packets used to recover a specific delivery object carry the same TOI value in the LCTheader.</t> <t>Theheader.</li> <li>The ROUTE receiver is expected to assert that the TSI and the Codepoint represent valid operation points in the signaling metadata,i.e.i.e., the signaling contains a matching entry to the TSI value provided in the packet header, as well as for this TSI, and the Codepoint field in the LCT header has a valid Codepointmapping.</t>mapping.</li> <li> <t>The ROUTE receiver should process the remainder of the payload, including the appropriate interpretation of the other payload header fields,andusing the source FEC Payload ID (to determine the start_offset) and the payload data to reconstruct the corresponding object as follows:<list style="letters"><t>For</t> <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 File@Transfer-Length attribute of the associated ExtendedFDT Instance,FDT-Instance, when present, to determine the length T of the object. When the File@Transfer-Length attribute is not present in the ExtendedFDT Instance,FDT-Instance, the receiver uses the maxTransportSize attribute of the associated ExtendedFDT InstanceFDT-Instance to determine the maximum length T' of the object. Alternatively, and specifically for delivery modes other than File Mode, the EXT_TOL header can be used to determine the length T of theobject.</t> <t>Theobject.</li> <li>The ROUTE receiver allocates buffer space for the T or T' bytes that the object will or mayoccupy.</t> <t>Theoccupy.</li> <li>The ROUTE receiver computes the length of the payload, Y, by subtracting the payload header length from the total length of the receivedpayload.</t> <t>Thepayload.</li> <li><t>The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or RECEIVED[0..T'-1], as appropriate, with all entries initialized to false to track received object symbols. The ROUTE receiver continuously acquires packet payloads for the object as long as all of the following conditions aresatisfied: i) theresatisfied:</t> <ol type="i"> <li>there is at least one entry in RECEIVED still set tofalse; ii) thefalse, </li> <li>the object has not yetexpired; and iii) theexpired, and</li> <li><t>the application has not given up on reception of thisobject. Moreobject.</t> <t>More details are provided below. </t> </li> </ol> </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:<list style="letters"> <t>If</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 becomeRECEIVED[0..T-1].</t> <t>LetRECEIVED[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 by subtracting the LCT header size and the FEC Payload ID size from the total length of the receivedpacket.</t> <t>Thepacket.</li> <li>The ROUTE receiver copies the data into the appropriate place within the space reserved for the object and sets RECEIVED[X ... X+Y-1] =true.</t> <t>Iftrue.</li> <li>If all T entries of RECEIVED are true, then the receiver has recovered the entireobject.</t> </list> </t> </list> </t> </list> </t>object.</li> </ol> </li> </ol> </li> </ol> <t> Upon recovery of both the complete set of packet payloads for the delivery object associated with a given TOI value, and the metadata for that delivery object, the reception of the delivery object, now a fully received Application Object, is complete.</t> <t> Given the timely reception of ROUTE packets belonging to an Application Object, the receiverSHALL<bcp14>SHALL</bcp14> make the Application Objects available to the application in a timelyfashion,fashion using the application-provided timing data(e.g.(e.g., the timing data signaled via the presentation manifest file). For example, HTTP/1.1 chunked transfer may need to be enabled to transfer the Application Objects if MPD@availabilityTimeOffset is signaled in the DASH presentationmanifest,manifest in order to allow for the timely sending of segment data to the application.</t> </section> <sectiontitle="Fastanchor="sect-6.2" numbered="true" toc="default"> <name>Fast StreamAcquisition" anchor="sect-6.2"><t>Acquisition</name> <t> When the receiver initially starts reception of ROUTE packets, it is likely that the reception does not start from the very first packet carrying the data of a multicast transportobject, andobject; in thiscasecase, such a partially received object is normally discarded. However, the channel acquisition or "tune-in" times can be improved if the partially received object is usable by the application. One example realization for this is as follows:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li>The receiver checks for the first received packet with the Codepoint value set to 10, indicating the start of a CMAF Random Accesschunk.</t> <t>Thechunk.</li> <li>The receiverMAY<bcp14>MAY</bcp14> make the partially received object (a partial DASH segment starting from the packet above) available to the application for fast streamacquisition.</t> <t>It MAYacquisition.</li> <li>It <bcp14>MAY</bcp14> recover the earliest presentation time of this CMAF Random Access chunk from the ROUTE packet LCT Congestion Control Information (CCI) field as specified in <xreftarget="sect-2.1"/>target="sect-2.1" format="default"/> to be able to add a new Period element in the MPD exposed to the application containing just the partially received DASH segment with period continuitysignaling.</t> </list> </t>signaling.</li> </ul> </section> <sectiontitle="Generatinganchor="sect-6.3" numbered="true" toc="default"> <name>Generating ExtendedFDT InstanceFDT-Instance for FileMode" anchor="sect-6.3"><t>Mode</name> <t> An ExtendedFDT InstanceFDT-Instance conforming to RFC 6726 <xreftarget="RFC6726"/>,target="RFC6726" format="default"/>, is produced at the receiver using the service metadata andin bandin-band signaling in the following steps:</t> <sectiontitle="Fileanchor="sect-6.3.1" numbered="true" toc="default"> <name>File Template Substitution for Content-LocationDerivation" anchor="sect-6.3.1"><t>Derivation</name> <t> The Content-Location element of the Extended FDT for a specific Application Object is derived as follows:</t> <t> "$TOI$" is substituted with the unique TOI value in the LCT header of the ROUTE packets used to recover the given delivery object (as specified in <xreftarget="sect-6.1"/>).</t>target="sect-6.1" format="default"/>).</t> <t> After the substitution, the fileTemplateSHALL<bcp14>SHALL</bcp14> be a valid URL corresponding to the Content-Location attribute of the associated Application Object.</t> <t> An example @fileTemplate using a width of 5 is: fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with exactly five digits in the number portion. The Media Segment file name for TOI=33 using this template is myVideo00033.mps.</t> </section> <sectiontitle="File@Transfer-Length Derivation" anchor="sect-6.3.2"><t>anchor="sect-6.3.2" numbered="true" toc="default"> <name>File@Transfer-Length Derivation</name> <t> Either the EXT_FTI header (per RFC 5775 <xreftarget="RFC5775"/>)target="RFC5775" format="default"/>) or the EXT_TOL header, when present, is used to derive the Transport Object Length (TOL) of the File. If the File@Transfer-Length parameter in the ExtendedFDT InstanceFDT-Instance is not present, then the EXT_TOL header or the or EXT_FTI headerSHALL<bcp14>SHALL</bcp14> be present. Note that a header containing the transport object length (EXT_TOL or EXT_FTI) need not be present in each packet header. If the broadcaster does not know the length of the transport object at the beginning of the transfer, an EXT_TOL or EXT_FTI headerSHALL<bcp14>SHALL</bcp14> be included in at least the last packet of the file and should be included in the last few packets of the transfer.</t> </section> <sectiontitle="FDT-Instance@Expires Derivation" anchor="sect-6.3.3"><t>anchor="sect-6.3.3" numbered="true" toc="default"> <name>FDT-Instance@Expires Derivation</name> <t> When present, the maxExpiresDelta attributeSHALL<bcp14>SHALL</bcp14> be used to generate the value of the FDT-Instance@Expires attribute. The receiver is expected to add this value to its wall clock time when acquiring the first ROUTE packet carrying the data of a given delivery object to obtain the value for @Expires.</t> <t> When maxExpiresDelta is not present, the EXT_TIME header with Expected Residual Time (ERT)SHALL<bcp14>SHALL</bcp14> be used to derive the expiry time of the ExtendedFDT Instance.FDT-Instance. When both maxExpiresDelta and the ERT of EXT_TIME are present, the smaller of the two values should be used as the incremental time interval to be added to the receiver's current time to generate the effective value for @Expires. When neither maxExpiresDelta nor the ERT field of the EXT_TIME header is present, then the expiration time of the ExtendedFDT InstanceFDT-Instance is given by its @Expires attribute.</t> </section> </section> </section> <sectiontitle="FEC Application" anchor="sect-7"><section title="Generalanchor="sect-7" numbered="true" toc="default"> <name>FEC Application</name> <section anchor="sect-7.1" numbered="true" toc="default"> <name>General FEC ApplicationGuidelines" anchor="sect-7.1"><t>Guidelines</name> <t> It is up to the receiver to decide to use zero,oneone, or more of the FEC streams. Hence, the application assigns a recovery property to each flow, which defines aspects such as the delay and the required memory if one or the other is chosen. The receiverMAY<bcp14>MAY</bcp14> decide whether or not to utilize Repair Flows based on the following considerations:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li>The desired start-up and end-to-end latency. If a Repair Flow requires a significant amount of buffering time to be effective, such Repair Flow might only be used in time-shift operations or in poor reception conditions, since use of such Repair Flow trades off end-to-end latency against DASH Media Presentationquality.</t> <t>FECquality.</li> <li>FEC capabilities,i.e.i.e., the receiverMAY<bcp14>MAY</bcp14> pick only the FEC algorithm that itsupports.</t> <t>Whichsupports.</li> <li>Which Source Flows are being protected; for example, if the Repair Flow protects Source Flows that are not selected by the receiver, then the receiver may not select the RepairFlow.</t> <t>OtherFlow.</li> <li>Other considerations such as available buffer size, reception conditions,etc.</t> </list> </t>etc.</li> </ul> <t> If a receiver decides to acquire a certain RepairFlowFlow, then the receiver must receive data on all Source Flows that are protected by that Repair Flow to collect the relevant packets.</t> </section> <sectiontitle="TOI Mapping" anchor="sect-7.2"><t>anchor="sect-7.2" numbered="true" toc="default"> <name>TOI Mapping</name> <t> When mappingTOIx/mappingTOIy are used to signal X and Y values,thenthe TOI value(s) of the one or more source objects (sourceTOI) protected by a given FEC transport object or FEC super-object with a TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y.</t> <t> When neither mappingTOIx nor mappingTOIy ispresentpresent, there is a 1:1 relationship between each delivery object carried in the Source Flow as identified by ptsi toana FEC object carried in this Repair Flow. In thiscasecase, the TOI of each of those delivery objectsSHALL<bcp14>SHALL</bcp14> be identical to the TOI of the corresponding FEC object.</t> </section> <sectiontitle="Deliveryanchor="sect-7.3" numbered="true" toc="default"> <name>Delivery Object ReceptionTimeout" anchor="sect-7.3"><t>Timeout</name> <t> The permitted start and end times for the receiver to perform the file repair procedure, in case of unsuccessful broadcast file reception, and associated rules and parameters are as follows:</t><t><list style="symbols"><t>The<ul spacing="normal"> <li>The latest time that the file repair procedure may start is bound by the @Expires attribute of theFDT-Instance.</t>FDT-Instance.</li> <li> <t>The receiver may choose to start the file repair procedureearlier,earlier if it detects the occurrence of any of the followingevents:<list style="symbols"><t>Presenceevents:</t> <ul spacing="normal"> <li>Presence of the Close Object flag (B) in the LCT header <xreftarget="RFC5651"/>target="RFC5651" format="default"/> for the file ofinterest;</t> <t>Presenceinterest;</li> <li>Presence of the Close Session flag (A) in the LCT header <xreftarget="RFC5651"/>target="RFC5651" format="default"/> before the nominal expiration of the ExtendedFDT InstanceFDT-Instance as defined by the @Expiresattribute.</t> </list> </t> </list> </t>attribute.</li> </ul> </li> </ul> </section> <sectiontitle="Exampleanchor="sect-7.4" numbered="true" toc="default"> <name>Example FECOperation" anchor="sect-7.4"><t>Operation</name> <t> To be able to recover the delivery objects that are protected by a Repair Flow, a receiver needs to obtain the necessary Service signaling metadata fragments that describe the corresponding collection of delivery objects that are covered by this Repair Flow. A Repair Flow is characterized by the combination of an LCT channel, a unique TSI number, as well as the corresponding protected Source Flows.</t> <t> If a receiver acquires data of a Repair Flow, the receiver is expected to collect all packets of all protected Transport Sessions. Upon receipt of each packet, whether it is a source or repair packet, the receiver proceeds with the following steps in the order listed.</t><t><list style="numbers"><t>The<ol spacing="normal" type="1"><li>The receiver is expected to parse the packet header and verify that it is a valid header. If it is not valid, then the packetSHALL<bcp14>SHALL</bcp14> be discarded without furtherprocessing.</t> <t>Theprocessing.</li> <li>The receiver is expected to parse the TSI field of the packet header and verify that a matching value exists in the Service signaling for the Repair Flow or the associated Protected Source Flow. If no match is found, the packetSHALL<bcp14>SHALL</bcp14> be discarded without furtherprocessing.</t>processing.</li> <li> <t>The receiver processes the remainder of the packet, including interpretation of the other header fields, and using the source FEC Payload ID (to determine the start_offset byte position within the source object), the Repair FEC Payload ID, as well as the payload data, reconstructs the decoding blocks corresponding to a FEC super-object asfollows:<list style="letters"><t>Forfollows:</t> <ol spacing="normal" type="a"><li>For a source packet, the receiver identifies the delivery object to which the received packet isassociated,associated using the session information and the TOI carried in the payload header. Similarly, for a repairobjectobject, the receiver identifies the FEC super-object to which the received packet isassociated,associated using the session information and the TOI carried in the payloadheader.</t> <t>Forheader.</li> <li>For source packets, the receiver collects the data for each FEC super-object and recovers FEC super-objects in the same way as a Source Flow in <xreftarget="sect-6.1"/>.target="sect-6.1" format="default"/>. The received FEC super-object is then mapped to a source block and the corresponding encoding symbols aregenerated.</t> <t>Withgenerated.</li> <li>With the reception of the repair packets, the FEC super-object can berecovered.</t> <t>Oncerecovered.</li> <li>Once the FEC super-object is recovered, the individual delivery objects can beextracted.</t> </list> </t> </list> </t>extracted.</li> </ol> </li> </ol> </section> </section> <sectiontitle="Considerationsanchor="sect-8" numbered="true" toc="default"> <name>Considerations for Defining ROUTEProfiles" anchor="sect-8"><t>Profiles</name> <t> Services(e.g.(e.g., ATSC-ROUTE[ATSCA331],<xref target="ATSCA331"/>, DVB-MABR[DVBMABR]<xref 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)[DVBMABR].<xref target="DVBMABR"/>. The definitionwithhas the following considerations. ServicesMAY</t> <t><list style="symbols"><t>Restrict<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 LCTheader.</t> <t>Restrictheader.</li> <li>Restrict using certain LCT header extensions and/or add new LCT headerextensions.</t> <t>Restrictextensions.</li> <li>Restrict or limit usage of someCodepoints,Codepoints and/or assign semantics to service-specific Codepoints marked as reserved in thisdocument.</t> <t>Restrictdocument.</li> <li>Restrict usage of certainserviceService signaling attributes and/or add their own servicemetadata.</t> </list> </t>metadata.</li> </ul> <t> ServicesSHALL NOT<bcp14>SHALL NOT</bcp14> redefine the semantics of any of the ROUTE attributes in LCT headers andextension, and serviceextensions, as well as Service signaling attributes already specified in this document.</t> <t> By following these guidelines, services can define profiles that are interoperable.</t> </section> <sectiontitle="ROUTE Concepts" anchor="sect-9"><section title="ROUTEanchor="sect-9" numbered="true" toc="default"> <name>ROUTE Concepts</name> <section anchor="sect-9.1" numbered="true" toc="default"> <name>ROUTE Modes ofDelivery" anchor="sect-9.1"><t>Delivery</name> <t> Different ROUTE delivery modes specified in <xreftarget="sect-4"/>target="sect-4" format="default"/> are optimized for delivery of different types of media data. For example, File Mode is specifically optimized for delivering DASH content using Segment Template with number substitution. Using File Template in EFDT avoids the needoffor the repeated sending of metadata as outlined in the following section. Sameoptimizations howeveroptimizations, however, cannot be used for time substitution and segment timeline where the addressing of each segment is time dependent and in general does not follow a fixed or repeated pattern. In this case, EntitymodeMode is more optimizedwhichsince it carries the file location in band. Also, EntitymodeMode can be used to deliver a file or part of the file using HTTP Partial Content response headers.</t> </section> <sectiontitle="Fileanchor="sect-9.2" numbered="true" toc="default"> <name>File ModeOptimizations" anchor="sect-9.2"><t>Optimizations</name> <t> Inthe file mode,File Mode, the delivery object represents an Application Object. This mode replicates FLUTE as defined in RFC 6726 <xreftarget="RFC6726"/>,target="RFC6726" format="default"/> but with the ability to send static and pre-known file metadata out of band.</t> <t> In FLUTE,FDT InstancesFDT-Instances are deliveredin-bandin band and need to be generated and delivered inreal-timereal time if objects are generated inreal-timereal time at the sender. TheseFDT InstancesFDT-Instances have some differences as compared to the FDT specified inSection 3.4.2 of RFC 6726<xreftarget="RFC6726"/>target="RFC6726" sectionFormat="of" section="3.4.2"/> and Section 7.2.10 of MBMS[MBMS].<xref target="MBMS"/>. The key difference is that besides separated delivery of file metadata from the delivery object it describes, the FDT functionality in ROUTE may be extended by additional file metadata and rules that enable the receiver to generate the Content-Location attribute of the File element of the FDT,on-the-fly.on the fly. This is done by using information in both the extensions to the FDT and the LCT header. The combination of pre-delivery of static file metadata and receiverself-generationself generation of dynamic file metadata avoids the necessity of continuously sending theFDT InstancesFDT-Instances for real-time objects. Such modified FDT functionality in ROUTE is referred to as the Extended FDT.</t> </section> <sectiontitle="In Bandanchor="sect-9.3" numbered="true" toc="default"> <name>In-Band Signaling of Object TransferLength" anchor="sect-9.3"><t>Length</name> <t> As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header extension with 24 bits or, if required, 48 bitsofto signal the Transfer Length directly within the ROUTE packet.</t> <t> 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.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.</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 itstransfer lengthTransfer 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.(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 a2 seconds2-second DASH segment with100 millisecond100-millisecond chunks, it may result in saving up to 1.9 second latency at the sending end.</t> </section> <sectiontitle="Repairanchor="sect-9.4" numbered="true" toc="default"> <name>Repair ProtocolConcepts" anchor="sect-9.4"><t>Concepts</name> <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 <xreftarget="RFC6363"/>,target="RFC6363" format="default"/>, but in contrast to the FEC Framework in RFC 6363 <xreftarget="RFC6363"/>target="RFC6363" format="default"/>, the ROUTE repair protocol does not protectpackets,packets but insteaditprotects 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 <xreftarget="RFC6363"/>.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 <xreftarget="RFC5052"/>target="RFC5052" format="default"/> and uses the terminology of that document. The FEC scheme defines the FEC encoding anddecoding,decoding as well as the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme.</t> <t> InROUTEROUTE, all packets are LCT packets as defined in RFC 5651 <xreftarget="RFC5651"/>.target="RFC5651" format="default"/>. Source and repair packets may be distinguished by:</t><t><list style="symbols"><t>Different<ul spacing="normal"> <li>Different ROUTEsessions;sessions, i.e., they are carried on different UDP/IP portcombinations.</t> <t>Differentcombinations.</li> <li>Different LCTchannels;channels, i.e., they use different TSI values in the LCTheader.</t> <t>Theheader.</li> <li>The most significant PSI bit in the LCT, if carried in the same LCT channel. This mode of operation is mostly suitable for FLUTE-compatibledeployments.</t> </list> </t>deployments.</li> </ul> </section> </section> <sectiontitle="Interoperability Chart" anchor="sect-10"><t>anchor="sect-10" numbered="true" toc="default"> <name>Interoperability Chart</name> <t> As noted in prevision sections, ATSC-ROUTE[ATSCA331]<xref target="ATSCA331"/> and DVB-MABR[DVBMABR]<xref target="DVBMABR"/> are considered services using this document that constrain 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 thisdocument,document withtheATSC-ROUTE[ATSCA331]<xref target="ATSCA331"/> and DVB-MABR[DVBMABR]:</t> <figure><artwork><![CDATA[ +---------------+---------------+--------------------+-----------------+ | Element | ATSC-ROUTE | This Document | DVB-MABR | | | | | | +--------+------+---------------+--------------------+-----------------+ | LCT |PSI | Set<xref target="DVBMABR"/>:</t> <table anchor="interoperability" align="center"> <name>Interoperability Chart</name> <thead> <tr> <th align="left" rowspan="1" colspan="1">Element</th> <th align="left" rowspan="1" colspan="1">ATSC-ROUTE</th> <th align="left" rowspan="1" colspan="1">This Document</th> <th align="left" rowspan="1" colspan="1">DVB-MABR</th> </tr> </thead> <tbody> <tr> <td align="left" rowspan="2" colspan="1">LCT header field</td> <td align="left" rowspan="1" colspan="1">PSI LSB set to 0| Not defined | Setfor Source Flow</td> <td align="left" rowspan="1" colspan="1">Not defined</td> <td align="left" rowspan="1" colspan="1">Set to 1 for| | header |least | for Source | |Source Flow for| | fields |signi-| Flow. | |CMAF Random| | |ficant| | | access chunk | | |bit | | | | | +------+---------------+--------------------------------------+ | |CCI | MayAccess chunk</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">CCI may be set| Mayto 0</td> <td align="left" rowspan="1" colspan="2">CCI may be set to EPT for SourceFlow | | | | to 0 | | +--------+------+---------------+--------------------+-----------------+ | LCT header | EXT_ROUTE_ | Not defined, | Shall not | | extensions | PRESENTATION_ |Flow</td> </tr> <tr> <td align="left" rowspan="2" colspan="1">LCT header extensions</td> <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| be used | | | TIME Header |by aprofile. | | | | used for | | | | | MDE mode | | | | +---------------+--------------------+-----------------+ | | EXT_TIME | EXT_TIME Header mayprofile.</td> <td align="left" rowspan="1" colspan="1">Shall not beused | | |used.</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">EXT_TIME Header| regardless (for | | |linked to| FDT-Instance@Expires | | |MDE mode| calculation) | | |in Annex| | | |A.3.7.2| | +---------------+---------------+--------------------+-----------------+ | Codepoints | Full set | Does<xref target="ATSCA331"/></td> <td align="left" rowspan="1" colspan="2">EXT_TIME Header may be used regardless (for FDT-Instance@Expires calculation)</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">Codepoints</td> <td align="left">Full set</td> <td align="left">Does not specify| Restricted | | | |range 11 - 255|(leaves to profiles)</td> <td align="left">Restricted to 5 -9 | | | | (leaves to | | | | | profiles) | | +---------------+---------------+--------------------+-----------------+ | Session | Full set | Only9</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">Session metadata</td> <td align="left">Full set</td> <td align="left">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. | | | | |integral/alphanumerical. Leaves rest to| | | | | profiles. | | +---------------+---------------+--------------------+-----------------+ | Extended | Instance | Not restricted, | Instance shall | | FDT |profiles.</td> <td align="left">Reuses A/331 metadata, duplicated from its own Service signaling.</td> </tr> <tr> <td align="left" rowspan="2" colspan="1">Extended FDT</td> <td align="left">Instance shall not|be sent with Source Flow</td> <td align="left">Not restricted, may be|restricted by a profile.</td> <td align="left">Instance shall not be sent| | | be sent | restricted | with Source | | |with Source| by a profile. | Flow | | | Flow | | | | +---------------+--------------------+-----------------+ | | No | OnlyFlow</td> </tr> <tr> <td align="left">No restriction</td> <td align="center" rowspan="1" colspan="2">Only allowed in FileMode | | | restriction | | +---------------+---------------+--------------------+-----------------+ | Delivery | File, Entity, Signed/ | Signed/ | |Mode</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">Delivery Object| unsigned package | unsigned | | Mode | |Mode</td> <td align="center" rowspan="1" colspan="2">File, Entity, Signed/unsigned package</td> <td align="left">Signed/unsigned package not| | | | allowed | +---------------+---------------+--------------------+-----------------+ | Sender | Definedallowed</td> </tr> <tr> <td align="left" rowspan="1" colspan="1">Sender operation: Packetization</td> <td align="left">Defined for| DefinedDASH segment</td> <td align="center" colspan="2">Defined for DASH segment and CMAF| | operation: | DASH |Chunks| | Packet- | segment | | | ization | | | +---------------+---------------+--------------------------------------+ | Receiver | Object | Object</td> </tr> <tr> <td align="left" rowspan="2" colspan="1">Receiver object recovery</td> <td align="left">Object handed to application upon complete reception</td> <td align="center" rowspan="1" colspan="2">Object may be handed before| | object | handed |completion if| | recovery | to |MPD@availabilityTimeOffset| | | application | signaled | | | upon | | | | complete | | | | reception | | | +---------------+--------------------------------------+ | | - | Fastsignaled</td> </tr> <tr> <td align="center">-</td> <td align="center" colspan="2">Fast Stream acquisition| | | | guideline provided | +---------------+---------------+--------------------------------------+ ]]></artwork> </figure>guidelines provided</td> </tr> </tbody> </table> </section> <sectiontitle="Securityanchor="sect-11" numbered="true" toc="default"> <name>Security and PrivacyConsiderations" anchor="sect-11"><section title="Security Considerations" anchor="sect-11.1"><t>Considerations</name> <section anchor="sect-11.1" numbered="true" toc="default"> <name>Security Considerations</name> <t> As noted in <xreftarget="sect-9"/>,target="sect-9" format="default"/>, ROUTE is aligned with FLUTE as specified in RFC 6726 <xreftarget="RFC6726"/> (see <xref target="sect-9"/>),target="RFC6726" format="default"/> and only diverges in certain signaling optimizations, especially for the real-time object delivery case.HenceHence, most of the security considerations documented in RFC 6726 <xreftarget="RFC6726"/>target="RFC6726" format="default"/> for the data flow itself, the session metadata (session control parameters in RFC 6726 <xreftarget="RFC6726"/>),target="RFC6726" format="default"/>), and the associated building blocks apply directly toROUTE,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 <xreftarget="RFC6726"/> SHOULDtarget="RFC6726" format="default"/>, <bcp14>SHOULD</bcp14> be used for ROUTE. Additionally, RFC 3740 <xreftarget="RFC3740"/>target="RFC3740" format="default"/> documents multicast security architecture in great detail with clear security recommendationswhich SHOULDthat <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 RFC63479147 <xreftarget="RFC6347"/> SHALL apply. At the time, draft DTLS 1.3 based on TSL 1.3 <xref target="I-D.ietf-tls-dtls13"/> is pending publication, and maytarget="RFC9147" format="default"/> <bcp14>SHOULD</bcp14> beconsidered as the alternate means for security post publication.</t>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.HenceHence, a service using ROUTESHOULD<bcp14>SHOULD</bcp14> take these threats into consideration and address them appropriately following theguidelineguidelines provided by RFC 6726 <xreftarget="RFC6726"/>. Additionallytarget="RFC6726" format="default"/>. Additionally, to the recommendations of RFC 6726 <xreftarget="RFC6726"/>,target="RFC6726" format="default"/>, for Internet connected devices, servicesSHOULD<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 unicastdomaindomain, which can enable highly secure access of session description data. Accessing viaunicast howeverunicast, however, will have different privacy considerations, noted in <xreftarget="sect-11.2"/>.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 protocolSHOULD<bcp14>SHOULD</bcp14> betime-synchronizedtime 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 ofFDT instanceFDT-Instances andhencehence, the corresponding threats noted in RFC 6726 <xreftarget="RFC6726"/>target="RFC6726" format="default"/> do not apply directly to ROUTE in this case. Thethreat howeverthreat, 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.HenceHence, integrity protection recommendations of ALC/LCT headerSHOULD<bcp14>SHOULD</bcp14> be considered with higher emphasis in this case for ROUTE.</t> <t> Finally, attacks against the congestion control building block for the case of ROUTE can impact the optional fast stream acquisition specified in <xreftarget="sect-6.2"/>.target="sect-6.2" format="default"/>. ReceiversSHOULD<bcp14>SHOULD</bcp14> have robustness against timestamp values that are suspicious,e.g.e.g., by comparing the signaled time in the LCT headers with the approximate time signaled by the MPD, andSHOULD<bcp14>SHOULD</bcp14> discard outlying values. Additionally, receiversMUST<bcp14>MUST</bcp14> adhere to the expiry timelines as specified in <xreftarget="sect-6"/>.target="sect-6" format="default"/>. Integrity protection mechanisms documented in RFC 6726 <xreftarget="RFC6726"/> SHOULDtarget="RFC6726" format="default"/> <bcp14>SHOULD</bcp14> be used to address this threat.</t> </section> <sectiontitle="Privacy Considerations" anchor="sect-11.2"><t>anchor="sect-11.2" numbered="true" toc="default"> <name>Privacy Considerations</name> <t> Encryption mechanisms recommended for security considerations in <xreftarget="sect-11.1"/> SHOULDtarget="sect-11.1" format="default"/> <bcp14>SHOULD</bcp14> also be applied to enable privacy and protection from snooping attacks.</t> <t> Since this protocol is primarily targeted for IP multicast/broadcastenvironmentenvironments where the end user is mostly listening, identity protection and user data retention considerations are more protected than in the unicast case. Best practices for enabling privacy on IP multicast/broadcastSHOULD<bcp14>SHOULD</bcp14> be applied by the operators,e.g. Recommendations for DNS Privacy Service Operatorse.g., "<xref target="RFC8932" format="title"/>" in RFC 8932 <xreftarget="RFC8932"/>.</t>target="RFC8932" format="default"/>.</t> <t> However, if clients access session description information via HTTPS, the same privacy considerations and solutionsSHALL<bcp14>SHALL</bcp14> apply to this access as for regular HTTPS communication, an areawhichthat is very well studied and the concepts of which are being integrated directly into newer transport protocols such as IETF QUIC <xreftarget="RFC9000"/>target="RFC9000" format="default"/> enabling HTTP/3 <xreftarget="I-D.ietf-quic-http"/>. Hencetarget="I-D.ietf-quic-http" format="default"/>. Hence, such newer protocolsSHOULD<bcp14>SHOULD</bcp14> be used to foster privacy.</t> <t> Note that streaming servicesMAY<bcp14>MAY</bcp14> contain content that may only be accessed via DRM (digital rights management) systems. DRM systems can prevent unauthorized access to content delivered via ROUTE.</t> </section> </section> <sectiontitle="IANA Considerations" anchor="sect-12"><t> Thisanchor="sect-12" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas norequests forIANAaction.</t>actions. </t> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC8174; &RFC5651; &RFC5775; &RFC6726; &RFC6330; &RFC3986; &RFC1952; &RFC2557; &RFC8551; &RFC5445; &RFC5052; &RFC6363; &RFC7231; <!-- draft-zia-route-06-manual.txt(1823): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [ATSCA331] ATSC A/331:2019, "ATSC Standard: Signaling,<displayreference target="I-D.ietf-quic-http" to="HTTP3"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5651.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5775.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6330.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5445.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5052.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6363.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/> <reference anchor="ATSCA331"> <front> <title>Signaling, Delivery, Synchronization, and ErrorProtection", June 2019. -->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> </references><references title="Informative References"> &RFC6968; <!-- draft-zia-route-06-manual.txt(1833): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [DVBMABR] ETSI: "Digital<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6968.xml"/> <reference anchor="DVBMABR"> <front> <title> Digital Video Broadcasting (DVB); Adaptive media streaming over IPmulticast", ETSI TS 103 769 V1.1.1 (2020-11) November 2020. --> <!-- draft-zia-route-06-manual.txt(1837): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [DASH] ISO/IEC 23009-1:2019: "Informationmulticast </title> <author> <organization>ETSI</organization> </author> <date month="November" year="2020"/> </front> <seriesInfo name="ETSI TS" value="103 769"/> <refcontent>version 1.1.1</refcontent> </reference> <reference anchor="DASH" target="https://www.iso.org/standard/79329.html"> <front> <title>Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segmentformats", Fourth edition, December 2019. --> <!-- draft-zia-route-06-manual.txt(1841): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [CMAF] ISO/IEC 23000-19:2018: "Informationformats</title> <author> <organization>International Organization for Standardization</organization> </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"> <front> <title>Information technology--- Multimedia application format (MPEG-A)--- Part 19: Common media application format (CMAF) for segmentedmedia", First edition, January 2018. --> <!-- draft-zia-route-06-manual.txt(1845): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [MBMS] ETSI: "Universalmedia</title> <author> <organization>International Organization for Standardization</organization> </author> <date month="January" year="2018" /> </front> <seriesInfo name="ISO/IEC FDIS" value="23000-19"/> <refcontent>First edition</refcontent> </reference> <reference anchor="MBMS"> <front> <title>Universal Mobile Telecommunications Systems (UMTS); LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS); Protocols andcodecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126 346 v13.3.0 (2016-01), European Telecommunications Standards Institute, January 2016. --> &RFC3740; &I-D.ietf-quic-http; &RFC9000; &RFC6347; &RFC8932; &I-D.ietf-tls-dtls13;codecs</title> <author> <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.RFC.3740.xml"/> <reference anchor="I-D.ietf-quic-http"> <front> <title>Hypertext Transfer Protocol Version 3 (HTTP/3) </title> <author fullname="Mike Bishop" role="editor"> </author> <date month="February" day="2" year="2021"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-quic-http-34.txt"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8932.xml"/> </references> </references> <sectiontitle="Acknowledgments" anchor="sect-14"><t>anchor="sect-14" numbered="false" toc="default"> <name>Acknowledgments</name> <t> As outlined in the introduction and in ROUTE concepts in <xreftarget="sect-9"/>,target="sect-9" format="default"/>, the concepts specified in this document are the culmination of the collaborative work of several experts and organizations over the years. The authors would especially like to acknowledge the work and efforts of the following people and organizations to help realize the technologies described in this document (in no specific order):Mike Luby, Kent Walker, Charles Lo,<contact fullname="Mike Luby"/>, <contact fullname="Kent Walker"/>, <contact fullname="Charles Lo"/>, and other colleagues from Qualcomm Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D.</t> </section> </back> </rfc>