• 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.

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 [RFC 5651]. 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 [RFC 5651]. 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.

• 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   +--------------------------------------------+

 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                         |
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 [RFC 5651].

Congestion Control flag (C) field:

This 2-bit field, as defined in RFC 5651 [RFC 5651], 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.

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).

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) [RFC 5651].

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 [RFC 5651]. The Sender Current Time SHALL be signaled using EXT_TIME.

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.

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 [RFC 6726], 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 [RFC 7231]. 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.

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 [RFC 6330] 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".

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 '$' characters following this prototype: %0[width]d

• Delivery object metadata SHALL be expressed in the form of entity headers as defined in HTTP/1.1, which correspond to one or more of the representation header fields, payload header fields, and response header fields as defined in Sections 3.1, 3.3, and 7, respectively, of [RFC 7231].
• The entity headers sent along with the delivery object provide all information about that multicast transport object.
• Sending a media object (if the object is chunked) in Entity Mode may result in one of the following options:
  • If the length of the chunked object is known at the sender, the ROUTE Entity Mode delivery object MAY be sent without using HTTP/1.1 chunked transfer coding, i.e., the object starts with an HTTP header containing the Content Length field followed by the concatenation of CMAF Chunks:

    |HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
    --||---chunk ----|
    

  • If the length of the chunked object is unknown at the sender when starting to send the object, HTTP/1.1 chunked transfer coding format SHALL be used:

    |HTTP Header||Separator+Length||---chunk ----
    ||Separator+Length||---chunk ----||Separator+Length||---chunk
    ----||Separator+Length||---chunk ----||Separator+Length=0|
    

    Note, however, that it is not required to send a CMAF Chunk in exactly one HTTP chunk.

• ROUTE limits the usage of the LCT building block to a single channel per session. Congestion control is thus sender driven in ROUTE. It also signifies that there is no specific congestion-control-related signaling from the sender to the receiver; the CCI field is either set to 0 or used for other purposes as specified in Section 2.1. The functionality of receiver-driven layered multicast may still be offered by the application, allowing the receiver application to select the appropriate delivery session based on the bandwidth requirement of that session.

• The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC 5651] is used with the following constraints:
  • The TSI in the LCT header SHALL be set equal to the value of the stsi attribute in Section 3.2.
  • The Codepoint (CP) in the LCT header SHALL be used to signal the applied formatting as defined in the signaling metadata.
  • In accordance with ALC, a source FEC Payload ID header is used to identify, for FEC purposes, the encoding symbols of the delivery object, or a portion thereof, carried by the associated ROUTE packet. This information may be sent in several ways:
    • As a simple new null FEC scheme with the following usage:
      • The value of the source FEC Payload ID header SHALL be set to 0 in case the ROUTE packet contains the entire delivery object, or
      • The value of the source FEC Payload ID header SHALL be set as a direct address (start offset) corresponding to the starting byte position of the portion of the object carried in this packet using a 32-bit field.
    • In a compatible manner to RFC 6330 [RFC 6330] where the SBN and ESI defines the start offset together with the symbol size T.
    • The signaling metadata provides the appropriate parameters to indicate any of the above modes using the srcFecPayloadId attribute.
• The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC 5651] MAY be used by the sender in the following manner:
  • The Sender Current Time (SCT), depending on the application, MAY be used to occasionally or frequently signal the sender current time possibly for reliever time synchronization.
  • The Expected Residual Time (ERT) MAY be used to indicate the expected remaining time for transmission of the current object in order to optimize detection of a lost delivery object.
  • The Sender Last Changed (SLC) flag is typically not utilized but MAY be used to indicate the addition/removal of Segments.

1. The amount of data to be sent in a single ROUTE packet is limited by the maximum transfer unit of the data packets or the size of the remaining data of the Application Object being sent, whichever is smaller. The transfer unit is determined either by knowledge of underlying transport block sizes or by other constraints.
2. The start_offset field in the LCT header of the ROUTE packet indicates the byte offset of the carried data in the Application Object being sent.
3. The Close Object flag (B) is set to 1 if this is the last ROUTE packet carrying the data of the Application Object.

1. If it is the first ROUTE packet carrying a CMAF Random Access chunk, except for the first CMAF Chunk in the segment, the Codepoint value MAY be set to 10, as specified in the Codepoint value table in Section 2.1. The receiver MAY use this information for optimization of random access.
2. As soon as the total length of the media object is known, potentially with the packaging of the last CMAF Chunk of a segment, the EXT_TOL extension header MAY be added to the LCT header to signal the Transfer Length, so that the receiver may know this information in a timely fashion.

• The TOI field in the ROUTE packet header SHALL be set such that Content-Location can be derived at the receiver according to File Template substitution specified in Section 6.3.1.
• After sending the first packet with a given TOI value, none of the packets pertaining to this TOI SHALL be sent later than the wall clock time as derived from maxExpiresDelta. The EXT_TIME header with Expected Residual Time (ERT) MAY be used in order to convey more accurate expiry time.

• FEC-related information is provided only where needed.
• Receivers not capable of this framework can ignore repair packets.
• The FEC is symbol based with fixed symbol size per protected Source Flow. The ALC protocol and existing FEC schemes are reused.
• A FEC Repair Flow provides protection of delivery objects from one or more Source Flows.

• FEC Repair Flow declaration including all FEC-specific information.
• A FEC transport object that is the concatenation of a delivery object, padding octets, and size information in order to form a chunk of data that has a size in symbols of N, where N >= 1.
• A FEC super-object that is the concatenation of one or more FEC transport objects in order to bundle FEC transport objects for FEC protection.
• A FEC protocol and packet structure.

• TSI and TOI of the delivery object. In this case, the FEC object corresponds to the (entire) delivery object.
• Octet range of the delivery object, i.e., start offset within the delivery object and number of subsequent and contiguous octets of delivery object that constitutes the FEC object (i.e., the FEC-protected portion of the source object). In this case, the FEC object corresponds to a contiguous byte range portion of the delivery object.

• F be the size of the delivery object in octets,
• F' be the F octets of data of the delivery object,
• f' denote the four octets of data carrying the value of F in network octet order (high-order octet first),
• S be the size of the FEC transport object with S=ceil((F+4)/Y), where the ceil() function rounds the result upward to its nearest integer,
• P' be S*Y-4-F octets of data, i.e., padding placed between the delivery object and the 4-byte field conveying the value of F and located at the end of the FEC transport object, and
• O' be the concatenation of F', P', and f'.

• The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object is generated
• The start octet within the delivery object for the associated FEC object
• The size in symbols of the FEC transport object, S

• N be the total number of FEC transport objects for the FEC super-object construction.
• For i = 0, ..., N-1, let S[i] be the size in symbols of FEC transport object i.
• B' be the FEC super-object that is the concatenation of the FEC transport objects in numerical order, comprised of K = Sum of N source symbols, each symbol denoted as S[i].

• The total number of FEC transport objects N.
• For each FEC transport object:
  • The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object is generated,
  • The start octet within the delivery object for the associated FEC object, and
  • The size in symbols of the FEC transport object.

• The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC 5651] is used as defined in Asynchronous Layered Coding (ALC), Section 2.1. In addition, the following constraint applies:
  • The TSI in the LCT header SHALL identify the Repair Flow to which this packet applies by the matching the value of the ptsi attribute in the signaling metadata among the LCT channels carrying Repair Flows.
• The FEC building block is used according to RFC 6330 [RFC 6330], but only repair packets are delivered.
  • Each repair packet within the scope of the Repair Flow (as indicated by the TSI field in the LCT header) SHALL carry the repair symbols for a corresponding FEC transport object/super-object as identified by its TOI. The repair object/super- object TOI SHALL be unique for each FEC super-object that is created within the scope of the TSI.

• The FEC configuration consisting of:
  • FEC Object Transmission Information (OTI) per RFC 5052 [RFC 5052].
  • Additional FEC information (see Section 3.3).
  • The total number of FEC objects included in the FEC super-object, N.
• For each FEC transport object:
  • TSI and TOI of the delivery object used to generate the FEC object associated with the FEC transport object,
  • The start octet within the delivery object of the associated FEC object, if applicable, and
  • The size in symbols of the FEC transport object, S.

• Statically in the session metadata as defined in Section 3.3, and
• Dynamically in an LCT extension header.

1)

The ROUTE receiver is expected to parse the LCT and FEC Payload ID to verify that it is a valid header. If it is not valid, then the payload is discarded without further processing.

2)

All ROUTE packets used to recover a specific delivery object carry the same TOI value in the LCT header.

3)

The ROUTE receiver is expected to assert that the TSI and the Codepoint represent valid operation points in the signaling metadata, i.e., the signaling contains a matching entry to the TSI value provided in the packet header, as well as for this TSI, and the 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, using the source FEC Payload ID (to determine the start_offset) and the payload data to reconstruct the corresponding object as follows:

1. For File Mode, upon receipt of the first ROUTE packet payload for an object, the ROUTE receiver uses the File@Transfer-Length attribute of the associated Extended FDT-Instance, when present, to determine the length T of the object. When the File@Transfer-Length attribute is not present in the Extended FDT-Instance, the receiver uses the maxTransportSize attribute of the associated Extended FDT-Instance to determine the maximum length T' of the object. Alternatively, and specifically for delivery modes other than File Mode, the EXT_TOL header can be used to determine the length T of the object.
2. The ROUTE receiver allocates buffer space for the T or T' bytes that the object will or may occupy.
3. The ROUTE receiver computes the length of the payload, Y, by subtracting the payload header length from the total length of the received payload.
4. The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or RECEIVED[0..T'-1], as appropriate, with all entries initialized to false to track received object symbols. The ROUTE receiver continuously acquires packet payloads for the object as long as all of the following conditions are satisfied:
   1. there is at least one entry in RECEIVED still set to false,
   2. the object has not yet expired, and
   3. the application has not given up on reception of this object. More details are provided below.
5. 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:
   1. 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].
   2. 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.
   3. 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.
   4. If all T entries of RECEIVED are true, then the receiver has recovered the entire object.

• The receiver checks for the first received packet with the Codepoint value set to 10, indicating the start of a CMAF Random Access chunk.
• The receiver MAY make the partially received object (a partial DASH segment starting from the packet above) available to the application for fast stream acquisition.
• It MAY recover the earliest presentation time of this CMAF Random Access chunk from the ROUTE packet LCT Congestion Control 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 containing just the partially received DASH segment with period continuity signaling.

• The desired start-up and end-to-end latency. If a Repair Flow requires a significant amount of buffering time to be effective, such Repair Flow might only be used in time-shift operations or in poor reception conditions, since use of such Repair Flow trades off end-to-end latency against DASH Media Presentation quality.
• FEC capabilities, i.e., the receiver MAY pick only the FEC algorithm that it supports.
• Which Source Flows are being protected; for example, if the Repair Flow protects Source Flows that are not selected by the receiver, then the receiver may not select the Repair Flow.
• Other considerations such as available buffer size, reception conditions, etc.

• The latest time that the file repair procedure may start is bound by the @Expires attribute of the FDT-Instance.
• The receiver may choose to start the file repair procedure earlier if it detects the occurrence of any of the following events:
  • Presence of the Close Object flag (B) in the LCT header [RFC 5651] for the file of interest;
  • Presence of the Close Session flag (A) in the LCT header [RFC 5651] before the nominal expiration of the Extended FDT-Instance as defined by the @Expires attribute.

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:
   1. 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.
   2. 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.
   3. With the reception of the repair packets, the FEC super-object can be recovered.
   4. Once the FEC super-object is recovered, the individual delivery objects can be extracted.

• Restrict the signaling of certain values signaled in the LCT header and/or provision unused fields in the LCT header.
• Restrict using certain LCT header extensions and/or add new LCT header extensions.
• Restrict or limit usage of some Codepoints and/or assign semantics to service-specific Codepoints marked as reserved in this document.
• Restrict usage of certain Service signaling attributes and/or add their own service metadata.

• 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.
• The most significant PSI bit in the LCT, if carried in the same LCT channel. This mode of operation is mostly suitable for FLUTE-compatible deployments.

[ATSCA331]

Advanced Television Systems Committee, "Signaling, Delivery, Synchronization, and Error Protection", ATSC Standard A/331:2022-03, March 2022.

[RFC1952]

P. Deutsch, "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2557]

J. Palme, A. Hopmann, and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>.

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC5052]

M. Watson, M. Luby, and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.

[RFC5445]

M. Watson, "Basic Forward Error Correction (FEC) Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
<https://www.rfc-editor.org/info/rfc5445>.

[RFC5651]

M. Luby, M. Watson, and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>.

[RFC5775]

M. Luby, M. Watson, and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010,
<https://www.rfc-editor.org/info/rfc5775>.

[RFC6330]

M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, August 2011,
<https://www.rfc-editor.org/info/rfc6330>.

[RFC6363]

M. Watson, A. Begen, and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.

[RFC6726]

T. Paila, R. Walsh, M. Luby, V. Roca, and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>.

[RFC7231]

R. Fielding, and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8551]

J. Schaad, B. Ramsdell, 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>.

[CMAF]

International Organization for Standardization, "Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", ISO/IEC FDIS 23000-19, January 2018,
<https://www.iso.org/standard/71975.html>.

[DASH]

International Organization for Standardization, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2019, December 2019,
<https://www.iso.org/standard/79329.html>.

[DVBMABR]

ETSI, "Digital Video Broadcasting (DVB); Adaptive media streaming over IP multicast", ETSI TS 103 769, November 2020.

[HTTP3]

, "Hypertext Transfer Protocol Version 3 (HTTP/3)", Internet-Draft draft-ietf-quic-http-34, February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34>.

[MBMS]

ETSI, "Universal Mobile Telecommunications Systems (UMTS); LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", ETSI TS 126 346, May 2021.

[RFC3740]

T. Hardjono, and B. Weis, "The Multicast Group Security Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
<https://www.rfc-editor.org/info/rfc3740>.

[RFC6968]

V. Roca, and B. Adamson, "FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6968, DOI 10.17487/RFC6968, July 2013,
<https://www.rfc-editor.org/info/rfc6968>.

[RFC8932]

S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, October 2020,
<https://www.rfc-editor.org/info/rfc8932>.

[RFC9000]

J. Iyengar, and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.

[RFC9147]

E. Rescorla, H. Tschofenig, and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.

Waqar Zia

Thomas Stockhammer

Lenaig Chaponniere

Giridhar Mandyam

Michael Luby