FLUTE (File Delivery over Unidirectional Transport - download delivery)
1). Protocol Study – FLUTE Overview
§ The most popular protocol for file delivery over IP multicast is the File Delivery over Unidirectional Transport (FLUTE) (RFC 3926) protocol for unidirectional delivery of files over the Internet
§ FLUTE has been adopted as the protocol for download delivery services in many broadcast technologies, as it is suited for one-to-many delivery over wireless broadcast radio systems.
§ FLUTE is applicable to the delivery of large and small files to many hosts using delivery sessions, and can be used with both multicast and unicast delivery, but it's primary application is for unidirectional multicast file delivery.
§ FLUTE requires connectivity between a sender and receivers in unidirection but does not require connectivity from receivers to a sender.
§ The purpose of FLUTE file delivery is to deliver content in files, and FLUTE is a protocol for the delivery of files, for example, images, documents, software, video, audio, and so on, enabling progressive as well as background download.
§ A file contains any type of data (e.g. Audio/Video file, Binary data, Still images, Text, ESG metadata).
§ Initially FLUTE was designed for transmission over the Internet on top of UDP/IP. FLUTE is carried over UDP/IP, and is independent of the IP version and the underlying link layers used. FLUTE is compatible with both IPv4 and IPv6, as no part of the packet is IP version specific.
2). Protocol Study – FLUTE: ALC (Asynchronous Layered Coding)
§ FLUTE builds on top of the Asynchronous Layered Coding (ALC) protocol instantiation - the base protocol designed for massively scalable multicast distribution. ALC provides the basic transport for FLUTE.
§ Asynchronous Layered Coding is a protocol designed for delivery of arbitrary binary objects. ALC is underspecified and used for transporting binary objects. It is especially suitable for massively scalable, unidirectional, multicast distribution.
§ These file-based operations are conducted using a File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) data carousel.
§ To deliver a file in a broadcast session, FLUTE provides mechanisms to signal and map the properties of a file to the Asynchronous Layered Coding (ALC) protocol such that receivers can assign these parameters to the received files.
3). Protocol Study – Building block structure of FLUTE (see Figure below)
http://docs.google.com/View?id=ddh56dhg_181g4qkbnf4
§ ALC combines the Layered Coding Transport (LCT) building block, a Congestion Control (CC) building block, and the Forward Error Correction (FEC) building block to provide congestion-controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender.
§ ALC uses the LCT building block to provide in-band session management functionality
§ ALC uses the FEC building block to provide reliability. This will reduce the error rate as seen by applications.
§ The use of CC and FEC building blocks with FLUTE is optional.
§ FLUTE inherits the use of FEC building block 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.
§ Two methods in this transmission are specified for FLUTE for this purpose:
- the use of ALC specific LCT extension header EXT_FTI and
- the use of FDT.
§ For simplicity of congestion control, all FLUTE channels shall be fully provisioned by the datacast operator so that no transport layer congestion control is necessary. FLUTE channelization may be provided by a single FLUTE channel.
Following properties and Example: conveyed by the file delivery protocol:
Example:
§ Identifier of the file - expressed as a URI. This identifier may be globally unique.
§ File name - can be concluded from the URI. In the above example:
§ File type - expressed as MIME media type - In the above example:
§ File size - expressed in bytes. In the above example:
§ Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB.
§ Security properties of the file such as digital signatures, message digests, etc. For example, one could use S/MIME as the content encoding type for files with this authentication wrapper, and one could use XML-DSIG to digitally sign an FDT Instance.
4). Protocol Study – ALC/LCT or FLUTE session
§ ALC is a protocol instantiation of Layered Coding Transport building block (LCT). ALC inherits the session concept of LCT.
§ A FLUTE session (i.e., an ALC/LCT session) consists of one or more ALC/LCT channels (a set of logically grouped ALC/LCT channels) associated with or defined by a single sender sending packets with ALC/LCT headers for one or more objects, and an address associated with the channel by the sender.
There are five types of file delivery sessions that are specified on the basis of FLUTE:
§ Static file delivery session.
§ Fixed content delivery session.
§ Dynamic file delivery session.
§ Static file delivery carousel.
§ Dynamic file delivery carousel.
5). Protocol Study – FLUTE Channel
§ An ALC/LCT channel defines by the combination of a sender and an address associated with the channel by the sender.
§ The use of single FLUTE channel for a FLUTE session shall be supported.
§ The use of multiple FLUTE channels for a FLUTE session may be supported by terminals and senders.
§ Spanning files over several file delivery sessions is not allowed.
§ For terminals that do not support multiple channels, it should be possible for them to receive enough data from the first channel named base FLUTE channel in order to declare the channel as complete, and shall ignore all but the base FLUTE channel declaration in the SDP session description file.
§ The base FLUTE channel is the channel for which the connection information appears first in the SDP session description file.
§ 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.
6). Protocol Study – FLUTE: FDT (File Delivery Table), FDT Header and Instance
6.1). FLUTE – FDT (File Delivery Table)
§ FLUTE is a fully specified protocol for transporting files and utilizes the File Delivery Table (FDT) to provide an index of files and the associated reception parameters in-band.
§ 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.
§ FDT is a set of file description entries for files to be delivered in the session.
§ Each file delivery session MUST have an FDT that is local to the given session.
6.2). FLUTE – ALC/LCT Header, TSI, and TOI in FDT (File Delivery Table)
§ TSI: One of the fields carried in the ALC/LCT header is the Transport Session Identifier.
§ The TSI is scoped by the source IP address, and the source IP address and TSI pair uniquely identifies a session.
§ TOI: In case multiple objects carries within a session, the Transport Object Identifier (TOI) field within the ALC/LCT header identifies from which object the data in the packet was generated.
§ Each object is associated with a unique TOI within the scope of a session.
§ Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file.
§ The FDT MUST provide a file description entry mapped to a TOI for each file appearing within the session.
6.3). FLUTE – FDT Instance and File Description Entry
§ An object that is delivered within the ALC session, but not described in the FDT, is not considered a 'file' belonging to the file delivery session.
§ 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.
§ Each FDT Instance contains at least a single file description entry and at most the complete FDT of the file delivery session.
§ Any FDT Instance can be equal to, a subset of, a superset of, or complement any other FDT Instance.
§ 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.
§ 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.
6.4). Data Elements in FLUTE Instance:
The FDT Instance data elements: mandatory in FLUTE:
§ Content-Location (URI of a file).
§ TOI (Transport Object Identifier of a file instance).
§ Expires (expiry data for the FDT Instance).
§ Content-Length (source file length in bytes).
§ Content-Type (content MIME type). This attribute shall be either in the FDT-Instance or File element or in both.
The following FDT Instance data elements: optional and depends on the FEC Scheme:
§ FEC-OTI-Maximum-Source-Block-Length.
§ FEC-OTI-Encoding-Symbol-Length.
§ FEC-OTI-Max-Number-of-Encoding-Symbols.
§ FEC-OTI-Scheme-Specific-Info.
The optional FDT Instance data elements may or may not be included for FLUTE:
§ Complete (the signalling that an FDT Instance provides a complete, and subsequently not modifiable, set of file parameters for a FLUTE session may or may not be performed according to this method).
§ FEC-OTI-FEC-Encoding-ID (the default value is FEC Encoding ID = 0).
§ FEC-OTI-FEC-Instance-ID.
§ Content_Encoding.
§ Transfer-Length (this field shall be present in case content encoding is applied to the transport object).
§ Content-MD5 (Checksum of the file).
7). Protocol Study – FLUTE Packet Format and Parameters
7.1). Constructing of FLUTE Packets
http://docs.google.com/View?id=ddh56dhg_179gkjvfcff
§ The sender takes a file, e.g. a video clip or a still image, which is used as the transport object for FLUTE
§ Alternatively, the file can be encoded (as GZIP) before using it as the transport object.
§ One FLUTE encoding symbol is carried as the payload of a each FLUTE packet, thus the FLUTE packet size is determined by the encoding symbol length.
§ Based on the transport object length, the encoding symbol length and the maximum source block length, FLUTE calculates the source block structure (i.e. the number of source blocks and their length).
§ The server communicates the transport object length, the encoding symbol length and the maximum source block length to the receiver(s) within the FLUTE transmission.
§ Thus the receiver can calculate the source block structure in advance of receiving a file.
§ Encoding Symbols are the FLUTE packet payloads. They are taken from the source blocks in fragments according to the encoding symbol length.
§ Then the FLUTE packet is constructed from FLUTE header and encoding symbol payload.
§ Source blocks are the logical collection of encoding symbols on which FEC encoding and decoding operations are performed.
7.2). Overall FDT Packet – N/A Here
7.3). FDT Instance Header (EXT_FDT) – N/A Here
7.4). ALC specific LCT extension header - General EXT_FTI format – N/A Here
7.5). Content Encoding of FDT Instance – N/A Here
7.6). Example: The following specifies the XML Schema for FDT Instance – N/A Here
沒有留言:
張貼留言