[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6726

Reliable Multicast Transport (RMT)                              T. Paila
Internet-Draft                                                  R. Walsh
Obsoletes: 3926 (if approved)                                      Nokia
Intended status: Standards Track                                 M. Luby
Expires: August 7, 2011                                   Qualcomm, Inc.
                                                                 V. Roca
                                                                   INRIA
                                                             R. Lehtonen
                                                             TeliaSonera
                                                        February 3, 2011


          FLUTE - File Delivery over Unidirectional Transport
                    draft-ietf-rmt-flute-revised-12

Abstract

   This document defines 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 RFC3926.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 7, 2011.

Copyright Notice

   Copyright (c) 2011 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



Paila, et al.            Expires August 7, 2011                 [Page 1]

Internet-Draft                    FLUTE                    February 2011


   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.

































Paila, et al.            Expires August 7, 2011                 [Page 2]

Internet-Draft                    FLUTE                    February 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Applicability Statement  . . . . . . . . . . . . . . . . .  6
       1.1.1.  The Target Application Space . . . . . . . . . . . . .  6
       1.1.2.  The Target Scale . . . . . . . . . . . . . . . . . . .  6
       1.1.3.  Intended Environments  . . . . . . . . . . . . . . . .  6
       1.1.4.  Weaknesses . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Conventions used in this Document  . . . . . . . . . . . . . .  7
   3.  File delivery  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  File delivery session  . . . . . . . . . . . . . . . . . .  9
     3.2.  File Delivery Table  . . . . . . . . . . . . . . . . . . . 11
     3.3.  Dynamics of FDT Instances within 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  . . . . . . . . . . . 22
   5.  Delivering FEC Object Transmission Information . . . . . . . . 24
   6.  Describing file delivery sessions  . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
     7.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . 27
     7.2.  Attacks against the data flow  . . . . . . . . . . . . . . 27
       7.2.1.  Access to confidential files . . . . . . . . . . . . . 27
       7.2.2.  File corruption  . . . . . . . . . . . . . . . . . . . 28
     7.3.  Attacks against the session control parameters and
           associated Building Blocks . . . . . . . . . . . . . . . . 29
       7.3.1.  Attacks against the Session Description  . . . . . . . 30
       7.3.2.  Attacks against the FDT Instances  . . . . . . . . . . 30
       7.3.3.  Attacks against the ALC/LCT parameters . . . . . . . . 31
       7.3.4.  Attacks against the associated Building Blocks . . . . 31
     7.4.  Other Security Considerations  . . . . . . . . . . . . . . 32
     7.5.  Minimum Security Recommendations . . . . . . . . . . . . . 32
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
     8.1.  Registration Request for XML Schema of FDT Instance  . . . 33
     8.2.  Media-Type Registration Request for application/fdt+xml  . 33
     8.3.  Content Encoding Algorithm Registration Request  . . . . . 34
       8.3.1.  Explicit IANA Assignment Guidelines  . . . . . . . . . 34
     8.4.  Registration of EXT_FDT LCT Header Extension Type  . . . . 35
     8.5.  Registration of EXT_CENC LCT Header Extension Type . . . . 35
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
   11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     11.1. RFC3926 to draft-ietf-rmt-flute-revised-12 . . . . . . . . 36
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     12.1. Normative references . . . . . . . . . . . . . . . . . . . 38
     12.2. Informative references . . . . . . . . . . . . . . . . . . 40



Paila, et al.            Expires August 7, 2011                 [Page 3]

Internet-Draft                    FLUTE                    February 2011


   Appendix A.  Receiver operation (informative)  . . . . . . . . . . 42
   Appendix B.  Example of FDT Instance (informative) . . . . . . . . 43
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
















































Paila, et al.            Expires August 7, 2011                 [Page 4]

Internet-Draft                    FLUTE                    February 2011


1.  Introduction

   This document defines FLUTE version 2, a protocol for unidirectional
   delivery of files over the Internet.  This specification may not be
   backwards compatible with the previous experimental version defined
   in [RFC3926].  The specification builds on Asynchronous Layered
   Coding (ALC), version 1 [ID.ALC-revised], 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 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:

   -  Definition of a file delivery session built on top of ALC,
      including transport details and timing constraints.

   -  In-band signaling of the transport parameters of the ALC session.

   -  In-band signaling of the properties of delivered files.

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



Paila, et al.            Expires August 7, 2011                 [Page 5]

Internet-Draft                    FLUTE                    February 2011


   This specification contains part of the definitions necessary to
   fully specify a Reliable Multicast Transport 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 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.

   The differences between RFC3926 and this document are listed in
   Section 11.

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 SDP [RFC.SDP] files which 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 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 [ID.ALC-revised], the
   Layered Coding Transport (LCT) Building Block [RFC5651] and the FEC
   Building Block [RFC5052].

   FLUTE can be used with both multicast and unicast delivery, but it's



Paila, et al.            Expires August 7, 2011                 [Page 6]

Internet-Draft                    FLUTE                    February 2011


   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.  FLUTE
   inherently works with all types of networks, including LANs, WANs,
   Intranets, the Internet, asymmetric networks, wireless networks, and
   satellite networks.

   FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
   is IP version specific.  FLUTE works with both multicast models: Any-
   Source Multicast (ASM) [RFC.ASM] and the Source-Specific Multicast
   (SSM) [PAPER.SSM].

   FLUTE is applicable for both Internet use, with a suitable congestion
   control building block, and provisioned/controlled systems, such as
   delivery over wireless broadcast radio systems.

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 these networks

   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) [RFC.3738] multiple rate
   congestion control scheme [ID.ALC-revised].  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 RFC 2119 [RFC.2119].

   The terms "object" and "transmission object" are consistent with the



Paila, et al.            Expires August 7, 2011                 [Page 7]

Internet-Draft                    FLUTE                    February 2011


   definitions in ALC [ID.ALC-revised] and LCT [RFC.LCT].  The terms
   "file" and "source object" are pseudonyms for "object".


3.  File delivery

   Asynchronous Layered Coding [ID.ALC-revised] 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.  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 MIME media type.  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 [RFC.ZLIB].  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
      [RFC.SMIME] as the content encoding type for files with this
      authentication wrapper, and one could use XML-DSIG [RFC.XML-DSIG]
      to digitally sign the file.  XML-DSIG can also be used to provide
      tamper prevention e.g. on the Content-Location field.  Content
      encoding is applied to file data before FEC protection.



Paila, et al.            Expires August 7, 2011                 [Page 8]

Internet-Draft                    FLUTE                    February 2011


   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 Layered Coding Transport building
   block (LCT) [RFC.LCT].  Thus ALC inherits the session concept of LCT.
   In this document we will use the concept 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).  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 extension header
   (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 RFC 5775, and LCT version 1 as specified in RFC 5651.

   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) carried in the ALC/LCT header of the packet.
   Note that when a receiver first begins receiving packets, it MAY 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



Paila, et al.            Expires August 7, 2011                 [Page 9]

Internet-Draft                    FLUTE                    February 2011


   the TSI and the FLUTE protocol version, until the EXT_FDT header
   arrives.  Alternately, a new receiver MAY discover a binding between
   TSI and FLUTE protocol version via a session discovery protocol that
   is out of scope in this document.

   If the sender is not assigned a permanent IP address accessible to
   receivers, then packets that can be received by receivers contain a
   temporary IP address.  In this case the TSI is scoped by this
   temporary 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 temporary 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 a permanent IP address or a temporary IP address, is
   outside the scope of this document.

   When FLUTE is used for file delivery over ALC the following rules
   apply:

   *  The ALC/LCT session is called a file delivery session.

   *  The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
      Delivery Table Instance' (section 3.2)

   *  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 RFC 5651 [RFC.LCT] for the LCT definition of the
      Close Session flag, and see section 4.2 of RFC 5775
      [ID.ALC-revised] for an example of the use of a TOI within an ALC
      packet.

   *  The TOI value '0' is reserved for 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.            Expires August 7, 2011                [Page 10]

Internet-Draft                    FLUTE                    February 2011


   *  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 nor
   exhaustive.

   Attributes related to the delivery of file:

   -  TOI value that represents the file

   -  FEC Object Transmission Information (including the FEC Encoding ID
      and, if relevant, the FEC Instance ID)

   -  Size of the transmission object carrying the file

   -  Aggregate rate of sending packets to all channels

   Attributes related to the file itself:

   -  Name, Identification and Location of file (specified by the URI)

   -  MIME media type of file

   -  Size of file

   -  Encoding of file

   -  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.            Expires August 7, 2011                [Page 11]

Internet-Draft                    FLUTE                    February 2011


   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.  Handling of these unmapped TOIs (Non-zero
   TOIs that are not resolved by the FDT) is out of scope of this
   specification.

   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, a subset of, 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.

3.3.  Dynamics of FDT Instances within 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.





Paila, et al.            Expires August 7, 2011                [Page 12]

Internet-Draft                    FLUTE                    February 2011


   *  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 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 is 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
      which 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 may be lost.

   *  Within a file delivery session, any TOI > 0 MAY be described more
      than once.  An example: previous FDT Instance 0 describes TOI of
      value '3'.  Now, subsequent FDT Instances can either keep TOI '3'
      unmodified on 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 an
      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) [RFC.NTP] time value.  These 32
      bits provide an unsigned integer representing the time in seconds
      relative to 0 hours 1 January 1900 in case of the prime epoch (era
      0) [NTPv4].  The handling of time wraparound (to happen in 2036)
      requires to consider the associated epoch.  In any case, both a
      sender and a receiver can determine to which (136 year) epoch the
      FDT Instance expiration time value pertains to by choosing the
      epoch for which the expiration time is closest in time to the
      current time.






Paila, et al.            Expires August 7, 2011                [Page 13]

Internet-Draft                    FLUTE                    February 2011


   *  The space of FDT Instance IDs is limited and so senders should
      take care to always have a large enough supply of FDT Instance IDs
      corresponding to unexpired FDTs when specifying FDT expiration
      times.

   *  The receiver SHOULD 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
      [RFC.FECSchemes] 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 understand the FEC Encoding ID in a FDT
      Instance, 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.

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



Paila, et al.            Expires August 7, 2011                [Page 14]

Internet-Draft                    FLUTE                    February 2011


   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
   (rather than in-band, within one or several FDT Instances).  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 with as much or greater reliability
   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 higher a
   delivery probability than the file recovery probability.

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.  The FDT Instance Header is placed in the same way as any
   other LCT extension header.  There MAY be other LCT extension headers
   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 extension headers are followed by the FEC Payload ID, and finally
   the Encoding Symbols for the FDT Instance which contains one or more
   file description entries.  A 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



Paila, et al.            Expires August 7, 2011                [Page 15]

Internet-Draft                    FLUTE                    February 2011


   depicted in the Figure 1 below.  All integer fields are carried in
   "big-endian" or "network order" format, that is, most significant
   byte (octet) first.  As defined in [ID.ALC-revised], 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 a FDT packet)                ~

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: Overall FDT Packet

3.4.1.  Format of FDT Instance Header

   The FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI
   specific LCT header extension [RFC.LCT].  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

   Version of FLUTE (V), 4 bits:

   This document specifies FLUTE version 2.  Hence in any ALC packet
   that carries 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:




Paila, et al.            Expires August 7, 2011                [Page 16]

Internet-Draft                    FLUTE                    February 2011


   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 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.
   Senders SHOULD NOT re-use 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 SHOULD be
   considered as an error case.  Receiver behavior in this case 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.

3.4.2.  Syntax of FDT Instance

   The FDT Instance contains file description entries that provide the
   mapping functionality described in 3.2 above.

   The FDT Instance is an XML structure that has a single root element
   "FDT-Instance".  The "FDT-Instance" element MUST contain "Expires"
   attribute, which tells the expiration time of the FDT Instance.  In
   addition, the "FDT-Instance" element MAY contain the "Complete"
   attribute (boolean), which, when TRUE, signals that this "FDT
   Instance" includes the set of "File" entries that exhausts both the
   set of files delivered so far and also 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 identical file parameters 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").

   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



Paila, et al.            Expires August 7, 2011                [Page 17]

Internet-Draft                    FLUTE                    February 2011


   represented by element "File" which is a child element of the FDT
   Instance structure.

   The attributes of "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 MIME
   field name and the XML attribute value corresponds to the value of
   the MIME field body.  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 above.  "Content-
   Location" MUST be assigned a valid URI as defined in [RFC.HTTP11]
   which identifies the object to be delivered, for example a URI with
   the "http" or "file" URI scheme.  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 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 [RFC.HTTP11].

   *  Where the length is described, the attribute "Content-Length" MUST
      be used for the purpose as defined in [RFC.HTTP11].  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.




Paila, et al.            Expires August 7, 2011                [Page 18]

Internet-Draft                    FLUTE                    February 2011


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

   *  Where the MD5 message digest is described, the attribute "Content-
      MD5" MUST be used for the purpose as defined in [RFC.HTTP11].

   *  The FEC Object Transmission Information attributes as described in
      section 5.2.

   The following specifies the XML Schema
   [XML-Schema-Part-1][XML-Schema-Part-2] for 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.            Expires August 7, 2011                [Page 19]

Internet-Draft                    FLUTE                    February 2011


       <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"/>
       <xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
                     type="xs:unsignedLong"



Paila, et al.            Expires August 7, 2011                [Page 20]

Internet-Draft                    FLUTE                    February 2011


                     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

   Any valid FDT Instance MUST use the above XML Schema.  This way FDT
   provides extensibility to support 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.).

   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 are in the
   format of MIME fields and are either defined in the HTTP/1.1
   specification [RFC.HTTP11] or another well-known specification.

3.4.3.  Content Encoding of FDT Instance

   The FDT Instance itself MAY be content encoded, for example
   compressed.  This specification defines FDT Instance Content Encoding
   Header (EXT_CENC).  EXT_CENC is a new fixed length LCT header
   extension [RFC.LCT].  The Header Extension Type (HET) for the
   extension is 193.  If the FDT Instance is content encoded, the
   EXT_CENC MUST be used to signal the content encoding type.  In that
   case, EXT_CENC header extension MUST be used in all ALC packets
   carrying the same FDT Instance ID.  Consequently, when 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 content encoding is not used for a given FDT
   Instance, the EXT_CENC MUST NOT be used in any packet carrying the
   FDT Instance.  The format of EXT_CENC is defined below:






Paila, et al.            Expires August 7, 2011                [Page 21]

Internet-Draft                    FLUTE                    February 2011


    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

   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 [RFC.ZLIB], DEFLATE
   [RFC.DEFLATE] and GZIP [RFC.GZIP] respectively.

   Reserved, 16 bits:

   This field MUST be set to all '0'.  This field SHOULD 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 MAY 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.


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.





Paila, et al.            Expires August 7, 2011                [Page 22]

Internet-Draft                    FLUTE                    February 2011


   (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 complete the delivery of the
   second object 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 is used for the file
   delivery session.

   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 is 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 high
      rate receivers will receive.







Paila, et al.            Expires August 7, 2011                [Page 23]

Internet-Draft                    FLUTE                    February 2011


   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 [RFC.FECSchemes] 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 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
   ALC specific LCT extension header EXT_FTI [ID.ALC-revised] and the
   use of 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 file delivery session MUST support delivery of FEC
   Object Transmission Information using the 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 FDT.

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




Paila, et al.            Expires August 7, 2011                [Page 24]

Internet-Draft                    FLUTE                    February 2011


   *  "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 "Maximum
      Number of Encoding Symbols" Object Transmission Information
      element defined in [RFC5052], if required by the FEC Scheme.

   *  "FEC-OTI-Scheme-specific-information" carries the "encoded scheme-
      specific FEC Object Transmission Information" as defined in
      [RFC5052], if required by the FEC Scheme.

   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 represents the
   entry point from which thereafter the receiver operation falls into
   the scope of this specification.  According to [ID.ALC-revised], the
   transport parameters of an ALC/LCT session that the receiver needs to
   know are:

   *  The source IP address;






Paila, et al.            Expires August 7, 2011                [Page 25]

Internet-Draft                    FLUTE                    February 2011


   *  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, 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 FDT;

   *  Content Encoding format if optional content encoding of 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 congestion control mechanism for
      the session ;

   *  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 [RFC.SDP] or XML
   based) and held in a file which would be acquired by the receiver
   before the FLUTE session begins by means of some transport protocol
   (such as Session Announcement Protocol [RFC.SAP], email, HTTP
   [RFC.HTTP11], SIP [RFC.SIP], manual pre-configuration, 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.







Paila, et al.            Expires August 7, 2011                [Page 26]

Internet-Draft                    FLUTE                    February 2011


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 counter-measures.  We provide
   recommendations in Section 7.5.

7.2.  Attacks against the data flow

   Let us consider attacks against the data flow first.  At least, the
   following types of attacks exist:

   *  attacks that are meant to give access to a confidential file
      (e.g., in case of a 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 be done on a packet per



Paila, et al.            Expires August 7, 2011                [Page 27]

Internet-Draft                    FLUTE                    February 2011


   packet basis (e.g., when IPsec/ESP is used [RFC.4303], 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 forward error
   correction 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 forward error correction
   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.

   Several techniques can provide this source authentication/content
   integrity service:

   *  at the file level, the file MAY be digitally signed, for instance
      by using RSASSA-PKCS1-v1_5 [RFC.3447].  This signature enables a
      receiver to check the file integrity, once this latter 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
      [RMT-SIMPLE-AUTH].  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;






Paila, et al.            Expires August 7, 2011                [Page 28]

Internet-Draft                    FLUTE                    February 2011


   *  at the packet level, a Group Message Authentication Code (MAC)
      [RFC.2104][RMT-SIMPLE-AUTH] scheme can be used, for instance by
      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 MAC scheme does not create prohibitive
      processing load nor 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, TESLA [RFC.4082][MSEC-TESLA] 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.  Yet checking a packet requires a
      small delay (a second or more) after its reception;

   *  at the packet level, IPsec/ESP [RFC.4303] 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
   a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
   pre-distributing the public keys of each group member.

   Techniques relying on symmetric key cryptography (Group 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:




Paila, et al.            Expires August 7, 2011                [Page 29]

Internet-Draft                    FLUTE                    February 2011


   *  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, for
      instance the multiple rate congestion control protocol.

   The consequences of these attacks are potentially serious, since they
   might compromise the behavior of 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
   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 Denial of Service
   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) be used instead of GF(2^^8) with FEC
   Encoding ID 2.  This may significantly increase the processing load
   while compromising FEC decoding.

   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 counter-measures mentioned above



Paila, et al.            Expires August 7, 2011                [Page 30]

Internet-Draft                    FLUTE                    February 2011


   (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 [RFC.XML-DSIG] 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 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.

   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 counter-measures 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, that 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 congestion control building block is applied with FLUTE, it is
   therefore 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 latter to launch an attack, it will
   enable the network operator to identify him and to take counter-
   measures.

   When 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
   [ID.ALC-revised] that a receiver using TESLA quickly reduces its
   subscription level when the receiver believes that a congestion did
   occur, even if the packet has not yet been authenticated.  Therefore



Paila, et al.            Expires August 7, 2011                [Page 31]

Internet-Draft                    FLUTE                    February 2011


   TESLA will not prevent DoS attacks where an attacker makes the
   receiver believe that a 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 MAC scheme could be
   used in parallel to TESLA to prevent attacks launched from outside of
   the group.

7.4.  Other Security Considerations

   Lastly, we note that the security considerations that apply to, and
   are described in, ALC [ID.ALC-revised], LCT [RFC.LCT] 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.

7.5.  Minimum Security Recommendations

   We now introduce a mandatory to implement but not necessarily to use
   security configuration, in the sense of [RFC.3365].  Since FLUTE
   relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
   [ID.ALC-revised].  More precisely, security is achieved by means of
   IPsec/ESP in transport mode.  [RFC.4303] explains that ESP can be
   used to potentially provide confidentiality, data origin
   authentication, content integrity, anti-replay and (limited) traffic
   flow confidentiality.  [ID.ALC-revised] 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 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.


8.  IANA Considerations

   This specification contains five separate items for IANA
   Considerations:







Paila, et al.            Expires August 7, 2011                [Page 32]

Internet-Draft                    FLUTE                    February 2011


   1. Registration Request for XML Schema of FDT Instance.

   2. Media-Type Registration Request for application/fdt+xml.

   3. Content Encoding Algorithm Registration Request.

   4. Registration of the EXT_FDT LCT Header Extension Type

   5. Registration of the EXT_CENC LCT Header Extension Type

8.1.  Registration Request for XML Schema of FDT Instance

   Document [RFC.3688] defines an IANA maintained registry of XML
   documents used within IETF protocols.  The following is the
   registration request for the FDT XML schema.

   Registrant Contact: Toni Paila (toni.paila (at) nokia.com)

   XML: The XML Schema specified in Section 3.4.2

8.2.  Media-Type Registration Request for application/fdt+xml

   This section provides the registration request, as per [RFC.MIME4a],
   [RFC.MIME4b] and [RFC.XML-Media-Types], to be submitted to IANA
   following IESG approval.

   Type name: application

   Subtype name: fdt+xml

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
   characters [RFC.UTF8] and must be well-formed XML.

   Additional content and transfer encodings may be used with fdt+xml
   files, with the appropriate encoding for any specific file being
   entirely dependent upon the deployed application.

   Restrictions on usage: Only for usage with FDT Instances which are
   valid according to the XML schema of section 3.4.2.

   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



Paila, et al.            Expires August 7, 2011                [Page 33]

Internet-Draft                    FLUTE                    February 2011


   well.

   Interoperability considerations: None

   Published specification: The present document including 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 which use this media type: Not restricted to any
   particular application

   Additional information:

       Magic number(s): none
       File extension(s): An FDT Instance may use the extension ".fdt"
                          but this is not required.
       Macintosh File Type Code(s): none

   Person and email address to contact for further information: Toni
   Paila (toni.paila (at) nokia.com)

   Intended usage: Common

   Author/Change controller: IETF

8.3.  Content Encoding Algorithm Registration Request

   Values of Content Encoding Algorithms are subject to IANA
   registration.  The value of Content Encoding Algorithm is a numeric
   non-negative index.  In this document, the range of values for
   Content Encoding Algorithms is 0 to 255.  This specification already
   assigns the values 0, 1, 2 and 3 as described in section 3.4.3.

8.3.1.  Explicit IANA Assignment Guidelines

   This document defines a name-space called "Content Encoding
   Algorithms".

   IANA has established and manages the new registry for the "FLUTE
   Content Encoding Algorithm" name-space.  The values that can be
   assigned within this name-space are numeric indexes in the range [0,
   255], boundaries included.  Assignment requests are granted on a
   "Specification Required" basis as defined in RFC 2434
   [RFC.Guidelines-Iana-Section].  Note that the values 0, 1, 2 and 3 of
   this registry are already assigned by this document as described in
   section 3.4.3.



Paila, et al.            Expires August 7, 2011                [Page 34]

Internet-Draft                    FLUTE                    February 2011


8.4.  Registration of EXT_FDT LCT Header Extension Type

   This document registers value 192 for the EXT_FDT LCT Header
   Extension defined in Section 3.4.1.

8.5.  Registration of EXT_CENC LCT Header Extension Type

   This document registers value 193 for the EXT_CENC LCT Header
   Extension defined in Section 3.4.3.


9.  Acknowledgements

   The following persons have contributed to this specification: Brian
   Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
   Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson.  The authors
   would like to thank all the contributors for their valuable work in
   reviewing and providing feedback regarding this specification.


10.  Contributors

   Jani Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere FIN-33101
   Finland
   Email: jani.peltotalo (at) tut.fi

   Sami Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere FIN-33101
   Finland
   Email: sami.peltotalo (at) tut.fi

   Magnus Westerlund
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm
   Sweden
   EMail: magnus.westerlund (at) ericsson.com

   Thorsten Lohmar
   Ericsson Research (EDD)
   Ericsson Allee 1
   52134 Herzogenrath, Germany
   EMail: thorsten.lohmar (at) ericsson.com



Paila, et al.            Expires August 7, 2011                [Page 35]

Internet-Draft                    FLUTE                    February 2011


11.  Change Log

11.1.  RFC3926 to draft-ietf-rmt-flute-revised-12

   Incremented FLUTE protocol version from 1 to 2, due to IESG concerns
   about backwards compatibility.

   Updated dependencies to other RFCs to revised versions, e.g., changed
   ALC reference from RFC 3450 to RFC 5775, changed LCT reference from
   RFC 3451 to RFC 5651, etc.

   Two additional items are added in the IANA considerations section,
   specifically the registration of two values in the LCT Header
   Extension Types registry (192 for EXT_FDT and 193 for EXT_CENC).

   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 an out-of-band delivery of FDT information.

   Clarified how to address FDT Instance expiration time wraparound with
   the notion of "epoch" of NTPv4 in Section 3.3.

   Clarified what should be considered as 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 the security section to define IPsec/ESP as a mandatory to
   implement security solution in Section 7.5.

   Removed the 'Statement of Intent' from the Section 1.  The statement
   of intent was meant to clarify the "Experimental" status of RFC3926.
   It does not apply to this draft that is intended for "Standard Track"
   submission.

   Added clarification on XML-DSIG in the end of Section 3.

   Revised the use of word "complete" in the Section 3.2.

   Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance".

   Clarified the FDT Instance ID wrap-around in the end of
   Section 3.4.1.

   Clarification for "Complete FDT" in the Section 3.4.2.




Paila, et al.            Expires August 7, 2011                [Page 36]

Internet-Draft                    FLUTE                    February 2011


   Added semantics for the case two TOIs refer to same Content-Location.
   Now it is in line how 3GPP and DVB interpret the case.

   In the Section 3.4.2 XML Schema of FDT instance is modified to
   various advices.  For example, extension by element was missing but
   is now supported.  Also namespace definition is changed to URN
   format.

   Clarified FDT-schema extensibility in the end of Section 3.4.2.

   The CENC value allocation is added in the end of Section 3.4.3.

   Section 5 is modified so that EXT_FTI and the FEC issues are replaced
   by a reference to LCT specification.  We count on revised LCT
   specification to specify the EXT_FTI.

   Added a clarifying paragraph on the use of Codepoint in the very end
   of Section 5.

   Reworked Section 8 - IANA Considerations.  Now it contains three IANA
   registration requests:

   *  Registration Request for XML Schema of FDT Instance
      (urn:ietf:params:xml:schema:fdt)

   *  Media-Type Registration Request for application/fdt+xml

   *  Content Encoding Algorithm Registration Request (ietf:rmt:cenc)

   Added Section 10 - Contributors.

   Revised list of both Normative as well as Informative references.

   Added a clarification that receiver should ignore reserved bits of
   Header Extension type 193 upon reception.

   Minor changes to remove forward references (use before definition) or
   refer to forward reference sections.

   Elaborate on just what kind of networks cannot support FLUTE
   congestion control (1.1.4)

   In Section 3.2 revise "several" (meaning 3-n vs. "couple" = 2) to
   "multiple" (meaning 2-n)

   Move Section 3.3 requirement to send FDT more reliably than files, to
   a bulleted RECOMMENDED requirement, making check-off easier for
   testers.



Paila, et al.            Expires August 7, 2011                [Page 37]

Internet-Draft                    FLUTE                    February 2011


   Sharpen Section 3.3 definition that future FDT file instances can
   "augment" (meaning enhance) rather than "complement" (sometimes
   meaning negate, which is not allowed) the file parameters.

   Elaborate in Section 3.3 and Section 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.

   Require in Section 3.3 that FLUTE receivers SHALL NOT attempt to
   decode FDTs if they do not understand the FEC Encoding ID

   Remove restriction of Section 3.3 in bullet #4 that TOI=0 for the
   FDT, to be consistent with Appendix, bullet 6, and elsewhere.  An FDT
   is signaled by an FDT Instance ID, NOT only by TOI = 0.

   Standardize on the term "expiration time" and avoid using the
   redundant but possibly confusing term "expiry time".

   To interwork with experimental flute, stipulate 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 mention in
   Section 6 that you may (optionally) derive the FLUTE version from the
   file delivery session description.

   Use a software writing tool to lower reading grade level and simplify
   Section 3.1.


12.  References

12.1.  Normative references

   [RFC.2119]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [ID.ALC-revised]
              Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              April 2010.

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

   [RFC.FECSchemes]



Paila, et al.            Expires August 7, 2011                [Page 38]

Internet-Draft                    FLUTE                    February 2011


              Watson, M., "Basic Forward Error Correction (FEC)
              Schemes", RFC 5445, March 2009.

   [RFC.NTP]  Mills, D., "Network Time Protocol (Version 3),
              Specification, Implementation and Analysis", RFC 1305,
              March 1992.

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

   [XML-Schema-Part-1]
              Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
              "XML Schema Part 1: Structures", W3C Recommendation,
              May 2001.

   [XML-Schema-Part-2]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
              W3C Recommendation, May 2001.

   [RFC.XML-Media-Types]
              Murata, M., St.Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC.UTF8]
              Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 3629, November 2003.

   [RFC.Guidelines-Iana-Section]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, May 2008.

   [RFC.ZLIB]
              Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC.DEFLATE]
              Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

   [RFC.GZIP]
              Deutsch, P., "GZIP file format specification version 4.3",
              RFC 1952, May 1996.

   [RFC.3738]
              Luby, M. and V. Goyal, "Wave and Equation Based Rate
              Control (WEBRC) Building Block", RFC 3738, April 2004.



Paila, et al.            Expires August 7, 2011                [Page 39]

Internet-Draft                    FLUTE                    February 2011


   [RFC.4303]
              Kent, S., "Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5651]  Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block", RFC 5651, October 2009.

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.

   [RFC.SAP]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC.SDP]  Handley, M., Jacobson, V., and C. Perkins, "Session
              Description Protocol", RFC 4566, July 2006.

   [RFC.ASM]  Deering, S., "Host Extensions for IP Multicasting",
              RFC 1112, STD 5, August 1989.

   [PAPER.SSM]
              Holbrook, H., "A Channel Model for Multicast, Ph.D.
              Dissertation, Stanford University, Department of Computer
              Science, Stanford, California", August 2001.

   [NTPv4]    Kasch, W., Mills, D., and J. Burbank, "Network Time
              Protocol Version 4 Protocol And Algorithms Specification",
              draft-ietf-ntp-ntpv4-proto-13 (work in progress) (work in
              progress), October 2009.

   [RFC.3365]
              Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, August 2002.

   [RFC.SMIME]
              Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC.XML-DSIG]
              Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC.MIME4a]



Paila, et al.            Expires August 7, 2011                [Page 40]

Internet-Draft                    FLUTE                    February 2011


              Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [RFC.MIME4b]
              Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              RFC 4289, December 2005.

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

   [RFC.3688]
              Mealling, M., "The IETF XML Registry", RFC 3688,
              January 2004.

   [RFC.3447]
              Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC.2104]
              Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC.4082]
              Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe,
              "Timed Efficient Stream Loss-Tolerant Authentication
              (TESLA): Multicast Source Authentication Transform
              Introduction", RFC 4082, June 2005.

   [MSEC-TESLA]
              Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in
              the ALC and NORM Protocols",
               draft-ietf-msec-tesla-for-alc-norm-10.txt (work in
              progress), October 2009.

   [RMT-SIMPLE-AUTH]
              Roca, V., "Simple Authentication Schemes for the ALC and
              NORM Protocols",
               draft-ietf-rmt-simple-auth-for-alc-norm-02.txt (work in
              progress), October 2009.







Paila, et al.            Expires August 7, 2011                [Page 41]

Internet-Draft                    FLUTE                    February 2011


Appendix A.  Receiver operation (informative)

   This section gives an example 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 pair: (source IP address, Transport Session
       Identifier).  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, 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.  Receiver recovers an object.  An object can be recovered when an
       appropriate set of packets containing Encoding Symbols for the
       transmission object have 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 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
       length matches with the description in the database.  Optionally,
       if MD5 checksum has been used, the receiver checks that the



Paila, et al.            Expires August 7, 2011                [Page 42]

Internet-Draft                    FLUTE                    February 2011


       calculated MD5 matches the description in the FDT database.

   8.  The actions the receiver takes with imperfectly received files
       (missing data, mismatching digestive, etc.) is 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 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>


Authors' Addresses

   Toni Paila
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Email: toni.paila@nokia.com







Paila, et al.            Expires August 7, 2011                [Page 43]

Internet-Draft                    FLUTE                    February 2011


   Rod Walsh
   Nokia
   Visiokatu 1
   Tampere  FIN-33720
   Finland

   Email: rod.walsh@nokia.com


   Michael Luby
   Qualcomm, Inc.
   3165 Kifer Rd.
   Santa Clara, CA  95051
   US

   Email: luby@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
   Hatanpaan valtatie 18
   Tampere  FIN-33100
   Finland

   Email: rami.lehtonen@teliasonera.com
















Paila, et al.            Expires August 7, 2011                [Page 44]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/