rfc9223.original   rfc9223.txt 
Internet Draft Waqar Zia,
Thomas Stockhammer,
Lenaig Chaponniere,
Giridhar Mandyam,
Qualcomm Incorporated
Michael Luby,
Intended status: Informational BitRipple, Inc.
Expires: August 2022 February 4, 2022
Real-time Transport Object delivery over Unidirectional Transport Independent Submission W. Zia
(ROUTE) Request for Comments: 9223 T. Stockhammer
draft-zia-route-06.txt Category: Informational Qualcomm CDMA Technologies GmbH
ISSN: 2070-1721 L. Chaponniere
G. Mandyam
Qualcomm Technologies Inc.
M. Luby
BitRipple, Inc.
April 2022
Real-Time Transport Object Delivery over Unidirectional Transport
(ROUTE)
Abstract Abstract
The Real-time Transport Object delivery over Unidirectional Transport The Real-time Transport Object delivery over Unidirectional Transport
protocol (ROUTE protocol) is specified for robust delivery of (ROUTE) protocol is specified for robust delivery of Application
Application Objects, including Application Objects with real-time Objects, including Application Objects with real-time delivery
delivery constraints, to receivers over a unidirectional transport. constraints, to receivers over a unidirectional transport.
Application Objects consist of data that has meaning to applications Application Objects consist of data that has meaning to applications
that use the ROUTE protocol for delivery of data to receivers, for that use the ROUTE protocol for delivery of data to receivers; for
example, it can be a file, or a DASH or HLS segment, a WAV audio example, it can be a file, a Dynamic Adaptive Streaming over HTTP
clip, etc. The ROUTE protocol also supports low-latency streaming (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc.
applications. The ROUTE protocol also supports low-latency streaming applications.
The ROUTE protocol is suitable for unicast, broadcast, and multicast The ROUTE protocol is suitable for unicast, broadcast, and multicast
transport. Therefore, it can be run over UDP/IP including multicast transport. Therefore, it can be run over UDP/IP, including multicast
IP. The ROUTE protocol can leverage the features of the underlying IP. The ROUTE protocol can leverage the features of the underlying
protocol layer, e.g. to provide security it can leverage IP security protocol layer, e.g., to provide security, it can leverage IP
protocols such as IPSec. security protocols such as IPsec.
This document specifies the ROUTE protocol such that it could be used This document specifies the ROUTE protocol such that it could be used
by a variety of services for delivery of Application Objects by by a variety of services for delivery of Application Objects by
specifying their own profiles of this protocol (e.g. by adding or specifying their own profiles of this protocol (e.g., by adding or
constraining some features). constraining some features).
This is not an IETF specification and does not have IETF consensus. This is not an IETF specification and does not have IETF consensus.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This is a contribution to the RFC Series, independently of any other
http://www.ietf.org/shadow.html RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on August 4, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9223.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction
1.1. Overview..................................................4 1.1. Overview
1.2. Protocol Stack for ROUTE..................................6 1.2. Protocol Stack for ROUTE
1.3. Data Model................................................6 1.3. Data Model
1.4. Architecture and Scope of Specification...................7 1.4. Architecture and Scope of Specification
1.5. Intellectual Property.....................................9 1.5. Conventions Used in This Document
1.6. Conventions used in this document.........................9 2. ROUTE Packet Format
2. ROUTE Packet Format............................................9 2.1. Packet Structure and Header Fields
2.1. Packet Structure and Header Fields........................9 2.2. LCT Header Extensions
2.2. LCT Header Extensions....................................11 2.3. FEC Payload ID for Source Flows
2.3. FEC Payload ID for Source Flows..........................11 2.4. FEC Payload ID for Repair Flows
2.4. FEC Payload ID for Repair Flows..........................12 3. Session Metadata
3. Session Metadata..............................................12 3.1. Generic Metadata
3.1. Generic Metadata.........................................12 3.2. Session Metadata for Source Flows
3.2. Session Metadata for Source Flows........................13 3.3. Session Metadata for Repair Flows
3.3. Session metadata for Repair Flows........................14 4. Delivery Object Mode
4. Delivery Object Mode..........................................15 4.1. File Mode
4.1. File Mode................................................15 4.1.1. Extensions to FDT
4.1.1. Extensions to FDT...................................15 4.1.2. Constraints on Extended FDT
4.1.2. Constraints on Extended FDT.........................16 4.2. Entity Mode
4.2. Entity Mode..............................................16 4.3. Unsigned Package Mode
4.3. Unsigned Package Mode....................................17 4.4. Signed Package Mode
4.4. Signed Package Mode......................................18 5. Sender Operation
5. Sender Operation..............................................18 5.1. Usage of ALC and LCT for Source Flow
5.1. Usage of ALC and LCT for Source Flow.....................18 5.2. ROUTE Packetization for Source Flow
5.2. ROUTE Packetization for Source Flow......................19 5.2.1. Basic ROUTE Packetization
5.2.1. Basic ROUTE Packetization...........................20 5.2.2. ROUTE Packetization for CMAF Chunked Content
5.2.2. ROUTE Packetization for CMAF Chunked Content........20 5.3. Timing of Packet Emission
5.3. Timing of Packet Emission................................21 5.4. Extended FDT Encoding for File Mode Sending
5.4. Extended FDT Encoding for File Mode Sending..............21 5.5. FEC Framework Considerations
5.5. FEC Framework Considerations.............................21 5.6. FEC Transport Object Construction
5.6. FEC Transport Object Construction........................22 5.7. Super-Object Construction
5.7. Super-Object Construction................................24 5.8. Repair Packet Considerations
5.8. Repair Packet Considerations.............................24 5.9. Summary FEC Information
5.9. Summary FEC Information..................................25 6. Receiver Operation
6. Receiver operation............................................26 6.1. Basic Application Object Recovery for Source Flows
6.1. Basic Application Object Recovery for Source Flows.......26 6.2. Fast Stream Acquisition
6.2. Fast Stream Acquisition..................................28 6.3. Generating Extended FDT-Instance for File Mode
6.3. Generating Extended FDT Instance for File Mode...........28 6.3.1. File Template Substitution for Content-Location
6.3.1. File Template Substitution for Content-Location Derivation
Derivation.................................................28 6.3.2. File@Transfer-Length Derivation
6.3.2. File@Transfer-Length Derivation.....................29 6.3.3. FDT-Instance@Expires Derivation
6.3.3. FDT-Instance@Expires Derivation.....................29 7. FEC Application
7. FEC Application...............................................30 7.1. General FEC Application Guidelines
7.1. General FEC Application Guidelines.......................30 7.2. TOI Mapping
7.2. TOI Mapping..............................................30 7.3. Delivery Object Reception Timeout
7.3. Delivery Object Reception Timeout........................31 7.4. Example FEC Operation
7.4. Example FEC Operation....................................31 8. Considerations for Defining ROUTE Profiles
8. Considerations for Defining ROUTE Profiles....................32 9. ROUTE Concepts
9. ROUTE Concepts................................................33 9.1. ROUTE Modes of Delivery
9.1. ROUTE Modes of Delivery..................................33 9.2. File Mode Optimizations
9.2. File Mode Optimizations..................................33 9.3. In-Band Signaling of Object Transfer Length
9.3. In Band Signaling of Object Transfer Length..............33 9.4. Repair Protocol Concepts
9.4. Repair Protocol Concepts.................................34 10. Interoperability Chart
10. Interoperability Chart.......................................35 11. Security and Privacy Considerations
11. Security and Privacy Considerations..........................37 11.1. Security Considerations
11.1. Security Considerations.................................37 11.2. Privacy Considerations
11.2. Privacy Considerations..................................38 12. IANA Considerations
12. IANA Considerations..........................................38 13. References
13. References...................................................39 13.1. Normative References
13.1. Normative References....................................39 13.2. Informative References
13.2. Informative References..................................40 Acknowledgments
14. Acknowledgments..............................................41 Authors' Addresses
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The Real-time Transport Object delivery over Unidirectional Transport The Real-time Transport Object delivery over Unidirectional Transport
protocol (ROUTE protocol) can be used for robust delivery of (ROUTE) protocol can be used for robust delivery of Application
Application Objects, including Application Objects with real-time Objects, including Application Objects with real-time delivery
delivery constraints, to receivers over a unidirectional transport. constraints, to receivers over a unidirectional transport.
Unidirectional transport in this document has identical meaning as in Unidirectional transport in this document has identical meaning to
RFC 6726 [RFC6726], i.e., transport in the direction of receiver(s) that in RFC 6726 [RFC6726], i.e., transport in the direction of
from a sender. The robustness is enabled by a built-in mechanism e.g. receiver(s) from a sender. The robustness is enabled by a built-in
signaling for loss detection, enabling loss recovery, and optionally mechanism, e.g., signaling for loss detection, enabling loss
integrating application-layer Forward Error Correction (FEC). recovery, and optionally integrating application-layer Forward Error
Correction (FEC).
Application Objects consist of data that has meaning to applications Application Objects consist of data that has meaning to applications
that use the ROUTE protocol for delivery of data to receivers, e.g., that use the ROUTE protocol for delivery of data to receivers, e.g.,
an Application Object can be a file, or an MPEG Dynamic Adaptive an Application Object can be a file, an MPEG Dynamic Adaptive
Streaming over HTTP (DASH)[DASH] video segment, a WAV audio clip, an Streaming over HTTP (DASH) [DASH] video segment, a WAV audio clip, an
MPEG Common Media Application Format (CMAF) [CMAF] addressable MPEG Common Media Application Format (CMAF) [CMAF] addressable
resource, an MPEG-4 video clip, etc. resource, an MPEG-4 video clip, etc.
The ROUTE protocol is designed to enable delivery of sequences of The ROUTE protocol is designed to enable delivery of sequences of
related Application Objects in a timely manner to receivers, e.g., a related Application Objects in a timely manner to receivers, e.g., a
sequence of DASH video segments associated to a Representation or a sequence of DASH video segments associated to a Representation or a
sequence of CMAF addressable resources associated to a CMAF Track. sequence of CMAF addressable resources associated to a CMAF Track.
The applications of this protocol target services enabled on media The applications of this protocol target services enabled on media
consumption devices such as smartphones, tablets, television sets and consumption devices such as smartphones, tablets, television sets,
so on. Most of these applications are real-time in the sense that and so on. Most of these applications are real-time in the sense
they are sensitive to and reply upon such timely reception of data. that they are sensitive to and rely upon such timely reception of
The ROUTE protocol also supports chunked delivery of real-time data. The ROUTE protocol also supports chunked delivery of real-time
Application Objects to enable low latency streaming applications Application Objects to enable low-latency streaming applications
(similar in its properties to chunked delivery using HTTP). The (similar in its properties to chunked delivery using HTTP). The
protocol also enables low-latency delivery of DASH and Apple HTTP protocol also enables low-latency delivery of DASH and Apple HTTP
Live Streaming (HLS) content with CMAF Chunks. Live Streaming (HLS) content with CMAF Chunks.
Content not intended for rendering in real time as it is received Content not intended for rendering in real time as it is received
e.g. a downloaded application, or a file comprising continuous or (e.g., a downloaded application), a file comprising continuous or
discrete media and belonging to an app-based feature, or a file discrete media and belonging to an app-based feature, or a file
containing (opaque) data to be consumed by a Digital Rights containing (opaque) data to be consumed by a Digital Rights
Management (DRM) system client can also delivered by ROUTE. Management (DRM) system client can also be delivered by ROUTE.
The ROUTE protocol supports a caching model, where Application The ROUTE protocol supports a caching model where Application Objects
Objects are recovered into a cache at the receiver and may be made are recovered into a cache at the receiver and may be made available
available to applications via standard HTTP requests from the cache. to applications via standard HTTP requests from the cache. Many
Many current day applications rely on using HTTP to access content, current day applications rely on using HTTP to access content; hence,
and hence this approach enables such applications in this approach enables such applications in broadcast/multicast
broadcast/multicast environments. environments.
ROUTE is aligned with FLUTE as defined in RFC 6726 [RFC6726] as well ROUTE is aligned with File Delivery over Unidirectional Transport
as the extensions defined in MBMS [MBMS], but also makes use of some (FLUTE) as defined in RFC 6726 [RFC6726] as well as the extensions
principles of FCAST (Object Delivery for the ALC and NACK-Oriented defined in Multimedia Broadcast/Multicast Service (MBMS) [MBMS], but
Reliable Multicast Protocols) as defined in RFC 6968 [RFC6968]; for it also makes use of some principles of FCAST (Object Delivery for
the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
Multicast (NORM) Protocols) as defined in RFC 6968 [RFC6968]; for
example, object metadata and the object content may be sent together example, object metadata and the object content may be sent together
in a compound object. in a compound object.
The alignment to FLUTE is enabled since in addition to reusing The alignment to FLUTE is enabled since in addition to reusing
several of the basic FLUTE protocol features, as referred to by this several of the basic FLUTE protocol features, as referred to by this
document, certain optimizations and restrictions are added that document, certain optimizations and restrictions are added that
enable optimized support for real-time delivery of media data; hence, enable optimized support for real-time delivery of media data; hence,
the name of the protocol. Among others, the source ROUTE protocol the name of the protocol. Among others, the source ROUTE protocol
enables or enhances the following functionalities: enables or enhances the following functionalities:
o Real-time delivery of object-based media data * Real-time delivery of object-based media data
o Flexible packetization, including enabling media-aware * Flexible packetization, including enabling media-aware
packetization as well as transport-aware packetization of delivery packetization as well as transport-aware packetization of delivery
objects objects
o Independence of Application Objects and delivery objects, i.e. a * Independence of Application Objects and delivery objects, i.e., a
delivery object may be a part of a file or may be a group of delivery object may be a part of a file or may be a group of
files. files.
Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE
protocol integrated with an ATSC 3.0 services layer. That protocol integrated with an ATSC 3.0 services layer. That
specification will be referred to as ATSC-ROUTE [ATSCA331] for the specification will be referred to as ATSC-ROUTE [ATSCA331] for the
remainder of this document. DVB has specified a profile of ATSC-ROUTE remainder of this document. Digital Video Broadcasting (DVB) has
in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming
[DVBMABR]. This document specifies the Application Object delivery over IP Multicast (DVB-MABR) [DVBMABR]. This document specifies the
aspects (delivery protocol) for such services, as the corresponding Application Object delivery aspects (delivery protocol) for such
delivery protocol could be used as a reference by a variety of services, as the corresponding delivery protocol could be used as a
services by specifying profiles of ROUTE in their respective fora, reference by a variety of services by specifying profiles of ROUTE in
e.g. by adding new optional features atop or by restricting various their respective fora, e.g., by adding new optional features atop or
optional features specified in this document in a specific service by restricting various optional features specified in this document
standard. Hence in the context of this document, the aforementioned in a specific service standard. Hence, in the context of this
ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition document, the aforementioned ATSC-ROUTE and DVB-MABR are the services
of profiles by the services also have to give due consideration to using ROUTE. The definition of profiles by the services also have to
compatibility issues, and some related guidelines are also provided give due consideration to compatibility issues, and some related
in this document. guidelines are also provided in this document.
This document is not an IETF specification and does not have IETF This document is not an IETF specification and does not have IETF
consensus. It is provided here to aid the production of interoperable consensus. It is provided here to aid the production of
implementations. interoperable implementations.
1.2. Protocol Stack for ROUTE 1.2. Protocol Stack for ROUTE
ROUTE delivers Application Objects such as MPEG DASH or HLS segments ROUTE delivers Application Objects such as MPEG DASH or HLS segments
and optionally the associated repair data, operating over UDP/IP and optionally the associated repair data, operating over UDP/IP
networks, as depicted in Figure 1. The session metadata signaling to networks, as depicted in Table 1. The session metadata signaling to
realize ROUTE session as specified in this document MAY be delivered realize a ROUTE session as specified in this document MAY be
out-of-band or in-band as well. Since ROUTE delivers objects in an delivered out of band or in band as well. Since ROUTE delivers
application cache at the receiver from where the application can objects in an application cache at the receiver from where the
access them using HTTP, an application like DASH may use its application can access them using HTTP, an application like DASH may
standardized unicast streaming mechanisms in conjunction with ROUTE use its standardized unicast streaming mechanisms in conjunction with
over broadcast/multicast to augment the services. ROUTE over broadcast/multicast to augment the services.
+-----------------------------------+ +--------------------------------------------------------+
|Application (DASH and HLS segments,| | Application (DASH and HLS segments, CMAF Chunks, etc.) |
| CMAF chunks etc.) | +--------------------------------------------------------+
+-----------------------------------+ | ROUTE |
| ROUTE | +--------------------------------------------------------+
+-----------------------------------+ | UDP |
| UDP | +--------------------------------------------------------+
+-----------------------------------+ | IP |
| IP | +--------------------------------------------------------+
+-----------------------------------+
Figure 1 Protocol Layering Table 1: Protocol Layering
1.3. Data Model 1.3. Data Model
The ROUTE data model is constituted by the following key concepts. The ROUTE data model is constituted by the following key concepts.
Application Object - data that has meaning to the application that Application Object: data that has meaning to the application that
uses the ROUTE protocol for delivery of data to receivers, e.g., an uses the ROUTE protocol for delivery of data to receivers,
Application Object can be a file, or a DASH video segment, a WAV e.g., an Application Object can be a file, a DASH video
audio clip, an MPEG-4 video clip, etc. segment, a WAV audio clip, an MPEG-4 video clip, etc.
Delivery Object - An object on course of delivery to the application Delivery Object: an object on course of delivery to the application
from the ROUTE sender to ROUTE receiver. from the ROUTE sender to ROUTE receiver.
Transport Object - an object identified by the Transport Object Transport Object: an object identified by the Transport Object
Identifier (TOI)in RFC 5651 [RFC5651]. It MAY be a either a source Identifier (TOI) in RFC 5651 [RFC5651]. It MAY be either a
or a repair object, if it is carried by a Source Flow or a Repair source or a repair object, depending on if it is carried by a
Flow, respectively. Source Flow or a Repair Flow, respectively.
Transport Session - An Layered Coding Transport (LCT) channel, as Transport Session: a Layered Coding Transport (LCT) channel, as
defined by RFC 5651 [RFC5651]. Transport session SHALL be uniquely defined by RFC 5651 [RFC5651]. A Transport Session SHALL be
identified by a unique Transport Session Identifier (TSI) value in uniquely identified by a unique Transport Session Identifier
the LCT header. The TSI is scoped by the IP address of the sender, (TSI) value in the LCT header. The TSI is scoped by the IP
and the IP address of the sender together with the TSI uniquely address of the sender, and the IP address of the sender
identify the session. Transport sessions are a subset of a ROUTE together with the TSI uniquely identify the session. Transport
session. For media delivery, a Transport Session would typically Sessions are a subset of a ROUTE session. For media delivery,
carry a media component, for example a DASH Representation. Within a Transport Session would typically carry a media component,
each transport session, one or more objects are carried, typically for example, a DASH Representation. Within each Transport
objects that are related, e.g. DASH Segments associated to one Session, one or more objects are carried, typically objects
Representation. that are related, e.g., DASH segments associated to one
Representation.
ROUTE Session - An ensemble or multiplex of one or more Transport ROUTE Session: an ensemble or multiplex of one or more Transport
Sessions. Each ROUTE Session is associated with an IP address/port Sessions. Each ROUTE session is associated with an IP address/
combination. ROUTE session typically carries one or more media port combination. A ROUTE session typically carries one or
components of streaming media e.g. Representations associated with a more media components of streaming media e.g., Representations
DASH Media Presentation. associated with a DASH Media Presentation.
Source Flow - Transport session carrying source data. Source Flow is Source Flow: a Transport Session carrying source data. Source Flow
independent of the repair Flow, i.e. the Source Flow MAY be used by is independent of the Repair Flow, i.e., the Source Flow MAY be
a ROUTE receiver without the ROUTE Repair Flows. used by a ROUTE receiver without the ROUTE Repair Flows.
Repair Flow - Transport session carrying repair data for one or more Repair Flow: a Transport Session carrying repair data for one or
Source Flows. more Source Flows.
1.4. Architecture and Scope of Specification 1.4. Architecture and Scope of Specification
The scope of the ROUTE protocol is to enable robust and real-time
transport of delivery objects using LCT packets. This architecture
is depicted in Figure 1.
The scope of the ROUTE protocol is robust and real-time transport of
delivery objects using LCT packets. This architecture is depicted in
Figure 2.
The normative aspects of the ROUTE protocol focus on the following The normative aspects of the ROUTE protocol focus on the following
aspects: aspects:
o The format of the LCT packets that carry the transport objects. * The format of the LCT packets that carry the transport objects.
o The robust transport of the delivery object using a repair * The robust transport of the delivery object using a repair
protocol based on Forward Error Correction (FEC). protocol based on Forward Error Correction (FEC).
o The definition and possible carriage of object metadata along with * The definition and possible carriage of object metadata along with
the delivery objects. Metadata may be conveyed in LCT packets the delivery objects. Metadata may be conveyed in LCT packets
and/or separate objects. and/or separate objects.
o The ROUTE session, LCT channel and delivery object description * The ROUTE session, LCT channel, and delivery object description
provided as service metadata signaling to enable the reception of provided as service metadata signaling to enable the reception of
objects. objects.
o The normative aspects (formats, semantics) of the delivery objects * The normative aspects (formats, semantics) of the delivery objects
conveyed as a content manifest to be delivered along with the conveyed as a content manifest to be delivered along with the
objects to optimize the performance for specific applications; objects to optimize the performance for specific applications
e.g., real-time delivery. The objects and manifest are made e.g., real-time delivery. The objects and manifest are made
available to the application through an Application Object cache. available to the application through an Application Object cache.
The interface of this cache to the application is not specified in The interface of this cache to the application is not specified in
this document, however it will typically be enabled by the this document; however, it will typically be enabled by the
application acting as an HTTP Client and the cache as the HTTP application acting as an HTTP client and the cache as the HTTP
server. server.
Application Objects Application Objects
Application to application Application to application
Objects from ^ Objects from ^
an application +--------------------------------------------+ an application +--------------------------------------------+
+ | ROUTE Receiver | | + | ROUTE Receiver | |
| | +------+------+ | | | +------+------+ |
| | | Application | | | | | Application | |
| | | Object Cache| | | | | Object Cache| |
skipping to change at page 8, line 48 skipping to change at line 351
| ROUTE | | | +---------------+ +----+----+ | | ROUTE | | | +---------------+ +----+----+ |
| Sender +----------+ ^ | | Sender +----------+ ^ |
+----+---+ | | | | +----+---+ | | | |
| | | +---------------+ | | | | | +---------------+ | |
| | | | Repair object | | | | | | | Repair object | | |
| | +->+ recovery +-------+ | | | +->+ recovery +-------+ |
+----------->+ +---------------+ | +----------->+ +---------------+ |
ROUTE | | ROUTE | |
Metadata +--------------------------------------------+ Metadata +--------------------------------------------+
Figure 2 Architecture/functional block diagram Figure 1: Architecture/Functional Block Diagram
1.5. Intellectual Property
The protocol described in this document may be subject to
intellectual property rights disclosed to the IETF in accordance with
BCP 78 and recorded in the datatracker entry for this document.
1.6. Conventions used in this document 1.5. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. ROUTE Packet Format 2. ROUTE Packet Format
2.1. Packet Structure and Header Fields 2.1. Packet Structure and Header Fields
The packet format used by ROUTE Source Flows and Repair Flows follows The packet format used by ROUTE Source Flows and Repair Flows follows
the ALC packet format specified in RFC 5775 [RFC5775], with the UDP the ALC packet format specified in RFC 5775 [RFC5775] with the UDP
header followed by the default LCT header and the source FEC Payload header followed by the default LCT header and the source FEC Payload
ID followed by the packet payload. The overall ROUTE packet format is ID followed by the packet payload. The overall ROUTE packet format
as depicted in Figure 3 below. is as depicted in Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header | | UDP Header |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header | | Default LCT header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID | | FEC Payload ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data | | Payload Data |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Overall ROUTE packet format
Figure 2: Overall ROUTE Packet Format
The Default LCT header is as defined in the LCT building block in RFC The Default LCT header is as defined in the LCT building block in RFC
5651 [RFC5651]. 5651 [RFC5651].
The LCT packet header fields SHALL be used as defined by the LCT The LCT packet header fields SHALL be used as defined by the LCT
building block in RFC 5651 [RFC5651]. The semantics and usage of the building block in RFC 5651 [RFC5651]. The semantics and usage of the
following LCT header fields SHALL be further constrained in ROUTE as following LCT header fields SHALL be further constrained in ROUTE as
follows: follows:
Version number (V) - This 4-bit field indicates the protocol version Version number (V): This 4-bit field indicates the protocol version
number. The version number SHALL be set to '0001', as specified in number. The version number SHALL be set to '0001', as specified
RFC 5651 [RFC5651]. in RFC 5651 [RFC5651].
Congestion Control flag (C) field - This 2-bit field, as defined in Congestion Control flag (C) field: This 2-bit field, as defined in
RFC 5651 [RFC5651], SHALL be set to '00'. RFC 5651 [RFC5651], SHALL be set to '00'.
Protocol-Specific Indication (PSI) - The most significant bit of this Protocol-Specific Indication (PSI): The most significant bit of this
two bit flag is called the Source Packet Indicator (SPI) and 2-bit flag is called the Source Packet Indicator (SPI) and
indicates whether the current packet is a source packet or an FEC indicates whether the current packet is a source packet or a FEC
repair packet. The SPI SHALL be set to '1' to indicate a source repair packet. The SPI SHALL be set to '1' to indicate a source
packet, and SHALL bet set to '0' to indicate a repair packet. packet and SHALL bet set to '0' to indicate a repair packet.
Transport Session Identifier flag (S) - This 1-bit field SHALL be set Transport Session Identifier flag (S): This 1-bit field SHALL be set
to '1' to indicate a 32-bit word in the TSI field. to '1' to indicate a 32-bit word in the TSI field.
Transport Object Identifier flag (O) - This 2-bit field SHALL be set Transport Object Identifier flag (O): This 2-bit field SHALL be set
to '01' to indicate the number of full 32-bit words in the TOI field. to '01' to indicate the number of full 32-bit words in the TOI
field.
Half-word flag (H) - This 1-bit field SHALL be set to '0' to indicate Half-word flag (H): This 1-bit field SHALL be set to '0' to indicate
that no half-word field sizes are used. that no half-word field sizes are used.
Codepoint (CP) - This 8-bit field is used to indicate the type of the Codepoint (CP): This 8-bit field is used to indicate the type of the
payload that is carried by this packet, and for ROUTE, is defined as payload that is carried by this packet; for ROUTE, it is defined
shown below to indicate the type of delivery object carried in the as shown below to indicate the type of delivery object carried in
payload of the associated ROUTE packet. The remaining, unmapped the payload of the associated ROUTE packet. The remaining
Codepoint values can be used by a service using ROUTE. In this case, unmapped Codepoint values can be used by a service using ROUTE.
the Codepoint values SHALL follow the semantics specified in the In this case, the Codepoint values SHALL follow the semantics
following table. "IS" stands for Initialization Segment of the media specified in the following table. "IS" stands for Initialization
content such as the DASH Initialization Segment [DASH]. The various Segment of the media content such as the DASH Initialization
modes of operation in the table (File/Entity/Package Mode) are Segment [DASH]. The various modes of operation in the table
specified in Section 4. The table also lists a Codepoint value range (File/Entity/Package Mode) are specified in Section 4. The table
that is reserved for future service-specific uses. also lists a Codepoint value range that is reserved for future
service-specific uses.
Codepoint value | Semantics +=================+=================================+
---------------------------------------------------- | Codepoint value | Semantics |
0 | Reserved (not used) +=================+=================================+
1 | Non Real Time (NRT) - File Mode | 0 | Reserved (not used) |
2 | NRT - Entity Mode +-----------------+---------------------------------+
3 | NRT - Unsigned Package Mode | 1 | Non Real Time (NRT) - File Mode |
4 | NRT - Signed Package Mode +-----------------+---------------------------------+
5 | New IS, timeline changed | 2 | NRT - Entity Mode |
6 | New IS, timeline continued +-----------------+---------------------------------+
7 | Redundant IS | 3 | NRT - Unsigned Package Mode |
8 | Media Segment, File Mode +-----------------+---------------------------------+
9 | Media Segment, Entity Mode | 4 | NRT - Signed Package Mode |
10 | Media Segment, File Mode with CMAF Random +-----------------+---------------------------------+
| Access Chunk | 5 | New IS, timeline changed |
11 - 255 | Reserved, service-specific +-----------------+---------------------------------+
| 6 | New IS, timeline continued |
+-----------------+---------------------------------+
| 7 | Redundant IS |
+-----------------+---------------------------------+
| 8 | Media Segment, File Mode |
+-----------------+---------------------------------+
| 9 | Media Segment, Entity Mode |
+-----------------+---------------------------------+
| 10 | Media Segment, File Mode with |
| | CMAF Random Access chunk |
+-----------------+---------------------------------+
| 11 - 255 | Reserved, service-specific |
+-----------------+---------------------------------+
Congestion Control Information (CCI) - For packets carrying DASH Table 2: Codepoint Values
segments, MAY convey the 32-bit earliest presentation time [DASH] of
the DASH segment contained in the ROUTE packet. In this case, this
information can be used by a ROUTE receiver for fast stream
acquisition (details in Section 6.2). Otherwise this field SHALL be
set to 0.
Transport Session Identifier (TSI) - This 32-bit field identifies the Congestion Control Information (CCI): For packets carrying DASH
Transport Session in ROUTE. The context of the Transport Session is segments, CCI MAY convey the 32-bit earliest presentation time
provided by signaling metadata. The value TSI = 0 SHALL only be used [DASH] of the DASH segment contained in the ROUTE packet. In this
for service-specific signaling. case, this information can be used by a ROUTE receiver for fast
stream acquisition (details in Section 6.2). Otherwise, this
field SHALL be set to 0.
Transport Object Identifier (TOI) - This 32-bit field SHALL identify Transport Session Identifier (TSI): This 32-bit field identifies the
the object within this session to which the payload of the current Transport Session in ROUTE. The context of the Transport Session
packet belongs. The mapping of the TOI field to the object is is provided by signaling metadata. The value TSI = 0 SHALL only
provided by the Extended File Delivery Table (FDT). be used for service-specific signaling.
2.2. LCT Header Extensions Transport Object Identifier (TOI): This 32-bit field SHALL identify
the object within this session to which the payload of the current
packet belongs. The mapping of the TOI field to the object is
provided by the Extended File Delivery Table (FDT).
2.2. LCT Header Extensions
The following LCT header extensions are defined or used by ROUTE: The following LCT header extensions are defined or used by ROUTE:
EXT_FTI - as specified in RFC 5775. EXT_FTI: as specified in RFC 5775.
EXT_TOL - The length in bytes of the multicast transport object shall EXT_TOL: the length in bytes of the multicast transport object shall
be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331]
24 bits or, if required, 48 bits of Transfer Length. The frequency of with 24 bits or, if required, 48 bits of Transfer Length. The
using the EXT_TOL header extension is determined by channel frequency of using the EXT_TOL header extension is determined by
conditions that may cause the loss of the packet carrying Close channel conditions that may cause the loss of the packet carrying
Object (B) flag [RFC5651]. the Close Object flag (B) [RFC5651].
NOTE: The transport object length can also be determined without the NOTE: The transport object length can also be determined without
use of EXT_TOL by examining the LCT packet with the Close Object (B) the use of EXT_TOL by examining the LCT packet with the Close
flag. However, if this packet is lost, then the EXT_TOL information Object flag (B). However, if this packet is lost, then the
can be used by the receiver to determine the transport object length. EXT_TOL information can be used by the receiver to determine the
transport object length.
EXT_TIME Header - as specified in RFC 5651 [RFC5651]. The Sender EXT_TIME Header: as specified in RFC 5651 [RFC5651]. The Sender
Current Time SHALL be signaled using EXT_TIME. Current Time SHALL be signaled using EXT_TIME.
2.3. FEC Payload ID for Source Flows 2.3. FEC Payload ID for Source Flows
The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme
used in ROUTE Source Flows is a 32-bit unsigned integer value that used in ROUTE Source Flows is a 32-bit unsigned integer value that
SHALL express the start_offset, as an octet number corresponding to SHALL express the start_offset as an octet number corresponding to
the first octet of the fragment of the delivery object carried in the first octet of the fragment of the delivery object carried in
this packet. The start_offset value for the first fragment of any this packet. The start_offset value for the first fragment of any
delivery object SHALL be set to 0. Figure 4 shows the 32-bit delivery object SHALL be set to 0. Figure 3 shows the 32-bit
start_offset field. start_offset field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start_offset | | start_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 FEC Payload ID for Source Flows.
2.4. FEC Payload ID for Repair Flows Figure 3: FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows
FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330]. FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330].
3. Session Metadata 3. Session Metadata
The required session metadata for Source and Repair Flows is The required session metadata for Source and Repair Flows is
specified in the following sections. The list specified here is not specified in the following sections. The list specified here is not
exhaustive; a service MAY signal more metadata to meet its needs. The exhaustive; a service MAY signal more metadata to meet its needs.
data format is also not specified beyond its cardinality; the exact The data format is also not specified beyond its cardinality; the
format of specifying the data is left for the service, e.g. by using exact format of specifying the data is left for the service, e.g., by
XML encoding format, as has been done by [DVBMABR] and [ATSCA331]. using XML encoding format, as has been done by [DVBMABR] and
It is specified in the following if an attribute is mandatory (m), [ATSCA331]. It is specified in the following if an attribute is
conditional mandatory (cm) or optional (o) to realize a basic ROUTE mandatory (m), conditional mandatory (cm) or optional (o) to realize
session. A mandatory filed SHALL always be present in the session a basic ROUTE session. A mandatory field SHALL always be present in
metadata, and a conditional mandatory field SHALL be present if the the session metadata, and a conditional mandatory field SHALL be
specified condition is true. The delivery of the session metadata to present if the specified condition is true. The delivery of the
the ROUTE receiver is beyond scope of this document. session metadata to the ROUTE receiver is beyond the scope of this
document.
3.1. Generic Metadata 3.1. Generic Metadata
Generic metadata is applicable to both Source and Repair Flows as Generic metadata is applicable to both Source and Repair Flows as
follows. Before a receiver can join a ROUTE session, the receiver follows. Before a receiver can join a ROUTE session, the receiver
needs to obtain this generic metadata that contains at least the needs to obtain this generic metadata that contains at least the
following information: following information:
ROUTE version number (m): The version number of ROUTE used in this ROUTE version number (m): the version number of ROUTE used in this
session. The version number conforming to this document SHALL be 1. session. The version number conforming to this document SHALL be
1.
Connection ID (m): unique identifier of a Connection, usually Connection ID (m): the unique identifier of a Connection, usually
consisting of 4-tuple: source IP address/source port number, consisting of the following 4-tuple: source IP address/source port
destination IP address/destination port number. The IP addresses can number, destination IP address/destination port number. The IP
be IPv4 or IPv6 addresses, depending upon which IP version is used by addresses can be IPv4 or IPv6 addresses depending upon which IP
the deployment. version is used by the deployment.
3.2. Session Metadata for Source Flows 3.2. Session Metadata for Source Flows
stsi (m) - LCT TSI value corresponding to the transport session for stsi (m): The LCT TSI value corresponding to the Transport Session
the Source Flow. for the Source Flow.
rt (o) - A Boolean flag which SHALL indicate whether the content rt (o): A Boolean flag that SHALL indicate whether the content
component carried by this Source Flow corresponds to real-time component carried by this Source Flow corresponds to real-time
streaming media, or non-real-time content. When set to "true", it streaming media or non-real-time content. When set to "true", it
SHALL be an indication of real-time content, and when absent or set SHALL be an indication of real-time content, and when absent or
to "false", it SHALL be an indication of non-real-time (NRT) content. set to "false", it SHALL be an indication of non-real-time (NRT)
content.
minBufferSize (o) - A 32-bit unsigned integer which SHALL represent, minBufferSize (o): A 32-bit unsigned integer that SHALL represent,
in kilobytes, the minimum required storage size of the receiver in kilobytes, the minimum required storage size of the receiver
transport buffer, for the parent LCT channel of this Source Flow. The transport buffer for the parent LCT channel of this Source Flow.
buffer holds the data belonging to a Source Object till its complete The buffer holds the data belonging to a source object until its
reception. This attribute is only applicable when rt = "true". complete reception. This attribute is only applicable when rt =
"true".
A service which chooses not to signal this attribute relies on A service that chooses not to signal this attribute relies on the
receiver implementation, which must discard the received data beyond receiver implementation, which must discard the received data
its buffering capability. Such discarding of data will impact the beyond its buffering capability. Such discarding of data will
service quality. impact the service quality.
EFDT (cm) - when present, SHALL contain a single instance of an FDT- EFDT (cm): When present, SHALL contain a single instance of an FDT-
Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain
optional FDT extensions as defined in Section 4.1. The optional EFDT the optional FDT extensions as defined in Section 4.1. The
element MAY only be present for File Mode of delivery. In File Mode, optional EFDT element MAY only be present for File Mode of
it SHALL be present if this Source Flow transports streaming media delivery. In File Mode, it SHALL be present if this Source Flow
segments. transports streaming media segments.
contentType (o) - A string that SHALL represent the media type for contentType (o): A string that SHALL represent the media type for
the media content. It SHALL obey the semantics of the Content-Type the media content. It SHALL obey the semantics of the Content-
header as specified by HTTP/1.1 protocol in RFC 7231 [RFC7231]. This Type header as specified by the HTTP/1.1 protocol in RFC 7231
document does not define any new contentType strings. In its absence, [RFC7231]. This document does not define any new contentType
the signalling of media type for the media content is beyond the strings. In its absence, the signaling of media type for the
scope of this document. media content is beyond the scope of this document.
applicationMapping (m) - A set of identifiers that provide an applicationMapping (m): A set of identifiers that provide an
application-specific mapping of the received Application Objects to application-specific mapping of the received Application Objects
the Source Flows. For example, for DASH, this would provide the to the Source Flows. For example, for DASH, this would provide
mapping a Source Flow to a specific DASH representation from a Media the mapping of a Source Flow to a specific DASH Representation
Presentation Description (MPD), the latter identified by its from a Media Presentation Description (MPD), the latter identified
Representation and corresponding Adaptation Set and Period IDs. by its Representation and corresponding Adaptation Set and Period
IDs.
3.3. Session metadata for Repair Flows 3.3. Session Metadata for Repair Flows
minBuffSize (o) - A 32-bit unsigned integer whose value SHALL minBuffSize (o): A 32-bit unsigned integer whose value SHALL
represent a required size of the receiver transport buffer for AL-FEC represent a required size of the receiver transport buffer for
decoding processing. When present, this attribute SHALL indicate the AL-FEC decoding processing. When present, this attribute SHALL
minimum buffer size that is required to handle all associated objects indicate the minimum buffer size that is required to handle all
that are assigned to a super-object i.e. a delivery object formed by associated objects that are assigned to a super-object, i.e., a
the concatenation of multiple FEC transport objects in order to delivery object formed by the concatenation of multiple FEC
bundle these FEC transport objects for AL-FEC protection. transport objects in order to bundle these FEC transport objects
for AL-FEC protection.
A service which chooses not to signal this attribute relies on A service that chooses not to signal this attribute relies on the
receiver implementation, which must discard the received repair data receiver implementation, which must discard the received repair
beyond its buffering capability. Such discarding of data will impact data beyond its buffering capability. Such discarding of data
the service quality. will impact the service quality.
fecOTI (m) - A parameter consisting of the concatenation of Common fecOTI (m): A parameter consisting of the concatenation of Common
and Scheme-Specific FEC Object Transmission Information (FEC OTI) as and Scheme-Specific FEC Object Transmission Information (FEC OTI)
defined in Sections 3.3.2 and 3.3.3 of RFC 6330 [RFC6330], and which as defined in Sections 3.3.2 and 3.3.3 of [RFC6330] and that
corresponds to the delivery objects carried in the Source Flow to corresponds to the delivery objects carried in the Source Flow to
which this Repair Flow is associated, with the following which this Repair Flow is associated, with the following
qualification. The 40-bit Transfer Length (F) field may either qualification: the 40-bit Transfer Length (F) field may either
represent the actual size of the object, or it is encoded as all represent the actual size of the object, or it is encoded as all
zeroes. In the latter case, it means that the FEC transport object zeroes. In the latter case, the FEC transport object size either
size is either unknown, or cannot be represented by this attribute. is unknown or cannot be represented by this attribute. In other
In other words, for the all-zeroes format, the delivery objects in words, for the all-zeroes format, the delivery objects in the
the Source flow correspond to streaming content - either a live Source Flow correspond to streaming content, either a live Service
Service whereby content encoding has not yet occurred at the time whereby content encoding has not yet occurred at the time this
this session data was generated, or pre-recorded streaming content session data was generated or pre-recorded streaming content whose
whose delivery object sizes, albeit known at the time of session data delivery object sizes, albeit known at the time of session data
generation, are variable and cannot be represented as a single value generation, are variable and cannot be represented as a single
by the fecOTI attribute. value by the fecOTI attribute.
ptsi (m) - TSI value(s) of each Source Flow protected by this Repair ptsi (m): TSI value(s) of each Source Flow protected by this Repair
Flow. Flow.
mappingTOIx (o) - Values of the constant X for use in deriving the mappingTOIx (o): Values of the constant X for use in deriving the
TOI of the delivery object of each protected Source Flow from the TOI of the delivery object of each protected Source Flow from the
TOI of the FEC (super-)object. The default value is "1". Multiple TOI of the FEC (super-)object. The default value is "1".
mappingTOIx values MAY be provided for each protected Source Flow, Multiple mappingTOIx values MAY be provided for each protected
depending upon the usage of FEC (super-)object. Source Flow depending upon the usage of FEC (super-)object.
mappingTOIy (o) - The corresponding constant Y to each mappingTOIx, mappingTOIy (o): The corresponding constant Y to each mappingTOIx,
when present, for use in deriving the parent SourceTOI value from the when present, for use in deriving the parent SourceTOI value from
above equation. The default value is "0". the above equation. The default value is "0".
4. Delivery Object Mode 4. Delivery Object Mode
ROUTE provides several different delivery object modes, and one of ROUTE provides several different delivery object modes, and one of
these modes may suite the application needs better for a given these modes may suit the application needs better for a given
transport session. A delivery object is self-contained for the Transport Session. A delivery object is self contained for the
application, typically associated with certain properties, metadata application, typically associated with certain properties, metadata,
and timing-related information that are of relevance for the and timing-related information relevant to the application. The
application. The signaling of the delivery object mode is done on an signaling of the delivery object mode is done on an object basis
object based using Codepoint as specified in Section 2.1. using Codepoint as specified in Section 2.1.
4.1. File Mode 4.1. File Mode
File mode uses an out-of-band Extended FDT (EDFT) signaling for File Mode uses an out-of-band Extended FDT (EFDT) signaling for
recovery of delivery objects with the following extensions and recovery of delivery objects with the following extensions and
considerations. considerations.
4.1.1. Extensions to FDT 4.1.1. Extensions to FDT
Following extensions are specified to FDT specified in RFC 6726 The following extensions are specified to FDT, as specified in RFC
[RFC6726]. An Extended FDT Instance is an instance of FLUTE FDT as 6726 [RFC6726]. An Extended FDT-Instance is an instance of FLUTE
specified in [RFC6726], plus optionally one or more of the following FDT, as specified in [RFC6726], plus optionally one or more of the
extensions. following extensions:
efdtVersion - A value that SHALL represent the version of this efdtVersion: A value that SHALL represent the version of this
Extended FDT Instance. Extended FDT-Instance.
maxExpiresDelta - Let "tp" represent the wall clock time at the maxExpiresDelta: Let "tp" represent the wall clock time at the
receiver when the receiver acquires the first ROUTE packet carrying receiver when the receiver acquires the first ROUTE packet
data of the object described by this Extended FDT Instance. carrying data of the object described by this Extended FDT-
maxExpiresDelta, when present, SHALL represent a time interval which Instance. maxExpiresDelta, when present, SHALL represent a time
when added to "tp" SHALL represent the expiration time of the interval that when added to "tp" SHALL represent the expiration
associated Extended FDT Instance "te". The time interval is expressed time of the associated Extended FDT-Instance "te". The time
in number of seconds. When maxExpiresDelta is not present, the interval is expressed in number of seconds. When maxExpiresDelta
expiration time of the Extended FDT Instance SHALL be given by the is not present, the expiration time of the Extended FDT-Instance
sum of a) the value of the ERT field in the EXT_TIME LCT header SHALL be given by the sum of a) the value of the ERT field in the
extension in the first ROUTE packet carrying data of that file, and EXT_TIME LCT header extension in the first ROUTE packet carrying
b) the current receiver time when parsing the packet header of that data of that file, and b) the current receiver time when parsing
ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for the packet header of that ROUTE packet. See Sections 5.4 and
deriving the Extended FDT Instance expiration time. Hence te__= tp + 6.3.3 on additional rules for deriving the Extended FDT-Instance
maxExpiresDelta expiration time. Hence, te = tp + maxExpiresDelta
maxTransportSize - An attribute that SHALL represent the maximum maxTransportSize: An attribute that SHALL represent the maximum
transport size in bytes of any delivery object described by this transport size in bytes of any delivery object described by this
Extended FDT Instance. This attribute SHALL be present if a) the Extended FDT-Instance. This attribute SHALL be present if a) the
fileTemplate is present in Extended FDT-Instance; or b) one or more fileTemplate is present in Extended FDT-Instance, or b) one or
File elements, if present in this Extended FDT Instance, do not more File elements, if present in this Extended FDT-Instance, do
include the Transfer-Length attribute. When maxTransportSize is not not include the Transfer-Length attribute. When maxTransportSize
present, the maximum transport size is not signaled, while other is not present, the maximum transport size is not signaled, while
signalling such as the Transfer-Length attribute signal the exact other signaling such as the Transfer-Length attribute signal the
transfer length of the object. exact Transfer Length of the object.
fileTemplate: A string value, which when present and in conjunction
with parameter substitution, is used in deriving the Content-
Location attribute for the delivery object described by this
Extended FDT-Instance. It SHALL include the "$TOI$" identifier.
Each identifier MAY be suffixed as needed by specific file names
within the enclosing '$' characters following this prototype:
%0[width]d
fileTemplate - A string value, which when present and in conjunction
with parameter substitution, is used in deriving the Content-Location
attribute, for the delivery object described by this Extended FDT
Instance. It SHALL include the "$TOI$" identifier. Each identifier
MAY be suffixed as needed by specific file names, within the
enclosing '$' characters following this prototype:
%0[width]d
The width parameter is an unsigned integer that provides the minimum The width parameter is an unsigned integer that provides the minimum
number of characters to be printed. If the value to be printed is number of characters to be printed. If the value to be printed is
shorter than this number, the result SHALL be padded with leading shorter than this number, the result SHALL be padded with leading
zeroes. The value is not truncated even if the result is larger. When zeroes. The value is not truncated even if the result is larger.
no format tag is present, a default format tag with width=1 SHALL be When no format tag is present, a default format tag with width=1
used. SHALL be used.
Strings other than identifiers SHALL only contain characters that are Strings other than identifiers SHALL only contain characters that are
permitted within URIs according to RFC 3986 [RFC3986]. permitted within URIs according to RFC 3986 [RFC3986].
$$ Is an escape sequence in fileTemplate value, i.e. "$$" is non- $$ is an escape sequence in fileTemplate value, i.e., "$$" is non-
recursively replaced with a single "$" recursively replaced with a single "$".
The usage of fileTemplate is described in Sender and Receiver The usage of fileTemplate is described in Sender and Receiver
operations in Sections 5.4 and 6.3, respectively. operations in Sections 5.4 and 6.3, respectively.
4.1.2. Constraints on Extended FDT 4.1.2. Constraints on Extended FDT
The Extended FDT Instance SHALL conform to an FDT Instance according The Extended FDT-Instance SHALL conform to an FDT-Instance according
to RFC 6726 [RFC6726], with the following constraints: at least one to RFC 6726 [RFC6726] with the following constraints: at least one
File element and the @Expires attribute SHALL be present. File element and the @Expires attribute SHALL be present.
Content encoding MAY be used for delivery of any file described by an Content encoding MAY be used for delivery of any file described by an
FDT-Instance.File element in the Extended FDT Instance. The content FDT-Instance.File element in the Extended FDT-Instance. The content
encoding defined in the present document is gzip [RFC1952]. When encoding defined in the present document is gzip [RFC1952]. When
content encoding is used, the File@Content-Encoding and File@Content- content encoding is used, the File@Content-Encoding and File@Content-
Length attributes SHALL be present in the Extended FDT Instance. Length attributes SHALL be present in the Extended FDT-Instance.
4.2. Entity Mode 4.2. Entity Mode
For Entity Mode, the following applies: For Entity Mode, the following applies:
o Delivery Object metadata SHALL be expressed in the form of entity * Delivery object metadata SHALL be expressed in the form of entity
headers as defined in HTTP/1.1, and which correspond to one or headers as defined in HTTP/1.1, which correspond to one or more of
more of the representation header fields, payload header fields the representation header fields, payload header fields, and
and response header fields as defined in Sections 3.1, 3.3 and 7, response header fields as defined in Sections 3.1, 3.3, and 7,
respectively, of RFC 7231. Additionally, a Digest HTTP response respectively, of [RFC7231].
header [RFC7231] MAY be included to enable a receiver to verify
the integrity of the multicast transport object.
The entity headers sent along with the delivery object provide all * The entity headers sent along with the delivery object provide all
information about that multicast transport object. information about that multicast transport object.
o Sending a media object (if the object is chunked) in Entity Mode * Sending a media object (if the object is chunked) in Entity Mode
may result in one of the following options: may result in one of the following options:
o If the length of the chunked object is known at sender, the - If the length of the chunked object is known at the sender, the
ROUTE Entity Mode delivery object MAY be sent without using ROUTE Entity Mode delivery object MAY be sent without using
HTTP/1.1 chunked transfer coding, i.e. the object starts with HTTP/1.1 chunked transfer coding, i.e., the object starts with
an HTTP header containing the Content Length field, followed an HTTP header containing the Content Length field followed by
by the concatenation of CMAF chunks: the concatenation of CMAF Chunks:
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk -- |HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
--||---chunk ----| --||---chunk ----|
o If the length of the chunked object is unknown at sender when - If the length of the chunked object is unknown at the sender
starting to send the object, HTTP/1.1 chunked transfer coding when starting to send the object, HTTP/1.1 chunked transfer
format SHALL be used: coding format SHALL be used:
|HTTP Header||Separator+Length||---chunk ---- |HTTP Header||Separator+Length||---chunk ----
||Separator+Length||---chunk ----||Separator+Length||---chunk ||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0| ----||Separator+Length||---chunk ----||Separator+Length=0|
Note, however, that it is not required to send a CMAF chunk in Note, however, that it is not required to send a CMAF Chunk in
exactly one HTTP chunk. exactly one HTTP chunk.
4.3. Unsigned Package Mode 4.3. Unsigned Package Mode
In this delivery mode, the delivery object consists of a group of In this delivery mode, the delivery object consists of a group of
files that are packaged for delivery only. If applied, the client is files that are packaged for delivery only. If applied, the client is
expected to unpack the package and provide each file as an expected to unpack the package and provide each file as an
independent object to the application. Packaging is supported by independent object to the application. Packaging is supported by
Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557], Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557],
where objects are packaged into one document for transport, with where objects are packaged into one document for transport, with
Content-Type set to multipart/related. When binary files are Content-Type set to multipart/related. When binary files are
included in the package, Content-Transfer-Encoding of "binary" included in the package, Content-Transfer-Encoding of "binary" should
should be used for those files. be used for those files.
4.4. Signed Package Mode 4.4. Signed Package Mode
In Signed Package Mode delivery, the delivery object consists of a In Signed Package Mode delivery, the delivery object consists of a
group of files that are packaged for delivery, and the package group of files that are packaged for delivery, and the package
includes one or more signatures for validation. Signed packaging is includes one or more signatures for validation. Signed packaging is
supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects
are packaged into one document for transport and the package includes are packaged into one document for transport and the package includes
objects necessary for validation of the package. objects necessary for validation of the package.
5. Sender Operation 5. Sender Operation
5.1. Usage of ALC and LCT for Source Flow 5.1. Usage of ALC and LCT for Source Flow
ROUTE Source Flow carry the source data as specified in RFC 5775 ROUTE Source Flow carries the source data as specified in RFC 5775
[RFC5775]. There are several special considerations that ROUTE [RFC5775]. There are several special considerations that ROUTE
introduces to the usage of the LCT building block as outlined in the introduces to the usage of the LCT building block as outlined in the
following: following:
o ROUTE limits the usage of the LCT building block to a single * ROUTE limits the usage of the LCT building block to a single
channel per session. Congestion control is thus sender-driven in channel per session. Congestion control is thus sender driven in
ROUTE. It also signifies that there is no specific congestion ROUTE. It also signifies that there is no specific congestion-
control related signalling from sender to the receiver; the CCI control-related signaling from the sender to the receiver; the CCI
field is either set to 0 or used for other purposes as specified field is either set to 0 or used for other purposes as specified
in Section 2.1. The functionality of receiver-driven layered in Section 2.1. The functionality of receiver-driven layered
multicast may still be offered by the application, allowing the multicast may still be offered by the application, allowing the
receiver application to select the appropriate delivery session receiver application to select the appropriate delivery session
based on the bandwidth requirement of that session. based on the bandwidth requirement of that session.
Further, following details apply to LCT: Further, the following details apply to LCT:
o The Layered Coding Transport (LCT) Building Block as defined in * The Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 [RFC5651] is used with the following constraints: RFC 5651 [RFC5651] is used with the following constraints:
o The TSI in the LCT header SHALL be set equal to the value of - The TSI in the LCT header SHALL be set equal to the value of
the stsi attribute in Section 3.2. the stsi attribute in Section 3.2.
o The Codepoint (CP) in the LCT header SHALL be used to signal - The Codepoint (CP) in the LCT header SHALL be used to signal
the applied formatting as defined in the signaling metadata. the applied formatting as defined in the signaling metadata.
o In accordance to ALC, a source FEC Payload ID header is used to - In accordance with ALC, a source FEC Payload ID header is used
identify, for FEC purposes, the encoding symbols of the to identify, for FEC purposes, the encoding symbols of the
delivery object, or a portion thereof, carried by the delivery object, or a portion thereof, carried by the
associated ROUTE packet. This information may be sent in associated ROUTE packet. This information may be sent in
several ways: several ways:
. As a simple new null FEC scheme with the following usage: o As a simple new null FEC scheme with the following usage:
. The value of the source FEC Payload ID header SHALL + The value of the source FEC Payload ID header SHALL be
be set to 0, in case the ROUTE packet contains the set to 0 in case the ROUTE packet contains the entire
entire delivery object, or delivery object, or
. The value of the source FEC Payload ID header SHALL + The value of the source FEC Payload ID header SHALL be
be set as a direct address (start offset) set as a direct address (start offset) corresponding to
corresponding to the starting byte position of the the starting byte position of the portion of the object
portion of the object carried in this packet using a carried in this packet using a 32-bit field.
32-bit field.
. In a compatible manner to RFC 6330 [RFC6330] where the o In a compatible manner to RFC 6330 [RFC6330] where the SBN
SBN and ESI defines the start offset together with the and ESI defines the start offset together with the symbol
symbol size T. size T.
. The signaling metadata provides the appropriate o The signaling metadata provides the appropriate parameters
parameters to indicate any of the above modes using the to indicate any of the above modes using the srcFecPayloadId
srcFecPayloadId attribute. attribute.
o The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651] * The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651]
MAY be used by the sender in the following manner: MAY be used by the sender in the following manner:
o The Sender Current Time (SCT), depending on the application, - The Sender Current Time (SCT), depending on the application,
MAY be used to occasionally or frequently signal the sender MAY be used to occasionally or frequently signal the sender
current time, possibly for reliever time synchronization. current time possibly for reliever time synchronization.
o The Expected Residual Time (ERT) MAY be used to indicate the - The Expected Residual Time (ERT) MAY be used to indicate the
expected remaining time for transmission of the current expected remaining time for transmission of the current object
object, to optimize detection of a lost delivery object. in order to optimize detection of a lost delivery object.
o The Sender Last Changed (SLC) flag is typically not utilized, - The Sender Last Changed (SLC) flag is typically not utilized
but MAY be used to indicate addition/removal of Segments. but MAY be used to indicate the addition/removal of Segments.
Additional extension headers MAY be used to support real-time Additional extension headers MAY be used to support real-time
delivery. Such extension headers are defined in Section 2.1. delivery. Such extension headers are defined in Section 2.1.
5.2. ROUTE Packetization for Source Flow 5.2. ROUTE Packetization for Source Flow
The following description of the ROUTE sender operation on the The following description of the ROUTE sender operation on the
mapping of the Application Object to the ROUTE packet payloads mapping of the Application Object to the ROUTE packet payloads
logically represents an extension of RFC 5445 [RFC5445], which in logically represents an extension of RFC 5445 [RFC5445], which in
turn inherits the context, language, declarations and restrictions of turn inherits the context, language, declarations, and restrictions
the FEC building block in RFC 5052 [RFC5052]. of the FEC building block in RFC 5052 [RFC5052].
The data carried in the payload of a given ROUTE packet constitute a The data carried in the payload of a given ROUTE packet constitutes a
contiguous portion of the Application Object. ROUTE source delivery contiguous portion of the Application Object. ROUTE source delivery
can be considered as a special case of the use of the Compact No-Code can be considered as a special case of the use of the Compact No-Code
Scheme associated with FEC Encoding ID = 0 according to Sections Scheme associated with FEC Encoding ID = 0 according to Sections
3.4.1 and 3.4.2 of RFC 5445 [RFC5445], in which the encoding symbol 3.4.1 and 3.4.2 of [RFC5445], in which the encoding symbol size is
size is exactly one byte. As specified in Section 2.1, for ROUTE exactly one byte. As specified in Section 2.1, for ROUTE Source
Source Flows, the FEC Payload ID SHALL deliver the 32-bit Flows, the FEC Payload ID SHALL deliver the 32-bit start_offset. All
start_offset. All receivers are expected to support, at minimum, receivers are expected to support, at minimum, operation with this
operation with this special case of the Compact No-Code FEC. special case of the Compact No-Code FEC.
Note that in the event the source object size is greater than 2^32 Note that in the event the source object size is greater than 2^32
bytes (approximately 4.3 GB), the applications (in the broadcaster bytes (approximately 4.3 GB), the applications (in the broadcaster
server and the receiver) are expected to perform segmentation/re- server and the receiver) are expected to perform segmentation/
assembly using methods beyond the scope of this document. reassembly using methods beyond the scope of this document.
Finally, in some special cases a ROUTE sender MAY need to produce Finally, in some special cases, a ROUTE sender MAY need to produce
ROUTE packets that do not contain any payload. This may be required, ROUTE packets that do not contain any payload. This may be required,
for example, to signal the end of a session. These data-less packets for example, to signal the end of a session. These dataless packets
do not contain FEC Payload ID or payload data, but only the LCT do not contain FEC Payload ID or payload data, but only the LCT
header fields. The total datagram length, conveyed by outer protocol header fields. The total datagram length, conveyed by outer protocol
headers (e.g., the IP or UDP header), enables receivers to detect the headers (e.g., the IP or UDP header), enables receivers to detect the
absence of the LCT header, FEC Payload ID and payload data. absence of the LCT header, FEC Payload ID, and payload data.
5.2.1. Basic ROUTE Packetization 5.2.1. Basic ROUTE Packetization
In the basic operation, it is assumed that the Application Object is In the basic operation, it is assumed that the Application Object is
fully available at the ROUTE sender. fully available at the ROUTE sender.
1. The amount of data to be sent in a single ROUTE packet is limited 1. The amount of data to be sent in a single ROUTE packet is limited
by the maximum transfer unit of the data packets or the size of by the maximum transfer unit of the data packets or the size of
the remaining data of the Application Object being sent, whichever the remaining data of the Application Object being sent,
is smaller. The transfer unit is determined either by knowledge of whichever is smaller. The transfer unit is determined either by
underlying transport block sizes or by other constraints. knowledge of underlying transport block sizes or by other
2. The start_offset field in the LCT header of the ROUTE packet constraints.
indicates the byte offset of the carried data in the Application
Object being sent. 2. The start_offset field in the LCT header of the ROUTE packet
3. The Close Object (B) flag is set to 1 if this is the last ROUTE indicates the byte offset of the carried data in the Application
packet carrying the data of the Application Object. Object being sent.
3. The Close Object flag (B) is set to 1 if this is the last ROUTE
packet carrying the data of the Application Object.
The order of packet delivery is arbitrary, but in the absence of The order of packet delivery is arbitrary, but in the absence of
other constraints delivery with increasing start_offset value is other constraints, delivery with increasing start_offset value is
recommended. recommended.
5.2.2. ROUTE Packetization for CMAF Chunked Content 5.2.2. ROUTE Packetization for CMAF Chunked Content
Following additional guidelines should be followed for ROUTE The following additional guidelines should be followed for ROUTE
packetization of CMAF Chunked Content in addition to the guideline of packetization of CMAF Chunked Content in addition to the guidelines
Section 5.2.1: of Section 5.2.1:
1. If it is the first ROUTE packet carrying a CMAF Random Access 1. If it is the first ROUTE packet carrying a CMAF Random Access
chunk, except for the first CMAF chunk in the segment, the chunk, except for the first CMAF Chunk in the segment, the
Codepoint value MAY be set to 10, as specified in the Codepoint Codepoint value MAY be set to 10, as specified in the Codepoint
value table in Section 2.1. The receiver MAY use this information value table in Section 2.1. The receiver MAY use this
for optimization of random access. information for optimization of random access.
2. As soon as the total length of the media object is known,
potentially with the packaging of the last CMAF chunk of a
segment, the EXT_TOL extension header MAY be added to the LCT
header to signal the Transfer Length, so that the receiver may
know this information in a timely fashion.
5.3. Timing of Packet Emission 2. As soon as the total length of the media object is known,
potentially with the packaging of the last CMAF Chunk of a
segment, the EXT_TOL extension header MAY be added to the LCT
header to signal the Transfer Length, so that the receiver may
know this information in a timely fashion.
5.3. Timing of Packet Emission
The sender SHALL use the timing information provided by the The sender SHALL use the timing information provided by the
application to time the emission of packets for a timely reception. application to time the emission of packets for a timely reception.
This information may be contained in the Application Objects e.g. This information may be contained in the Application Objects e.g.,
DASH Segments and/or the presentation manifest. Hence such packets of DASH segments and/or the presentation manifest. Hence, such packets
streaming media with real time constraints SHALL be sent in such a of streaming media with real-time constraints SHALL be sent in such a
way to enable their timely reception with respect to the presentation way as to enable their timely reception with respect to the
timeline. presentation timeline.
5.4. Extended FDT Encoding for File Mode Sending 5.4. Extended FDT Encoding for File Mode Sending
For File Mode Sending: For File Mode sending:
o The TOI field in the ROUTE packet header SHALL be set such that * The TOI field in the ROUTE packet header SHALL be set such that
Content-Location can be derived at the receiver according to File Content-Location can be derived at the receiver according to File
Template substitution specified in Section 6.3.1. Template substitution specified in Section 6.3.1.
o After sending the first packet with a given TOI value, none of the * After sending the first packet with a given TOI value, none of the
packets pertaining to this TOI SHALL be sent later than the wall packets pertaining to this TOI SHALL be sent later than the wall
clock time as derived from maxExpiresDelta. The EXT_TIME header clock time as derived from maxExpiresDelta. The EXT_TIME header
with Expected Residual Time (ERT) MAY be used in order to convey with Expected Residual Time (ERT) MAY be used in order to convey
more accurate expiry time. more accurate expiry time.
5.5. FEC Framework Considerations 5.5. FEC Framework Considerations
The FEC framework uses concepts of the FECFRAME work as defined in The FEC framework uses concepts of the FECFRAME work as defined in
RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052 RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052
[RFC5052], which is adopted in the existing FLUTE/ALC/LCT [RFC5052], which is adopted in the existing FLUTE/ALC/LCT
specifications. specifications.
The FEC design adheres to the following principles: The FEC design adheres to the following principles:
o FEC-related information is provided only where needed. * FEC-related information is provided only where needed.
o Receivers not capable of this framework can ignore repair packets. * Receivers not capable of this framework can ignore repair packets.
o The FEC is symbol-based with fixed symbol size per protected * The FEC is symbol based with fixed symbol size per protected
Source Flow. The ALC protocol and existing FEC schemes are reused. Source Flow. The ALC protocol and existing FEC schemes are
reused.
o A FEC Repair Flow provides protection of delivery objects from one * A FEC Repair Flow provides protection of delivery objects from one
or more Source Flows. or more Source Flows.
The FEC-specific components of the FEC framework are: The FEC-specific components of the FEC framework are:
o FEC Repair Flow declaration including all FEC-specific * FEC Repair Flow declaration including all FEC-specific
information. information.
o FEC transport object that is the concatenation of a delivery * A FEC transport object that is the concatenation of a delivery
object, padding octets and size information in order to form an N- object, padding octets, and size information in order to form a
symbol-sized chunk of data, where N >= 1. chunk of data that has a size in symbols of N, where N >= 1.
o FEC super-object that is the concatenation of one or more FEC * A FEC super-object that is the concatenation of one or more FEC
transport objects in order to bundle FEC transport objects for FEC transport objects in order to bundle FEC transport objects for FEC
protection. protection.
o FEC protocol and packet structure. * A FEC protocol and packet structure.
A receiver needs to be able to recover delivery objects from repair A receiver needs to be able to recover delivery objects from repair
packets based on available FEC information. packets based on available FEC information.
5.6. FEC Transport Object Construction 5.6. FEC Transport Object Construction
In order to identify a delivery object in the context of the Repair In order to identify a delivery object in the context of the repair
protocol, the following information is needed: protocol, the following information is needed:
o TSI and TOI of the delivery object. In this case, the FEC object * TSI and TOI of the delivery object. In this case, the FEC object
corresponds to the (entire) delivery object. corresponds to the (entire) delivery object.
o Octet range of the delivery object, i.e. start offset within the * Octet range of the delivery object, i.e., start offset within the
delivery object and number of subsequent and contiguous octets of delivery object and number of subsequent and contiguous octets of
delivery object that constitutes the FEC object (i.e., the FEC- delivery object that constitutes the FEC object (i.e., the FEC-
protected portion of the source object). In this case, the FEC protected portion of the source object). In this case, the FEC
object corresponds to a contiguous byte range portion of the object corresponds to a contiguous byte range portion of the
delivery object. delivery object.
Typically, for real-time object delivery with smaller delivery object Typically, for real-time object delivery with smaller delivery object
sizes, the first mapping is applied; i.e., the delivery object is an sizes, the first mapping is applied, i.e., the delivery object is a
FEC object. FEC object.
Assuming that the FEC object is the delivery object, for each Assuming that the FEC object is the delivery object, for each
delivery object, the associated FEC transport object is comprised of delivery object, the associated FEC transport object is comprised of
the concatenation of the delivery object, padding octets (P) and the the concatenation of the delivery object, padding octets (P), and the
FEC object size (F) in octets, where F is carried in a 4-octet field. FEC object size (F) in octets, where F is carried in a 4-octet field.
The FEC transport object size S, in FEC encoding symbols, SHALL be an The FEC transport object size S, in FEC encoding symbols, SHALL be an
integer multiple of the symbol size Y. integer multiple of the symbol size Y. S is determined from the
S is determined from the session information and/or the repair packet session information and/or the repair packet headers.
headers.
F is carried in the last 4 octets of the FEC transport object. F is carried in the last 4 octets of the FEC transport object.
Specifically, let: Specifically, let:
o F be the size of the delivery object in octets, * F be the size of the delivery object in octets,
o F' be the F octets of data of the delivery object, * F' be the F octets of data of the delivery object,
o f' denote the four octets of data carrying the value of F in * f' denote the four octets of data carrying the value of F in
network octet order (high-order octet first), network octet order (high-order octet first),
o S be the size of the FEC transport object with S=ceil((F+4)/Y), * S be the size of the FEC transport object with S=ceil((F+4)/Y),
where the ceil() function rounds the result upward to its nearest where the ceil() function rounds the result upward to its nearest
integer, integer,
o P' be S*Y-4-F octets of data, i.e. padding placed between the * P' be S*Y-4-F octets of data, i.e., padding placed between the
delivery object and the 4-byte field conveying the value of F and delivery object and the 4-byte field conveying the value of F and
located at the end of the FEC transport object, and located at the end of the FEC transport object, and
o O' be the concatenation of F', P' and f'. * O' be the concatenation of F', P', and f'.
O' then constitutes the FEC transport object of size S*Y octets. Note O' then constitutes the FEC transport object of size S*Y octets.
that padding octets and the object size F are not sent in source Note that padding octets and the object size F are not sent in source
packets of the delivery object, but are only part of an FEC transport packets of the delivery object but are only part of a FEC transport
object that FEC decoding recovers in order to extract the FEC object object that FEC decoding recovers in order to extract the FEC object
and thus the delivery object or portion of the delivery object that and thus the delivery object or portion of the delivery object that
constitutes the FEC object. In the above context, the FEC transport constitutes the FEC object. In the above context, the FEC transport
object size in symbols is S. object size in symbols is S.
The general information about an FEC transport object that is The general information about a FEC transport object that is conveyed
conveyed to an FEC-enabled receiver is the source TSI, source TOI and to a FEC-enabled receiver is the source TSI, source TOI, and the
the associated octet range within the delivery object comprising the associated octet range within the delivery object comprising the
associated FEC object. However, as the size in octets of the FEC associated FEC object. However, as the size in octets of the FEC
object is provided in the appended field within the FEC transport object is provided in the appended field within the FEC transport
object, the remaining information can be conveyed as: object, the remaining information can be conveyed as:
o TSI and TOI of the delivery object from which the FEC object * The TSI and TOI of the delivery object from which the FEC object
associated with the FEC transport object is generated associated with the FEC transport object is generated
o Start octet within delivery object for the associated FEC object * The start octet within the delivery object for the associated FEC
object
o Size in symbols of the FEC transport object, S * The size in symbols of the FEC transport object, S
5.7. Super-Object Construction 5.7. Super-Object Construction
From the FEC Repair Flow declaration, the construction of an FEC From the FEC Repair Flow declaration, the construction of a FEC
super-object as the concatenation of one or more FEC transport super-object as the concatenation of one or more FEC transport
objects can be determined. The FEC super-object includes the general objects can be determined. The FEC super-object includes the general
information about the FEC transport objects as described in the information about the FEC transport objects as described in the
previous sections, as well as the placement order of FEC transport previous sections, as well as the placement order of FEC transport
objects within the FEC super-object. objects within the FEC super-object.
Let: Let:
o N be the total number of FEC transport objects for the FEC super-
* N be the total number of FEC transport objects for the FEC super-
object construction. object construction.
o For i = 0,..., N-1, let S[i] be the size in symbols of FEC * For i = 0, ..., N-1, let S[i] be the size in symbols of FEC
transport object i. transport object i.
o B' be the FEC super-object which is the concatenation of the FEC * B' be the FEC super-object that is the concatenation of the FEC
transport objects in numerical order, comprised of K = Sum of N transport objects in numerical order, comprised of K = Sum of N
source symbols, each symbol denoted as S[i]. source symbols, each symbol denoted as S[i].
For each FEC super-object, the remaining general information that For each FEC super-object, the remaining general information that
needs to be conveyed to an FEC-enabled receiver, beyond what is needs to be conveyed to a FEC-enabled receiver, beyond what is
already carried in the FEC transport objects that constitute the FEC already carried in the FEC transport objects that constitute the FEC
super-object, comprises: super-object, comprises:
o The total number of FEC transport objects N. * The total number of FEC transport objects N.
o For each FEC transport object, the: * For each FEC transport object:
o TSI and TOI of the delivery object from which the FEC object - The TSI and TOI of the delivery object from which the FEC
associated with the FEC transport object is generated, object associated with the FEC transport object is generated,
o Start octet within delivery object for the associated FEC - The start octet within the delivery object for the associated
object, and FEC object, and
o Size in symbols of the FEC transport object. - The size in symbols of the FEC transport object.
The carriage of the FEC repair information is discussed below. The carriage of the FEC repair information is discussed below.
5.8. Repair Packet Considerations 5.8. Repair Packet Considerations
The repair protocol is based on Asynchronous Layered Coding (ALC) as The repair protocol is based on Asynchronous Layered Coding (ALC) as
defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT) defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT)
Building Block as defined in RFC 5651 [RFC5651] with the following Building Block as defined in RFC 5651 [RFC5651] with the following
details: details:
o The Layered Coding Transport (LCT) Building Block as defined in * The Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 [RFC5651] is used as defined in Asynchronous Layered RFC 5651 [RFC5651] is used as defined in Asynchronous Layered
Coding (ALC), Section 2.1. In addition, the following constraints Coding (ALC), Section 2.1. In addition, the following constraint
apply: applies:
o The TSI in the LCT header SHALL identify the Repair Flow to - The TSI in the LCT header SHALL identify the Repair Flow to
which this packet applies, by the matching value of the ptsi which this packet applies by the matching the value of the ptsi
attribute in the signaling metadata among the LCT channels attribute in the signaling metadata among the LCT channels
carrying Repair Flows. carrying Repair Flows.
o The FEC building block is used according to RFC 6330 [RFC6330], * The FEC building block is used according to RFC 6330 [RFC6330],
but only repair packets are delivered. but only repair packets are delivered.
o Each repair packet within the scope of the Repair Flow (as - Each repair packet within the scope of the Repair Flow (as
indicated by the TSI field in the LCT header) SHALL carry the indicated by the TSI field in the LCT header) SHALL carry the
repair symbols for a corresponding FEC transport object/super- repair symbols for a corresponding FEC transport object/super-
object as identified by its TOI. The repair object/super- object as identified by its TOI. The repair object/super-
object TOI SHALL be unique for each FEC super-object that is object TOI SHALL be unique for each FEC super-object that is
created within the scope of the TSI. created within the scope of the TSI.
5.9. Summary FEC Information 5.9. Summary FEC Information
For each super-object (identified by a unique TOI within a Repair For each super-object (identified by a unique TOI within a Repair
Flow that is in turn identified by the TSI in the LCT header) that is Flow that is in turn identified by the TSI in the LCT header) that is
generated, the following information needs to be communicated to the generated, the following information needs to be communicated to the
receiver: receiver:
o The FEC configuration consisting of: * The FEC configuration consisting of:
o FEC Object Transmission Information (OTI) per RFC 5052 - FEC Object Transmission Information (OTI) per RFC 5052
[RFC5052]. [RFC5052].
o Additional FEC information (see Section 3.3). - Additional FEC information (see Section 3.3).
o The total number of FEC objects included in the FEC super- - The total number of FEC objects included in the FEC super-
object, N. object, N.
o For each FEC transport object: * For each FEC transport object:
o TSI and TOI of the delivery object used to generate the FEC - TSI and TOI of the delivery object used to generate the FEC
object associated with the FEC transport object, object associated with the FEC transport object,
o Start octet within the delivery object of the associated FEC - The start octet within the delivery object of the associated
object, if applicable, and FEC object, if applicable, and
o The size in symbols of the FEC transport object, S. - The size in symbols of the FEC transport object, S.
The above information is delivered: The above information is delivered:
o Statically in the session metadata as defined in Section 3.3, and * Statically in the session metadata as defined in Section 3.3, and
o Dynamically in an LCT extension header. * Dynamically in an LCT extension header.
6. Receiver operation 6. Receiver Operation
The receiver receives packets and filters those packets according to The receiver receives packets and filters those packets according to
the following. From the ROUTE session and each contained LCT channel, the following. From the ROUTE session and each contained LCT
the receiver regenerates delivery objects from the ROUTE session and channel, the receiver regenerates delivery objects from the ROUTE
each contained LCT channel. session and each contained LCT channel.
In the event that the receiver receives data that does not conform to In the event that the receiver receives data that does not conform to
the ROUTE protocol specified in this document, the receiver SHOULD the ROUTE protocol specified in this document, the receiver SHOULD
attempt to recover gracefully by e.g. informing the application about attempt to recover gracefully by e.g., informing the application
the issues using means beyond the scope of this document. The ROUTE about the issues using means beyond the scope of this document. The
Packetization specified in Section 5.2.1 implies that the receiver ROUTE packetization specified in Section 5.2.1 implies that the
SHALL NOT receive overlapping data: if such a condition is receiver SHALL NOT receive overlapping data; if such a condition is
encountered at the receiver, the packet SHALL be assumed to be encountered at the receiver, the packet SHALL be assumed to be
corrupted. corrupted.
The basic receiver operation is provided below, it assumes an error- The basic receiver operation is provided below (it assumes an error-
free scenario, while repair considerations are provided in Section 7. free scenario), while repair considerations are provided in
Section 7.
6.1. Basic Application Object Recovery for Source Flows 6.1. Basic Application Object Recovery for Source Flows
Upon receipt of each ROUTE packet of a Source Flow, the receiver Upon receipt of each ROUTE packet of a Source Flow, the receiver
proceeds with the following steps in the order listed. proceeds with the following steps in the order listed.
1) The ROUTE receiver is expected to parse the LCT and FEC Payload ID 1) The ROUTE receiver is expected to parse the LCT and FEC Payload
to verify that it is a valid header. If it is not valid, then the ID to verify that it is a valid header. If it is not valid, then
payload is discarded without further processing. the payload is discarded without further processing.
2) All ROUTE packets used to recover a specific delivery object carry
the same TOI value in the LCT header.
3) The ROUTE receiver is expected to assert that the TSI and the
Codepoint represent valid operation points in the signaling
metadata, i.e. the signaling contains a matching entry to the TSI
value provided in the packet header, as well as for this TSI, and
Codepoint field in the LCT header has a valid Codepoint mapping.
4) The ROUTE receiver should process the remainder of the payload,
including the appropriate interpretation of the other payload
header fields, and using the source FEC Payload ID (to determine
the start_offset) and the payload data to reconstruct the
corresponding object as follows:
a. For File Mode, upon receipt of the first ROUTE packet 2) All ROUTE packets used to recover a specific delivery object
payload for an object, the ROUTE receiver uses the carry the same TOI value in the LCT header.
File@Transfer-Length attribute of the associated Extended FDT
Instance, when present, to determine the length T of the 3) The ROUTE receiver is expected to assert that the TSI and the
object. When the File@Transfer-Length attribute is not Codepoint represent valid operation points in the signaling
present in the Extended FDT Instance, the receiver uses the metadata, i.e., the signaling contains a matching entry to the
maxTransportSize attribute of the associated Extended FDT TSI value provided in the packet header, as well as for this TSI,
Instance to determine the maximum length T' of the object. and the Codepoint field in the LCT header has a valid Codepoint
Alternatively, and specifically for delivery modes other than mapping.
File Mode, EXT_TOL header can be used to determine the length
T of the object. 4) The ROUTE receiver should process the remainder of the payload,
b. The ROUTE receiver allocates buffer space for the T or T' including the appropriate interpretation of the other payload
bytes that the object will or may occupy. header fields, using the source FEC Payload ID (to determine the
c. The ROUTE receiver computes the length of the payload, Y, by start_offset) and the payload data to reconstruct the
subtracting the payload header length from the total length corresponding object as follows:
of the received payload.
d. The ROUTE receiver allocates a Boolean array RECEIVED[0..T- a. For File Mode, upon receipt of the first ROUTE packet payload
1] or RECEIVED[0..T'-1], as appropriate, with all entries for an object, the ROUTE receiver uses the File@Transfer-
initialized to false to track received object symbols. The Length attribute of the associated Extended FDT-Instance,
ROUTE receiver continuously acquires packet payloads for the when present, to determine the length T of the object. When
object as long as all of the following conditions are the File@Transfer-Length attribute is not present in the
satisfied: i) there is at least one entry in RECEIVED still Extended FDT-Instance, the receiver uses the maxTransportSize
set to false; ii) the object has not yet expired; and iii) attribute of the associated Extended FDT-Instance to
the application has not given up on reception of this object. determine the maximum length T' of the object.
More details are provided below. Alternatively, and specifically for delivery modes other than
e. For each received ROUTE packet payload for the object File Mode, the EXT_TOL header can be used to determine the
(including the first payload), the steps to be taken to help length T of the object.
recover the object are as follows:
i. If the packet includes an EXT_TOL or EXT_FTI header, b. The ROUTE receiver allocates buffer space for the T or T'
modify the Boolean array RECEIVED[0..T'-1] to become bytes that the object will or may occupy.
RECEIVED[0..T-1].
ii. Let X be the value of the start_offset field in the ROUTE c. The ROUTE receiver computes the length of the payload, Y, by
packet header and let Y be the length of the payload, Y, subtracting the payload header length from the total length
computed by subtracting the LCT header size and the FEC of the received payload.
Payload ID size from the total length of the received
packet. d. The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1]
iii. The ROUTE receiver copies the data into the appropriate or RECEIVED[0..T'-1], as appropriate, with all entries
place within the space reserved for the object and sets initialized to false to track received object symbols. The
RECEIVED[X ... X+Y-1] = true. ROUTE receiver continuously acquires packet payloads for the
iv. If all T entries of RECEIVED are true, then the receiver object as long as all of the following conditions are
has recovered the entire object. satisfied:
i. there is at least one entry in RECEIVED still set to
false,
ii. the object has not yet expired, and
iii. the application has not given up on reception of this
object.
More details are provided below.
e. For each received ROUTE packet payload for the object
(including the first payload), the steps to be taken to help
recover the object are as follows:
i. If the packet includes an EXT_TOL or EXT_FTI header,
modify the Boolean array RECEIVED[0..T'-1] to become
RECEIVED[0..T-1].
ii. Let X be the value of the start_offset field in the
ROUTE packet header and let Y be the length of the
payload, Y, computed by subtracting the LCT header size
and the FEC Payload ID size from the total length of
the received packet.
iii. The ROUTE receiver copies the data into the appropriate
place within the space reserved for the object and sets
RECEIVED[X ... X+Y-1] = true.
iv. If all T entries of RECEIVED are true, then the
receiver has recovered the entire object.
Upon recovery of both the complete set of packet payloads for the Upon recovery of both the complete set of packet payloads for the
delivery object associated with a given TOI value, and the metadata delivery object associated with a given TOI value, and the metadata
for that delivery object, the reception of the delivery object, now a for that delivery object, the reception of the delivery object, now a
fully received Application Object, is complete. fully received Application Object, is complete.
Given the timely reception of ROUTE packets belonging to an Given the timely reception of ROUTE packets belonging to an
Application Object, the receiver SHALL make the Application Objects Application Object, the receiver SHALL make the Application Objects
available to the application in a timely fashion, using the available to the application in a timely fashion using the
application-provided timing data (e.g. the timing data signaled via application-provided timing data (e.g., the timing data signaled via
the presentation manifest file). For example, HTTP/1.1 chunked the presentation manifest file). For example, HTTP/1.1 chunked
transfer may need to be enabled to transfer the Application Objects transfer may need to be enabled to transfer the Application Objects
if MPD@availabilityTimeOffset is signaled in the DASH presentation if MPD@availabilityTimeOffset is signaled in the DASH presentation
manifest, to allow for timely sending of segment data to the manifest in order to allow for the timely sending of segment data to
application. the application.
6.2. Fast Stream Acquisition 6.2. Fast Stream Acquisition
When the receiver initially starts reception of ROUTE packets, it is When the receiver initially starts reception of ROUTE packets, it is
likely that the reception does not start from the very first packet likely that the reception does not start from the very first packet
carrying the data of a multicast transport object, and in this case carrying the data of a multicast transport object; in this case, such
such a partially received object is normally discarded. However, the a partially received object is normally discarded. However, the
channel acquisition or "tune-in" times can be improved if the channel acquisition or "tune-in" times can be improved if the
partially received object is usable by the application. partially received object is usable by the application. One example
One example realization for this is as follows: realization for this is as follows:
o The receiver checks for the first received packet with the * The receiver checks for the first received packet with the
Codepoint value set to 10, indicating the start of a CMAF Random Codepoint value set to 10, indicating the start of a CMAF Random
Access chunk. Access chunk.
o The receiver MAY make the partially received object (a partial * The receiver MAY make the partially received object (a partial
DASH segment starting from the packet above) available to the DASH segment starting from the packet above) available to the
application for fast stream acquisition. application for fast stream acquisition.
o It MAY recover the earliest presentation time of this CMAF Random * It MAY recover the earliest presentation time of this CMAF Random
Access chunk from the ROUTE packet LCT Congestion Control Access chunk from the ROUTE packet LCT Congestion Control
Information (CCI) field as specified in Section 2.1 to be able to Information (CCI) field as specified in Section 2.1 to be able to
add a new Period element in the MPD exposed to the application add a new Period element in the MPD exposed to the application
containing just the partially received DASH segment with period containing just the partially received DASH segment with period
continuity signaling. continuity signaling.
6.3. Generating Extended FDT Instance for File Mode 6.3. Generating Extended FDT-Instance for File Mode
An Extended FDT Instance conforming to RFC 6726 [RFC6726], is An Extended FDT-Instance conforming to RFC 6726 [RFC6726], is
produced at the receiver using the service metadata and in band produced at the receiver using the service metadata and in-band
signaling in the following steps: signaling in the following steps:
6.3.1. File Template Substitution for Content-Location Derivation 6.3.1. File Template Substitution for Content-Location Derivation
The Content-Location element of the Extended FDT for a specific The Content-Location element of the Extended FDT for a specific
Application Object is derived as follows: Application Object is derived as follows:
"$TOI$" is substituted with the unique TOI value in the LCT header of "$TOI$" is substituted with the unique TOI value in the LCT header of
the ROUTE packets used to recover the given delivery object (as the ROUTE packets used to recover the given delivery object (as
specified in Section 6.1). specified in Section 6.1).
After the substitution, the fileTemplate SHALL be a valid URL After the substitution, the fileTemplate SHALL be a valid URL
corresponding to the Content-Location attribute of the associated corresponding to the Content-Location attribute of the associated
Application Object. Application Object.
An example @fileTemplate using a width of 5 is: An example @fileTemplate using a width of 5 is:
fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with
exactly five digits in the number portion. The Media Segment file exactly five digits in the number portion. The Media Segment file
name for TOI=33 using this template is myVideo00033.mps. name for TOI=33 using this template is myVideo00033.mps.
6.3.2. File@Transfer-Length Derivation 6.3.2. File@Transfer-Length Derivation
Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL
header, when present, is used to derive the Transport Object Length header, when present, is used to derive the Transport Object Length
(TOL) of the File. If the File@Transfer-Length parameter in the (TOL) of the File. If the File@Transfer-Length parameter in the
Extended FDT Instance is not present, then the EXT_TOL header or the Extended FDT-Instance is not present, then the EXT_TOL header or the
or EXT_FTI header SHALL be present. Note that a header containing the or EXT_FTI header SHALL be present. Note that a header containing
transport object length (EXT_TOL or EXT_FTI) need not be present in the transport object length (EXT_TOL or EXT_FTI) need not be present
each packet header. If the broadcaster does not know the length of in each packet header. If the broadcaster does not know the length
the transport object at the beginning of the transfer, an EXT_TOL or of the transport object at the beginning of the transfer, an EXT_TOL
EXT_FTI header SHALL be included in at least the last packet of the or EXT_FTI header SHALL be included in at least the last packet of
file and should be included in the last few packets of the transfer. the file and should be included in the last few packets of the
transfer.
6.3.3. FDT-Instance@Expires Derivation 6.3.3. FDT-Instance@Expires Derivation
When present, the maxExpiresDelta attribute SHALL be used to generate When present, the maxExpiresDelta attribute SHALL be used to generate
the value of the FDT-Instance@Expires attribute. The receiver is the value of the FDT-Instance@Expires attribute. The receiver is
expected to add this value to its wall clock time when acquiring the expected to add this value to its wall clock time when acquiring the
first ROUTE packet carrying the data of a given delivery object to first ROUTE packet carrying the data of a given delivery object to
obtain the value for @Expires. obtain the value for @Expires.
When maxExpiresDelta is not present, the EXT_TIME header with When maxExpiresDelta is not present, the EXT_TIME header with
Expected Residual Time (ERT) SHALL be used to derive the expiry time Expected Residual Time (ERT) SHALL be used to derive the expiry time
of the Extended FDT Instance. When both maxExpiresDelta and the ERT of the Extended FDT-Instance. When both maxExpiresDelta and the ERT
of EXT_TIME are present, the smaller of the two values should be used of EXT_TIME are present, the smaller of the two values should be used
as the incremental time interval to be added to the receiver's as the incremental time interval to be added to the receiver's
current time to generate the effective value for @Expires. When current time to generate the effective value for @Expires. When
neither maxExpiresDelta nor the ERT field of the EXT_TIME header is neither maxExpiresDelta nor the ERT field of the EXT_TIME header is
present, then the expiration time of the Extended FDT Instance is present, then the expiration time of the Extended FDT-Instance is
given by its @Expires attribute. given by its @Expires attribute.
7. FEC Application 7. FEC Application
7.1. General FEC Application Guidelines 7.1. General FEC Application Guidelines
It is up to the receiver to decide to use zero, one or more of the It is up to the receiver to decide to use zero, one, or more of the
FEC streams. Hence, the application assigns a recovery property to FEC streams. Hence, the application assigns a recovery property to
each flow, which defines aspects such as the delay and the required each flow, which defines aspects such as the delay and the required
memory if one or the other is chosen. The receiver MAY decide whether memory if one or the other is chosen. The receiver MAY decide
or not to utilize Repair Flows based on the following considerations: whether or not to utilize Repair Flows based on the following
considerations:
o The desired start-up and end-to-end latency. If a Repair Flow * The desired start-up and end-to-end latency. If a Repair Flow
requires a significant amount of buffering time to be effective, requires a significant amount of buffering time to be effective,
such Repair Flow might only be used in time-shift operations or in such Repair Flow might only be used in time-shift operations or in
poor reception conditions, since use of such Repair Flow trades poor reception conditions, since use of such Repair Flow trades
off end-to-end latency against DASH Media Presentation quality. off end-to-end latency against DASH Media Presentation quality.
o FEC capabilities, i.e. the receiver MAY pick only the FEC * FEC capabilities, i.e., the receiver MAY pick only the FEC
algorithm that it supports. algorithm that it supports.
o Which Source Flows are being protected; for example, if the Repair * Which Source Flows are being protected; for example, if the Repair
Flow protects Source Flows that are not selected by the receiver, Flow protects Source Flows that are not selected by the receiver,
then the receiver may not select the Repair Flow. then the receiver may not select the Repair Flow.
o Other considerations such as available buffer size, reception * Other considerations such as available buffer size, reception
conditions, etc. conditions, etc.
If a receiver decides to acquire a certain Repair Flow then the If a receiver decides to acquire a certain Repair Flow, then the
receiver must receive data on all Source Flows that are protected by receiver must receive data on all Source Flows that are protected by
that Repair Flow to collect the relevant packets. that Repair Flow to collect the relevant packets.
7.2. TOI Mapping 7.2. TOI Mapping
When mappingTOIx/mappingTOIy are used to signal X and Y values, then When mappingTOIx/mappingTOIy are used to signal X and Y values, the
the TOI value(s) of the one or more source objects (sourceTOI) TOI value(s) of the one or more source objects (sourceTOI) protected
protected by a given FEC transport object or FEC super-object with a by a given FEC transport object or FEC super-object with a TOI value
TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y. rTOI is derived through an equation sourceTOI = X*rTOI + Y.
When neither mappingTOIx nor mappingTOIy is present there is a 1:1 When neither mappingTOIx nor mappingTOIy is present, there is a 1:1
relationship between each delivery object carried in the Source Flow relationship between each delivery object carried in the Source Flow
as identified by ptsi to an FEC object carried in this Repair Flow. as identified by ptsi to a FEC object carried in this Repair Flow.
In this case the TOI of each of those delivery objects SHALL be In this case, the TOI of each of those delivery objects SHALL be
identical to the TOI of the corresponding FEC object. identical to the TOI of the corresponding FEC object.
7.3. Delivery Object Reception Timeout 7.3. Delivery Object Reception Timeout
The permitted start and end times for the receiver to perform the The permitted start and end times for the receiver to perform the
file repair procedure, in case of unsuccessful broadcast file file repair procedure, in case of unsuccessful broadcast file
reception, and associated rules and parameters are as follows: reception, and associated rules and parameters are as follows:
o The latest time that the file repair procedure may start is bound * The latest time that the file repair procedure may start is bound
by the @Expires attribute of the FDT-Instance. by the @Expires attribute of the FDT-Instance.
o The receiver may choose to start the file repair procedure * The receiver may choose to start the file repair procedure earlier
earlier, if it detects the occurrence of any of the following if it detects the occurrence of any of the following events:
events:
o Presence of the Close Object flag (B) in the LCT header - Presence of the Close Object flag (B) in the LCT header
[RFC5651] for the file of interest; [RFC5651] for the file of interest;
o Presence of the Close Session flag (A) in the LCT header - Presence of the Close Session flag (A) in the LCT header
[RFC5651] before the nominal expiration of the Extended FDT [RFC5651] before the nominal expiration of the Extended FDT-
Instance as defined by the @Expires attribute. Instance as defined by the @Expires attribute.
7.4. Example FEC Operation 7.4. Example FEC Operation
To be able to recover the delivery objects that are protected by a To be able to recover the delivery objects that are protected by a
Repair Flow, a receiver needs to obtain the necessary Service Repair Flow, a receiver needs to obtain the necessary Service
signaling metadata fragments that describe the corresponding signaling metadata fragments that describe the corresponding
collection of delivery objects that are covered by this Repair Flow. collection of delivery objects that are covered by this Repair Flow.
A Repair Flow is characterized by the combination of an LCT channel, A Repair Flow is characterized by the combination of an LCT channel,
a unique TSI number, as well as the corresponding protected Source a unique TSI number, as well as the corresponding protected Source
Flows. Flows.
If a receiver acquires data of a Repair Flow, the receiver is If a receiver acquires data of a Repair Flow, the receiver is
expected to collect all packets of all protected Transport Sessions. expected to collect all packets of all protected Transport Sessions.
Upon receipt of each packet, whether it is a source or repair packet, Upon receipt of each packet, whether it is a source or repair packet,
the receiver proceeds with the following steps in the order listed. the receiver proceeds with the following steps in the order listed.
1. The receiver is expected to parse the packet header and verify
that it is a valid header. If it is not valid, then the packet
SHALL be discarded without further processing.
2. The receiver is expected to parse the TSI field of the packet
header and verify that a matching value exists in the Service
signaling for the Repair Flow or the associated Protected Source
Flow. If no match is found, the packet SHALL be discarded without
further processing.
3. The receiver processes the remainder of the packet, including
interpretation of the other header fields, and using the source
FEC Payload ID (to determine the start_offset byte position within
the source object), the Repair FEC Payload ID, as well as the
payload data, reconstructs the decoding blocks corresponding to a
FEC super-object as follows:
a. For a source packet, the receiver identifies the delivery
object to which the received packet is associated, using the
session information and the TOI carried in the payload
header. Similarly, for a repair object the receiver
identifies the FEC super-object to which the received packet
is associated, using the session information and the TOI
carried in the payload header.
b. For source packets, the receiver collects the data for each
FEC super-object and recovers FEC super-objects in same way
as Source Flow in Section 6.1. The received FEC super-object
is then mapped to a source block and the corresponding
encoding symbols are generated.
c. With the reception of the repair packets, the FEC super-
object can be recovered.
d. Once the FEC super-object is recovered, the individual
delivery objects can be extracted.
8. Considerations for Defining ROUTE Profiles 1. The receiver is expected to parse the packet header and verify
that it is a valid header. If it is not valid, then the packet
SHALL be discarded without further processing.
Services (e.g. ATSC-ROUTE [ATSCA331], DVB-MABR [DVBMABR] etc.) may 2. The receiver is expected to parse the TSI field of the packet
header and verify that a matching value exists in the Service
signaling for the Repair Flow or the associated Protected Source
Flow. If no match is found, the packet SHALL be discarded
without further processing.
3. The receiver processes the remainder of the packet, including
interpretation of the other header fields, and using the source
FEC Payload ID (to determine the start_offset byte position
within the source object), the Repair FEC Payload ID, as well as
the payload data, reconstructs the decoding blocks corresponding
to a FEC super-object as follows:
a. For a source packet, the receiver identifies the delivery
object to which the received packet is associated using the
session information and the TOI carried in the payload
header. Similarly, for a repair object, the receiver
identifies the FEC super-object to which the received packet
is associated using the session information and the TOI
carried in the payload header.
b. For source packets, the receiver collects the data for each
FEC super-object and recovers FEC super-objects in the same
way as a Source Flow in Section 6.1. The received FEC super-
object is then mapped to a source block and the corresponding
encoding symbols are generated.
c. With the reception of the repair packets, the FEC super-
object can be recovered.
d. Once the FEC super-object is recovered, the individual
delivery objects can be extracted.
8. Considerations for Defining ROUTE Profiles
Services (e.g., ATSC-ROUTE [ATSCA331], DVB-MABR [DVBMABR], etc.) may
define specific ROUTE "profiles" based on this document in their define specific ROUTE "profiles" based on this document in their
respective standards organizations. An example is noted in the respective standards organizations. An example is noted in the
overview section: DVB has specified a profile of ATSC-ROUTE in DVB overview section: DVB has specified a profile of ATSC-ROUTE in DVB
Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. The Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. The
definition with the following considerations. Services MAY definition has the following considerations. Services MAY
o Restrict the signaling certain values signaled in the LCT header * Restrict the signaling of certain values signaled in the LCT
and/or provision unused fields in the LCT header. header and/or provision unused fields in the LCT header.
o Restrict using certain LCT header extensions and/or add new LCT * Restrict using certain LCT header extensions and/or add new LCT
header extensions. header extensions.
o Restrict or limit usage of some Codepoints, and/or assign * Restrict or limit usage of some Codepoints and/or assign semantics
semantics to service-specific Codepoints marked as reserved in to service-specific Codepoints marked as reserved in this
this document. document.
o Restrict usage of certain service signaling attributes and/or add * Restrict usage of certain Service signaling attributes and/or add
own service metadata. their own service metadata.
Services SHALL NOT redefine the semantics of any of the ROUTE Services SHALL NOT redefine the semantics of any of the ROUTE
attributes in LCT headers and extension, and service signaling attributes in LCT headers and extensions, as well as Service
attributes already specified in this document. signaling attributes already specified in this document.
By following these guidelines, services can define profiles that are By following these guidelines, services can define profiles that are
interoperable. interoperable.
9. ROUTE Concepts 9. ROUTE Concepts
9.1. ROUTE Modes of Delivery 9.1. ROUTE Modes of Delivery
Different ROUTE delivery modes specified in Section 4 are optimized Different ROUTE delivery modes specified in Section 4 are optimized
for delivery of different types of media data. For example, File Mode for delivery of different types of media data. For example, File
is specifically optimized for delivering DASH content using Segment Mode is specifically optimized for delivering DASH content using
Template with number substitution. Using File Template in EFDT avoids Segment Template with number substitution. Using File Template in
the need of repeated sending of metadata as outlined in the following EFDT avoids the need for the repeated sending of metadata as outlined
section. Same optimizations however cannot be used for time in the following section. Same optimizations, however, cannot be
substitution and segment timeline where the addressing of each used for time substitution and segment timeline where the addressing
segment is time dependent and in general does not follow a fixed or of each segment is time dependent and in general does not follow a
repeated pattern. In this case, Entity mode is more optimized which fixed or repeated pattern. In this case, Entity Mode is more
carries the file location in band. Also, Entity mode can be used to optimized since it carries the file location in band. Also, Entity
deliver a file or part of the file using HTTP Partial Content Mode can be used to deliver a file or part of the file using HTTP
response headers. Partial Content response headers.
9.2. File Mode Optimizations 9.2. File Mode Optimizations
In the file mode, the delivery object represents an Application In File Mode, the delivery object represents an Application Object.
Object. This mode replicates FLUTE as defined in RFC 6726 [RFC6726], This mode replicates FLUTE as defined in RFC 6726 [RFC6726] but with
but with the ability to send static and pre-known file metadata out the ability to send static and pre-known file metadata out of band.
of band.
In FLUTE, FDT Instances are delivered in-band and need to be In FLUTE, FDT-Instances are delivered in band and need to be
generated and delivered in real-time if objects are generated in generated and delivered in real time if objects are generated in real
real-time at the sender. These FDT Instances have some differences as time at the sender. These FDT-Instances have some differences as
compared to the FDT specified in Section 3.4.2 of RFC 6726 [RFC6726] compared to the FDT specified in Section 3.4.2 of [RFC6726] and
and Section 7.2.10 of MBMS [MBMS]. The key difference is that besides Section 7.2.10 of MBMS [MBMS]. The key difference is that besides
separated delivery of file metadata from the delivery object it separated delivery of file metadata from the delivery object it
describes, the FDT functionality in ROUTE may be extended by describes, the FDT functionality in ROUTE may be extended by
additional file metadata and rules that enable the receiver to additional file metadata and rules that enable the receiver to
generate the Content-Location attribute of the File element of the generate the Content-Location attribute of the File element of the
FDT, on-the-fly. This is done by using information in both the FDT, on the fly. This is done by using information in both the
extensions to the FDT and the LCT header. The combination of pre- extensions to the FDT and the LCT header. The combination of pre-
delivery of static file metadata and receiver self-generation of delivery of static file metadata and receiver self generation of
dynamic file metadata avoids the necessity of continuously sending dynamic file metadata avoids the necessity of continuously sending
the FDT Instances for real-time objects. Such modified FDT the FDT-Instances for real-time objects. Such modified FDT
functionality in ROUTE is referred to as the Extended FDT. functionality in ROUTE is referred to as the Extended FDT.
9.3. In Band Signaling of Object Transfer Length 9.3. In-Band Signaling of Object Transfer Length
As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header
extension with 24 bits or, if required, 48 bits of to signal the extension with 24 bits or, if required, 48 bits to signal the
Transfer Length directly within the ROUTE packet. Transfer Length directly within the ROUTE packet.
The transport object length can also be determined without the use of The transport object length can also be determined without the use of
EXT_TOL by examining the LCT packet with the Close Object (B) flag. EXT_TOL by examining the LCT packet with the Close Object flag (B).
However, if this packet is lost, then the EXT_TOL information can be However, if this packet is lost, then the EXT_TOL information can be
used by the receiver to determine the transport object length. used by the receiver to determine the transport object length.
Applications using ROUTE for delivery of low-latency streaming Applications using ROUTE for delivery of low-latency streaming
content may make use of this feature for sender-end latency content may make use of this feature for sender-end latency
optimizations: the sender does not have to wait for the completion of optimizations: the sender does not have to wait for the completion of
the packaging of a whole Application Object to find its transfer the packaging of a whole Application Object to find its Transfer
length to be included in the FDT before the sending can start. Length to be included in the FDT before the sending can start.
Rather, partially encoded data can already be started to be sent via Rather, partially encoded data can already be started to be sent via
the ROUTE sender. As the time approaches when the encoding of the the ROUTE sender. As the time approaches when the encoding of the
Application Object is nearing completion, and the length of the Application Object is nearing completion, and the length of the
object becomes known (e.g. time of writing the last CMAF Chunk of a object becomes known (e.g., the time of writing the last CMAF Chunk
DASH segment), only then the sender can signal the object length of a DASH segment), only then the sender can signal the object length
using the EXT TOL LCT header. For example, for a 2 seconds DASH using the EXT TOL LCT header. For example, for a 2-second DASH
segment with 100 millisecond chunks, it may result in saving up to segment with 100-millisecond chunks, it may result in saving up to
1.9 second latency at the sending end. 1.9 second latency at the sending end.
9.4. Repair Protocol Concepts 9.4. Repair Protocol Concepts
The ROUTE repair protocol is FEC-based and is enabled as an The ROUTE repair protocol is FEC-based and is enabled as an
additional layer between the transport layer (e.g., UDP) and the additional layer between the transport layer (e.g., UDP) and the
object delivery layer protocol. The FEC reuses concepts of FEC object delivery layer protocol. The FEC reuses concepts of the FEC
Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC
Framework in RFC 6363 [RFC6363] the ROUTE repair protocol does not Framework in RFC 6363 [RFC6363], the ROUTE repair protocol does not
protect packets, but instead it protects delivery objects as protect packets but instead protects delivery objects as delivered in
delivered in the source protocol. In addition, as an extension to the source protocol. In addition, as an extension to FLUTE, it
FLUTE, it supports the protection of multiple objects in one source supports the protection of multiple objects in one source block which
block which is in alignment with the FEC Framework as defined in RFC is in alignment with the FEC Framework as defined in RFC 6363
6363 [RFC6363]. Each FEC source block may consist of parts of a [RFC6363]. Each FEC source block may consist of parts of a delivery
delivery object, as a single delivery object (similar to FLUTE) or object, as a single delivery object (similar to FLUTE) or multiple
multiple delivery objects that are bundled prior to FEC protection. delivery objects that are bundled prior to FEC protection. ROUTE FEC
ROUTE FEC makes use of FEC schemes in a similar way as those defined makes use of FEC schemes in a similar way as those defined in RFC
in RFC 5052 [RFC5052] and uses the terminology of that document. The 5052 [RFC5052] and uses the terminology of that document. The FEC
FEC scheme defines the FEC encoding and decoding, as well as the scheme defines the FEC encoding and decoding as well as the protocol
protocol fields and procedures used to identify packet payload data fields and procedures used to identify packet payload data in the
in the context of the FEC scheme. context of the FEC scheme.
In ROUTE all packets are LCT packets as defined in RFC 5651
[RFC5651]. Source and repair packets may be distinguished by:
o Different ROUTE sessions; i.e., they are carried on different In ROUTE, all packets are LCT packets as defined in RFC 5651
UDP/IP port combinations. [RFC5651]. Source and repair packets may be distinguished by:
o Different LCT channels; i.e., they use different TSI values in the * Different ROUTE sessions, i.e., they are carried on different UDP/
IP port combinations.
* Different LCT channels, i.e., they use different TSI values in the
LCT header. LCT header.
o The most significant PSI bit in the LCT, if carried in the same * The most significant PSI bit in the LCT, if carried in the same
LCT channel. This mode of operation is mostly suitable for FLUTE- LCT channel. This mode of operation is mostly suitable for FLUTE-
compatible deployments. compatible deployments.
10. Interoperability Chart 10. Interoperability Chart
As noted in prevision sections, ATSC-ROUTE [ATSCA331] and DVB-MABR As noted in prevision sections, ATSC-ROUTE [ATSCA331] and DVB-MABR
[DVBMABR] are considered services using this document that constrain [DVBMABR] are considered services using this document that constrain
specific features as well as add new ones. In this context, the specific features as well as add new ones. In this context, the
following table is an informative comparison of the interoperability following table is an informative comparison of the interoperability
of ROUTE as specified in this document, with the ATSC-ROUTE of ROUTE as specified in this document with ATSC-ROUTE [ATSCA331] and
[ATSCA331] and DVB-MABR [DVBMABR]: DVB-MABR [DVBMABR]:
+---------------+---------------+--------------------+-----------------+ +===============+===================+==================+============+
| Element | ATSC-ROUTE | This Document | DVB-MABR | | Element | ATSC-ROUTE | This Document | DVB-MABR |
| | | | | +===============+===================+==================+============+
+--------+------+---------------+--------------------+-----------------+ | LCT header | PSI LSB set to 0 | Not defined | Set to 1 |
| LCT |PSI | Set to 0 | Not defined | Set to 1 for | | field | for Source Flow | | for Source |
| header |least | for Source | | Source Flow for | | | | | Flow for |
| fields |signi-| Flow. | | CMAF Random | | | | | CMAF |
| |ficant| | | access chunk | | | | | Random |
| |bit | | | | | | | | Access |
| +------+---------------+--------------------------------------+ | | | | chunk |
| |CCI | May be set | May be set to EPT for Source Flow | | +-------------------+------------------+------------+
| | | to 0 | | | | CCI may be set to | CCI may be set to EPT for |
+--------+------+---------------+--------------------+-----------------+ | | 0 | Source Flow |
| LCT header | EXT_ROUTE_ | Not defined, | Shall not | +---------------+-------------------+------------------+------------+
| extensions | PRESENTATION_ | may be added | be used | | LCT header | EXT_ROUTE_ | Not defined; | Shall not |
| | TIME Header | by a profile. | | | extensions | PRESENTATION_TIME | may be added by | be used. |
| | used for | | | | | Header used for | a profile. | |
| | MDE mode | | | | | Media Delivery | | |
| +---------------+--------------------+-----------------+ | | Event (MDE) mode | | |
| | EXT_TIME | EXT_TIME Header may be used | | +-------------------+------------------+------------+
| | Header | regardless (for | | | EXT_TIME Header | EXT_TIME Header may be used |
| | linked to | FDT-Instance@Expires | | | linked to MDE | regardless (for FDT- |
| | MDE mode | calculation) | | | mode in Annex | Instance@Expires |
| | in Annex | | | | A.3.7.2 | calculation) |
| | A.3.7.2 | | | | [ATSCA331] | |
+---------------+---------------+--------------------+-----------------+ +---------------+-------------------+------------------+------------+
| Codepoints | Full set | Does not specify | Restricted | | Codepoints | Full set | Does not | Restricted |
| | | range 11 - 255 | to 5 - 9 | | | | specify range | to 5 - 9 |
| | | (leaves to | | | | | 11 - 255 | |
| | | profiles) | | | | | (leaves to | |
+---------------+---------------+--------------------+-----------------+ | | | profiles) | |
| Session | Full set | Only defines | Reuses A/331 | +---------------+-------------------+------------------+------------+
| metadata | | a small subset | metadata, | | Session | Full set | Only defines a | Reuses |
| | | of data necessary | duplicated | | metadata | | small subset of | A/331 |
| | | for setting up | from its own | | | | data necessary | metadata, |
| | | Source and Repair | service | | | | for setting up | duplicated |
| | | Flows. | signaling. | | | | Source and | from its |
| | | Does not define | | | | | Repair Flows. | own |
| | | format or | | | | | Does not define | Service |
| | | encoding of data | | | | | format or | signaling. |
| | | except if data is | | | | | encoding of | |
| | | integral/ | | | | | data except if | |
| | | alphanumerical. | | | | | data is | |
| | | Leaves rest to | | | | | integral/ | |
| | | profiles. | | | | | alphanumerical. | |
+---------------+---------------+--------------------+-----------------+ | | | Leaves rest to | |
| Extended | Instance | Not restricted, | Instance shall | | | | profiles. | |
| FDT | shall not | may be | not be sent | +---------------+-------------------+------------------+------------+
| | be sent | restricted | with Source | | Extended FDT | Instance shall | Not restricted, | Instance |
| | with Source | by a profile. | Flow | | | not be sent with | may be | shall not |
| | Flow | | | | | Source Flow | restricted by a | be sent |
| +---------------+--------------------+-----------------+ | | | profile. | with |
| | No | Only allowed in File Mode | | | | | Source |
| | restriction | | | | | | Flow |
+---------------+---------------+--------------------+-----------------+ | +-------------------+------------------+------------+
| Delivery | File, Entity, Signed/ | Signed/ | | | No restriction | Only allowed in File Mode |
| Object | unsigned package | unsigned | +---------------+-------------------+------------------+------------+
| Mode | | package not | | Delivery | File, Entity, Signed/unsigned | Signed/ |
| | | allowed | | Object Mode | package | unsigned |
+---------------+---------------+--------------------+-----------------+ | | | package |
| Sender | Defined for | Defined for DASH segment and CMAF | | | | not |
| operation: | DASH | Chunks | | | | allowed |
| Packet- | segment | | +---------------+-------------------+------------------+------------+
| ization | | | | Sender | Defined for DASH | Defined for DASH segment and |
+---------------+---------------+--------------------------------------+ | operation: | segment | CMAF Chunks |
| Receiver | Object | Object may be handed before | | Packetization | | |
| object | handed | completion if | +---------------+-------------------+-------------------------------+
| recovery | to | MPD@availabilityTimeOffset | | Receiver | Object handed to | Object may be handed before |
| | application | signaled | | object | application upon | completion if |
| | upon | | | recovery | complete | MPD@availabilityTimeOffset |
| | complete | | | | reception | signaled |
| | reception | | | +-------------------+-------------------------------+
| +---------------+--------------------------------------+ | | - | Fast Stream acquisition |
| | - | Fast Stream acquisition | | | | guidelines provided |
| | | guideline provided | +---------------+-------------------+-------------------------------+
+---------------+---------------+--------------------------------------+
11. Security and Privacy Considerations
11.1. Security Considerations Table 3: Interoperability Chart
11. Security and Privacy Considerations
11.1. Security Considerations
As noted in Section 9, ROUTE is aligned with FLUTE as specified in As noted in Section 9, ROUTE is aligned with FLUTE as specified in
RFC 6726 [RFC6726] (see Section 9), and only diverges in certain RFC 6726 [RFC6726] and only diverges in certain signaling
signaling optimizations, especially for the real-time object delivery optimizations, especially for the real-time object delivery case.
case. Hence most of the security considerations documented in RFC Hence, most of the security considerations documented in RFC 6726
6726 [RFC6726] for the data flow itself, the session metadata [RFC6726] for the data flow itself, the session metadata (session
(session control parameters in RFC 6726 [RFC6726]), and the control parameters in RFC 6726 [RFC6726]), and the associated
associated building blocks apply directly to ROUTE, as elaborated in building blocks apply directly to ROUTE as elaborated in the
the following along with some additional considerations. following along with some additional considerations.
Both encryption and integrity protection applied either on file or Both encryption and integrity protection applied either on file or
packet level, as recommended in file corruption considerations of RFC packet level, as recommended in the file corruption considerations of
6726 [RFC6726] SHOULD be used for ROUTE. Additionally, RFC 3740 RFC 6726 [RFC6726], SHOULD be used for ROUTE. Additionally, RFC 3740
[RFC3740] documents multicast security architecture in great detail [RFC3740] documents multicast security architecture in great detail
with clear security recommendations which SHOULD be followed. with clear security recommendations that SHOULD be followed.
When ROUTE is carried over UDP and a reverse channel from receiver to When ROUTE is carried over UDP and a reverse channel from receiver to
sender is available, the security mechanisms provided in RFC 6347 sender is available, the security mechanisms provided in RFC 9147
[RFC6347] SHALL apply. At the time, draft DTLS 1.3 based on TSL 1.3 [RFC9147] SHOULD be applied.
[DTLS13] is pending publication, and may be considered as the
alternate means for security post publication.
In regard to considerations for attacks against session description, In regard to considerations for attacks against session description,
this document does not specify the semantics or mechanism of delivery this document does not specify the semantics or mechanism of delivery
of session metadata, though the same threats apply for service using of session metadata, though the same threats apply for service using
ROUTE as well. Hence a service using ROUTE SHOULD take these threats ROUTE as well. Hence, a service using ROUTE SHOULD take these
into consideration and address them appropriately following the threats into consideration and address them appropriately following
guideline provided by RFC 6726 [RFC6726]. Additionally to the the guidelines provided by RFC 6726 [RFC6726]. Additionally, to the
recommendations of RFC 6726 [RFC6726], for Internet connected recommendations of RFC 6726 [RFC6726], for Internet connected
devices, services SHOULD enable clients to access the session devices, services SHOULD enable clients to access the session
description information using HTTPS with customary description information using HTTPS with customary authentication/
authentication/authorization, instead of sending this data via authorization, instead of sending this data via multicast/broadcast,
multicast/broadcast, since considerable security work has been done since considerable security work has been done already in this
already in this unicast domain which can enable highly secure access unicast domain, which can enable highly secure access of session
of session description data. Accessing via unicast however will have description data. Accessing via unicast, however, will have
different privacy considerations, noted in Section 11.2. Note that in different privacy considerations, noted in Section 11.2. Note that
general the multicast/broadcast stream is delayed with respect to the in general the multicast/broadcast stream is delayed with respect to
unicast stream. Therefore, the session description protocol SHOULD the unicast stream. Therefore, the session description protocol
be time-synchronized with the broadcast stream, particularly if the SHOULD be time synchronized with the broadcast stream, particularly
session description contains security-related information. if the session description contains security-related information.
In regard to FDT, there is one key difference for File Mode when In regard to FDT, there is one key difference for File Mode when
using File Template in EFDT, which avoids repeated sending of FDT using File Template in EFDT, which avoids repeated sending of FDT-
instance and hence the corresponding threats noted in RFC 6726 Instances and hence, the corresponding threats noted in RFC 6726
[RFC6726] do not apply directly to ROUTE in this case. The threat,
[RFC6726] do not apply directly to ROUTE in this case. The threat however, is shifted to the ALC/LCT headers, since they carry the
however is shifted to the ALC/LCT headers, since they carry the
additional signaling that enables determining Content-Location and additional signaling that enables determining Content-Location and
File@Transfer-Length in this case. Hence integrity protection File@Transfer-Length in this case. Hence, integrity protection
recommendations of ALC/LCT header SHOULD be considered with higher recommendations of ALC/LCT header SHOULD be considered with higher
emphasis in this case for ROUTE. emphasis in this case for ROUTE.
Finally, attacks against the congestion control building block for Finally, attacks against the congestion control building block for
the case of ROUTE can impact the optional fast stream acquisition the case of ROUTE can impact the optional fast stream acquisition
specified in Section 6.2. Receivers SHOULD have robustness against specified in Section 6.2. Receivers SHOULD have robustness against
timestamp values that are suspicious, e.g. by comparing the signaled timestamp values that are suspicious, e.g., by comparing the signaled
time in the LCT headers with the approximate time signaled by the time in the LCT headers with the approximate time signaled by the
MPD, and SHOULD discard outlying values. Additionally, receivers MUST MPD, and SHOULD discard outlying values. Additionally, receivers
adhere to the expiry timelines as specified in Section 6. Integrity MUST adhere to the expiry timelines as specified in Section 6.
protection mechanisms documented in RFC 6726 [RFC6726] SHOULD be used Integrity protection mechanisms documented in RFC 6726 [RFC6726]
to address this threat. SHOULD be used to address this threat.
11.2. Privacy Considerations 11.2. Privacy Considerations
Encryption mechanisms recommended for security considerations in Encryption mechanisms recommended for security considerations in
Section 11.1 SHOULD also be applied to enable privacy and protection Section 11.1 SHOULD also be applied to enable privacy and protection
from snooping attacks. from snooping attacks.
Since this protocol is primarily targeted for IP multicast/broadcast Since this protocol is primarily targeted for IP multicast/broadcast
environment where the end user is mostly listening, identity environments where the end user is mostly listening, identity
protection and user data retention considerations are more protected protection and user data retention considerations are more protected
than in the unicast case. Best practices for enabling privacy on IP than in the unicast case. Best practices for enabling privacy on IP
multicast/broadcast SHOULD be applied by the operators, e.g. multicast/broadcast SHOULD be applied by the operators, e.g.,
Recommendations for DNS Privacy Service Operators in RFC 8932 "Recommendations for DNS Privacy Service Operators" in RFC 8932
[RFC8932]. [RFC8932].
However, if clients access session description information via HTTPS, However, if clients access session description information via HTTPS,
the same privacy considerations and solutions SHALL apply to this the same privacy considerations and solutions SHALL apply to this
access as for regular HTTPS communication, an area which is very well access as for regular HTTPS communication, an area that is very well
studied and the concepts of which are being integrated directly into studied and the concepts of which are being integrated directly into
newer transport protocols such as IETF QUIC [RFC9000] enabling HTTP/3 newer transport protocols such as IETF QUIC [RFC9000] enabling HTTP/3
[HTTP3]. Hence such newer protocols SHOULD be used to foster privacy. [HTTP3]. Hence, such newer protocols SHOULD be used to foster
privacy.
Note that streaming services MAY contain content that may only be Note that streaming services MAY contain content that may only be
accessed via DRM (digital rights management) systems. DRM systems accessed via DRM (digital rights management) systems. DRM systems
can prevent unauthorized access to content delivered via ROUTE. can prevent unauthorized access to content delivered via ROUTE.
12. IANA Considerations 12. IANA Considerations
This document makes no requests for IANA action.
13. References This document has no IANA actions.
13.1. Normative References 13. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 13.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
http://tools.ietf.org/html/rfc2119
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [ATSCA331] Advanced Television Systems Committee, "Signaling,
Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174, May 2017. Delivery, Synchronization, and Error Protection", ATSC
http://tools.ietf.org/html/rfc8174 Standard A/331:2022-03, March 2022.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
Transport (LCT) Building Block", RFC 5651, October 2009. RFC 1952, DOI 10.17487/RFC1952, May 1996,
http://tools.ietf.org/html/rfc5651 <https://www.rfc-editor.org/info/rfc1952>.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010. Requirement Levels", BCP 14, RFC 2119,
http://tools.ietf.org/html/rfc5775 DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6726] Paila, T., Luby, M., Lehtonen, R., Roca, V., Walsh, R., [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
"FLUTE-File Delivery over Unidirectional Transport." 2012. Encapsulation of Aggregate Documents, such as HTML
http://tools.ietf.org/html/rfc6726 (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>.
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Minder, L. "RaptorQ forward error correction scheme for object Resource Identifier (URI): Generic Syntax", STD 66,
delivery", 2011. RFC 3986, DOI 10.17487/RFC3986, January 2005,
http://tools.ietf.org/html/rfc6330 <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Resource Identifier (URI): Generic Syntax", January 2005. Correction (FEC) Building Block", RFC 5052,
http://tools.ietf.org/html/rfc3986 DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3," [RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Internet Engineering Task Force, Reston, VA, May, 1996. Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
http://tools.ietf.org/html/rfc1952 <https://www.rfc-editor.org/info/rfc5445>.
[RFC2557] Palme, J., Hopmann, A. and Shelness, N., "MIME [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Encapsulation of Aggregate Documents, such as HTML (MHTML)", Internet Transport (LCT) Building Block", RFC 5651,
Engineering Task Force, Reston, VA, March 1999. DOI 10.17487/RFC5651, October 2009,
http://tools.ietf.org/html/rfc2557 <https://www.rfc-editor.org/info/rfc5651>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Layered Coding (ALC) Protocol Instantiation", RFC 5775,
Message Specification," Internet Engineering Task Force, Fremont, CA, DOI 10.17487/RFC5775, April 2010,
January 2010. <https://www.rfc-editor.org/info/rfc5775>.
https://tools.ietf.org/html/rfc8551
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes," [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
Internet Engineering Task Force, Reston, VA, March, 2009. and L. Minder, "RaptorQ Forward Error Correction Scheme
http://tools.ietf.org/html/rfc5445 for Object Delivery", RFC 6330, DOI 10.17487/RFC6330,
August 2011, <https://www.rfc-editor.org/info/rfc6330>.
[RFC5052] Watson, M., Luby, M., and Vicisano, L., "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Building Block," Internet Engineering Task Force, Correction (FEC) Framework", RFC 6363,
Reston, VA, August 2007. http://tools.ietf.org/html/rfc5052 DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson, M., Begen, A. and Roca, V., "Forward Error [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
Correction (FEC) Framework," Internet Engineering Task Force, Reston, "FLUTE - File Delivery over Unidirectional Transport",
VA, October, 2011. http://tools.ietf.org/html/rfc6363 RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>.
[RFC7231] IETF RFC 7231 "Hypertext Transfer Protocol (HTTP/1.1): [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Semantics and Content", June 2014. Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
http://tools.ietf.org/html/rfc7231 DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[ATSCA331] ATSC A/331:2019: "ATSC Standard: Signaling, Delivery, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Synchronization, and Error Protection", 20 June 2019. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC6968] Roca, V. and Adamson, B., "FCAST: Object Delivery for the 13.2. Informative References
Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
Multicast (NORM) Protocols," Internet Engineering Task Force, Reston,
VA, July, 2013. http://tools.ietf.org/html/rfc6968
[DVBMABR] ETSI: "Digital Video Broadcasting (DVB); Adaptive media [CMAF] International Organization for Standardization,
streaming over IP multicast", ETSI TS 103 769 V1.1.1 (2020-11) "Information technology -- Multimedia application format
November 2020. (MPEG-A) -- Part 19: Common media application format
(CMAF) for segmented media", First edition, ISO/IEC
FDIS 23000-19, January 2018,
<https://www.iso.org/standard/71975.html>.
[DASH] ISO/IEC 23009-1:2019: "Information technology - Dynamic [DASH] International Organization for Standardization,
adaptive streaming over HTTP (DASH) - Part 1: Media presentation "Information technology - Dynamic adaptive streaming over
description and segment formats", Fourth edition, December 2019. HTTP (DASH) - Part 1: Media presentation description and
segment formats", Fourth edition, ISO/IEC 23009-1:2019,
December 2019, <https://www.iso.org/standard/79329.html>.
[CMAF] ISO/IEC 23000-19:2018: "Information technology - Multimedia [DVBMABR] ETSI, "Digital Video Broadcasting (DVB); Adaptive media
application format (MPEG-A) - Part 19: Common media application streaming over IP multicast", version 1.1.1, ETSI TS 103
format (CMAF) for segmented media", First edition, January 2018. 769, November 2020.
[MBMS] ETSI: "Universal Mobile Telecommunications Systems (UMTS); [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
LTE; Multimedia Broadcast/Multicast Service (MBMS); Protocols and (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
codecs (3GPP TS 26.346 version 13.3.0 Release 13)," Doc. ETSI TS 126 quic-http-34, 2 February 2021,
346 v13.3.0 (2016-01), European Telecommunications Standards <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
Institute, January 2016. http-34>.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [MBMS] ETSI, "Universal Mobile Telecommunications Systems (UMTS);
Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS);
https://www.rfc-editor.org/info/rfc3740. Protocols and codecs", version 16.9.1, ETSI TS 126 346,
May 2021.
[HTTP3] M. Bishop, Ed, "Hypertext Transfer Protocol Version 3 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
(HTTP/3)", draft-ietf-quic-http-34, February 2021. Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
<https://www.rfc-editor.org/info/rfc3740>.
[RFC9000] Iyengar, J., Ed., and M. Thomson, Ed., "QUIC: A UDP-Based [RFC6968] Roca, V. and B. Adamson, "FCAST: Object Delivery for the
Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, Asynchronous Layered Coding (ALC) and NACK-Oriented
May 2021, <https://www.rfc-editor.org/info/rfc9000>. Reliable Multicast (NORM) Protocols", RFC 6968,
DOI 10.17487/RFC6968, July 2013,
<https://www.rfc-editor.org/info/rfc6968>.
[RFC6347] Rescorla E. and N. Modadugu. "Datagram Transport Layer [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, A. Mankin, "Recommendations for DNS Privacy Service
https://www.rfc-editor.org/info/rfc6347. Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
October 2020, <https://www.rfc-editor.org/info/rfc8932>.
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP Multiplexed and Secure Transport", RFC 9000,
232, RFC 8932, DOI 10.17487/RFC8932, October 2020, https://www.rfc- DOI 10.17487/RFC9000, May 2021,
editor.org/info/rfc8932. <https://www.rfc-editor.org/info/rfc9000>.
[DTLS13] Rescorla, E., Tschofenig, H., Modadugu, N., "The Datagram [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Transport Layer Security (DTLS) Protocol Version 1.3", Work in Datagram Transport Layer Security (DTLS) Protocol Version
Progress, draft-ietf-tls-dtls13, February 2022. 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
14. Acknowledgments Acknowledgments
As outlined in the introduction and in ROUTE concepts in Section 9, As outlined in the introduction and in ROUTE concepts in Section 9,
the concepts specified in this document are the culmination of the the concepts specified in this document are the culmination of the
collaborative work of several experts and organizations over the collaborative work of several experts and organizations over the
years. The authors would especially like to acknowledge the work and years. The authors would especially like to acknowledge the work and
efforts of the following people and organizations to help realize the efforts of the following people and organizations to help realize the
technologies described in this document (in no specific order): Mike technologies described in this document (in no specific order): Mike
Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm
Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D. Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D.
Authors' Addresses Authors' Addresses
Waqar Zia Waqar Zia
Qualcomm CDMA Technologies GmbH Qualcomm CDMA Technologies GmbH
Anzinger Str. 13, 81671, Munich, Germany Anzinger Str. 13
81671 Munich
Germany
Email: wzia@qti.qualcomm.com Email: wzia@qti.qualcomm.com
Thomas Stockhammer Thomas Stockhammer
Qualcomm CDMA Technologies GmbH Qualcomm CDMA Technologies GmbH
Anzinger Str. 13, 81671, Munich, Germany Anzinger Str. 13
81671 Munich
Germany
Email: tsto@qti.qualcomm.com Email: tsto@qti.qualcomm.com
Lenaig Chaponniere Lenaig Chaponniere
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, California 92121 San Diego, CA 92121
USA United States of America
Email: lguellec@qti.qualcomm.com Email: lguellec@qti.qualcomm.com
Giridhar Mandyam Giridhar Mandyam
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, California 92121 San Diego, CA 92121
USA United States of America
Email: mandyam@qti.qualcomm.com Email: mandyam@qti.qualcomm.com
Michael Luby Michael Luby
BitRipple, Inc. BitRipple, Inc.
1133 Miller Ave 1133 Miller Ave
Berkeley CA 94708 Berkeley, CA 94708
USA United States of America
Email: luby@bitripple.com Email: luby@bitripple.com
 End of changes. 367 change blocks. 
1161 lines changed or deleted 1218 lines changed or added

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