ROUTE Source Flow carries the source data as specified in
RFC 5775 [
RFC 5775]. There are several special considerations that ROUTE introduces to the usage of the LCT building block as outlined in the following:
-
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.
Further, the following details apply to LCT:
-
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.
Additional extension headers
MAY be used to support real-time delivery. Such extension headers are defined in
Section 2.1.
The following description of the ROUTE sender operation on the mapping of the Application Object to the ROUTE packet payloads logically represents an extension of
RFC 5445 [
RFC 5445], which in turn inherits the context, language, declarations, and restrictions of the FEC building block in
RFC 5052 [
RFC 5052].
The data carried in the payload of a given ROUTE packet constitutes a contiguous portion of the Application Object. ROUTE source delivery can be considered as a special case of the use of the Compact No-Code Scheme associated with FEC Encoding ID = 0 according to Sections
3.4.1 and
3.4.2 of [
RFC 5445], in which the encoding symbol size is exactly one byte. As specified in
Section 2.1, for ROUTE Source Flows, the FEC Payload ID
SHALL deliver the 32-bit start_offset. All receivers are expected to support, at minimum, operation with this special case of the Compact No-Code FEC.
Note that in the event the source object size is greater than 2
32 bytes (approximately 4.3 GB), the applications (in the broadcaster server and the receiver) are expected to perform segmentation/reassembly using methods beyond the scope of this document.
Finally, in some special cases, a ROUTE sender
MAY need to produce ROUTE packets that do not contain any payload. This may be required, 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 header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the LCT header, FEC Payload ID, and payload data.
In the basic operation, it is assumed that the Application Object is fully available at the ROUTE sender.
-
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.
-
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.
-
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 other constraints, delivery with increasing start_offset value is recommended.
The following additional guidelines should be followed for ROUTE packetization of CMAF Chunked Content in addition to the guidelines of
Section 5.2.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.
-
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 sender
SHALL use the timing information provided by the application to time the emission of packets for a timely reception. This information may be contained in the Application Objects e.g., DASH segments and/or the presentation manifest. Hence, such packets of streaming media with real-time constraints
SHALL be sent in such a way as to enable their timely reception with respect to the presentation timeline.
For File Mode sending:
-
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.
The FEC framework uses concepts of the FECFRAME work as defined in
RFC 6363 [
RFC 6363], as well as the FEC building block,
RFC 5052 [
RFC 5052], which is adopted in the existing FLUTE/ALC/LCT specifications.
The FEC design adheres to the following principles:
-
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.
The FEC-specific components of the FEC framework are:
-
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.
A receiver needs to be able to recover delivery objects from repair packets based on available FEC information.
In order to identify a delivery object in the context of the repair protocol, the following information is needed:
-
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.
Typically, for real-time object delivery with smaller delivery object sizes, the first mapping is applied, i.e., the delivery object is a FEC object.
Assuming that the FEC object is the delivery object, for each delivery object, the associated FEC transport object is comprised of the concatenation of the delivery object, padding octets (P), and the 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 integer multiple of the symbol size Y. S is determined from the session information and/or the repair packet headers.
F is carried in the last 4 octets of the FEC transport object. Specifically, let:
-
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'.
O' then constitutes the FEC transport object of size S*Y octets. Note that padding octets and the object size F are not sent in source packets of the delivery object but are only part of a FEC transport object that FEC decoding recovers in order to extract the FEC object and thus the delivery object or portion of the delivery object that constitutes the FEC object. In the above context, the FEC transport object size in symbols is S.
The general information about a FEC transport object that is conveyed to a FEC-enabled receiver is the source TSI, source TOI, and the associated octet range within the delivery object comprising the associated FEC object. However, as the size in octets of the FEC object is provided in the appended field within the FEC transport object, the remaining information can be conveyed as:
-
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
From the FEC Repair Flow declaration, the construction of a FEC super-object as the concatenation of one or more FEC transport objects can be determined. The FEC super-object includes the general information about the FEC transport objects as described in the previous sections, as well as the placement order of FEC transport objects within the FEC super-object.
Let:
-
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].
For each FEC super-object, the remaining general information that needs to be conveyed to a FEC-enabled receiver, beyond what is already carried in the FEC transport objects that constitute the FEC super-object, comprises:
-
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 carriage of the FEC repair information is discussed below.
The repair protocol is based on Asynchronous Layered Coding (ALC) as defined in
RFC 5775 [
RFC 5775] and the Layered Coding Transport (LCT) Building Block as defined in
RFC 5651 [
RFC 5651] with the following details:
-
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.
For each super-object (identified by a unique TOI within a Repair Flow that is in turn identified by the TSI in the LCT header) that is generated, the following information needs to be communicated to the receiver:
-
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.
The above information is delivered:
-
Statically in the session metadata as defined in Section 3.3, and
-
Dynamically in an LCT extension header.