GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6726

Internet Engineering Task Force (IETF) T. Paila Request for Comments: 6726 Nokia Obsoletes: 3926 R. Walsh Category: Standards Track Nokia/TUT ISSN: 2070-1721 M. Luby

                                           Qualcomm Technologies, Inc.
                                                               V. Roca
                                                                 INRIA
                                                           R. Lehtonen
                                                           TeliaSonera
                                                         November 2012
        FLUTE - File Delivery over Unidirectional Transport

Abstract

 This document defines File Delivery over Unidirectional Transport
 (FLUTE), a protocol for the unidirectional delivery of files over the
 Internet, which is particularly suited to multicast networks.  The
 specification builds on Asynchronous Layered Coding, the base
 protocol designed for massively scalable multicast distribution.
 This document obsoletes RFC 3926.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6726.

Paila, et al. Standards Track [Page 1] RFC 6726 FLUTE November 2012

Copyright Notice

 Copyright (c) 2012 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
 (http://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.  Code Components extracted from this document must
 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.
 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.

Table of Contents

 1. Introduction ....................................................3
    1.1. Applicability Statement ....................................5
         1.1.1. The Target Application Space ........................5
         1.1.2. The Target Scale ....................................5
         1.1.3. Intended Environments ...............................5
         1.1.4. Weaknesses ..........................................6
 2. Conventions Used in This Document ...............................6
 3. File Delivery ...................................................7
    3.1. File Delivery Session ......................................8
    3.2. File Delivery Table .......................................10
    3.3. Dynamics of FDT Instances within a File Delivery Session ..12
    3.4. Structure of FDT Instance Packets .........................15
         3.4.1. Format of FDT Instance Header ......................16
         3.4.2. Syntax of FDT Instance .............................17
         3.4.3. Content Encoding of FDT Instance ...................21
    3.5. Multiplexing of Files within a File Delivery Session ......22
 4. Channels, Congestion Control, and Timing .......................23
 5. Delivering FEC Object Transmission Information .................24
 6. Describing File Delivery Sessions ..............................26

Paila, et al. Standards Track [Page 2] RFC 6726 FLUTE November 2012

 7. Security Considerations ........................................27
    7.1. Problem Statement .........................................27
    7.2. Attacks against the Data Flow .............................28
         7.2.1. Access to Confidential Files .......................28
         7.2.2. File Corruption ....................................28
    7.3. Attacks against the Session Control Parameters and
         Associated Building Blocks ................................30
         7.3.1. Attacks against the Session Description ............30
         7.3.2. Attacks against the FDT Instances ..................31
         7.3.3. Attacks against the ALC/LCT Parameters .............31
         7.3.4. Attacks against the Associated Building Blocks .....32
    7.4. Other Security Considerations .............................32
    7.5. Minimum Security Recommendations ..........................33
 8. IANA Considerations ............................................34
    8.1. Registration of the FDT Instance XML Namespace ............34
    8.2. Registration of the FDT Instance XML Schema ...............34
    8.3. Registration of the application/fdt+xml Media Type ........35
    8.4. Creation of the FLUTE Content Encoding Algorithms
         Registry ..................................................36
    8.5. Registration of LCT Header Extension Types ................36
 9. Acknowledgments ................................................36
 10. Contributors ..................................................37
 11. Change Log ....................................................37
    11.1. RFC 3926 to This Document ................................37
 12. References ....................................................40
    12.1. Normative References .....................................40
    12.2. Informative References ...................................41
 Appendix A. Receiver Operation (Informative) ......................44
 Appendix B. Example of FDT Instance (Informative) .................45

1. Introduction

 This document defines FLUTE version 2, a protocol for unidirectional
 delivery of files over the Internet.  This specification is not
 backwards compatible with the previous experimental version defined
 in [RFC3926] (see Section 11 for details).  The specification builds
 on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base
 protocol designed for massively scalable multicast distribution.  ALC
 defines transport of arbitrary binary objects.  For file delivery
 applications, mere transport of objects is not enough, however.  The
 end systems need to know what the objects actually represent.  This
 document specifies a technique called FLUTE -- a mechanism for
 signaling and mapping the properties of files to concepts of ALC in a
 way that allows receivers to assign those parameters for received
 objects.  Consequently, throughout this document the term 'file'
 relates to an 'object' as discussed in ALC.  Although this

Paila, et al. Standards Track [Page 3] RFC 6726 FLUTE November 2012

 specification frequently makes use of multicast addressing as an
 example, the techniques are similarly applicable for use with unicast
 addressing.
 This document defines a specific transport application of ALC, adding
 the following specifications:
  1. Definition of a file delivery session built on top of ALC,

including transport details and timing constraints.

  1. In-band signaling of the transport parameters of the ALC session.
  1. In-band signaling of the properties of delivered files.
  1. Details associated with the multiplexing of multiple files within

a session.

 This specification is structured as follows.  Section 3 begins by
 defining the concept of the file delivery session.  Following that,
 it introduces the File Delivery Table, which forms the core part of
 this specification.  Further, it discusses multiplexing issues of
 transmission objects within a file delivery session.  Section 4
 describes the use of congestion control and channels with FLUTE.
 Section 5 defines how the Forward Error Correction (FEC) Object
 Transmission Information is to be delivered within a file delivery
 session.  Section 6 defines the required parameters for describing
 file delivery sessions in a general case.  Section 7 outlines
 security considerations regarding file delivery with FLUTE.  Last,
 there are two informative appendices.  Appendix A describes an
 envisioned receiver operation for the receiver of the file delivery
 session.  Readers who want to see a simple example of FLUTE in
 operation should refer to Appendix A right away.  Appendix B gives an
 example of a File Delivery Table.
 This specification contains part of the definitions necessary to
 fully specify a Reliable Multicast Transport (RMT) protocol in
 accordance with [RFC2357].
 This document obsoletes [RFC3926], which contained a previous version
 of this specification and was published in the "Experimental"
 category.  This Proposed Standard specification is thus based on
 [RFC3926] and has been updated according to accumulated experience
 and growing protocol maturity since the publication of [RFC3926].
 Said experience applies both to this specification itself and to
 congestion control strategies related to the use of this
 specification.

Paila, et al. Standards Track [Page 4] RFC 6726 FLUTE November 2012

 The differences between [RFC3926] and this document are listed in
 Section 11.
 This document updates ALC [RFC5775] and Layered Coding Transport
 (LCT) [RFC5651] in the sense that it defines two new header
 extensions, EXT_FDT and EXT_CENC.

1.1. Applicability Statement

1.1.1. The Target Application Space

 FLUTE is applicable to the delivery of large and small files to many
 hosts, using delivery sessions of several seconds or more.  For
 instance, FLUTE could be used for the delivery of large software
 updates to many hosts simultaneously.  It could also be used for
 continuous, but segmented, data such as time-lined text for
 subtitling -- potentially leveraging its layering inheritance from
 ALC and LCT to scale the richness of the session to the congestion
 status of the network.  It is also suitable for the basic transport
 of metadata, for example, Session Description Protocol (SDP)
 [RFC4566] files that enable user applications to access multimedia
 sessions.

1.1.2. The Target Scale

 Massive scalability is a primary design goal for FLUTE.  IP multicast
 is inherently massively scalable, but the best-effort service that it
 provides does not provide session management functionality,
 congestion control, or reliability.  FLUTE provides all of this by
 using ALC and IP multicast without sacrificing any of the inherent
 scalability of IP multicast.

1.1.3. Intended Environments

 All of the environmental requirements and considerations that apply
 to the RMT building blocks used by FLUTE shall also apply to FLUTE.
 These are the ALC protocol instantiation [RFC5775], the LCT building
 block [RFC5651], and the FEC building block [RFC5052].
 FLUTE can be used with both multicast and unicast delivery, but its
 primary application is for unidirectional multicast file delivery.
 FLUTE requires connectivity between a sender and receivers but does
 not require connectivity from receivers to a sender.  Because of its
 low expectations, FLUTE works with most types of networks, including
 LANs, WANs, Intranets, the Internet, asymmetric networks, wireless
 networks, and satellite networks.

Paila, et al. Standards Track [Page 5] RFC 6726 FLUTE November 2012

 FLUTE is compatible with both IPv4 and IPv6, as no part of the packet
 is IP version specific.  FLUTE works with both multicast models:
 Any-Source Multicast (ASM) [RFC1112] and Source-Specific Multicast
 (SSM) [PAPER.SSM].
 FLUTE is applicable for both shared networks, such as the Internet,
 with a suitable congestion control building block; and provisioned/
 controlled networks, such as wireless broadcast radio systems, with a
 traffic-shaping building block.

1.1.4. Weaknesses

 FLUTE congestion control protocols depend on the ability of a
 receiver to change multicast subscriptions between multicast groups
 supporting different rates and/or layered codings.  If the network
 does not support this, then the FLUTE congestion control protocols
 may not be amenable to such a network.
 FLUTE can also be used for point-to-point (unicast) communications.
 At a minimum, implementations of ALC MUST support the Wave and
 Equation Based Rate Control (WEBRC) [RFC3738] multiple-rate
 congestion control scheme [RFC5775].  However, since WEBRC has been
 designed for massively scalable multicast flows, it is not clear how
 appropriate it is to the particular case of unicast flows.  Using a
 separate point-to-point congestion control scheme is another
 alternative.  How to do that is outside the scope of the present
 document.
 FLUTE provides reliability using the FEC building block.  This will
 reduce the error rate as seen by applications.  However, FLUTE does
 not provide a method for senders to verify the reception success of
 receivers, and the specification of such a method is outside the
 scope of this document.

2. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 The terms "object" and "transmission object" are consistent with the
 definitions in ALC [RFC5775] and LCT [RFC5651].  The terms "file" and
 "source object" are pseudonyms for "object".

Paila, et al. Standards Track [Page 6] RFC 6726 FLUTE November 2012

3. File Delivery

 Asynchronous Layered Coding [RFC5775] is a protocol designed for
 delivery of arbitrary binary objects.  It is especially suitable for
 massively scalable, unidirectional multicast distribution.  ALC
 provides the basic transport for FLUTE, and thus FLUTE inherits the
 requirements of ALC.
 This specification is designed for the delivery of files.  The core
 of this specification is to define how the properties of the files
 are carried in-band together with the delivered files.
 As an example, let us consider a 5200-byte file referred to by
 "http://www.example.com/docs/file.txt".  Using the example, the
 following properties describe the properties that need to be conveyed
 by the file delivery protocol.
  • Identifier of the file, expressed as a URI [RFC3986]. The

identifier MAY provide a location for the file. In the above

    example: "http://www.example.com/docs/file.txt".
  • File name (usually, this can be concluded from the URI). In the

above example: "file.txt".

  • File type, expressed as Internet Media Types (often referred to as

"Media Types"). In the above example: "text/plain".

  • File size, expressed in octets. In the above example: "5200". If

the file is content encoded, then this is the file size before

    content encoding.
  • Content encoding of the file, within transport. In the above

example, the file could be encoded using ZLIB [RFC1950]. In this

    case, the size of the transmission object carrying the file would
    probably differ from the file size.  The transmission object size
    is delivered to receivers as part of the FLUTE protocol.
  • Security properties of the file, such as digital signatures,

message digests, etc. For example, one could use S/MIME [RFC5751]

    as the content encoding type for files with this authentication
    wrapper, and one could use XML Digital Signatures (XML-DSIG)
    [RFC3275] to digitally sign the file.  XML-DSIG can also be used
    to provide tamper prevention, e.g., in the Content-Location field.
    Content encoding is applied to file data before FEC protection.

Paila, et al. Standards Track [Page 7] RFC 6726 FLUTE November 2012

 For each unique file, FLUTE encodes the attributes listed above and
 other attributes as children of an XML file element.  A table of XML
 file elements is transmitted as a special file called a 'File
 Delivery Table' (FDT), which is further described in the next
 subsection and in Section 3.2.

3.1. File Delivery Session

 ALC is a protocol instantiation of the Layered Coding Transport (LCT)
 building block [RFC5651].  Thus, ALC inherits the session concept of
 LCT.  In this document, we will use the concept of the ALC/LCT
 session to collectively denote the interchangeable terms "ALC
 session" and "LCT session".
 An ALC/LCT session consists of a set of logically grouped ALC/LCT
 channels associated with a single sender sending ALC/LCT packets for
 one or more objects.  An ALC/LCT channel is defined by the
 combination of a sender and an address associated with the channel by
 the sender.  A receiver joins a channel to start receiving the data
 packets sent to the channel by the sender, and a receiver leaves a
 channel to stop receiving data packets from the channel.
 One of the fields carried in the ALC/LCT header is the Transport
 Session Identifier (TSI), an integer carried in a field of size 16,
 32, or 48 bits (note that the TSI may be carried by other means, in
 which case it is absent from the LCT header [RFC5651]).  The (source
 IP address, TSI) pair uniquely identifies a session.  Note that the
 TSI is scoped by the IP address, so the same TSI may be used by
 several source IP addresses at once.  Thus, the receiver uses the
 (source IP address, TSI) pair from each packet to uniquely identify
 the session sending each packet.  When a session carries multiple
 objects, the Transmission Object Identifier (TOI) field within the
 ALC/LCT header names the object used to generate each packet.  Note
 that each object is associated with a unique TOI within the scope of
 a session.
 A FLUTE session consistent with this specification MUST use FLUTE
 version 2 as specified in this document.  Thus, all sessions
 consistent with this specification MUST set the FLUTE version to 2.
 The FLUTE version is carried within the EXT_FDT Header Extension
 (defined in Section 3.4.1) in the ALC/LCT layer.  A FLUTE session
 consistent with this specification MUST use ALC version 1 as
 specified in [RFC5775], and LCT version 1 as specified in [RFC5651].
 If multiple FLUTE sessions are sent to a channel, then receivers MUST
 determine the FLUTE protocol version, based on version fields and the
 (source IP address, TSI) pair carried in the ALC/LCT header of the
 packet.  Note that when a receiver first begins receiving packets, it

Paila, et al. Standards Track [Page 8] RFC 6726 FLUTE November 2012

 might not know the FLUTE protocol version, as not every LCT packet
 carries the EXT_FDT header (containing the FLUTE protocol version).
 A new receiver MAY keep an open binding in the LCT protocol layer
 between the TSI and the FLUTE protocol version, until the EXT_FDT
 header arrives.  Alternatively, a new receiver MAY discover a binding
 between TSI and FLUTE protocol version via a session discovery
 protocol that is out of scope of this document.
 If the sender's IP address is not accessible to receivers, then
 packets that can be received by receivers contain an intermediate IP
 address.  In this case, the TSI is scoped by this intermediate IP
 address of the sender for the duration of the session.  As an
 example, the sender may be behind a Network Address Translation (NAT)
 device that temporarily assigns an IP address for the sender.  In
 this case, the TSI is scoped by the intermediate IP address assigned
 by the NAT.  As another example, the sender may send its original
 packets using IPv6, but some portions of the network may not be IPv6
 capable.  Thus, there may be an IPv6-to-IPv4 translator that changes
 the IP address of the packets to a different IPv4 address.  In this
 case, receivers in the IPv4 portion of the network will receive
 packets containing the IPv4 address, and thus the TSI for them is
 scoped by the IPv4 address.  How the IP address of the sender to be
 used to scope the session by receivers is delivered to receivers,
 whether it is the sender's IP address or an intermediate IP address,
 is outside the scope of this document.
 When FLUTE is used for file delivery over ALC, the ALC/LCT session is
 called a file delivery session, and the ALC/LCT concept of 'object'
 denotes either a 'file' or a 'File Delivery Table Instance'
 (Section 3.2).
 Additionally, the following rules apply:
  • The TOI field MUST be included in ALC packets sent within a FLUTE

session, with the exception that ALC packets sent in a FLUTE

    session with the Close Session (A) flag set to 1 (signaling the
    end of the session) and that contain no payload (carrying no
    information for any file or FDT) SHALL NOT carry the TOI.  See
    Section 5.1 of [RFC5651] for the LCT definition of the Close
    Session flag, and see Section 4.2 of [RFC5775] for an example of
    the use of a TOI within an ALC packet.
  • The TOI value '0' is reserved for the delivery of File Delivery

Table Instances. Each non-expired File Delivery Table Instance is

    uniquely identified by an FDT Instance ID within the EXT_FDT
    header defined in Section 3.4.1.

Paila, et al. Standards Track [Page 9] RFC 6726 FLUTE November 2012

  • Each file in a file delivery session MUST be associated with a TOI

(>0) in the scope of that session.

  • Information carried in the headers and the payload of a packet is

scoped by the source IP address and the TSI. Information

    particular to the object carried in the headers and the payload of
    a packet is further scoped by the TOI for file objects, and is
    further scoped by both the TOI and the FDT Instance ID for FDT
    Instance objects.

3.2. File Delivery Table

 The File Delivery Table (FDT) provides a means to describe various
 attributes associated with files that are to be delivered within the
 file delivery session.  The following lists are examples of such
 attributes and are not intended to be mutually exclusive or
 exhaustive.
 Attributes related to the delivery of a file:
  1. TOI value that represents the file
  1. FEC Object Transmission Information (including the FEC Encoding ID

and, if relevant, the FEC Instance ID)

  1. Size of the transmission object carrying the file
  1. Aggregate rate of sending packets to all channels
 Attributes related to the file itself:
  1. Name, Identification, and Location of file (specified by the URI)
  1. Media type of file
  1. Size of file
  1. Encoding of file
  1. Message digest of file
 Some of these attributes MUST be included in the file description
 entry for a file; others are optional, as defined in Section 3.4.2.
 Logically, the FDT is a set of file description entries for files to
 be delivered in the session.  Each file description entry MUST
 include the TOI for the file that it describes and the URI
 identifying the file.  The TOI carried in each file description entry

Paila, et al. Standards Track [Page 10] RFC 6726 FLUTE November 2012

 is how FLUTE names the ALC/LCT data packets used for delivery of the
 file.  Each file description entry may also contain one or more
 descriptors that map the above-mentioned attributes to the file.
 Each file delivery session MUST have an FDT that is local to the
 given session.  The FDT MUST provide a file description entry mapped
 to a TOI for each file appearing within the session.  An object that
 is delivered within the ALC session, but not described in the FDT,
 other than the FDT itself, is not considered a 'file' belonging to
 the file delivery session.  This object received with an unmapped TOI
 (non-zero TOI that is not resolved by the FDT) SHOULD in general be
 ignored by a FLUTE receiver.  The details of how to do that are out
 of scope of this specification.
 Note that a client that joins an active file delivery session MAY
 receive data packets for a TOI > 0 before receiving any FDT Instance
 (see Section 3.3 for recommendations on how to limit the probability
 that this situation will occur).  Even if the TOI is not mapped to
 any file description entry, this is hopefully a transient situation.
 When this happens, system performance might be improved by caching
 such packets within a reasonable time window and storage size.  Such
 optimizations are use-case and implementation specific, and further
 details are beyond the scope of this document.
 Within the file delivery session, the FDT is delivered as FDT
 Instances.  An FDT Instance contains one or more file description
 entries of the FDT.  Any FDT Instance can be equal to, be a subset
 of, be a superset of, overlap with, or complement any other FDT
 Instance.  A certain FDT Instance may be repeated multiple times
 during a session, even after subsequent FDT Instances (with higher
 FDT Instance ID numbers) have been transmitted.  Each FDT Instance
 contains at least a single file description entry and at most the
 exhaustive set of file description entries of the files being
 delivered in the file delivery session.
 A receiver of the file delivery session keeps an FDT database for
 received file description entries.  The receiver maintains the
 database, for example, upon reception of FDT Instances.  Thus, at any
 given time the contents of the FDT database represent the receiver's
 current view of the FDT of the file delivery session.  Since each
 receiver behaves independently of other receivers, it SHOULD NOT be
 assumed that the contents of the FDT database are the same for all
 the receivers of a given file delivery session.
 Since the FDT database is an abstract concept, the structure and the
 maintenance of the FDT database are left to individual
 implementations and are thus out of scope of this specification.

Paila, et al. Standards Track [Page 11] RFC 6726 FLUTE November 2012

3.3. Dynamics of FDT Instances within a File Delivery Session

 The following rules define the dynamics of the FDT Instances within a
 file delivery session:
  • 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.  A file description entry
    contains at a minimum the mapping between the TOI and the URI.
  • An FDT Instance MAY appear in any part of the file delivery

session, and packets for an FDT Instance MAY be interleaved with

    packets for other files or other FDT Instances within a session.
  • The TOI value of '0' MUST be reserved for delivery of FDT

Instances. The use of other TOI values (i.e., an integer > 0) for

    FDT Instances is outside the scope of this specification.
  • The FDT Instance is identified by the use of a new fixed-length

LCT Header Extension, EXT_FDT (defined later in this section).

    Each non-expired FDT Instance is uniquely identified within the
    file delivery session by its FDT Instance ID, carried by the
    EXT_FDT Header Extension.  Any ALC/LCT packet carrying an FDT
    Instance MUST include EXT_FDT.
  • It is RECOMMENDED that an FDT Instance that contains the file

description entry for a file be sent at least once before sending

    the described file within a file delivery session.  This
    recommendation is intended to minimize the amount of file data
    that may be received by receivers in advance of the FDT Instance
    containing the entry for a file (such data must either be
    speculatively buffered or discarded).  Note that this possibility
    cannot be completely eliminated, since the first transmission of
    FDT data might be lost.
  • Within a file delivery session, any TOI > 0 MAY be described more

than once. For example, a previous FDT Instance 0 describes a TOI

    of value '3'.  Now, subsequent FDT Instances can either keep TOI
    '3' unmodified in the table, not include it, or augment the
    description.  However, subsequent FDT Instances MUST NOT change
    the parameters already described for a specific TOI.
  • An FDT Instance is valid until its expiration time. The

expiration time is expressed within the FDT Instance payload as a

    UTF-8 decimal representation of a 32-bit unsigned integer.  The
    value of this integer represents the 32 most significant bits of a
    64-bit Network Time Protocol (NTP) [RFC5905] time value.  These
    32 bits provide an unsigned integer representing the time in

Paila, et al. Standards Track [Page 12] RFC 6726 FLUTE November 2012

    seconds relative to 0 hours 1 January 1900 in the case of the
    prime epoch (era 0) [RFC5905].  The handling of time wraparound
    (to happen in 2036) requires that the associated epoch be
    considered.  In any case, both a sender and a receiver easily
    determine to which (136-year) epoch the FDT Instance expiration
    time value pertains by choosing the epoch for which the expiration
    time is closest in time to the current time.
    Here is an example.  Let us imagine that a new FLUTE session is
    started on February 7th, 2036, 0h, i.e., at NTP time
    4,294,944,000, a few hours before the end of epoch 0.  In order to
    define an FDT Instance valid for the next 48 hours, The FLUTE
    sender sets an expiry time of 149,504.  This FDT Instance will
    expire exactly on February 9th, 2036, 0h.  A client that receives
    this FDT Instance on the 7th, 0h, just after it has been sent,
    immediately understands that this value corresponds to epoch 1.  A
    client that joins the session on February 8th, 0h, i.e., at NTP
    time 63,104, epoch 1, immediately understands that the 149,504 NTP
    timestamp corresponds to epoch 1.
  • The space of FDT Instance IDs is limited by the associated field

size (i.e., 20 bits) in the EXT_FDT Header Extension

    (Section 3.4.1).  Therefore, senders should take care to always
    have a large enough supply of available FDT Instance IDs when
    specifying FDT expiration times.
  • The receiver MUST NOT use a received FDT Instance to interpret

packets received beyond the expiration time of the FDT Instance.

  • A sender MUST use an expiration time in the future upon creation

of an FDT Instance relative to its Sender Current Time (SCT).

  • Any FEC Encoding ID MAY be used for the sending of FDT Instances.

The default is to use the Compact No-Code FEC Encoding ID 0

    [RFC5445] for the sending of FDT Instances.  (Note that since FEC
    Encoding ID 0 is the default for FLUTE, this implies that Source
    Block Number and Encoding Symbol ID lengths both default to
    16 bits each.)
  • If the receiver does not support the FEC Scheme indicated by the

FEC Encoding ID, the receiver MUST NOT decode the associated FDT.

  • It is RECOMMENDED that the mechanisms used for file attribute

delivery SHOULD achieve a delivery probability that is higher than

    the file recovery probability and the file attributes SHOULD be
    delivered at this higher priority before the delivery of the
    associated files begins.

Paila, et al. Standards Track [Page 13] RFC 6726 FLUTE November 2012

 Generally, a receiver needs to receive an FDT Instance describing a
 file before it is able to recover the file itself.  In this sense,
 FDT Instances are of higher priority than files.  Additionally, a
 FLUTE sender SHOULD assume that receivers will not receive all
 packets pertaining to FDT Instances.  The way FDT Instances are
 transmitted has a large impact on satisfying the recommendation
 above.  When there is a single file transmitted in the session, one
 way to satisfy the recommendation above is to repeatedly transmit on
 a regular enough basis FDT Instances describing the file while the
 file is being transmitted.  If an FDT Instance is longer than one
 packet payload in length, it is RECOMMENDED that an FEC code that
 provides protection against loss be used for delivering this FDT
 Instance.  When there are multiple files in a session concurrently
 being transmitted to receivers, the way the FDT Instances are
 structured and transmitted also has a large impact.  As an example, a
 way to satisfy the recommendation above is to transmit an FDT
 Instance that describes all files currently being transmitted, and to
 transmit this FDT Instance reliably, using the same techniques as
 explained for the case when there is a single file transmitted in a
 session.  If instead the concurrently transmitted files are described
 in separate FDT Instances, another way to satisfy this recommendation
 is to transmit all the relevant FDT Instances reliably, using the
 same techniques as explained for the case when there is a single file
 transmitted in a session.
 In any case, how often the description of a file is sent in an FDT
 Instance, how often an FDT Instance is sent, and how much FEC
 protection is provided for an FDT Instance (if longer than one packet
 payload) are dependent on the particular application and are outside
 the scope of this document.
 Sometimes the various attributes associated with files that are to be
 delivered within the file delivery session are sent out-of-band.  The
 details of how this is done are out of the scope of this document.
 However, it is still RECOMMENDED that any out-of-band transmission be
 managed in such a way that a receiver will be able to recover the
 attributes associated with a file at least as reliably as the
 receiver is able to receive enough packets containing encoding
 symbols to recover the file.  For example, the probability of a
 randomly chosen receiver being able to recover a given file can often
 be estimated based on a statistical model of reception conditions,
 the amount of data transmitted, and the properties of any Forward
 Error Correction in use.  The recommendation above suggests that
 mechanisms used for file attribute delivery should achieve a higher
 delivery probability than the file recovery probability.  The sender
 MAY also continue sending the various file attributes in-band, in
 addition to the out-of-band transmission.

Paila, et al. Standards Track [Page 14] RFC 6726 FLUTE November 2012

3.4. Structure of FDT Instance Packets

 FDT Instances are carried in ALC packets with TOI = 0 and with an
 additional REQUIRED LCT Header extension called the FDT Instance
 Header.  The FDT Instance Header (EXT_FDT) contains the FDT Instance
 ID that uniquely identifies FDT Instances within a file delivery
 session.  Placement of the FDT Instance Header is the same as that of
 any other LCT Header Extension.  There MAY be other LCT Header
 Extensions in use.
 The FDT Instance is encoded for transmission, like any other object,
 using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme).
 The LCT Header Extensions are followed by the FEC Payload ID, and
 finally the Encoding Symbols for the FDT Instance, which contains one
 or more file description entries.  An FDT Instance MAY span several
 ALC packets -- the number of ALC packets is a function of the file
 attributes associated with the FDT Instance.  The FDT Instance Header
 is carried in each ALC packet carrying the FDT Instance.  The FDT
 Instance Header is identical for all ALC/LCT packets for a particular
 FDT Instance.
 The overall format of ALC/LCT packets carrying an FDT Instance is
 depicted in Figure 1 below.  All integer fields are carried in
 "big-endian" or "network order" format (i.e., most significant byte
 (octet) first).  As defined in [RFC5775], all ALC/LCT packets are
 sent using UDP.
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         UDP header                            |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Default LCT header (with TOI = 0)              |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          LCT Header Extensions (EXT_FDT, EXT_FTI, etc.)       |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       FEC Payload ID                          |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                FLUTE Payload: Encoding Symbol(s)
 ~             (for FDT Instance in an FDT packet)               ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 1: Overall FDT Packet

Paila, et al. Standards Track [Page 15] RFC 6726 FLUTE November 2012

3.4.1. Format of FDT Instance Header

 The FDT Instance Header (EXT_FDT) is a new fixed-length, ALC
 Protocol-Instantiation-specific LCT Header Extension [RFC5651].  The
 Header Extension Type (HET) for the extension is 192.  Its format is
 defined below:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET = 192   |   V   |          FDT Instance ID              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 2: EXT_FDT Format
 Version of FLUTE (V), 4 bits:
 This document specifies FLUTE version 2.  Hence, in any ALC packet
 that carries an FDT Instance and that belongs to the file delivery
 session as specified in this specification MUST set this field
 to '2'.
 FDT Instance ID, 20 bits:
 For each file delivery session, the numbering of FDT Instances starts
 from '0' and is incremented by one for each subsequent FDT Instance.
 After reaching the maximum value (2^20-1), the numbering starts from
 the smallest FDT Instance ID value assigned to an expired FDT
 Instance.  When wraparound from a greater FDT Instance ID value to a
 smaller FDT Instance ID value occurs, the smaller FDT Instance ID
 value is considered logically higher than the greater FDT Instance ID
 value.  Then, the subsequent FDT Instances are assigned the next
 available smallest FDT Instance ID value, in order to always keep the
 FDT Instance ID values logically increasing.
 Senders MUST NOT reuse an FDT Instance ID value that is already in
 use for a non-expired FDT Instance.  Sender behavior when all the FDT
 Instance IDs are used by non-expired FEC Instances is outside the
 scope of this specification and left to individual implementations of
 FLUTE.  Receipt of an FDT Instance that reuses an FDT Instance ID
 value that is currently used by a non-expired FDT Instance MUST be
 considered an error case.  Receiver behavior in this case (e.g.,
 leave the session or ignore the new FDT Instance) is outside the
 scope of this specification and left to individual implementations of
 FLUTE.  Receivers MUST be ready to handle FDT Instance ID wraparound
 and situations where missing FDT Instance IDs result in increments
 larger than one.

Paila, et al. Standards Track [Page 16] RFC 6726 FLUTE November 2012

3.4.2. Syntax of FDT Instance

 The FDT Instance contains file description entries that provide the
 mapping functionality described in Section 3.2 above.
 The FDT Instance is an Extensible Markup Language (XML) structure
 that has a single root element "FDT-Instance".  The "FDT-Instance"
 element MUST contain the "Expires" attribute, which provides the
 expiration time of the FDT Instance.  In addition, the "FDT-Instance"
 element MAY contain the "Complete" attribute, a boolean that can be
 either set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE.
 When TRUE, the "Complete" attribute signals that this "FDT Instance"
 includes the set of "File" entries that exhausts both the set of
 files delivered so far and the set of files to be delivered in the
 session.  This implies that no new data will be provided in future
 FDT Instances within this session (i.e., that either FDT Instances
 with higher ID numbers will not be used or, if they are used, will
 only provide file parameters identical to those already given in this
 and previous FDT Instances).  The "Complete" attribute is therefore
 used to provide a complete list of files in an entire FLUTE session
 (a "complete FDT").  Note that when all the FDT Instances received so
 far have no "Complete" attribute, the receiver MUST consider that the
 session is not complete and that new data MAY be provided in future
 FDT Instances.  This is equivalent to receiving FDT Instances having
 the "Complete" attribute set to FALSE.
 The "FDT-Instance" element MAY contain attributes that give common
 parameters for all files of an FDT Instance.  These attributes MAY
 also be provided for individual files in the "File" element.  Where
 the same attribute appears in both the "FDT-Instance" and the "File"
 elements, the value of the attribute provided in the "File" element
 takes precedence.
 For each file to be declared in the given FDT Instance, there is a
 single file description entry in the FDT Instance.  Each entry is
 represented by element "File", which is a child element of the FDT
 Instance structure.
 The attributes of the "File" element in the XML structure represent
 the attributes given to the file that is delivered in the file
 delivery session.  The value of the XML attribute name corresponds to
 the MIME field name, and the XML attribute value corresponds to the
 value of the MIME field body [RFC2045].  Each "File" element MUST
 contain at least two attributes: "TOI" and "Content-Location".  "TOI"
 MUST be assigned a valid TOI value as described in Section 3.3.
 "Content-Location" [RFC2616] MUST be assigned a syntactically valid
 URI, as defined in [RFC3986], which identifies the file to be
 delivered.  For example, it can be a URI with the "http" or "file"

Paila, et al. Standards Track [Page 17] RFC 6726 FLUTE November 2012

 URI scheme.  Only one "Content-Location" attribute is allowed for
 each file.  The "Content-Location" field MUST be considered a string
 that identifies a file (i.e., two different strings are two different
 identifiers).  Any use of the "Content-Location" field for anything
 else other than to identify the object is out of scope of this
 specification.  The semantics for any two "File" elements declaring
 the same "Content-Location" but differing "TOI" is that the element
 appearing in the FDT Instance with the greater FDT Instance ID is
 considered to declare a newer instance (e.g., version) of the same
 "File".
 In addition to mandatory attributes, the "FDT-Instance" element and
 the "File" element MAY contain other attributes, of which the
 following are specifically pointed out:
  • The attribute "Content-Type" SHOULD be included and, when present,

MUST be used for the purpose defined in [RFC2616].

  • Where the length is described, the attribute "Content-Length" MUST

be used for the purpose defined in [RFC2616]. The transfer length

    is defined to be the length of the object transported in octets.
    It is often important to convey the transfer length to receivers,
    because the source block structure needs to be known for the FEC
    decoder to be applied to recover source blocks of the file, and
    the transfer length is often needed to properly determine the
    source block structure of the file.  There generally will be a
    difference between the length of the original file and the
    transfer length if content encoding is applied to the file before
    transport, and thus the "Content-Encoding" attribute is used.  If
    the file is not content encoded before transport (and thus the
    "Content-Encoding" attribute is not used), then the transfer
    length is the length of the original file, and in this case the
    "Content-Length" is also the transfer length.  However, if the
    file is content encoded before transport (and thus the
    "Content-Encoding" attribute is used), e.g., if compression is
    applied before transport to reduce the number of octets that need
    to be transferred, then the transfer length is generally different
    than the length of the original file, and in this case the
    attribute "Transfer-Length" MAY be used to carry the transfer
    length.
  • Whenever content encoding is applied, the attribute

"Content-Encoding" MUST be included. Whenever the attribute

    "Content-Encoding" is included, it MUST be used as described in
    [RFC2616].

Paila, et al. Standards Track [Page 18] RFC 6726 FLUTE November 2012

  • Where the MD5 message digest is described, the attribute

"Content-MD5" MUST be used for the purpose defined in [RFC2616].

    Note that the goal is to provide a decoded object integrity
    service in cases where transmission and/or FLUTE/ALC processing
    errors may occur (the probability of collision is in that case
    negligible).  It MUST NOT be regarded as a security mechanism (see
    Section 7 for information regarding security measures).
  • The FEC Object Transmission Information attributes are described

in Section 5.

 The following specifies the XML Schema [XML-Schema-Part-1]
 [XML-Schema-Part-2] for the FDT Instance:
 BEGIN
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns="urn:ietf:params:xml:ns:fdt"
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            targetNamespace="urn:ietf:params:xml:ns:fdt"
            elementFormDefault="qualified">
   <xs:element name="FDT-Instance" type="FDT-InstanceType"/>
   <xs:complexType name="FDT-InstanceType">
     <xs:sequence>
       <xs:element name="File" type="FileType" maxOccurs="unbounded"/>
       <xs:any namespace="##other" processContents="skip"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="Expires"
                   type="xs:string"
                   use="required"/>
     <xs:attribute name="Complete"
                   type="xs:boolean"
                   use="optional"/>
     <xs:attribute name="Content-Type"
                   type="xs:string"
                   use="optional"/>
     <xs:attribute name="Content-Encoding"
                   type="xs:string"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-FEC-Encoding-ID"
                   type="xs:unsignedByte"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-FEC-Instance-ID"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
                   type="xs:unsignedLong"
                   use="optional"/>

Paila, et al. Standards Track [Page 19] RFC 6726 FLUTE November 2012

     <xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Scheme-Specific-Info"
                   type="xs:base64Binary"
                   use="optional"/>
     <xs:anyAttribute processContents="skip"/>
   </xs:complexType>
   <xs:complexType name="FileType">
     <xs:sequence>
       <xs:any namespace="##other" processContents="skip"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="Content-Location"
                   type="xs:anyURI"
                   use="required"/>
     <xs:attribute name="TOI"
                   type="xs:positiveInteger"
                   use="required"/>
     <xs:attribute name="Content-Length"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="Transfer-Length"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="Content-Type"
                   type="xs:string"
                   use="optional"/>
     <xs:attribute name="Content-Encoding"
                   type="xs:string"
                   use="optional"/>
     <xs:attribute name="Content-MD5"
                   type="xs:base64Binary"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-FEC-Encoding-ID"
                   type="xs:unsignedByte"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-FEC-Instance-ID"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
                   type="xs:unsignedLong"
                   use="optional"/>

Paila, et al. Standards Track [Page 20] RFC 6726 FLUTE November 2012

     <xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
                   type="xs:unsignedLong"
                   use="optional"/>
     <xs:attribute name="FEC-OTI-Scheme-Specific-Info"
                   type="xs:base64Binary"
                   use="optional"/>
     <xs:anyAttribute processContents="skip"/>
   </xs:complexType>
 </xs:schema>
 END
               Figure 3: XML Schema for the FDT Instance
 Any valid FDT Instance MUST use the above XML Schema.  This way, FDT
 provides extensibility to support private elements and private
 attributes within the file description entries.  Those could be, for
 example, the attributes related to the delivery of the file (timing,
 packet transmission rate, etc.).  Unsupported private elements and
 attributes SHOULD be silently ignored by a FLUTE receiver.
 In case the basic FDT XML Schema is extended in terms of new
 descriptors (attributes or elements), for descriptors applying to a
 single file, those MUST be placed within the element "File".  For
 descriptors applying to all files described by the current FDT
 Instance, those MUST be placed within the element "FDT-Instance".  It
 is RECOMMENDED that the new attributes applied in the FDT be in the
 format of message header fields and be either defined in the HTTP/1.1
 specification [RFC2616] or another well-known specification, or in an
 IANA registry [IANAheaderfields].  However, this specification
 doesn't prohibit the use of other formats to allow private attributes
 to be used when interoperability is not a concern.

3.4.3. Content Encoding of FDT Instance

 The FDT Instance itself MAY be content encoded (e.g., compressed).
 This specification defines the FDT Instance Content Encoding Header
 (EXT_CENC).  EXT_CENC is a new fixed-length LCT Header Extension
 [RFC5651].  The Header Extension Type (HET) for the extension is 193.
 If the FDT Instance is content encoded, EXT_CENC MUST be used to
 signal the content encoding type.  In that case, the EXT_CENC Header
 Extension MUST be used in all ALC packets carrying the same FDT
 Instance ID.  Consequently, when the EXT_CENC header is used, it MUST
 be used together with a proper FDT Instance Header (EXT_FDT).  Within
 a file delivery session, FDT Instances that are not content encoded
 and FDT Instances that are content encoded MAY both appear.  If

Paila, et al. Standards Track [Page 21] RFC 6726 FLUTE November 2012

 content encoding is not used for a given FDT Instance, EXT_CENC MUST
 NOT be used in any packet carrying the FDT Instance.  The format of
 EXT_CENC is defined below:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET = 193   |     CENC      |          Reserved             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 4: EXT_CENC Format
 Content Encoding Algorithm (CENC), 8 bits:
 This field signals the content encoding algorithm used in the FDT
 Instance payload.  This subsection reserves the Content Encoding
 Algorithm values 0, 1, 2, and 3 for null, ZLIB [RFC1950], DEFLATE
 [RFC1951], and GZIP [RFC1952], respectively.
 Reserved, 16 bits:
 This field MUST be set to all '0's.  This field MUST be ignored on
 reception.

3.5. Multiplexing of Files within a File Delivery Session

 The delivered files are carried as transmission objects (identified
 with TOIs) in the file delivery session.  All these objects,
 including the FDT Instances, MAY be multiplexed in any order and in
 parallel with each other within a session; i.e., packets for one file
 may be interleaved with packets for other files or other FDT
 Instances within a session.
 Multiple FDT Instances MAY be delivered in a single session using
 TOI = 0.  In this case, it is RECOMMENDED that the sending of a
 previous FDT Instance SHOULD end before the sending of the next FDT
 Instance starts.  However, due to unexpected network conditions,
 packets for the FDT Instances might be interleaved.  A receiver can
 determine which FDT Instance a packet contains information about,
 since the FDT Instances are uniquely identified by their FDT Instance
 ID carried in the EXT_FDT headers.

Paila, et al. Standards Track [Page 22] RFC 6726 FLUTE November 2012

4. Channels, Congestion Control, and Timing

 ALC/LCT has a concept of channels and congestion control.  There are
 four scenarios in which FLUTE is envisioned to be applied.
 (a)  Use of a single channel and a single-rate congestion control
      protocol.
 (b)  Use of multiple channels and a multiple-rate congestion control
      protocol.  In this case, the FDT Instances MAY be delivered on
      more than one channel.
 (c)  Use of a single channel without congestion control supplied by
      ALC, but only when in a controlled network environment where
      flow/congestion control is being provided by other means.
 (d)  Use of multiple channels without congestion control supplied by
      ALC, but only when in a controlled network environment where
      flow/congestion control is being provided by other means.  In
      this case, the FDT Instances MAY be delivered on more than one
      channel.
 When using just one channel for a file delivery session, as in (a)
 and (c), the notion of 'prior' and 'after' are intuitively defined
 for the delivery of objects with respect to their delivery times.
 However, if multiple channels are used, as in (b) and (d), it is not
 straightforward to state that an object was delivered 'prior' to the
 other.  An object may begin to be delivered on one or more of those
 channels before the delivery of a second object begins.  However, the
 use of multiple channels/layers may mean that the delivery of the
 second object is completed before the first.  This is not a problem
 when objects are delivered sequentially using a single channel.
 Thus, if the application of FLUTE has a mandatory or critical
 requirement that the first transmission object must complete 'prior'
 to the second one, it is RECOMMENDED that only a single channel be
 used for the file delivery session.

Paila, et al. Standards Track [Page 23] RFC 6726 FLUTE November 2012

 Furthermore, if multiple channels are used, then a receiver joined to
 the session at a low reception rate will only be joined to the lower
 layers of the session.  Thus, since the reception of FDT Instances is
 of higher priority than the reception of files (because the reception
 of files depends on the reception of an FDT Instance describing it),
 the following are RECOMMENDED:
 1.  The layers to which packets for FDT Instances are sent SHOULD NOT
     be biased towards those layers to which lower-rate receivers are
     not joined.  For example, it is okay to put all the packets for
     an FDT Instance into the lowest layer (if this layer carries
     enough packets to deliver the FDT to higher-rate receivers in a
     reasonable amount of time), but it is not okay to put all the
     packets for an FDT Instance into the higher layers that only
     higher-rate receivers will receive.
 2.  If FDT Instances are generally longer than one Encoding Symbol in
     length and some packets for FDT Instances are sent to layers that
     lower-rate receivers do not receive, an FEC encoding other than
     Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to
     deliver FDT Instances.  This is because in this case, even when
     there is no packet loss in the network, a lower-rate receiver
     will not receive all packets sent for an FDT Instance.

5. Delivering FEC Object Transmission Information

 FLUTE inherits the use of the FEC building block [RFC5052] from ALC.
 When using FLUTE for file delivery over ALC, the FEC Object
 Transmission Information MUST be delivered in-band within the file
 delivery session.  There are two methods to achieve this: the use of
 the ALC-specific LCT Header Extension EXT_FTI [RFC5775] and the use
 of the FDT.  The latter method is specified in this section.  The use
 of EXT_FTI requires repetition of the FEC Object Transmission
 Information to ensure reception (though not necessarily in every
 packet) and thus may entail higher overhead than the use of the FDT,
 but may also provide more timely delivery of the FEC Object
 Transmission Information.
 The receiver of a file delivery session MUST support delivery of FEC
 Object Transmission Information using EXT_FTI for the FDT Instances
 carried using TOI value 0.  For the TOI values other than 0, the
 receiver MUST support both methods: the use of EXT_FTI and the use of
 the FDT.

Paila, et al. Standards Track [Page 24] RFC 6726 FLUTE November 2012

 The FEC Object Transmission Information that needs to be delivered to
 receivers MUST be exactly the same whether it is delivered using
 EXT_FTI or using the FDT (or both).  The FEC Object Transmission
 Information that MUST be delivered to receivers is defined by the FEC
 Scheme.  This section describes the delivery using the FDT.
 The FEC Object Transmission Information regarding a given TOI may be
 available from several sources.  In this case, it is RECOMMENDED that
 the receiver of the file delivery session prioritize the sources in
 the following way (in order of decreasing priority).
 1.  FEC Object Transmission Information that is available in EXT_FTI.
 2.  FEC Object Transmission Information that is available in the FDT.
 The FDT delivers FEC Object Transmission Information for each file
 using an appropriate attribute within the "FDT-Instance" or the
 "File" element of the FDT structure.
  • "Transfer-Length" carries the "Transfer-Length" Object

Transmission Information element defined in [RFC5052].

  • "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object

Transmission Information element defined in [RFC5052], as carried

    in the Codepoint field of the ALC/LCT header.
  • "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object

Transmission Information element defined in [RFC5052] for

    Under-Specified FEC Schemes.
  • "FEC-OTI-Maximum-Source-Block-Length" carries the

"Maximum-Source-Block-Length" Object Transmission Information

    element defined in [RFC5052], if required by the FEC Scheme.
  • "FEC-OTI-Encoding-Symbol-Length" carries the

"Encoding-Symbol-Length" Object Transmission Information element

    defined in [RFC5052], if required by the FEC Scheme.
  • "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the

"Max-Number-of-Encoding-Symbols" Object Transmission Information

    element defined in [RFC5052], if required by the FEC Scheme.
  • "FEC-OTI-Scheme-Specific-Info" carries the "encoded

Scheme-specific FEC Object Transmission Information" as defined in

    [RFC5052], if required by the FEC Scheme.

Paila, et al. Standards Track [Page 25] RFC 6726 FLUTE November 2012

 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
 carried in the Codepoint field of the ALC/LCT header.  When the FEC
 Object Transmission Information for this TOI is delivered through the
 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
 Codepoint field of all packets for this TOI MUST be the same.

6. Describing File Delivery Sessions

 To start receiving a file delivery session, the receiver needs to
 know transport parameters associated with the session.  Interpreting
 these parameters and starting the reception therefore represent the
 entry point from which thereafter the receiver operation falls into
 the scope of this specification.  According to [RFC5775], the
 transport parameters of an ALC/LCT session that the receiver needs to
 know are:
  • The source IP address;
  • The number of channels in the session;
  • The destination IP address and port number for each channel in the

session;

  • The Transport Session Identifier (TSI) of the session;
  • An indication that the session is a FLUTE session. The need to

demultiplex objects upon reception is implicit in any use of

    FLUTE, and this fulfills the ALC requirement of an indication of
    whether or not a session carries packets for more than one object
    (all FLUTE sessions carry packets for more than one object).
 Optionally, the following parameters MAY be associated with the
 session (note that the list is not exhaustive):
  • The start time and end time of the session;
  • FEC Encoding ID and FEC Instance ID when the default FEC Encoding

ID 0 is not used for the delivery of the FDT;

  • Content encoding format if optional content encoding of the FDT

Instance is used, e.g., compression;

  • Some information that tells receiver, in the first place, that the

session contains files that are of interest;

  • Definition and configuration of a congestion control mechanism for

the session;

Paila, et al. Standards Track [Page 26] RFC 6726 FLUTE November 2012

  • Security parameters relevant for the session;
  • FLUTE version number.
 It is envisioned that these parameters would be described according
 to some session description syntax (such as SDP [RFC4566] or XML
 based) and held in a file that would be acquired by the receiver
 before the FLUTE session begins by means of some transport protocol
 (such as the Session Announcement Protocol (SAP) [RFC2974], email,
 HTTP [RFC2616], SIP [RFC3261], manual preconfiguration, etc.).
 However, the way in which the receiver discovers the above-mentioned
 parameters is out of scope of this document, as it is for LCT and
 ALC.  In particular, this specification does not mandate or exclude
 any mechanism.

7. Security Considerations

7.1. Problem Statement

 A content delivery system is potentially subject to attacks.  Attacks
 may target:
  • the network (to compromise the routing infrastructure, e.g., by

creating congestion),

  • the Content Delivery Protocol (CDP) (e.g., to compromise the

normal behavior of FLUTE), or

  • the content itself (e.g., to corrupt the files being transmitted).
 These attacks can be launched either:
  • against the data flow itself (e.g., by sending forged packets),
  • against the session control parameters (e.g., by corrupting the

session description, the FDT Instances, or the ALC/LCT control

    parameters) that are sent either in-band or out-of-band, or
  • against some associated building blocks (e.g., the congestion

control component).

 In the following sections, we provide more details on these possible
 attacks and sketch some possible countermeasures.  We provide
 recommendations in Section 7.5.

Paila, et al. Standards Track [Page 27] RFC 6726 FLUTE November 2012

7.2. Attacks against the Data Flow

 Let us consider attacks against the data flow first.  At the least,
 the following types of attacks exist:
  • attacks that are meant to give access to a confidential file

(e.g., in the case of non-free content) and

  • attacks that try to corrupt the file being transmitted (e.g., to

inject malicious code within a file, or to prevent a receiver from

    using a file, which is a kind of denial of service (DoS)).

7.2.1. Access to Confidential Files

 Access control to the file being transmitted is typically provided by
 means of encryption.  This encryption can be done over the whole
 file, i.e., before applying FEC protection (e.g., by the content
 provider, before submitting the file to FLUTE), or can be done on a
 packet-by-packet basis (e.g., when IPsec/ESP [RFC4303] is used; see
 Section 7.5).  If confidentiality is a concern, it is RECOMMENDED
 that one of these solutions be used.

7.2.2. File Corruption

 Protection against corruptions (e.g., if an attacker sends forged
 packets) is achieved by means of a content integrity verification/
 sender authentication scheme.  This service can be provided at the
 file level, i.e., before applying content encoding and FEC encoding.
 In that case, a receiver has no way to identify which symbol(s)
 is(are) corrupted if the file is detected as corrupted.  This service
 can also be provided at the packet level, i.e., after applying
 content encoding and FEC encoding, on a packet-by-packet basis.  In
 this case, after removing all corrupted packets, the file may be in
 some cases recovered from the remaining correct packets.
 Integrity protection applied at the file level has the advantage of
 lower overhead, since only relatively few bits are added to provide
 the integrity protection compared to the file size.  However, it has
 the disadvantage that it cannot distinguish between correct packets
 and corrupt packets, and therefore correct packets, which may form
 the majority of packets received, may be unusable.  Integrity
 protection applied at the packet level has the advantage that it can
 distinguish between correct and corrupt packets, at the cost of
 additional per-packet overhead.

Paila, et al. Standards Track [Page 28] RFC 6726 FLUTE November 2012

 Several techniques can provide this source authentication/content
 integrity service:
  • At the file level, the file MAY be digitally signed (e.g., by

using RSA Probabilistic Signature Scheme Public-Key Cryptography

    Standards version 1.5 (RSASSA-PKCS1-v1_5) [RFC3447]).  This
    signature enables a receiver to check the file's integrity once
    the file has been fully decoded.  Even if digital signatures are
    computationally expensive, this calculation occurs only once per
    file, which is usually acceptable.
  • At the packet level, each packet can be digitally signed

[RFC6584]. A major limitation is the high computational and

    transmission overheads that this solution requires.  To avoid this
    problem, the signature may span a set of symbols (instead of a
    single one) in order to amortize the signature calculation, but if
    a single symbol is missing, the integrity of the whole set cannot
    be checked.
  • At the packet level, a Group-Keyed Message Authentication Code

(MAC) [RFC2104] [RFC6584] scheme can be used; an example is using

    HMAC-SHA-256 with a secret key shared by all the group members,
    senders, and receivers.  This technique creates a
    cryptographically secured digest of a packet that is sent along
    with the packet.  The Group-Keyed MAC scheme does not create
    prohibitive processing load or transmission overhead, but it has a
    major limitation: it only provides a group authentication/
    integrity service, since all group members share the same secret
    group key, which means that each member can send a forged packet.
    It is therefore restricted to situations where group members are
    fully trusted (or in association with another technique as a
    pre-check).
  • At the packet level, Timed Efficient Stream Loss-Tolerant

Authentication (TESLA) [RFC4082] [RFC5776] is an attractive

    solution that is robust to losses, provides a true authentication/
    integrity service, and does not create any prohibitive processing
    load or transmission overhead.  However, checking a packet
    requires a small delay (a second or more) after its reception.
  • At the packet level, IPsec/ESP [RFC4303] can be used to check the

integrity and authenticate the sender of all the packets being

    exchanged in a session (see Section 7.5).
 Techniques relying on public key cryptography (digital signatures and
 TESLA during the bootstrap process, when used) require that public
 keys be securely associated to the entities.  This can be achieved by

Paila, et al. Standards Track [Page 29] RFC 6726 FLUTE November 2012

 a Public Key Infrastructure (PKI), or by a Pretty Good Privacy (PGP)
 Web of Trust, or by pre-distributing the public keys of each group
 member.
 Techniques relying on symmetric key cryptography (Group-Keyed MAC)
 require that a secret key be shared by all group members.  This can
 be achieved by means of a group key management protocol, or simply by
 pre-distributing the secret key (but this manual solution has many
 limitations).
 It is up to the developer and deployer, who know the security
 requirements and features of the target application area, to define
 which solution is the most appropriate.  Nonetheless, in case there
 is any concern of the threat of file corruption, it is RECOMMENDED
 that at least one of these techniques be used.

7.3. Attacks against the Session Control Parameters and Associated

    Building Blocks
 Let us now consider attacks against the session control parameters
 and the associated building blocks.  The attacker has at least the
 following opportunities to launch an attack:
  • the attack can target the session description,
  • the attack can target the FDT Instances,
  • the attack can target the ALC/LCT parameters, carried within the

LCT header, or

  • the attack can target the FLUTE associated building blocks (e.g.,

the multiple-rate congestion control protocol).

 The consequences of these attacks are potentially serious, since they
 might compromise the behavior of the content delivery system itself.

7.3.1. Attacks against the Session Description

 A FLUTE receiver may potentially obtain an incorrect session
 description for the session.  The consequence of this is that
 legitimate receivers with the wrong session description are unable to
 correctly receive the session content, or that receivers
 inadvertently try to receive at a much higher rate than they are
 capable of, thereby possibly disrupting other traffic in the network.
 To avoid these problems, it is RECOMMENDED that measures be taken to
 prevent receivers from accepting incorrect session descriptions.  One
 such measure is source authentication to ensure that receivers only

Paila, et al. Standards Track [Page 30] RFC 6726 FLUTE November 2012

 accept legitimate session descriptions from authorized senders.  How
 these measures are achieved is outside the scope of this document,
 since this session description is usually carried out-of-band.

7.3.2. Attacks against the FDT Instances

 Corrupting the FDT Instances is one way to create a DoS attack.  For
 example, the attacker changes the MD5 sum associated to a file.  This
 possibly leads a receiver to reject the files received, no matter
 whether the files have been correctly received or not.
 Corrupting the FDT Instances is also a way to make the reception
 process more costly than it should be.  This can be achieved by
 changing the FEC Object Transmission Information when the FEC Object
 Transmission Information is included in the FDT Instance.  For
 example, an attacker may corrupt the FDT Instance in such a way that
 Reed-Solomon over GF(2^^16) would be used instead of GF(2^^8) with
 FEC Encoding ID 2.  This may significantly increase the processing
 load while compromising FEC decoding.
 More generally, because FDT Instance data is structured using the XML
 language by means of an XML media type, many of the security
 considerations described in [RFC3023] and [RFC3470] also apply to
 such data.
 It is therefore RECOMMENDED that measures be taken to guarantee the
 integrity and to check the sender's identity of the FDT Instances.
 To that purpose, one of the countermeasures mentioned above
 (Section 7.2.2) SHOULD be used.  These measures will either be
 applied on a packet level or globally over the whole FDT Instance
 object.  Additionally, XML digital signatures [RFC3275] are a way to
 protect the FDT Instance by digitally signing it.  When there is no
 packet-level integrity verification scheme, it is RECOMMENDED to rely
 on XML digital signatures of the FDT Instances.

7.3.3. Attacks against the ALC/LCT Parameters

 By corrupting the ALC/LCT header (or header extensions), one can
 execute attacks on the underlying ALC/LCT implementation.  For
 example, sending forged ALC packets with the Close Session flag (A)
 set to one can lead the receiver to prematurely close the session.
 Similarly, sending forged ALC packets with the Close Object flag (B)
 set to one can lead the receiver to prematurely give up the reception
 of an object.

Paila, et al. Standards Track [Page 31] RFC 6726 FLUTE November 2012

 It is therefore RECOMMENDED that measures be taken to guarantee the
 integrity and to check the sender's identity of the ALC packets
 received.  To that purpose, one of the countermeasures mentioned
 above (Section 7.2.2) SHOULD be used.

7.3.4. Attacks against the Associated Building Blocks

 Let us first focus on the congestion control building block, which
 may be used in the ALC session.  A receiver with an incorrect or
 corrupted implementation of the multiple-rate congestion control
 building block may affect the health of the network in the path
 between the sender and the receiver.  That may also affect the
 reception rates of other receivers who joined the session.
 When the congestion control building block is applied with FLUTE, it
 is RECOMMENDED that receivers be required to identify themselves as
 legitimate before they receive the session description needed to join
 the session.  How receivers identify themselves as legitimate is
 outside the scope of this document.  If authenticating a receiver
 does not prevent this receiver from launching an attack, this
 authentication will enable the network operator to identify him and
 to take countermeasures.
 When the congestion control building block is applied with FLUTE, it
 is also RECOMMENDED that a packet-level authentication scheme be
 used, as explained in Section 7.2.2.  Some of them, like TESLA, only
 provide a delayed authentication service, whereas congestion control
 requires a rapid reaction.  It is therefore RECOMMENDED [RFC5775]
 that a receiver using TESLA quickly reduce its subscription level
 when the receiver believes that congestion did occur, even if the
 packet has not yet been authenticated.  Therefore, TESLA will not
 prevent DoS attacks where an attacker makes the receiver believe that
 congestion occurred.  This is an issue for the receiver, but this
 will not compromise the network.  Other authentication methods that
 do not feature this delayed authentication could be preferred, or a
 Group-Keyed MAC scheme could be used in parallel with TESLA to
 prevent attacks launched from outside of the group.

7.4. Other Security Considerations

 The security considerations that apply to, and are described in, ALC
 [RFC5775], LCT [RFC5651], and FEC [RFC5052] also apply to FLUTE, as
 FLUTE builds on those specifications.  In addition, any security
 considerations that apply to any congestion control building block
 used in conjunction with FLUTE also apply to FLUTE.

Paila, et al. Standards Track [Page 32] RFC 6726 FLUTE November 2012

 Even if FLUTE defines a purely unidirectional delivery service,
 without any feedback information that would be sent to the sender,
 security considerations MAY require bidirectional communications.
 For instance, if an automated key management scheme is used, a
 bidirectional point-to-point channel is often needed to establish a
 shared secret between each receiver and the sender.  Each shared
 secret can then be used to distribute additional keys to the
 associated receiver (e.g., traffic encryption keys).
 As an example, [MBMSsecurity] details a complete security framework
 for the Third Generation Partnership Project (3GPP) Multimedia
 Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for
 Download Sessions.  It relies on bidirectional point-to-point
 communications for User Equipment authentication and for key
 distribution, using the Multimedia Internet KEYing (MIKEY) protocol
 [RFC3830].  Because this security framework is specific to this use
 case, it cannot be reused as such for generic security
 recommendations in this specification.  Instead, the following
 section introduces minimum security recommendations.

7.5. Minimum Security Recommendations

 We now introduce a mandatory-to-implement, but not necessarily to
 use, security configuration, in the sense of [RFC3365].  Since FLUTE
 relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
 [RFC5775].  More precisely, security is achieved by means of IPsec/
 ESP in transport mode.  [RFC4303] explains that ESP can be used to
 potentially provide confidentiality, data origin authentication,
 content integrity, anti-replay, and (limited) traffic flow
 confidentiality.  [RFC5775] specifies that the data origin
 authentication, content integrity, and anti-replay services SHALL be
 supported, and that the confidentiality service is RECOMMENDED.  If a
 short-lived session MAY rely on manual keying, it is also RECOMMENDED
 that an automated key management scheme be used, especially in the
 case of long-lived sessions.
 Therefore, the RECOMMENDED solution for FLUTE provides per-packet
 security, with data origin authentication, integrity verification,
 and anti-replay.  This is sufficient to prevent most of the in-band
 attacks listed above.  If confidentiality is required, a per-packet
 encryption SHOULD also be used.

Paila, et al. Standards Track [Page 33] RFC 6726 FLUTE November 2012

8. IANA Considerations

 This specification contains five separate items upon which IANA has
 taken action:
 1.  Registration of the FDT Instance XML Namespace.
 2.  Registration of the FDT Instance XML Schema.
 3.  Registration of the application/fdt+xml Media Type.
 4.  Registration of the Content Encoding Algorithms.
 5.  Registration of two LCT Header Extension Types (EXT_FDT and
     EXT_CENC).

8.1. Registration of the FDT Instance XML Namespace

 IANA has registered the following new XML Namespace in the IETF XML
 "ns" registry [RFC3688] at
 http://www.iana.org/assignments/xml-registry/ns.html.
 URI: urn:ietf:params:xml:ns:fdt
 Registrant Contact: Toni Paila (toni.paila@gmail.com)
 XML: N/A

8.2. Registration of the FDT Instance XML Schema

 IANA has registered the following in the IETF XML "schema" registry
 [RFC3688] at
 http://www.iana.org/assignments/xml-registry/schema.html.
 URI: urn:ietf:params:xml:schema:fdt
 Registrant Contact: Toni Paila (toni.paila@gmail.com)
 XML: The XML Schema specified in Section 3.4.2

Paila, et al. Standards Track [Page 34] RFC 6726 FLUTE November 2012

8.3. Registration of the application/fdt+xml Media Type

 IANA has registered the following in the "Application Media Types"
 registry at http://www.iana.org/assignments/media-types/application/.
 Type name: application
 Subtype name: fdt+xml
 Required parameters: none
 Optional parameters: charset="utf-8"
 Encoding considerations: binary (the FLUTE file delivery protocol
 does not impose any restriction on the objects it carries and in
 particular on the FDT Instance itself)
 Restrictions on usage: none
 Security considerations: fdt+xml data is passive and does not
 generally represent a unique or new security threat.  However, there
 is some risk in sharing any kind of data, in that unintentional
 information may be exposed, and that risk applies to fdt+xml data as
 well.
 Interoperability considerations: None
 Published specification: [RFC6726], especially noting Section 3.4.2.
 The specified FDT Instance functions as an actual media format of use
 to the general Internet community, and thus media type registration
 under the Standards Tree is appropriate to maximize interoperability.
 Applications that use this media type: file and object delivery
 applications and protocols (e.g., FLUTE).
 Additional information:
     Magic number(s): none
     File extension(s): ".fdt" (e.g., if there is a need to store an
                        FDT Instance as a file)
     Macintosh File Type Code(s): none
 Person and email address to contact for further information:
 Toni Paila (toni.paila@gmail.com)
 Intended usage: Common
 Author/Change controller: IETF

Paila, et al. Standards Track [Page 35] RFC 6726 FLUTE November 2012

8.4. Creation of the FLUTE Content Encoding Algorithms Registry

 IANA has created a new registry, "FLUTE Content Encoding Algorithms",
 with a reference to [RFC6726]; see Section 3.4.3.  The registry
 entries consist of a numeric value from 0 to 255, inclusive, and may
 be registered using the Specification Required policy [RFC5226].
 The initial contents of the registry are as follows, with unspecified
 values available for new registrations:
                +-------+----------------+-----------+
                | Value | Algorithm Name | Reference |
                +-------+----------------+-----------+
                |   0   |      null      | [RFC6726] |
                |   1   |      ZLIB      | [RFC1950] |
                |   2   |     DEFLATE    | [RFC1951] |
                |   3   |      GZIP      | [RFC1952] |
                +-------+----------------+-----------+

8.5. Registration of LCT Header Extension Types

 IANA has registered two new entries in the "Layered Coding Transport
 (LCT) Header Extension Types" registry [RFC5651], as follows:
            +--------+----------+-------------------------+
            | Number |   Name   |        Reference        |
            +--------+----------+-------------------------+
            |   192  |  EXT_FDT | [RFC6726] Section 3.4.1 |
            |   193  | EXT_CENC | [RFC6726] Section 3.4.3 |
            +--------+----------+-------------------------+

9. Acknowledgments

 The following persons have contributed to this specification: Brian
 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
 Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington,
 Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis
 Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba.  The authors
 would like to thank all the contributors for their valuable work in
 reviewing and providing feedback regarding this specification.

Paila, et al. Standards Track [Page 36] RFC 6726 FLUTE November 2012

10. Contributors

 Jani Peltotalo
 Tampere University of Technology
 P.O. Box 553 (Korkeakoulunkatu 1)
 Tampere FIN-33101
 Finland
 EMail: jani.peltotalo@tut.fi
 Sami Peltotalo
 Tampere University of Technology
 P.O. Box 553 (Korkeakoulunkatu 1)
 Tampere FIN-33101
 Finland
 EMail: sami.peltotalo@tut.fi
 Magnus Westerlund
 Ericsson Research
 Ericsson AB
 SE-164 80 Stockholm
 Sweden
 EMail: magnus.westerlund@ericsson.com
 Thorsten Lohmar
 Ericsson Research (EDD)
 Ericsson Allee 1
 52134 Herzogenrath
 Germany
 EMail: thorsten.lohmar@ericsson.com

11. Change Log

11.1. RFC 3926 to This Document

 Incremented the FLUTE protocol version from 1 to 2, due to concerns
 about backwards compatibility.  For instance, the LCT header changed
 between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
 the LCT header indicate the presence of Sender Current Time and
 Expected Residual Time, respectively.  In [RFC5651], these fields
 MUST be set to zero and MUST be ignored by receivers (instead, the
 EXT_TIME Header Extensions can convey this information if needed).
 Thus, [RFC5651] is not backwards compatible with RFC 3451, even
 though both use LCT version 1.  FLUTE version 1 as specified in
 [RFC3926] MUST use RFC 3451.  FLUTE version 2 as specified in this
 document MUST use [RFC5651].  Therefore, an implementation that
 relies on [RFC3926] and RFC 3451 will not be backwards compatible
 with FLUTE as specified in this document.

Paila, et al. Standards Track [Page 37] RFC 6726 FLUTE November 2012

 Updated dependencies to other RFCs to revised versions; e.g., changed
 ALC reference from RFC 3450 to [RFC5775], changed LCT reference from
 RFC 3451 to [RFC5651], etc.
 Added clarification for the use of FLUTE for unicast communications
 in Section 1.1.4.
 Clarified how to reliably deliver the FDT in Section 3.3 and the
 possibility of using out-of-band delivery of FDT information.
 Clarified how to address FDT Instance expiration time wraparound with
 the notion of the NTPv4 "epoch" in Section 3.3.
 Clarified what should be considered erroneous situations in
 Section 3.4.1 (definition of FDT Instance ID).  In particular, a
 receiver MUST be ready to handle FDT Instance ID wraparounds and
 missing FDT Instances.
 Updated Section 7.5 to define IPsec/ESP as a mandatory-to-implement
 security solution.
 Removed the 'Statement of Intent' from Section 1.  The statement of
 intent was meant to clarify the "Experimental" status of [RFC3926].
 It does not apply to this document.
 Added clarification of "XML-DSIG" near the end of Section 3.
 In Section 3.2, replaced "complete FDT" with text that is more
 descriptive.
 Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT
 Instance".
 Clarified the text regarding FDT Instance ID wraparound at the end of
 Section 3.4.1.
 Clarified "complete FDT" in Section 3.4.2.
 Added semantics for the case where two TOIs refer to the same
 Content-Location.  It is now in line with the way that 3GPP and
 Digital Video Broadcasting (DVB) standards interpret this case.
 In Section 3.4.2, the XML Schema of the FDT Instance was modified per
 advice from various sources.  For example, extension by element was
 missing but is now supported.  Also, the namespace definition was
 changed to URN format.
 Clarified FDT-schema extensibility at the end of Section 3.4.2.

Paila, et al. Standards Track [Page 38] RFC 6726 FLUTE November 2012

 The CENC value allocation has been added at the end of Section 3.4.3.
 Section 5 has been modified so that EXT_FTI and the FEC issues were
 replaced by a reference to the ALC specification [RFC5775].
 Added a clarifying paragraph on the use of the Codepoint field at the
 end of Section 5.
 Reworked Section 8 -- IANA Considerations; it now contains six IANA
 registration requests:
  • Registration of the FDT Instance XML Namespace.
  • Registration of the FDT Instance XML Schema.
  • Registration of the application/fdt+xml Media Type.
  • Registration of the Content Encoding Algorithms.
  • Registration of two LCT Header Extension Types and corresponding

values in the LCT Header Extension Types Registry (192 for EXT_FDT

    and 193 for EXT_CENC).
 Added Section 10 -- Contributors.
 Revised lists of both Normative and Informative references.
 Added a clarification that the receiver should ignore reserved bits
 of Header Extension type 193 upon reception.
 Elaborated on what kinds of networks cannot support FLUTE congestion
 control (Section 1.1.4).
 In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to
 "multiple" (meaning 2-n).
 Moved the requirement in Section 3.3 (to send FDT more reliably than
 files) to a bulleted RECOMMENDED requirement, making check-off easier
 for testers.
 In Section 3.3, sharpened the definition that future FDT file
 instances can "augment" (meaning enhance) rather than "complement"
 (sometimes meaning negate, which is not allowed) the file parameters.
 Elaborated in Sections 3.3 and 4 that FEC Encoding ID = 0 is Compact
 No-Code FEC, so that the reader doesn't have to search other RFCs to
 understand these protocol constants used by FLUTE.

Paila, et al. Standards Track [Page 39] RFC 6726 FLUTE November 2012

 Required in Section 3.3 that FLUTE receivers SHALL NOT attempt to
 decode FDTs if they do not understand the FEC Encoding ID.
 Removed the restriction of Section 3.3, in bullet #4, that TOI = 0
 for the FDT, to be consistent with Appendix A step 6 and elsewhere.
 An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0.
 Standardized on the term "expiration time", and avoided using the
 redundant and possibly confusing term "expiry time".
 To interwork with experimental FLUTE, stipulated in Section 3.1 that
 only 1 instantiation of all 3 protocols -- FLUTE, ALC, and LCT -- can
 be associated with a session (source IP Address, TSI), and mentioned
 in Section 6 that one may (optionally) derive the FLUTE version from
 the file delivery session description.
 Used a software writing tool to lower the reading grade level and
 simplify Section 3.1.

12. References

12.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
            Layered Coding (ALC) Protocol Instantiation", RFC 5775,
            April 2010.
 [RFC5651]  Luby, M., Watson, M., and L. Vicisano, "Layered Coding
            Transport (LCT) Building Block", RFC 5651, October 2009.
 [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
            Correction (FEC) Building Block", RFC 5052, August 2007.
 [RFC5445]  Watson, M., "Basic Forward Error Correction (FEC)
            Schemes", RFC 5445, March 2009.
 [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
            "Network Time Protocol Version 4: Protocol and Algorithms
            Specification", RFC 5905, June 2010.
 [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
            Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

Paila, et al. Standards Track [Page 40] RFC 6726 FLUTE November 2012

 [XML-Schema-Part-1]
            Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
            "XML Schema Part 1: Structures Second Edition",
            W3C Recommendation, October 2004,
            <http://www.w3.org/TR/xmlschema-1/>.
 [XML-Schema-Part-2]
            Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
            Second Edition", W3C Recommendation, October 2004,
            <http://www.w3.org/TR/xmlschema-2/>.
 [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
            Types", RFC 3023, January 2001.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", RFC 5226, May 2008.
 [RFC3738]  Luby, M. and V. Goyal, "Wave and Equation Based Rate
            Control (WEBRC) Building Block", RFC 3738, April 2004.
            Note: The RFC 3738 reference is to a target document of a
            lower maturity level.  Some caution should be used, since
            it may be less stable than the present document.
 [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
            RFC 4303, December 2005.

12.2. Informative References

 [RFC3926]  Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
            "FLUTE - File Delivery over Unidirectional Transport",
            RFC 3926, October 2004.
 [RFC2357]  Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
            Criteria for Evaluating Reliable Multicast Transport and
            Application Protocols", RFC 2357, June 1998.
 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66,
            RFC 3986, January 2005.
 [RFC3470]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
            the Use of Extensible Markup Language (XML)
            within IETF Protocols", BCP 70, RFC 3470, January 2003.
 [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
            Extensions (MIME) Part One: Format of Internet Message
            Bodies", RFC 2045, November 1996.

Paila, et al. Standards Track [Page 41] RFC 6726 FLUTE November 2012

 [RFC1950]  Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
            Specification version 3.3", RFC 1950, May 1996.
 [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
            version 1.3", RFC 1951, May 1996.
 [RFC1952]  Deutsch, P., "GZIP file format specification version 4.3",
            RFC 1952, May 1996.
 [IANAheaderfields]
            IANA, "Message Header Fields",
            <http://www.iana.org/protocols>.
 [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
            Announcement Protocol", RFC 2974, October 2000.
 [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
            Description Protocol", RFC 4566, July 2006.
 [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
            RFC 1112, August 1989.
 [PAPER.SSM]
            Holbrook, H., "A Channel Model for Multicast", Ph.D.
            Dissertation, Stanford University, Department of Computer
            Science, Stanford, California, August 2001.
 [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
            Engineering Task Force Standard Protocols", BCP 61,
            RFC 3365, August 2002.
 [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
            Mail Extensions (S/MIME) Version 3.2 Message
            Specification", RFC 5751, January 2010.
 [RFC3275]  Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
            Markup Language) XML-Signature Syntax and Processing",
            RFC 3275, March 2002.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.

Paila, et al. Standards Track [Page 42] RFC 6726 FLUTE November 2012

 [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
            Standards (PKCS) #1: RSA Cryptography Specifications
            Version 2.1", RFC 3447, February 2003.
 [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
            Hashing for Message Authentication", RFC 2104,
            February 1997.
 [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
            Briscoe, "Timed Efficient Stream Loss-Tolerant
            Authentication (TESLA): Multicast Source Authentication
            Transform Introduction", RFC 4082, June 2005.
 [RFC5776]  Roca, V., Francillon, A., and S. Faurite, "Use of Timed
            Efficient Stream Loss-Tolerant Authentication (TESLA) in
            the Asynchronous Layered Coding (ALC) and NACK-Oriented
            Reliable Multicast (NORM) Protocols", RFC 5776,
            April 2010.
 [RFC6584]  Roca, V., "Simple Authentication Schemes for the
            Asynchronous Layered Coding (ALC) and NACK-Oriented
            Reliable Multicast (NORM) Protocols", RFC 6584,
            April 2012.
 [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
            Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
            August 2004.
 [MBMSsecurity]
            3GPP, "3rd Generation Partnership Project; Technical
            Specification Group Services and System Aspects; 3G
            Security; Security of Multimedia Broadcast/Multicast
            Service (MBMS) (Release 10)", December 2010,
            <http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.

Paila, et al. Standards Track [Page 43] RFC 6726 FLUTE November 2012

Appendix A. Receiver Operation (Informative)

 This section gives an example of how the receiver of the file
 delivery session may operate.  Instead of a detailed state-by-state
 specification, the following should be interpreted as a rough
 sequence of an envisioned file delivery receiver.
 1.  The receiver obtains the description of the file delivery session
     identified by the (source IP address, Transport Session
     Identifier) pair.  The receiver also obtains the destination IP
     addresses and respective ports associated with the file delivery
     session.
 2.  The receiver joins the channels in order to receive packets
     associated with the file delivery session.  The receiver may
     schedule this join operation utilizing the timing information
     contained in a possible description of the file delivery session.
 3.  The receiver receives ALC/LCT packets associated with the file
     delivery session.  The receiver checks that the packets match the
     declared Transport Session Identifier.  If not, the packets are
     silently discarded.
 4.  While receiving, the receiver demultiplexes packets based on
     their TOI and stores the relevant packet information in an
     appropriate area for recovery of the corresponding file.
     Multiple files can be reconstructed concurrently.
 5.  The receiver recovers an object.  An object can be recovered when
     an appropriate set of packets containing Encoding Symbols for the
     transmission object has been received.  An appropriate set of
     packets is dependent on the properties of the FEC Encoding ID and
     FEC Instance ID, and on other information contained in the FEC
     Object Transmission Information.
 6.  Objects with TOI = 0 are reserved for FDT Instances.  All FDT
     Instances are signaled by including an EXT_FDT Header Extension
     in the LCT header.  The EXT_FDT header contains an FDT Instance
     ID (i.e., an FDT version number).  If the object has an FDT
     Instance ID 'N', the receiver parses the payload of the instance
     'N' of the FDT and updates its FDT database accordingly.
 7.  If the object recovered is not an FDT Instance but a file, the
     receiver looks up its FDT database to get the properties
     described in the database, and assigns the file the given
     properties.  The receiver also checks that the received content

Paila, et al. Standards Track [Page 44] RFC 6726 FLUTE November 2012

     length matches with the description in the database.  Optionally,
     if an MD5 checksum has been used, the receiver checks that the
     calculated MD5 matches the description in the FDT database.
 8.  The actions the receiver takes with imperfectly received files
     (missing data, mismatching content integrity digest, etc.) are
     outside the scope of this specification.  When a file is
     recovered before the associated file description entry is
     available, a possible behavior is to wait until an FDT Instance
     is received that includes the missing properties.
 9.  If the file delivery session end time has not been reached, go
     back to step 3.  Otherwise, end.

Appendix B. Example of FDT Instance (Informative)

 <?xml version="1.0" encoding="UTF-8"?>
 <FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
                       ietf-flute-fdt.xsd"
   Expires="2890842807">
   <File
     Content-Location="http://www.example.com/menu/tracklist.html"
     TOI="1"
     Content-Type="text/html"/>
   <File
     Content-Location="http://www.example.com/tracks/track1.mp3"
     TOI="2"
     Content-Length="6100"
     Content-Type="audio/mp3"
     Content-Encoding="gzip"
     Content-MD5="+VP5IrWploFkZWc11iLDdA=="
     Some-Private-Extension-Tag="abc123"/>
 </FDT-Instance>

Paila, et al. Standards Track [Page 45] RFC 6726 FLUTE November 2012

Authors' Addresses

 Toni Paila
 Nokia
 Itamerenkatu 11-13
 Helsinki  00180
 Finland
 EMail: toni.paila@gmail.com
 Rod Walsh
 Nokia/Tampere University of Technology
 P.O. Box 553 (Korkeakoulunkatu 1)
 Tampere  FI-33101
 Finland
 EMail: roderick.walsh@tut.fi
 Michael Luby
 Qualcomm Technologies, Inc.
 2030 Addison Street, Suite 420
 Berkeley, CA  94704
 USA
 EMail: luby@qti.qualcomm.com
 Vincent Roca
 INRIA
 655, av. de l'Europe
 Inovallee; Montbonnot
 ST ISMIER cedex  38334
 France
 EMail: vincent.roca@inria.fr
 Rami Lehtonen
 TeliaSonera
 Hatanpaankatu 1
 Tampere  FIN-33100
 Finland
 EMail: rami.lehtonen@teliasonera.com

Paila, et al. Standards Track [Page 46]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6726.txt · Last modified: 2012/11/06 19:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki