FLUTE - File Delivery over Unidirectional Transport
obsoletes
- rfc-3926 — FLUTE - File Delivery over Unidirectional Transport
Extracted elements (30)
FDT Instance expiration timestamps use only the 32 most significant bits of a 64-bit NTP time value, representing whole seconds. Both senders and receivers determine the correct 136-year epoch by choosing whichever makes the expiration time closest to current time, handling the 2036 wraparound without flag bits.
FDT Instances have higher priority than files because a receiver needs a file's FDT entry before it can recover the file. It is RECOMMENDED that FDT Instances be sent before and during file transmission, and that FEC protection be applied to multi-packet FDT Instances to handle packet loss.
FEC OTI can be delivered either via EXT_FTI (per-packet, lower latency but higher overhead) or via the FDT (once in the file description entry, lower overhead). When both are available, receivers SHOULD prioritize EXT_FTI, as the FDT may arrive later.
FLUTE uses XML for FDT Instances to allow extensibility: private elements and attributes may be added inside 'File' or 'FDT-Instance' elements, and unsupported private attributes SHOULD be silently ignored. This avoids versioning churn for application-specific metadata.
FLUTE version 2 (this specification) is not backwards compatible with FLUTE version 1 defined in RFC 3926. Receivers encountering multiple FLUTE sessions on a channel MUST determine the version from the EXT_FDT header's V field combined with the (source IP address, TSI) pair.
When using multiple channels/layers, ordering guarantees between objects are lost: delivery of a second object may complete before the first. Applications with a mandatory requirement that objects complete in order SHOULD use a single channel.
A FLUTE session consistent with this specification MUST use FLUTE version 2, and all packets MUST set the FLUTE version field to '2' in the EXT_FDT Header Extension. The session MUST also use ALC version 1 and LCT version 1.
A receiver MUST NOT use a received FDT Instance to interpret packets beyond its expiration time. A sender MUST use an expiration time in the future (relative to Sender Current Time) upon creation of an FDT Instance.
Any ALC/LCT packet carrying an FDT Instance MUST include the EXT_FDT LCT Header Extension. The FDT Instance Header is identical for all packets belonging to a particular FDT Instance.
Each file in a file delivery session MUST be associated with a TOI value greater than 0, scoped by the source IP address and TSI. An object received with an unmapped non-zero TOI SHOULD in general be ignored by a FLUTE receiver.
For every file delivered within a file delivery session, there MUST be a file description entry included in at least one FDT Instance sent within the session. Each entry MUST include at minimum the TOI-to-URI mapping.
If an FDT Instance is content encoded, EXT_CENC MUST be used to signal the encoding type and MUST appear in all ALC packets carrying the same FDT Instance ID alongside EXT_FDT. If content encoding is not used, EXT_CENC MUST NOT appear.
Senders MUST NOT reuse an FDT Instance ID value already in use for a non-expired FDT Instance. Receipt of an FDT Instance reusing a currently-active ID MUST be considered an error. Receivers MUST be ready to handle FDT Instance ID wraparound.
The 'FDT-Instance' root XML element MUST contain the 'Expires' attribute. Each 'File' child element MUST contain at least 'TOI' and 'Content-Location' attributes, where 'Content-Location' MUST be a syntactically valid URI.
The TOI field MUST be included in all ALC packets sent within a FLUTE session, except for Close Session packets (A flag = 1) that contain no payload. TOI value '0' MUST be reserved exclusively for delivery of FDT Instances.
When FEC Object Transmission Information is delivered via the FDT, the 'FEC-OTI-FEC-Encoding-ID' attribute and the Codepoint field of all packets for the same TOI MUST be identical. The receiver MUST support FEC OTI delivery via both EXT_FTI and the FDT.
Whenever content encoding is applied to a file, the 'Content-Encoding' attribute MUST be included in the FDT file description entry and MUST be used as described in RFC 2616. 'Content-MD5' MUST NOT be regarded as a security mechanism.
An FDT Instance is an XML document with root element 'FDT-Instance' containing one or more 'File' child elements. It carries a mandatory 'Expires' timestamp (32 most significant bits of a 64-bit NTP value as UTF-8 decimal) and an optional 'Complete' boolean attribute.
The File Delivery Table (FDT) is a logical set of file description entries delivered as FDT Instances within the session. Each entry maps a TOI to file attributes including URI (Content-Location), media type, size, encoding, and FEC Object Transmission Information.
IANA created the 'FLUTE Content Encoding Algorithms' registry with values 0-255, using Specification Required policy. Initial entries: 0=null, 1=ZLIB (RFC 1950), 2=DEFLATE (RFC 1951), 3=GZIP (RFC 1952). The 8-bit CENC field in EXT_CENC references this registry.
IANA registered the XML namespace 'urn:ietf:params:xml:ns:fdt', the XML schema 'urn:ietf:params:xml:schema:fdt', and the media type 'application/fdt+xml' for FDT Instances. The media type uses optional parameter charset='utf-8' and file extension '.fdt'.
IANA registered two new entries in the 'Layered Coding Transport (LCT) Header Extension Types' registry: 192 = EXT_FDT (FDT Instance Header) and 193 = EXT_CENC (Content Encoding Header), both defined in RFC 6726.
Corrupting FDT Instances can cause denial-of-service by making receivers reject correctly received files (e.g., via forged MD5 checksums) or by substituting FEC parameters to vastly increase processing load. It is RECOMMENDED that FDT Instance integrity and sender authentication be guaranteed, using XML digital signatures when no packet-level scheme is used.
File-level integrity (digital signature applied once per file) has low overhead but cannot isolate corrupt packets. Packet-level integrity (TESLA, HMAC Group-Keyed MAC, per-packet digital signatures) can isolate corrupt packets but adds per-packet overhead. At least one technique SHOULD be used when file corruption is a concern.
Forged ALC packets with the Close Session (A) or Close Object (B) flags set can cause receivers to prematurely terminate a session or abandon object reception. Packet-level authentication (Section 7.2.2) is RECOMMENDED to protect ALC/LCT header integrity.
The mandatory-to-implement baseline security for FLUTE is IPsec/ESP in transport mode, inheriting ALC's baseline. Data origin authentication, content integrity, and anti-replay SHALL be supported; confidentiality is RECOMMENDED. Automated key management is RECOMMENDED for long-lived sessions.
FDT Instance lifecycle: ACTIVE (valid, identified by FDT Instance ID within EXT_FDT) transitions to EXPIRED when current time exceeds the 'Expires' NTP timestamp. Once expired, the ID may be reclaimed by starting from the smallest expired ID. Receivers MUST NOT apply an expired FDT Instance to newly received packets.
ALC/LCT packets carrying an FDT Instance consist of (in order): UDP header, default LCT header with TOI=0, LCT Header Extensions (EXT_FDT, optionally EXT_CENC and EXT_FTI), FEC Payload ID, and Encoding Symbols for the FDT Instance payload. All integer fields are in network byte order.
EXT_CENC (HET=193) is a 32-bit fixed-length LCT Header Extension: 8-bit HET field (value 193), 8-bit CENC field (content encoding algorithm: 0=null, 1=ZLIB, 2=DEFLATE, 3=GZIP), and 16-bit Reserved field (MUST be set to 0, MUST be ignored on reception).
EXT_FDT (HET=192) is a 32-bit fixed-length LCT Header Extension: 8-bit HET field (value 192), 4-bit FLUTE Version field (V, set to 2), and 20-bit FDT Instance ID. FDT Instance IDs start at 0 and increment per new instance within a session.