💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc9223.txt captured on 2023-06-16 at 16:45:35.
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Independent Submission W. Zia Request for Comments: 9223 T. Stockhammer Category: Informational Qualcomm CDMA Technologies GmbH ISSN: 2070-1721 L. Chaponniere G. Mandyam Qualcomm Technologies Inc. M. Luby BitRipple, Inc. April 2022 Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) Abstract The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications. The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec. This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features). This is not an IETF specification and does not have IETF consensus. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9223. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Overview 1.2. Protocol Stack for ROUTE 1.3. Data Model 1.4. Architecture and Scope of Specification 1.5. Conventions Used in This Document 2. ROUTE Packet Format 2.1. Packet Structure and Header Fields 2.2. LCT Header Extensions 2.3. FEC Payload ID for Source Flows 2.4. FEC Payload ID for Repair Flows 3. Session Metadata 3.1. Generic Metadata 3.2. Session Metadata for Source Flows 3.3. Session Metadata for Repair Flows 4. Delivery Object Mode 4.1. File Mode 4.1.1. Extensions to FDT 4.1.2. Constraints on Extended FDT 4.2. Entity Mode 4.3. Unsigned Package Mode 4.4. Signed Package Mode 5. Sender Operation 5.1. Usage of ALC and LCT for Source Flow 5.2. ROUTE Packetization for Source Flow 5.2.1. Basic ROUTE Packetization 5.2.2. ROUTE Packetization for CMAF Chunked Content 5.3. Timing of Packet Emission 5.4. Extended FDT Encoding for File Mode Sending 5.5. FEC Framework Considerations 5.6. FEC Transport Object Construction 5.7. Super-Object Construction 5.8. Repair Packet Considerations 5.9. Summary FEC Information 6. Receiver Operation 6.1. Basic Application Object Recovery for Source Flows 6.2. Fast Stream Acquisition 6.3. Generating Extended FDT-Instance for File Mode 6.3.1. File Template Substitution for Content-Location Derivation 6.3.2. File@Transfer-Length Derivation 6.3.3. FDT-Instance@Expires Derivation 7. FEC Application 7.1. General FEC Application Guidelines 7.2. TOI Mapping 7.3. Delivery Object Reception Timeout 7.4. Example FEC Operation 8. Considerations for Defining ROUTE Profiles 9. ROUTE Concepts 9.1. ROUTE Modes of Delivery 9.2. File Mode Optimizations 9.3. In-Band Signaling of Object Transfer Length 9.4. Repair Protocol Concepts 10. Interoperability Chart 11. Security and Privacy Considerations 11.1. Security Considerations 11.2. Privacy Considerations 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Acknowledgments Authors' Addresses 1. Introduction 1.1. Overview The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol can be used for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Unidirectional transport in this document has identical meaning to that in RFC 6726 [RFC6726], i.e., transport in the direction of receiver(s) from a sender. The robustness is enabled by a built-in mechanism, e.g., signaling for loss detection, enabling loss recovery, and optionally integrating application-layer Forward Error Correction (FEC). Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, an MPEG Dynamic Adaptive Streaming over HTTP (DASH) [DASH] video segment, a WAV audio clip, an MPEG Common Media Application Format (CMAF) [CMAF] addressable resource, an MPEG-4 video clip, etc. The ROUTE protocol is designed to enable delivery of sequences of related Application Objects in a timely manner to receivers, e.g., a sequence of DASH video segments associated to a Representation or a sequence of CMAF addressable resources associated to a CMAF Track. The applications of this protocol target services enabled on media consumption devices such as smartphones, tablets, television sets, and so on. Most of these applications are real-time in the sense that they are sensitive to and rely upon such timely reception of data. The ROUTE protocol also supports chunked delivery of real-time Application Objects to enable low-latency streaming applications (similar in its properties to chunked delivery using HTTP). The protocol also enables low-latency delivery of DASH and Apple HTTP Live Streaming (HLS) content with CMAF Chunks. Content not intended for rendering in real time as it is received (e.g., a downloaded application), a file comprising continuous or discrete media and belonging to an app-based feature, or a file containing (opaque) data to be consumed by a Digital Rights Management (DRM) system client can also be delivered by ROUTE. The ROUTE protocol supports a caching model where Application Objects are recovered into a cache at the receiver and may be made available to applications via standard HTTP requests from the cache. Many current day applications rely on using HTTP to access content; hence, this approach enables such applications in broadcast/multicast environments. ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE) as defined in RFC 6726 [RFC6726] as well as the extensions defined in Multimedia Broadcast/Multicast Service (MBMS) [MBMS], but it also makes use of some principles of FCAST (Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols) as defined in RFC 6968 [RFC6968]; for example, object metadata and the object content may be sent together in a compound object. The alignment to FLUTE is enabled since in addition to reusing several of the basic FLUTE protocol features, as referred to by this document, certain optimizations and restrictions are added that enable optimized support for real-time delivery of media data; hence, the name of the protocol. Among others, the source ROUTE protocol enables or enhances the following functionalities: * Real-time delivery of object-based media data * Flexible packetization, including enabling media-aware packetization as well as transport-aware packetization of delivery objects * Independence of Application Objects and delivery objects, i.e., a delivery object may be a part of a file or may be a group of files. Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE protocol integrated with an ATSC 3.0 services layer. That specification will be referred to as ATSC-ROUTE [ATSCA331] for the remainder of this document. Digital Video Broadcasting (DVB) has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. This document specifies the Application Object delivery aspects (delivery protocol) for such services, as the corresponding delivery protocol could be used as a reference by a variety of services by specifying profiles of ROUTE in their respective fora, e.g., by adding new optional features atop or by restricting various optional features specified in this document in a specific service standard. Hence, in the context of this document, the aforementioned ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition of profiles by the services also have to give due consideration to compatibility issues, and some related guidelines are also provided in this document. This document is not an IETF specification and does not have IETF consensus. It is provided here to aid the production of interoperable implementations. 1.2. Protocol Stack for ROUTE ROUTE delivers Application Objects such as MPEG DASH or HLS segments and optionally the associated repair data, operating over UDP/IP networks, as depicted in Table 1. The session metadata signaling to realize a ROUTE session as specified in this document MAY be delivered out of band or in band as well. Since ROUTE delivers objects in an application cache at the receiver from where the application can access them using HTTP, an application like DASH may use its standardized unicast streaming mechanisms in conjunction with ROUTE over broadcast/multicast to augment the services. +--------------------------------------------------------+ | Application (DASH and HLS segments, CMAF Chunks, etc.) | +--------------------------------------------------------+ | ROUTE | +--------------------------------------------------------+ | UDP | +--------------------------------------------------------+ | IP | +--------------------------------------------------------+ Table 1: Protocol Layering 1.3. Data Model The ROUTE data model is constituted by the following key concepts. Application Object: data that has meaning to the application that uses the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, a DASH video segment, a WAV audio clip, an MPEG-4 video clip, etc. Delivery Object: an object on course of delivery to the application from the ROUTE sender to ROUTE receiver. Transport Object: an object identified by the Transport Object Identifier (TOI) in RFC 5651 [RFC5651]. It MAY be either a source or a repair object, depending on if it is carried by a Source Flow or a Repair Flow, respectively. Transport Session: a Layered Coding Transport (LCT) channel, as defined by RFC 5651 [RFC5651]. A Transport Session SHALL be uniquely identified by a unique Transport Session Identifier (TSI) value in the LCT header. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Transport Sessions are a subset of a ROUTE session. For media delivery, a Transport Session would typically carry a media component, for example, a DASH Representation. Within each Transport Session, one or more objects are carried, typically objects that are related, e.g., DASH segments associated to one Representation. ROUTE Session: an ensemble or multiplex of one or more Transport Sessions. Each ROUTE session is associated with an IP address/ port combination. A ROUTE session typically carries one or more media components of streaming media e.g., Representations associated with a DASH Media Presentation. Source Flow: a Transport Session carrying source data. Source Flow is independent of the Repair Flow, i.e., the Source Flow MAY be used by a ROUTE receiver without the ROUTE Repair Flows. Repair Flow: a Transport Session carrying repair data for one or more Source Flows. 1.4. Architecture and Scope of Specification The scope of the ROUTE protocol is to enable robust and real-time transport of delivery objects using LCT packets. This architecture is depicted in Figure 1. The normative aspects of the ROUTE protocol focus on the following aspects: * The format of the LCT packets that carry the transport objects. * The robust transport of the delivery object using a repair protocol based on Forward Error Correction (FEC). * The definition and possible carriage of object metadata along with the delivery objects. Metadata may be conveyed in LCT packets and/or separate objects. * The ROUTE session, LCT channel, and delivery object description provided as service metadata signaling to enable the reception of objects. * The normative aspects (formats, semantics) of the delivery objects conveyed as a content manifest to be delivered along with the objects to optimize the performance for specific applications e.g., real-time delivery. The objects and manifest are made available to the application through an Application Object cache. The interface of this cache to the application is not specified in this document; however, it will typically be enabled by the application acting as an HTTP client and the cache as the HTTP server. Application Objects Application to application Objects from ^ an application +--------------------------------------------+ + | ROUTE Receiver | | | | +------+------+ | | | | Application | | | | | Object Cache| | | | +------+------+ | | LCT over| +---------------+ ^ | v UDP/IP | | Source object | +---------+ | | +----+---+ | +->+ recovery +--+ Repair +-+ | | ROUTE | | | +---------------+ +----+----+ | | Sender +----------+ ^ | +----+---+ | | | | | | | +---------------+ | | | | | | Repair object | | | | | +->+ recovery +-------+ | +----------->+ +---------------+ | ROUTE | | Metadata +--------------------------------------------+ Figure 1: Architecture/Functional Block Diagram 1.5. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. ROUTE Packet Format 2.1. Packet Structure and Header Fields The packet format used by ROUTE Source Flows and Repair Flows follows the ALC packet format specified in RFC 5775 [RFC5775] with the UDP header followed by the default LCT header and the source FEC Payload ID followed by the packet payload. The overall ROUTE packet format is as depicted in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Default LCT header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Overall ROUTE Packet Format The Default LCT header is as defined in the LCT building block in RFC 5651 [RFC5651]. The LCT packet header fields SHALL be used as defined by the LCT building block in RFC 5651 [RFC5651]. The semantics and usage of the following LCT header fields SHALL be further constrained in ROUTE as follows: Version number (V): This 4-bit field indicates the protocol version number. The version number SHALL be set to '0001', as specified in RFC 5651 [RFC5651]. Congestion Control flag (C) field: This 2-bit field, as defined in RFC 5651 [RFC5651], SHALL be set to '00'. Protocol-Specific Indication (PSI): The most significant bit of this 2-bit flag is called the Source Packet Indicator (SPI) and indicates whether the current packet is a source packet or a FEC repair packet. The SPI SHALL be set to '1' to indicate a source packet and SHALL bet set to '0' to indicate a repair packet. Transport Session Identifier flag (S): This 1-bit field SHALL be set to '1' to indicate a 32-bit word in the TSI field. Transport Object Identifier flag (O): This 2-bit field SHALL be set to '01' to indicate the number of full 32-bit words in the TOI field. Half-word flag (H): This 1-bit field SHALL be set to '0' to indicate that no half-word field sizes are used. Codepoint (CP): This 8-bit field is used to indicate the type of the payload that is carried by this packet; for ROUTE, it is defined as shown below to indicate the type of delivery object carried in the payload of the associated ROUTE packet. The remaining unmapped Codepoint values can be used by a service using ROUTE. In this case, the Codepoint values SHALL follow the semantics specified in the following table. "IS" stands for Initialization Segment of the media content such as the DASH Initialization Segment [DASH]. The various modes of operation in the table (File/Entity/Package Mode) are specified in Section 4. The table also lists a Codepoint value range that is reserved for future service-specific uses. +=================+=================================+ | Codepoint value | Semantics | +=================+=================================+ | 0 | Reserved (not used) | +-----------------+---------------------------------+ | 1 | Non Real Time (NRT) - File Mode | +-----------------+---------------------------------+ | 2 | NRT - Entity Mode | +-----------------+---------------------------------+ | 3 | NRT - Unsigned Package Mode | +-----------------+---------------------------------+ | 4 | NRT - Signed Package Mode | +-----------------+---------------------------------+ | 5 | New IS, timeline changed | +-----------------+---------------------------------+ | 6 | New IS, timeline continued | +-----------------+---------------------------------+ | 7 | Redundant IS | +-----------------+---------------------------------+ | 8 | Media Segment, File Mode | +-----------------+---------------------------------+ | 9 | Media Segment, Entity Mode | +-----------------+---------------------------------+ | 10 | Media Segment, File Mode with | | | CMAF Random Access chunk | +-----------------+---------------------------------+ | 11 - 255 | Reserved, service-specific | +-----------------+---------------------------------+ Table 2: Codepoint Values Congestion Control Information (CCI): For packets carrying DASH segments, CCI MAY convey the 32-bit earliest presentation time [DASH] of the DASH segment contained in the ROUTE packet. In this case, this information can be used by a ROUTE receiver for fast stream acquisition (details in Section 6.2). Otherwise, this field SHALL be set to 0. Transport Session Identifier (TSI): This 32-bit field identifies the Transport Session in ROUTE. The context of the Transport Session is provided by signaling metadata. The value TSI = 0 SHALL only be used for service-specific signaling. Transport Object Identifier (TOI): This 32-bit field SHALL identify the object within this session to which the payload of the current packet belongs. The mapping of the TOI field to the object is provided by the Extended File Delivery Table (FDT). 2.2. LCT Header Extensions The following LCT header extensions are defined or used by ROUTE: EXT_FTI: as specified in RFC 5775. EXT_TOL: the length in bytes of the multicast transport object shall be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with 24 bits or, if required, 48 bits of Transfer Length. The frequency of using the EXT_TOL header extension is determined by channel conditions that may cause the loss of the packet carrying the Close Object flag (B) [RFC5651]. NOTE: The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length. EXT_TIME Header: as specified in RFC 5651 [RFC5651]. The Sender Current Time SHALL be signaled using EXT_TIME. 2.3. FEC Payload ID for Source Flows The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme used in ROUTE Source Flows is a 32-bit unsigned integer value that SHALL express the start_offset as an octet number corresponding to the first octet of the fragment of the delivery object carried in this packet. The start_offset value for the first fragment of any delivery object SHALL be set to 0. Figure 3 shows the 32-bit start_offset field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FEC Payload ID for Source Flows 2.4. FEC Payload ID for Repair Flows FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330]. 3. Session Metadata The required session metadata for Source and Repair Flows is specified in the following sections. The list specified here is not exhaustive; a service MAY signal more metadata to meet its needs. The data format is also not specified beyond its cardinality; the exact format of specifying the data is left for the service, e.g., by using XML encoding format, as has been done by [DVBMABR] and [ATSCA331]. It is specified in the following if an attribute is mandatory (m), conditional mandatory (cm) or optional (o) to realize a basic ROUTE session. A mandatory field SHALL always be present in the session metadata, and a conditional mandatory field SHALL be present if the specified condition is true. The delivery of the session metadata to the ROUTE receiver is beyond the scope of this document. 3.1. Generic Metadata Generic metadata is applicable to both Source and Repair Flows as follows. Before a receiver can join a ROUTE session, the receiver needs to obtain this generic metadata that contains at least the following information: ROUTE version number (m): the version number of ROUTE used in this session. The version number conforming to this document SHALL be 1. Connection ID (m): the unique identifier of a Connection, usually consisting of the following 4-tuple: source IP address/source port number, destination IP address/destination port number. The IP addresses can be IPv4 or IPv6 addresses depending upon which IP version is used by the deployment. 3.2. Session Metadata for Source Flows stsi (m): The LCT TSI value corresponding to the Transport Session for the Source Flow. rt (o): A Boolean flag that SHALL indicate whether the content component carried by this Source Flow corresponds to real-time streaming media or non-real-time content. When set to "true", it SHALL be an indication of real-time content, and when absent or set to "false", it SHALL be an indication of non-real-time (NRT) content. minBufferSize (o): A 32-bit unsigned integer that SHALL represent, in kilobytes, the minimum required storage size of the receiver transport buffer for the parent LCT channel of this Source Flow. The buffer holds the data belonging to a source object until its complete reception. This attribute is only applicable when rt = "true". A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received data beyond its buffering capability. Such discarding of data will impact the service quality. EFDT (cm): When present, SHALL contain a single instance of an FDT- Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the optional FDT extensions as defined in Section 4.1. The optional EFDT element MAY only be present for File Mode of delivery. In File Mode, it SHALL be present if this Source Flow transports streaming media segments. contentType (o): A string that SHALL represent the media type for the media content. It SHALL obey the semantics of the Content- Type header as specified by the HTTP/1.1 protocol in RFC 7231 [RFC7231]. This document does not define any new contentType strings. In its absence, the signaling of media type for the media content is beyond the scope of this document. applicationMapping (m): A set of identifiers that provide an application-specific mapping of the received Application Objects to the Source Flows. For example, for DASH, this would provide the mapping of a Source Flow to a specific DASH Representation from a Media Presentation Description (MPD), the latter identified by its Representation and corresponding Adaptation Set and Period IDs. 3.3. Session Metadata for Repair Flows minBuffSize (o): A 32-bit unsigned integer whose value SHALL represent a required size of the receiver transport buffer for AL-FEC decoding processing. When present, this attribute SHALL indicate the minimum buffer size that is required to handle all associated objects that are assigned to a super-object, i.e., a delivery object formed by the concatenation of multiple FEC transport objects in order to bundle these FEC transport objects for AL-FEC protection. A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received repair data beyond its buffering capability. Such discarding of data will impact the service quality. fecOTI (m): A parameter consisting of the concatenation of Common and Scheme-Specific FEC Object Transmission Information (FEC OTI) as defined in Sections 3.3.2 and 3.3.3 of [RFC6330] and that corresponds to the delivery objects carried in the Source Flow to which this Repair Flow is associated, with the following qualification: the 40-bit Transfer Length (F) field may either represent the actual size of the object, or it is encoded as all zeroes. In the latter case, the FEC transport object size either is unknown or cannot be represented by this attribute. In other words, for the all-zeroes format, the delivery objects in the Source Flow correspond to streaming content, either a live Service whereby content encoding has not yet occurred at the time this session data was generated or pre-recorded streaming content whose delivery object sizes, albeit known at the time of session data generation, are variable and cannot be represented as a single value by the fecOTI attribute. ptsi (m): TSI value(s) of each Source Flow protected by this Repair Flow. mappingTOIx (o): Values of the constant X for use in deriving the TOI of the delivery object of each protected Source Flow from the TOI of the FEC (super-)object. The default value is "1". Multiple mappingTOIx values MAY be provided for each protected Source Flow depending upon the usage of FEC (super-)object. mappingTOIy (o): The corresponding constant Y to each mappingTOIx, when present, for use in deriving the parent SourceTOI value from the above equation. The default value is "0". 4. Delivery Object Mode ROUTE provides several different delivery object modes, and one of these modes may suit the application needs better for a given Transport Session. A delivery object is self contained for the application, typically associated with certain properties, metadata, and timing-related information relevant to the application. The signaling of the delivery object mode is done on an object basis using Codepoint as specified in Section 2.1. 4.1. File Mode File Mode uses an out-of-band Extended FDT (EFDT) signaling for recovery of delivery objects with the following extensions and considerations. 4.1.1. Extensions to FDT The following extensions are specified to FDT, as specified in RFC 6726 [RFC6726]. An Extended FDT-Instance is an instance of FLUTE FDT, as specified in [RFC6726], plus optionally one or more of the following extensions: efdtVersion: A value that SHALL represent the version of this Extended FDT-Instance. maxExpiresDelta: Let "tp" represent the wall clock time at the receiver when the receiver acquires the first ROUTE packet carrying data of the object described by this Extended FDT- Instance. maxExpiresDelta, when present, SHALL represent a time interval that when added to "tp" SHALL represent the expiration time of the associated Extended FDT-Instance "te". The time interval is expressed in number of seconds. When maxExpiresDelta is not present, the expiration time of the Extended FDT-Instance SHALL be given by the sum of a) the value of the ERT field in the EXT_TIME LCT header extension in the first ROUTE packet carrying data of that file, and b) the current receiver time when parsing the packet header of that ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for deriving the Extended FDT-Instance expiration time. Hence, te = tp + maxExpiresDelta maxTransportSize: An attribute that SHALL represent the maximum transport size in bytes of any delivery object described by this Extended FDT-Instance. This attribute SHALL be present if a) the fileTemplate is present in Extended FDT-Instance, or b) one or more File elements, if present in this Extended FDT-Instance, do not include the Transfer-Length attribute. When maxTransportSize is not present, the maximum transport size is not signaled, while other signaling such as the Transfer-Length attribute signal the exact Transfer Length of the object. fileTemplate: A string value, which when present and in conjunction with parameter substitution, is used in deriving the Content- Location attribute for the delivery object described by this Extended FDT-Instance. It SHALL include the "$TOI$" identifier. Each identifier MAY be suffixed as needed by specific file names within the enclosing '