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

Versions: 00 01 02 03 04 05 06 07 08 RFC 3926

RMT                                                             T. Paila
Internet-Draft                                                     Nokia
Expires: January 30, 2004                                        M. Luby
                                                        Digital Fountain
                                                             R. Lehtonen
                                                             TeliaSonera
                                                                 V. Roca
                                                       INRIA Rhone-Alpes
                                                             August 2003


          FLUTE - File Delivery over Unidirectional Transport
                      draft-ietf-rmt-flute-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 30, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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.




Paila, et al.           Expires January 30, 2004                [Page 1]


Internet-Draft                   FLUTE                       August 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Conventions used in this document  . . . . . . . . . . . . .  4
   3.    File delivery  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1   File delivery session  . . . . . . . . . . . . . . . . . . .  5
   3.2   File Delivery Table  . . . . . . . . . . . . . . . . . . . .  6
   3.3   Dynamics of FDT Instances within file delivery session . . .  8
   3.4   Structure of FDT Instance  . . . . . . . . . . . . . . . . .  9
   3.4.1 Format of FDT Instance Header  . . . . . . . . . . . . . . . 10
   3.4.2 Syntax of FDT Instance Payload . . . . . . . . . . . . . . . 10
   3.5   Multiplexing of files within a file delivery session . . . . 12
   4.    Channels, congestion control and timing  . . . . . . . . . . 13
   5.    Delivering FEC Object Transmission Information . . . . . . . 14
   5.1   Use of EXT_FTI for delivery of FEC Object Transmission
         Information  . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.1.1 General EXT_FTI format . . . . . . . . . . . . . . . . . . . 14
   5.1.2 FEC Encoding ID specific formats for EXT_FTI . . . . . . . . 15
   5.2   Use of FDT for delivery of FEC Object Transmission
         Information  . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.    Describing file delivery sessions  . . . . . . . . . . . . . 19
   7.    Security considerations  . . . . . . . . . . . . . . . . . . 20
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
         Normative references . . . . . . . . . . . . . . . . . . . . 23
         Informative references . . . . . . . . . . . . . . . . . . . 24
   A.    Receiver operation (informative) . . . . . . . . . . . . . . 26
   B.    Example of FDT Instance Payload (informative)  . . . . . . . 28
         Intellectual Property and Copyright Statements . . . . . . . 29






















Paila, et al.           Expires January 30, 2004                [Page 2]


Internet-Draft                   FLUTE                       August 2003


1. Introduction

   This document defines FLUTE, a protocol for unidirectional delivery
   of files over the Internet.  The specification builds on Asynchronous
   Layered Coding (ALC), version 1 [3], 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 do the objects actually represent.  This document specifies
   a technique called FLUTE - a mechanism for signalling 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 specification answers the following questions:

   *  How does an ALC session represent a file delivery session?

   *  How can the properties of delivered files be signaled in-band
      within the file delivery session?

   *  How to describe the file delivery session, its transport details
      and its schedule in a general case?

   *  What is the internal structure of file delivery sessions wherein
      several files can be delivered within a single session?

   This specification is structured as follows.  Chapter 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
   transport objects within a file delivery session.  Chapter 4
   describes the use of congestion control and channels with FLUTE.
   Chapter 5 defines how the FEC Object Transmission Information is to
   be delivered within a file delivery session.  Chapter 6 defines the
   required parameters for describing file delivery sessions in a
   general case.  Chapter 7 outlines security considerations regarding
   file delivery with FLUTE.  Last, there are two informative
   appendixes.  The first appendix gives an example of File Delivery
   Table.  The second appendix describes an envisioned receiver
   operation for the receiver of the file delivery session.







Paila, et al.           Expires January 30, 2004                [Page 3]


Internet-Draft                   FLUTE                       August 2003


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 [2].














































Paila, et al.           Expires January 30, 2004                [Page 4]


Internet-Draft                   FLUTE                       August 2003


3. File delivery

   Asynchronous Layered Coding 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.

   In this specification the above-mentioned arbitrary binary objects
   are 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 file referred by "www.ex.com/docs/
   file.txt".  Using the example, the following properties describe the
   properties that need to be conveyed by the file delivery protocol.

   *  Location of the file, expressed as either absolute or relative
      URL.  In the above example: "www.ex.com/docs/file.txt"

   *  File name (usually, this can be concluded from the URL).  In the
      above example: "file.txt"

   *  File type, expressed as MIME media type (usually, this can also be
      concluded from the extension of the file name).  In the above
      example: "text/plain"

   *  File size, expressed as bytes.  In the above example (imaginary):
      "5200"

   *  Content encoding of the file, within transport.  In the above
      example, the file could be encoded using ZLIB [10].

   *  Security properties of the file such as digital signatures,
      message digestives, etc.


3.1 File delivery session

   ALC is a protocol instantiation of Layered Coding Transport building
   block (LCT) [4].  Thus ALC inherits the session concept of LCT.  In
   this document we will use 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 packets with ALC/LCT
   headers 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



Paila, et al.           Expires January 30, 2004                [Page 5]


Internet-Draft                   FLUTE                       August 2003


   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 TSI is scoped by the source IP
   address, and the (source IP address, TSI) pair uniquely identifies a
   session, i.e., the receiver uses this pair carried in each packet to
   uniquely identify from which session the packet was received.  In
   case multiple objects are carried within a session another field
   within the ALC/LCT header, the Transport Object Identifier (TOI),
   identifies from which object within the session the data in the
   packet was generated.  Note that each object is associated with a
   unique TOI within the scope of a session.

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

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

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

   *  The TOI field MUST be used in ALC/LCT packets.

   *  The TOI value '0' is reserved for delivery of File Delivery Table

   *  Each file in a file delivery session MUST be associated with a TOI
      (>0) in the scope of that session.


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.  Such attributes are for example the
   following.

   Attributes related to the delivery of file:

   -  TOI value that represents the file

   -  FEC Instance ID

   -  FEC Object Transmission Information

   -  Aggregate rate of sending packets to all channels

   Attributes related to the file itself:



Paila, et al.           Expires January 30, 2004                [Page 6]


Internet-Draft                   FLUTE                       August 2003


   -  Location of file

   -  Name of file

   -  MIME media type of file

   -  Size of file

   -  Encoding of file

   -  Message digest of file

   Some of these attributes are mandatory, others optional, as defined
   in section 3.4.2.

   Logically, the FDT is a set of file description entries.  Each file
   description entry is identified by a unique identifier in the given
   session.  In FLUTE, this identifier is the TOI of an instance of the
   file.  Each file description entry consequently contains one or more
   descriptors that map the above-mentioned attributes to the identified
   file.  At minimum the mapping from TOI to URL value MUST be given.

   Each file delivery session MUST have an FDT that is local to the
   given session.  The FDT SHOULD provide mapping for every TOI
   appearing within the session.  Handling of unmapped TOIs (those 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, or complement any other FDT Instance.  A certain FDT
   Instance may be repeated several times during a session, even after
   subsequent FDT Instances (with higher FDT Instance ID numbers) have
   been transmitted.  In minimum the FDT Instance contains a single file
   description entry.  In maximum the FDT Instance contains the complete
   FDT of 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 FDT database is an abstract concept, the structure and the
   maintaining of the FDT database are left to individual



Paila, et al.           Expires January 30, 2004                [Page 7]


Internet-Draft                   FLUTE                       August 2003


   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:

   *  Within a file delivery session, the complete FDT MUST be sent at
      least once.  The complete FDT is defined as an FDT that has file
      description entry for every file sent within the file delivery
      session.  In minimum, each file description entry contains the
      mapping to TOI and the URL.

   *  An FDT Instance MAY appear in any part of the file delivery
      session and even multiplexed with other files or other FDT
      Instances.

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

   *  FDT Instance is identified by the use of a new fixed length LCT
      Header Extension EXT_FDT (defined later in this chapter).  Each
      FDT Instance is uniquely identified within the file delivery
      session by its FDT Instance ID.  Any ALC/LCT packet carrying FDT
      Instance (indicated by TOI = 0) MUST include EXT_FDT.

   *  It is RECOMMENDED that FDT Instance that contains the file
      description entry for a file is sent prior to the sending of the
      described file within a file delivery session.

   *  Within a file delivery session, any TOI 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 to include it, complement the
      description or modify the description.  In the last case the
      receiver interpretation of such a situation is specific to
      implementation and therefore is left out of scope of this
      specification.

   *  An FDT Instance is valid until its expiration time.  The expiry
      time is expressed within the FDT Instance payload as a 32 bit
      Network Time Protocol (NTP) time value in seconds.

   *  The receiver behaviour upon expiration of the FDT Instance is out
      of scope of this specification.





Paila, et al.           Expires January 30, 2004                [Page 8]


Internet-Draft                   FLUTE                       August 2003


   *  A sender MUST use an expiry time in the future upon creation of an
      FDT Instance.

   *  Any FEC Encoding ID MAY be used for the sending of FDT Instances.
      The default is to use FEC Encoding ID 0 for the sending of FDT
      Instances.


3.4 Structure of FDT Instance

   The FDT Instance consists of two parts: FDT Instance Header and FDT
   Instance Payload.  The FDT Instance Header is a new fixed length LCT
   Header extension (EXT_FDT).  It 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 LCT extension headers are followed by the FEC Payload ID, and
   finally the FDT Instance Payload which contains one or more file
   description entries.  The FDT Instance Payload MAY span over several
   ALC packets - the number of ALC packets is indicated by the FEC
   Object Transmission Information associated to this FDT Instance.  The
   FDT Instance Header is carried in each ALC packet carrying FDT
   Instance.  The FDT Instance Header is identical for all the ALC/LCT
   packets carrying parts of a particular FDT Instance.

   The overall format of ALC/LCT packets carrying FDT Instance is
   depicted in the Figure 1  below.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         UDP header                            |
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                     Default LCT header                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          LCT header extensions (EXT_FDT, EXT_FTI, etc.)       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       FEC Payload ID                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Encoding Symbol(s) of FDT Instance Payload            |
   |                           ...                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1 - Overall FDT Packet



Paila, et al.           Expires January 30, 2004                [Page 9]


Internet-Draft                   FLUTE                       August 2003


3.4.1 Format of FDT Instance Header

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


   FDT Instance ID, 24 bits:

   For each file delivery session the numbering of FDT Instances starts
   from '0' and is incremented by exactly one for each subsequent FDT
   Instance.  After reaching the maximum value (2^24-1), the numbering
   starts again from '0'.  When wraparound from 2^24-1 to 0 occurs, 0 is
   considered higher than 2^24-1.  Receiver handling of wraparound and
   other special situations (for example, missing FDT Instance IDs
   resulting in longer increments than one) is left out of this
   specification to individual implementations of FLUTE.

3.4.2 Syntax of FDT Instance Payload

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

   The FDT Instance Payload is an XML structure that has a single root
   element "FDT-Payload".  The "FDT-Payload" element MUST contain
   "Expires" attribute, which tells the expiry time of the FDT Instance
   Payload.  In addition, the "FDT-Payload" element MAY contain
   "Complete" attribute (boolean), which MAY be used to signal that the
   given FDT Instance is the last FDT Instance to be expected on this
   file delivery session.  For each file to be declared in the given FDT
   Instance there is a single file description entry in the FDT Instance
   Payload.  Each entry is represented by element "File" which is a
   child element of the FDT Payload 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.  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 URL as defined in [6].




Paila, et al.           Expires January 30, 2004               [Page 10]


Internet-Draft                   FLUTE                       August 2003


   In addition to mandatory attributes, the "File" entity MAY contain
   other attributes of which the following are specifically pointed out.

   *  If the MIME type of the file is described, attribute
      "Content-Type" MUST be used for the purpose as defined in [6].

   *  If the length of the file is described, attribute "Content-Length"
      MUST be used for the purpose as defined in [6].  Note that
      Content-Length describes the transferred object length, not the
      actual file size after decoding.  If the actual size of the file
      length without any content encoding is described, attribute
      "Entity-Length" (value in bytes) MUST be used.

   *  If the encoding scheme of the file is described, attribute
      "Content-Encoding" MUST be used for the purpose as defined in [6].

   *  If the MD5 message digest of the file is described, attribute
      "Content-MD5" MUST be used for the purpose as defined in [6].

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

   The following specifies the XML Schema [8][9] for FDT Instance
   Payload:


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns:fl="http://www.example.com/flute" elementFormDefault:xs="qualified" targetNamespace:xs="http://www.example.com/flute">
     <xs:element name="FDT-Payload">
      <xs:complexType>
       <xs:attribute name="Expires" type="xs:string" use="required"/>
       <xs:attribute name="Complete" type="xs:boolean" use="optional"/>
       <xs:sequence>
        <xs:element name="File" maxOccurs="unbounded">
         <xs:complexType>
          <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="Entity-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"



Paila, et al.           Expires January 30, 2004               [Page 11]


Internet-Draft                   FLUTE                       August 2003


                        type="xs:base64Binary" use="optional"/>
          <xs:attribute name="FEC-OTI-FEC-Instance-ID"
                        type="xs:unsignedLong" use="optional"/>
          <xs:attribute name="FEC-OTI-Source-Block-Length"
                        type="xs:unsignedLong" use="optional"/>
          <xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
                        type="xs:unsignedLong" use="optional"/>
          <xs:attribute name="FEC-OTI-Max-Number-of-Data-Symbols-per-Block"
                        type="xs:unsignedLong" use="optional"/>
          <xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
                        type="xs:unsignedLong" use="optional"/>
          <xs:anyAttribute processContents="skip" />
         </xs:complexType>
        </xs:element>
       </xs:sequence>
      </xs:complexType>
     </xs:element>
   </xs:schema>

   Any XML document that conforms with the above XML Schema is a valid
   FDT.  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, those MUST be placed within the attributes of the
   element "File".  It is RECOMMENDED that the new descriptors applied
   in the FDT are in the format of MIME fields and are either defined in
   HTTP/1.1 specification [6] or otherwise well-known specification.

3.5 Multiplexing of files within a file delivery session

   The delivered files appear as objects (identified with TOIs) within
   the file delivery session.  All the objects, including the FDT
   Instances,  MAY be multiplexed in any order and in parallel with each
   other.

   Especially multiple FDT Instances MAY be delivered during the session
   in a particular TOI.  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 the FDT Instances MAY be multiplexed packetwise.  In that
   case, the FDT Instances are uniquely identified by their FDT Instance
   ID carried in the EXT_FDT headers.






Paila, et al.           Expires January 30, 2004               [Page 12]


Internet-Draft                   FLUTE                       August 2003


4. Channels, congestion control and timing

   ALC/LCT has a concept of channels and congestion control.  There are
   four scenarios FLUTE is envisioned to be applied.

   (a) Use a single channel and a single-rate congestion control
      protocol.

   (b) Use 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 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 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, like 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, like 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 object must complete 'prior' to
   the second one, it is RECOMMENDED that only a single channel is used
   for the file delivery session.















Paila, et al.           Expires January 30, 2004               [Page 13]


Internet-Draft                   FLUTE                       August 2003


5. Delivering FEC Object Transmission Information

   FLUTE inherits the use of FEC building block [5] 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.  In this chapter, two methods are specified for FLUTE for
   this purpose: the use of ALC specific LCT extension header EXT_FTI
   [3], and, the use of FDT.

   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
   either method MAY be applied: the use of EXT_FTI and the use of 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 prioritizes 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.

   3.  FEC Object Transmission Information that is available out of
      band.


5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information

   As specified in [3], the EXT_FTI header extension is intended to
   carry in band the FEC Object Transmission Information for an object.
   It is left up to individual implementations to decide how frequently
   and in which ALC packets the EXT_FTI header extension occurs.

   The ALC specification does not define the format or the processing of
   the EXT_FTI header extension.  The following sections specify EXT_FTI
   when used in FLUTE.

   In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint
   field of the ALC/LCT header.

5.1.1 General EXT_FTI format

   The general EXT_FTI format specifies the structure and those
   attributes of FEC Object Transmission Information that are applicable
   to any FEC Encoding ID.





Paila, et al.           Expires January 30, 2004               [Page 14]


Internet-Draft                   FLUTE                       August 2003


    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 = 64    |     HEL       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                         Object Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   FEC Instance ID             | FEC Enc. ID Specific Format   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Header Extension Type (HET), 8 bits:

   64 as defined in [3]

   Header Extension Length (HEL), 8 bits:

   The length of the whole Header Extension field, expressed in
   multiples of 32-bit words.  This length includes the FEC Encoding ID
   specific format part.

   Object Length, 48 bits:

   As specified in [3].  The length of the object in bytes.

   FEC Instance ID, optional, 16 bits:

   This field is used for FEC Instance ID.  It is only present if the
   value of FEC Encoding ID is in the range of 128-255.  When the value
   of FEC Encoding ID is in the range of 0-127, this field is set to 0.

   FEC Encoding ID Specific Format:

   Different FEC encoding schemes will need different sets of encoding
   parameters.  Thus, the structure and length of this field depends on
   FEC Encoding ID.  The next sections specify structure of this field
   for FEC Encoding ID numbers 0, 128, 129 and 130.






5.1.2 FEC Encoding ID specific formats for EXT_FTI

5.1.2.1 FEC Encoding IDs 0, 128, and 130

   FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7].
   FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC'



Paila, et al.           Expires January 30, 2004               [Page 15]


Internet-Draft                   FLUTE                       August 2003


   (Under-Specified) [5].  FEC Encoding ID 130 is 'Compact FEC'
   (Under-Specified) [7].  For these FEC Encoding IDs, the FEC Encoding
   ID specific format of EXT_FTI is defined as follows.

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      General EXT_FTI format       |    Encoding Symbol Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source Block Length                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Encoding Symbol Length, 16 bits:

   Length of encoding symbol in bytes.

   Source Block Length, 32 bits

   The number of source symbols in a full-sized source block.  In this
   EXT_FTI specification, it is assumed that:

   1.  All source blocks MUST have a predictable size.  The blocking
      scheme is defined by an algorithm shared by the source and the
      receivers, and the information contained in the EXT_FTI.  The
      blocking scheme is outside the scope of this document.  Yet an
      example is to have all blocks the same size 'Source Block Length',
      except perhaps the last two blocks whose size is shorter when the
      total 'Object Length' is not a multiple of 'Source Block Length'
      times 'Encoding Symbol Length'.  The advantage of this blocking
      scheme is that no block is shorter than half the 'Source Block
      Length'.

   2.  All source symbols of all source blocks are of the same size,
      except perhaps some of them.  This size MUST be predictable and
      only depends on the blocking algorithm and the information
      contained in the EXT_FTI.  For instance, the last symbol of a
      block can be shorter when the block size in bytes is not a
      multiple of the symbol size.

   3.  The size of a full-sized source symbol is equal to the size of an
      encoding symbol.


5.1.2.2 FEC Encoding ID 129

   Small Block Systematic FEC (Under-Specified).  The FEC Encoding ID
   specific format of EXT_FTI is defined as follows.




Paila, et al.           Expires January 30, 2004               [Page 16]


Internet-Draft                   FLUTE                       August 2003


    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      General EXT_FTI format       |  Max. Data Symbols per Block  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Max. Num. of Encoding Symbols |   Encoding Symbol Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Maximum Number of Data Symbols per Block, 16 bits:

   Indicates the current maximum number of user data segments per FEC
   coding block to be used by the sender during the session.

   Maximum Number of Encoding Symbols, 16 bits:

   Maximum number of encoding symbols that can be generated for a source
   block.

   Encoding Symbol Length, 16 bits:

   Length of encoding symbol in bytes.

5.2 Use of FDT for delivery of FEC Object Transmission Information

   The receiver of file delivery session MAY support delivery of FEC
   Object Transmission Information using FDT.  In that case the
   following attributes within the "File" element of the FDT structure
   MUST be used when applicable.  If the listed attributes do not
   fulfill the needs of describing the FEC Object Transmission
   Information, additional new attributes MAY be used.

   *  "Content-Length" is semantically equivalent with the field "Object
      Length" of EXT_FTI.

   *  "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the
      field "FEC Instance ID" of EXT_FTI.

   *  "FEC-OTI-Source-Block-Length" is semantically equivalent with the
      field "Source Block Length" of EXT_FTI for FEC Encoding IDs 0, 128
      and 130.

   *  "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with
      the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs
      0, 128, 129 and 130.

   *  "FEC-OTI-Max-Number-of-Data-Symbols-per-Block" is semantically
      equivalent with the field "Maximum Number of Data Symbols per
      Block" of EXT_FTI for FEC Encoding ID 129.



Paila, et al.           Expires January 30, 2004               [Page 17]


Internet-Draft                   FLUTE                       August 2003


   *  "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically
      equivalent with the field "Maximum Number of Encoding Symbols" of
      EXT_FTI for FEC Encoding ID 129.
















































Paila, et al.           Expires January 30, 2004               [Page 18]


Internet-Draft                   FLUTE                       August 2003


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 on the receiver operation falls into the scope
   of this specification.  According to [3], the transport parameters of
   an ALC/LCT session that the receiver needs to know are:

   *  The sender IP address;

   *  The number of channels in the session;

   *  The destination IP address and port number for each channel in the
      session;

   *  The Transport Session Identifier (TSI) of the session;

   *  An indication of whether or not the session carries 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;

   *  Compression format if optional compression of FDT Instance Payload
      is used;

   *  The FEC Object Transmission Information when this information is
      neither available in the EXT_FTI nor FDT as described in section
      5.

   *  Some information that tells receiver, in the first place, that the
      session contains files that are of interest

   How the receiver acquires the above-mentioned parameters is out of
   scope of this document.  The specification, in particular, does not
   mandate or exclude any mechanism.  The description can be conveyed to
   the receiver via techniques such as Session Announcement Protocol
   [11], email, accessing URL, manual configuration, etc.  Similarly the
   format of this session description is out of the scope of this
   document.





Paila, et al.           Expires January 30, 2004               [Page 19]


Internet-Draft                   FLUTE                       August 2003


7. Security considerations

   There is a risk of forged file delivery sessions.  A malicious
   attacker may spoof file delivery (ALC/LCT) packets in order to
   initiate an attack.  The attacker may have several objectives he or
   she wishes to achieve, like Denial of Service (DoS).  The following
   are the most obvious risks, however not exhaustive.

   The attacker can focus on the FDT information, sending forged packets
   with erroneous FDT-Payload fields.  Many attacks can follow this
   approach.  For instance a malicious attacker may alter the
   Content-Location field of TOI 'n', to make it point to a system file
   or a user configuration file.  Then, TOI 'n' can carry a Trojan horse
   or some other type of virus.  Another example is generating a bad
   Content-MD5 sum, leading receivers to reject the associated file that
   will be declared corrupted.  The Content-Encoding can also be
   modified, which also prevents the receivers to correctly handle the
   associated file.

   These examples show that the FDT information is critical to the FLUTE
   delivery service.  It is therefore highly RECOMMENDED that the FDT
   information be protected by the appropriate security measures.  For
   instance TESLA [13] can be used for authenticating the FDT source,
   along with the other packets exchanged during the ALC/LCT session.
   In some cases a group authentication service can be sufficient.  In
   that case, simple and efficient cryptographic transforms can then be
   used [12].  The FDT content may also be digitally signed, which
   provides both source authentication and packet integrity.  This is
   feasible if the FDT packet rate is kept sufficiently low (generating/
   verifying digital signatures are computationally demanding tasks).
   In that case, the number of signature verifications at a receiver
   should be rate limited in order to prevent DoS attacks consisting in
   sending a high number of forged FDT packets.  Finally it is
   RECOMMENDED that the FLUTE delivery service does not have write
   access to the system files or directories, or any other critical
   areas.

   An attacker can also eavesdrop on the FLUTE session.  Packets
   containing the FDT information are critical from that point of view
   since they contain information on the session content.  When this is
   an issue it is RECOMMENDED that the FDT packets be encrypted (as well
   as the data packets) using a confidentiality service.  The MSEC IETF
   Working Group defines security transforms, Group Key Management and
   Group Security Associations building blocks that can be used to that
   purpose.

   A difficulty is the unidirectional feature of FLUTE.  Many protocols
   providing application-level security are based on bidirectional



Paila, et al.           Expires January 30, 2004               [Page 20]


Internet-Draft                   FLUTE                       August 2003


   communications.  The application of these security protocols in case
   of strictly unidirectional links is not considered in the present
   document.

   In addition to the attacks on the FDT information, FLUTE is subject
   to attacks on the ALC/LCT session itself.  Therefore, the security
   considerations of [3] and [4] also apply to FLUTE.












































Paila, et al.           Expires January 30, 2004               [Page 21]


Internet-Draft                   FLUTE                       August 2003


8. Acknowledgements

   The following persons have contributed to this specification: Rod
   Walsh, Juha-Pekka Luoma, Esa Jalonen, Sami Peltotalo, Jani Peltotalo
   and Brian Adamson.  The authors would like to thank all the
   contributors for their valuable work in reviewing and providing
   feedback regarding this specification.












































Paila, et al.           Expires January 30, 2004               [Page 22]


Internet-Draft                   FLUTE                       August 2003


Normative references

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        2026, BCP 9, October 1996.

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

   [3]  Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
        "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
        3450, December 2002.

   [4]  Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
        "Layered Coding Transport (LCT) Building Block", RFC 3451,
        December 2002.

   [5]  Luby, M., Gemmel, J., Vicisano, L., Rizzo, L., Crowcroft, J. and
        M. Handley, "Forward Error Correction (FEC) Building Block", RFC
        3452, December 2002.

   [6]  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.

   [7]  Luby, M. and L. Vicisano, "Compact Forward Error Correction
        (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in
        progress), May 2003.

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

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


















Paila, et al.           Expires January 30, 2004               [Page 23]


Internet-Draft                   FLUTE                       August 2003


Informative references

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

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

   [12]  Hardjono, T. and B. Weis, "The Multicast Security
         Architecture", draft-ietf-msec-arch-01 (work in progress), May
         2003.

   [13]  Perrig, A., Canetti, R., Song, D., Tygar, D. and B. Briscoe,
         "TESLA: Multicast Source Authentication Transform
         Introduction", draft-ietf-msec-tesla-intro-01 (work in
         progress), October 2002.


Authors' Addresses

   Toni Paila
   Nokia
   Itamerenkatu 11-13
   Helsinki  FIN-00180
   Finland

   EMail: toni.paila@nokia.com


   Michael Luby
   Digital Fountain
   39141 Civic Center Dr.
   Suite 300
   Fremont, CA  94538
   USA

   EMail: luby@digitalfountain.com


   Rami Lehtonen
   TeliaSonera
   Hatanpaan valtatie 18
   Tampere  FIN-33100
   Finland

   EMail: rami.lehtonen@teliasonera.com





Paila, et al.           Expires January 30, 2004               [Page 24]


Internet-Draft                   FLUTE                       August 2003


   Vincent Roca
   INRIA Rhone-Alpes
   655, av. de l'Europe
   Montbonnot
   St Ismier cedex  38334
   France

   EMail: vincent.roca@inrialpes.fr











































Paila, et al.           Expires January 30, 2004               [Page 25]


Internet-Draft                   FLUTE                       August 2003


Appendix A. Receiver operation (informative)

   This chapter 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
      object have been received and the object can be recovered.  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.  If the recovered object was an FDT instance with FDT Instance ID
      'N', the receiver parses the payload of the instance 'N' of FDT
      and updates its FDT database accordingly.  The receiver identifies
      FDT instances within a file delivery session by the EXT_FDT header
      extension.  Any object that is delivered using EXT_FDT header
      extension is an FDT instance, uniquely identified by the FDT
      Instance ID.  Note that TOI '0' is exclusively reserved for FDT
      delivery.

   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 file with the given properties.  The
      receiver also checks that received content length matches with the



Paila, et al.           Expires January 30, 2004               [Page 26]


Internet-Draft                   FLUTE                       August 2003


      description in the database.  Optionally, if MD5 checksum has been
      used, the receiver checks that calculated MD5 matches with 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.






































Paila, et al.           Expires January 30, 2004               [Page 27]


Internet-Draft                   FLUTE                       August 2003


Appendix B. Example of FDT Instance Payload (informative)


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
































Paila, et al.           Expires January 30, 2004               [Page 28]


Internet-Draft                   FLUTE                       August 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Paila, et al.           Expires January 30, 2004               [Page 29]


Internet-Draft                   FLUTE                       August 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Paila, et al.           Expires January 30, 2004               [Page 30]


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