idnits 2.17.1
draft-ietf-rmt-flute-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 2 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
** There are 2 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 5, 2004) is 7264 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 3450 (ref. '2') (Obsoleted by RFC 5775)
** Obsolete normative reference: RFC 3451 (ref. '3') (Obsoleted by RFC 5651)
** Obsolete normative reference: RFC 3452 (ref. '4') (Obsoleted by RFC
5052, RFC 5445)
** Obsolete normative reference: RFC 1305 (ref. '5') (Obsoleted by RFC 5905)
** Obsolete normative reference: RFC 2616 (ref. '6') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 3695 (ref. '7') (Obsoleted by RFC 5445)
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Obsolete informational reference (is this intentional?): RFC 2327 (ref.
'12') (Obsoleted by RFC 4566)
-- Obsolete informational reference (is this intentional?): RFC 2633 (ref.
'18') (Obsoleted by RFC 3851)
-- Obsolete informational reference (is this intentional?): RFC 2048 (ref.
'20') (Obsoleted by RFC 4288, RFC 4289)
-- Obsolete informational reference (is this intentional?): RFC 1521 (ref.
'21') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)
Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 RMT T. Paila
2 Internet-Draft Nokia
3 Expires: December 4, 2004 M. Luby
4 Digital Fountain
5 R. Lehtonen
6 TeliaSonera
7 V. Roca
8 INRIA Rhone-Alpes
9 R. Walsh
10 Nokia
11 June 5, 2004
13 FLUTE - File Delivery over Unidirectional Transport
14 draft-ietf-rmt-flute-08.txt
16 Status of this Memo
18 This document is an Internet-Draft and is in full conformance with
19 all provisions of Section 10 of RFC2026.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that other
23 groups may also distribute working documents as Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at http://
31 www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on December 4, 2004.
38 Copyright Notice
40 Copyright (C) The Internet Society (2004). All Rights Reserved.
42 Abstract
44 This document defines FLUTE, a protocol for the unidirectional
45 delivery of files over the Internet, which is particularly suited to
46 multicast networks. The specification builds on Asynchronous Layered
47 Coding, the base protocol designed for massively scalable multicast
48 distribution.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.1 Applicability Statement . . . . . . . . . . . . . . . . . . 4
54 1.1.1 The Target Application Space . . . . . . . . . . . . . . . . 4
55 1.1.2 The Target Scale . . . . . . . . . . . . . . . . . . . . . . 4
56 1.1.3 Intended Environments . . . . . . . . . . . . . . . . . . . 4
57 1.1.4 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 2. Conventions used in this document . . . . . . . . . . . . . 5
59 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . 5
60 3.1 File delivery session . . . . . . . . . . . . . . . . . . . 6
61 3.2 File Delivery Table . . . . . . . . . . . . . . . . . . . . 8
62 3.3 Dynamics of FDT Instances within file delivery session . . . 10
63 3.4 Structure of FDT Instance packets . . . . . . . . . . . . . 11
64 3.4.1 Format of FDT Instance Header . . . . . . . . . . . . . . . 12
65 3.4.2 Syntax of FDT Instance . . . . . . . . . . . . . . . . . . . 13
66 3.4.3 Content Encoding of FDT Instance . . . . . . . . . . . . . . 17
67 3.5 Multiplexing of files within a file delivery session . . . . 17
68 4. Channels, congestion control and timing . . . . . . . . . . 18
69 5. Delivering FEC Object Transmission Information . . . . . . . 19
70 5.1 Use of EXT_FTI for delivery of FEC Object Transmission
71 Information . . . . . . . . . . . . . . . . . . . . . . . . 20
72 5.1.1 General EXT_FTI format . . . . . . . . . . . . . . . . . . . 20
73 5.1.2 FEC Encoding ID specific formats for EXT_FTI . . . . . . . . 21
74 5.2 Use of FDT for delivery of FEC Object Transmission
75 Information . . . . . . . . . . . . . . . . . . . . . . . . 24
76 6. Describing file delivery sessions . . . . . . . . . . . . . 25
77 7. Security Considerations . . . . . . . . . . . . . . . . . . 26
78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
80 Normative references . . . . . . . . . . . . . . . . . . . . 29
81 Informative references . . . . . . . . . . . . . . . . . . . 29
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
83 A. Receiver operation (informative) . . . . . . . . . . . . . . 32
84 B. Example of FDT Instance (informative) . . . . . . . . . . . 33
85 Intellectual Property and Copyright Statements . . . . . . . 34
87 1. Introduction
89 This document defines FLUTE version 1, a protocol for unidirectional
90 delivery of files over the Internet. The specification builds on
91 Asynchronous Layered Coding (ALC), version 1 [2], the base protocol
92 designed for massively scalable multicast distribution. ALC defines
93 transport of arbitrary binary objects. For file delivery applications
94 mere transport of objects is not enough, however. The end systems
95 need to know what do the objects actually represent. This document
96 specifies a technique called FLUTE - a mechanism for signaling and
97 mapping the properties of files to concepts of ALC in a way that
98 allows receivers to assign those parameters for received objects.
99 Consequently, throughout this document the term 'file' relates to an
100 'object' as discussed in ALC. Although this specification frequently
101 makes use of multicast addressing as an example, the techniques are
102 similarly applicable for use with unicast addressing.
104 This document defines a specific transport application of ALC, adding
105 the following specifications:
107 - Definition of a file delivery session built on top of ALC,
108 including transport details and timing constraints.
110 - In-band signalling of the transport parameters of the ALC session.
112 - In-band signalling of the properties of delivered files.
114 - Details associated with the multiplexing of multiple files within
115 a session.
117 This specification is structured as follows. Section 3 begins by
118 defining the concept of the file delivery session. Following that it
119 introduces the File Delivery Table that forms the core part of this
120 specification. Further, it discusses multiplexing issues of transport
121 objects within a file delivery session. Section 4 describes the use
122 of congestion control and channels with FLUTE. Section 5 defines how
123 the Forward Error Correction (FEC) Object Transmission Information is
124 to be delivered within a file delivery session. Section 6 defines the
125 required parameters for describing file delivery sessions in a
126 general case. Section 7 outlines security considerations regarding
127 file delivery with FLUTE. Last, there are two informative appendices.
128 The first appendix describes an envisioned receiver operation for the
129 receiver of the file delivery session. The second appendix gives an
130 example of File Delivery Table.
132 Statement of Intent
134 This memo contains part of the definitions necessary to fully
135 specify a Reliable Multicast Transport protocol in accordance with
136 RFC2357. As per RFC2357, the use of any reliable multicast
137 protocol in the Internet requires an adequate congestion control
138 scheme.
140 While waiting for such a scheme to be available, or for an
141 existing scheme to be proven adequate, the Reliable Multicast
142 Transport working group (RMT) publishes this Request for Comments
143 in the "Experimental" category.
145 It is the intent of RMT to re-submit this specification as an IETF
146 Proposed Standard as soon as the above condition is met.
148 1.1 Applicability Statement
150 1.1.1 The Target Application Space
152 FLUTE is applicable to the delivery of large and small files to many
153 hosts, using delivery sessions of several seconds or more. For
154 instance, FLUTE could be used for the delivery of large software
155 updates to many hosts simultaneously. It could also be used for
156 continuous, but segmented, data such as time-lined text for
157 subtitling - potentially leveraging its layering inheritance from ALC
158 and LCT to scale the richness of the session to the congestion status
159 of the network. It is also suitable for the basic transport of
160 metadata, for example SDP [12] files which enable user applications
161 to access multimedia sessions.
163 1.1.2 The Target Scale
165 Massive scalability is a primary design goal for FLUTE. IP multicast
166 is inherently massively scalable, but the best effort service that it
167 provides does not provide session management functionality,
168 congestion control or reliability. FLUTE provides all of this using
169 ALC and IP multicast without sacrificing any of the inherent
170 scalability of IP multicast.
172 1.1.3 Intended Environments
174 All of the environmental requirements and considerations that apply
175 to the ALC building block [2] and to any additional building blocks
176 that FLUTE uses also apply to FLUTE.
178 FLUTE can be used with both multicast and unicast delivery, but it's
179 primary application is for unidirectional multicast file delivery.
180 FLUTE requires connectivity between a sender and receivers but does
181 not require connectivity from receivers to a sender. FLUTE inherently
182 works with all types of networks, including LANs, WANs, Intranets,
183 the Internet, asymmetric networks, wireless networks, and satellite
184 networks.
186 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
187 is IP version specific. FLUTE works with both multicast models:
188 Any-Source Multicast (ASM) [13] and the Source-Specific Multicast
189 (SSM) [15].
191 FLUTE is applicable for both Internet use, with a suitable congestion
192 control building block, and provisioned/controlled systems, such as
193 delivery over wireless broadcast radio systems.
195 1.1.4 Weaknesses
197 Some networks are not amenable to some congestion control protocols
198 that could be used with FLUTE. In particular, for a satellite or
199 wireless network, there may be no mechanism for receivers to
200 effectively reduce their reception rate since there may be a fixed
201 transmission rate allocated to the session.
203 FLUTE provides reliability using the FEC building block. This will
204 reduce the error rate as seen by applications. However, FLUTE does
205 not provide a method for senders to verify the reception success of
206 receivers, and the specification of such a method is outside the
207 scope of this document.
209 2. Conventions used in this document
211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
213 document are to be interpreted as described in RFC 2119 [1].
215 The terms "object" and "transport object" are consistent with the
216 definitions in ALC [2] and LCT [3]. The terms "file" and "source
217 object" are pseudonyms for "object".
219 3. File delivery
221 Asynchronous Layered Coding [2] is a protocol designed for delivery
222 of arbitrary binary objects. It is especially suitable for massively
223 scalable, unidirectional, multicast distribution. ALC provides the
224 basic transport for FLUTE, and thus FLUTE inherits the requirements
225 of ALC.
227 This specification is designed for the delivery of files. The core of
228 this specification is to define how the properties of the files are
229 carried in-band together with the delivered files.
231 As an example, let us consider a 5200 byte file referred to by
232 "http://www.example.com/docs/file.txt". Using the example, the
233 following properties describe the properties that need to be conveyed
234 by the file delivery protocol.
236 * Identifier of the file, expressed as a URI. This identifier may be
237 globally unique. The identifier may also provide a location for
238 the file. In the above example: "http://www.example.com/docs/
239 file.txt".
241 * File name (usually, this can be concluded from the URI). In the
242 above example: "file.txt".
244 * File type, expressed as MIME media type (usually, this can also be
245 concluded from the extension of the file name). In the above
246 example: "text/plain". If an explicit value for the MIME type is
247 provided separately from the file extension and does not match the
248 MIME type of the file extension then the explicitly provided value
249 MUST be used as the MIME type.
251 * File size, expressed in bytes. In the above example: "5200". If
252 the file is content encoded then this is the file size before
253 content encoding.
255 * Content encoding of the file, within transport. In the above
256 example, the file could be encoded using ZLIB [10]. In this case
257 the size of the transport object carrying the file would probably
258 differ from the file size. The transport object size is delivered
259 to receivers as part of the FLUTE protocol.
261 * Security properties of the file such as digital signatures,
262 message digests, etc. For example, one could use S/MIME [18] as
263 the content encoding type for files with this authentication
264 wrapper, and one could use XML-DSIG [19] to digitally sign an FDT
265 Instance.
267 3.1 File delivery session
269 ALC is a protocol instantiation of Layered Coding Transport building
270 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
271 this document we will use the concept ALC/LCT session to collectively
272 denote the interchangeable terms ALC session and LCT session.
274 An ALC/LCT session consists of a set of logically grouped ALC/LCT
275 channels associated with a single sender sending packets with ALC/LCT
276 headers for one or more objects. An ALC/LCT channel is defined by the
277 combination of a sender and an address associated with the channel by
278 the sender. A receiver joins a channel to start receiving the data
279 packets sent to the channel by the sender, and a receiver leaves a
280 channel to stop receiving data packets from the channel.
282 One of the fields carried in the ALC/LCT header is the Transport
283 Session Identifier (TSI). The TSI is scoped by the source IP address,
284 and the (source IP address, TSI) pair uniquely identifies a session,
285 i.e., the receiver uses this pair carried in each packet to uniquely
286 identify from which session the packet was received. In case multiple
287 objects are carried within a session another field within the ALC/LCT
288 header, the Transport Object Identifier (TOI), identifies from which
289 object within the session the data in the packet was generated. Note
290 that each object is associated with a unique TOI within the scope of
291 a session.
293 If the sender is not assigned a permanent IP address accessible to
294 receivers, but instead packets that can be received by receivers
295 contain a temporary IP address for packets sent by the sender, then
296 the TSI is scoped by this temporary IP address of the sender for the
297 duration of the session. As an example, the sender may be behind a
298 Network Address Translation (NAT) device that temporarily assigns an
299 IP address for the sender that is accessible to receivers, and in
300 this case the TSI is scoped by the temporary IP address assigned by
301 the NAT that will appear in packets received by the receiver. As
302 another example, the sender may send its original packets using IPv6,
303 but some portions of the network may not be IPv6 capable and thus
304 there may be an IPv6 to IPv4 translator that changes the IP address
305 of the packets to a different IPv4 address. In this case, receivers
306 in the IPv4 portion of the network will receive packets containing
307 the IPv4 address, and thus the TSI for them is scoped by the IPv4
308 address. How the IP address of the sender to be used to scope the
309 session by receivers is delivered to receivers, whether it is a
310 permanent IP address or a temporary IP address, is outside the scope
311 of this document.
313 When FLUTE is used for file delivery over ALC the following rules
314 apply:
316 * The ALC/LCT session is called file delivery session.
318 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
319 Delivery Table Instance' (section 3.2)
321 * The TOI field MUST be included in ALC packets sent within a FLUTE
322 session, with the exception that ALC packets sent in a FLUTE
323 session with the Close Session (A) flag set to 1 (signaling the
324 end of the session) and that contain no payload (carrying no
325 information for any file for FDT) SHALL NOT carry the TOI. See
326 Section 5.1 of RFC 3451 [3] for the LCT definition of the Close
327 Session flag, and see Section 4.2 of RFC 3450 [2] for an example
328 of its use within an ALC packet.
330 * The TOI value '0' is reserved for delivery of File Delivery Table
331 Instances. Each File Delivery Table Instance is uniquely
332 identified by an FDT Instance ID.
334 * Each file in a file delivery session MUST be associated with a TOI
335 (>0) in the scope of that session.
337 * Information carried in the headers and the payload of a packet is
338 scoped by the source IP address and the TSI. Information
339 particular to the object carried in the headers and the payload of
340 a packet is further scoped by the TOI for file objects, and is
341 further scoped by both the TOI and the FDT Instance ID for FDT
342 Instance objects.
344 3.2 File Delivery Table
346 The File Delivery Table (FDT) provides a means to describe various
347 attributes associated with files that are to be delivered within the
348 file delivery session. The following lists are examples of such
349 attributes, and are not intended to be mutually exclusive nor
350 exhaustive.
352 Attributes related to the delivery of file:
354 - TOI value that represents the file
356 - FEC Object Transmission Information (including the FEC Encoding ID
357 and, if relevant, the FEC Instance ID)
359 - Size of the transport object carrying the file
361 - Aggregate rate of sending packets to all channels
363 Attributes related to the file itself:
365 - Name, Identification and Location of file (specified by the URI)
366 - MIME media type of file
368 - Size of file
370 - Encoding of file
372 - Message digest of file
374 Some of these attributes MUST be included in the file description
375 entry for a file, others are optional, as defined in section 3.4.2.
377 Logically, the FDT is a set of file description entries for files to
378 be delivered in the session. Each file description entry MUST include
379 the TOI for the file that it describes and the URI identifying the
380 file. The TOI is included in each ALC/LCT data packet during the
381 delivery of the file, and thus the TOI carried in the file
382 description entry is how the receiver determines which ALC/LCT data
383 packets contain information about which file. Each file description
384 entry may also contain one or more descriptors that map the
385 above-mentioned attributes to the file.
387 Each file delivery session MUST have an FDT that is local to the
388 given session. The FDT MUST provide a file description entry mapped
389 to a TOI for each file appearing within the session. An object that
390 is delivered within the ALC session, but not described in the FDT, is
391 not considered a 'file' belonging to the file delivery session.
392 Handling of these unmapped TOIs (TOIs that are not resolved by the
393 FDT) is out of scope of this specification.
395 Within the file delivery session the FDT is delivered as FDT
396 Instances. An FDT Instance contains one or more file description
397 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
398 superset of, or complement any other FDT Instance. A certain FDT
399 Instance may be repeated several times during a session, even after
400 subsequent FDT Instances (with higher FDT Instance ID numbers) have
401 been transmitted. Each FDT Instance contains at least a single file
402 description entry and at most the complete FDT of the file delivery
403 session.
405 A receiver of the file delivery session keeps an FDT database for
406 received file description entries. The receiver maintains the
407 database, for example, upon reception of FDT Instances. Thus, at any
408 given time the contents of the FDT database represent the receiver's
409 current view of the FDT of the file delivery session. Since each
410 receiver behaves independently of other receivers, it SHOULD NOT be
411 assumed that the contents of the FDT database are the same for all
412 the receivers of a given file delivery session.
414 Since FDT database is an abstract concept, the structure and the
415 maintaining of the FDT database are left to individual
416 implementations and are thus out of scope of this specification.
418 3.3 Dynamics of FDT Instances within file delivery session
420 The following rules define the dynamics of the FDT Instances within a
421 file delivery session:
423 * For every file delivered within a file delivery session there MUST
424 be a file description entry included in at least one FDT Instance
425 sent within the session. A file description entry contains at a
426 minimum the mapping between the TOI and the URI.
428 * An FDT Instance MAY appear in any part of the file delivery
429 session and packets for an FDT Instance MAY be interleaved with
430 packets for other files or other FDT Instances within a session.
432 * The TOI value of '0' MUST be reserved for delivery of FDT
433 Instances. The use of other TOI values for FDT Instances is
434 outside the scope of this specification.
436 * FDT Instance is identified by the use of a new fixed length LCT
437 Header Extension EXT_FDT (defined later in this section). Each FDT
438 Instance is uniquely identified within the file delivery session
439 by its FDT Instance ID. Any ALC/LCT packet carrying FDT Instance
440 (indicated by TOI = 0) MUST include EXT_FDT.
442 * It is RECOMMENDED that FDT Instance that contains the file
443 description entry for a file is sent prior to the sending of the
444 described file within a file delivery session.
446 * Within a file delivery session, any TOI MAY be described more than
447 once. An example: previous FDT Instance 0 describes TOI of value
448 '3'. Now, subsequent FDT Instances can either keep TOI '3'
449 unmodified on the table, not to include it or complement the
450 description. However, subsequent FDT Instances MUST NOT change the
451 parameters already described for a specific TOI.
453 * An FDT Instance is valid until its expiration time. The expiration
454 time is expressed within the FDT Instance payload as a 32 bit data
455 field. The value of the data field represents the 32 most
456 significant bits of a 64 bit Network Time Protocol (NTP) [5] time
457 value. These 32 bits provide an unsigned integer representing the
458 time in seconds relative to 0 hours 1 January 1900. Handling of
459 wraparound of the 32 bit time is outside the scope of NTP and
460 FLUTE.
462 * The receiver SHOULD NOT use a received FDT Instance to interpret
463 packets received beyond the expiration time of the FDT Instance.
465 * A sender MUST use an expiry time in the future upon creation of an
466 FDT Instance relative to its Sender Current Time (SCT).
468 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
469 The default is to use FEC Encoding ID 0 for the sending of FDT
470 Instances. (Note that since FEC Encoding ID 0 is the default for
471 FLUTE, this implies that Source Block Number and Encoding Symbol
472 ID lengths both default to 16 bits each.)
474 Generally, a receiver needs to receive an FDT Instance describing a
475 file before it is able to recover the file itself. In this sense FDT
476 Instances are of higher priority than files. Thus, it is RECOMMENDED
477 that FDT Instances describing a file be sent with at least as much
478 reliability within a session (more often or with more FEC protection)
479 as the files they describe. In particular, if FDT Instances are
480 generally longer than one packet payload in length it is RECOMMENDED
481 that an FEC code that can provide protection against loss be used for
482 delivering FDT Instances. How often the description of a file is sent
483 in an FDT Instance or how much FEC protection is provided for each
484 FDT Instance (if the FDT Instance is longer than one packet payload)
485 is dependent on the particular application and outside the scope of
486 this document.
488 3.4 Structure of FDT Instance packets
490 FDT Instances are carried in ALC packets with TOI = 0 and with an
491 additional REQUIRED LCT Header extension called the FDT Instance
492 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
493 ID that uniquely identifies FDT Instances within a file delivery
494 session. The FDT Instance Header is placed in the same way as any
495 other LCT extension header. There MAY be other LCT extension headers
496 in use.
498 The LCT extension headers are followed by the FEC Payload ID, and
499 finally the Encoding Symbols for the FDT Instance which contains one
500 or more file description entries. The FDT Instance MAY span over
501 several ALC packets - the number of ALC packets is a function of the
502 FEC Object Transmission Information associated to this FDT Instance.
503 The FDT Instance Header is carried in each ALC packet carrying the
504 FDT Instance. The FDT Instance Header is identical for all ALC/LCT
505 packets for a particular FDT Instance.
507 The overall format of ALC/LCT packets carrying an FDT Instance is
508 depicted in the Figure 1 below. All integer fields are carried in
509 "big-endian" or "network order" format, that is, most significant
510 byte (octet) first. As defined in [2], all ALC/LCT packets are sent
511 using UDP.
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 | UDP header |
515 | |
516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
517 | Default LCT header (with TOI = 0) |
518 | |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
521 | |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | FEC Payload ID |
524 | |
525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
526 | Encoding Symbol(s) for FDT Instance |
527 | ... |
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 Figure 1 - Overall FDT Packet
532 3.4.1 Format of FDT Instance Header
534 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
535 LCT header extension [3]. The Header Extension Type (HET) for the
536 extension is 192. Its format is defined below:
538 0 1 2 3
539 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
540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
541 | HET = 192 | V | FDT Instance ID |
542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
544 Version of FLUTE (V), 4 bits:
546 This document specifies FLUTE version 1. Hence in any ALC packet that
547 carries FDT Instance and that belongs to the file delivery session as
548 specified in this specification MUST set this field to '1'.
550 FDT Instance ID, 20 bits:
552 For each file delivery session the numbering of FDT Instances starts
553 from '0' and is incremented by exactly one for each subsequent FDT
554 Instance. After reaching the maximum value (2^20-1), the numbering
555 starts again from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is
556 considered higher than 2^20-1. A new FDT Instance reusing a previous
557 FDT Instance ID number, due to wraparound, may not implicitly expire
558 the previous FDT Instance with the same ID. It would be reasonable
559 for FLUTE Senders to only construct and deliver FDT Instances with
560 wraparound IDs after the previous FDT Instance using the same ID has
561 expired. However, mandatory receiver behavior for handling FDT
562 Instance ID wraparound and other special situations (for example,
563 missing FDT Instance IDs resulting in longer increments than one) is
564 left out of this specification to individual implementations of
565 FLUTE.
567 3.4.2 Syntax of FDT Instance
569 The FDT Instance contains file description entries that provide the
570 mapping functionality described in 3.2 above.
572 The FDT Instance is an XML structure that has a single root element
573 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
574 attribute, which tells the expiry time of the FDT Instance. In
575 addition, the "FDT-Instance" element MAY contain the "Complete"
576 attribute (boolean), which, when TRUE, signals that no new data will
577 be provided in future FDT Instances within this session (i.e. that
578 either FDT Instances with higher ID numbers will not be used or if
579 they are used, will only provide identical file parameters to that
580 already given in this and previous FDT Instances). For example, this
581 may be used to provide a complete list of files in an entire FLUTE
582 session (a "complete FDT").
584 The "FDT-Instance" element MAY contain attributes that give common
585 parameters for all files of an FDT Instance. These attributes MAY
586 also be provided for individual files in the "File" element. Where
587 the same attribute appears in both the "FDT-Instance" and the "File"
588 elements, the value of the attribute provided in the "File" element
589 takes precedence.
591 For each file to be declared in the given FDT Instance there is a
592 single file description entry in the FDT Instance. Each entry is
593 represented by element "File" which is a child element of the FDT
594 Instance structure.
596 The attributes of "File" element in the XML structure represent the
597 attributes given to the file that is delivered in the file delivery
598 session. The value of the XML attribute name corresponds to MIME
599 field name and the XML attribute value corresponds to the value of
600 the MIME field body. Each "File" element MUST contain at least two
601 attributes "TOI" and "Content-Location". "TOI" MUST be assigned a
602 valid TOI value as described in section 3.3 above. "Content-Location"
603 MUST be assigned a valid URI as defined in [6].
605 In addition to mandatory attributes, the "FDT-Instance" element and
606 the "File" element MAY contain other attributes of which the
607 following are specifically pointed out.
609 * Where the MIME type is described, the attribute "Content-Type"
610 MUST be used for the purpose as defined in [6].
612 * Where the length is described, the attribute "Content-Length" MUST
613 be used for the purpose as defined in [6]. The transfer length is
614 defined to be the length of the object transported in bytes. It is
615 often important to convey the transfer length to receivers,
616 because the source block structure needs to be known for the FEC
617 decoder to be applied to recover source blocks of the file, and
618 the transfer length is often needed to properly determine the
619 source block structure of the file. There generally will be a
620 difference between the length of the original file and the
621 transfer length if content encoding is applied to the file before
622 transport, and thus the "Content-Encoding" attribute is used. If
623 the file is not content encoded before transport (and thus the
624 "Content-Encoding" attribute is not used) then the transfer length
625 is the length of the original file, and in this case the
626 "Content-Length" is also the transfer length. However, if the file
627 is content encoded before transport (and thus the
628 "Content-Encoding" attribute is used), e.g. if compression is
629 applied before transport to reduce the number of bytes that need
630 to be transferred, then the transfer length is generally different
631 than the length of the original file, and in this case the
632 attribute "Transfer-Length" MAY be used to carry the transfer
633 length.
635 * Where the content encoding scheme is described, the attribute
636 "Content-Encoding" MUST be used for the purpose as defined in [6].
638 * Where the MD5 message digest is described, the attribute
639 "Content-MD5" MUST be used for the purpose as defined in [6].
641 * The FEC Object Transmission Information attributes as described in
642 section 5.2.
644 The following specifies the XML Schema [8][9] for FDT Instance:
646
647
651
652
653
654
655
656
659
662
665
668
671
674
677
680
683
686
689
692
693
694
695
696
699
702
705
708
711
714
717
720
723
724
725
726
728 Any valid FDT Instance must use the above XML Schema. This way FDT
729 provides extensibility to support private attributes within the file
730 description entries. Those could be, for example, the attributes
731 related to the delivery of the file (timing, packet transmission
732 rate, etc.).
734 In case the basic FDT XML Schema is extended in terms of new
735 descriptors, for attributes applying to a single file, those MUST be
736 placed within the attributes of the element "File", and for
737 attributes applying to all files described by the current FDT
738 Instance MUST be placed within the element "FDT-Instance". It is
739 RECOMMENDED that the new descriptors applied in the FDT are in the
740 format of MIME fields and are either defined in HTTP/1.1
741 specification [6] or otherwise well-known specification.
743 3.4.3 Content Encoding of FDT Instance
745 The FDT Instance itself MAY be content encoded, for example
746 compressed. This specification defines FDT Instance Content Encoding
747 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific
748 LCT header extension [3]. The Header Extension Type (HET) for the
749 extension is 193. If the FDT Instance is content encoded, the
750 EXT_CENC MUST be used to signal the content encoding type. In that
751 case, EXT_CENC header extension MUST be used in all ALC packets
752 carrying the same FDT Instance ID. Consequently, when EXT_CENC header
753 is used, it MUST be used together with a proper FDT Instance Header
754 (EXT_FDT). Within a file delivery session, FDT Instances that are not
755 content encoded and FDT Instances that are content encoded MAY both
756 appear. If content encoding is not used for a given FDT Instance, the
757 EXT_CENC MUST NOT be used in any packet carrying the FDT Instance.
758 The format of EXT_CENC is defined below:
760 0 1 2 3
761 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
762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
763 | HET = 193 | CENC | Reserved |
764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
766 Content Encoding Algorithm (CENC), 8 bits:
768 This field signals the content encoding algorithm used in the FDT
769 Instance payload. The definition of this field is outside the scope
770 of this specification. Applicable content encoding algorithms
771 include, for example, ZLIB [10], DEFLATE [16] and GZIP [17].
773 Reserved, 16 bits:
775 This field MUST be set to all '0'.
777 3.5 Multiplexing of files within a file delivery session
779 The delivered files are carried as transport objects (identified with
780 TOIs) in the file delivery session. All these objects, including the
781 FDT Instances, MAY be multiplexed in any order and in parallel with
782 each other within a session, i.e., packets for one file MAY be
783 interleaved with packets for other files or other FDT Instances
784 within a session.
786 Multiple FDT Instances MAY be delivered in a single session using TOI
787 = 0. In this case, it is RECOMMENDED that the sending of a previous
788 FDT Instance SHOULD end before the sending of the next FDT Instance
789 starts. However, due to unexpected network conditions, packets for
790 the FDT Instances MAY be interleaved. A receiver can determine which
791 FDT Instance a packet contains information about since the FDT
792 Instances are uniquely identified by their FDT Instance ID carried in
793 the EXT_FDT headers.
795 4. Channels, congestion control and timing
797 ALC/LCT has a concept of channels and congestion control. There are
798 four scenarios FLUTE is envisioned to be applied.
800 (a) Use a single channel and a single-rate congestion control
801 protocol.
803 (b) Use multiple channels and a multiple-rate congestion control
804 protocol. In this case the FDT Instances MAY be delivered on more
805 than one channel.
807 (c) Use a single channel without congestion control supplied by ALC,
808 but only when in a controlled network environment where flow/
809 congestion control is being provided by other means.
811 (d) Use multiple channels without congestion control supplied by ALC,
812 but only when in a controlled network environment where flow/
813 congestion control is being provided by other means. In this case
814 the FDT Instances MAY be delivered on more than one channel.
816 When using just one channel for a file delivery session, as in (a)
817 and (c), the notion of 'prior' and 'after' are intuitively defined
818 for the delivery of objects with respect to their delivery times.
820 However, if multiple channels are used, as in (b) and (d), it is not
821 straightforward to state that an object was delivered 'prior' to the
822 other. An object may begin to be delivered on one or more of those
823 channels before the delivery of a second object begins. However, the
824 use of multiple channels/layers may complete the delivery of the
825 second object before the first. This is not a problem when objects
826 are delivered sequentially using a single channel. Thus, if the
827 application of FLUTE has a mandatory or critical requirement that the
828 first transport object must complete 'prior' to the second one, it is
829 RECOMMENDED that only a single channel is used for the file delivery
830 session.
832 Furthermore, if multiple channels are used then a receiver joined to
833 the session at a low reception rate will only be joined to the lower
834 layers of the session. Thus, since the reception of FDT Instances is
835 of higher priority than the reception of files (because the reception
836 of files depends on the reception of an FDT Instance describing it),
837 the following is RECOMMENDED:
839 1. The layers to which packets for FDT Instances are sent SHOULD NOT
840 be biased towards those layers to which lower rate receivers are
841 not joined. For example, it is ok to put all the packets for an
842 FDT Instance into the lowest layer (if this layer carries enough
843 packets to deliver the FDT to higher rate receivers in a
844 reasonable amount of time), but it is not ok to put all the
845 packets for an FDT Instance into the higher layers that only high
846 rate receivers will receive.
848 2. If FDT Instances are generally longer than one Encoding Symbol in
849 length and some packets for FDT Instances are sent to layers that
850 lower rate receivers do not receive, an FEC Encoding other than
851 FEC Encoding ID 0 SHOULD be used to deliver FDT Instances. This
852 is because in this case, even when there is no packet loss in the
853 network, a lower rate receiver will not receive all packets sent
854 for an FDT Instance.
856 5. Delivering FEC Object Transmission Information
858 FLUTE inherits the use of FEC building block [4] from ALC. When using
859 FLUTE for file delivery over ALC the FEC Object Transmission
860 Information MUST be delivered in-band within the file delivery
861 session. In this section, two methods are specified for FLUTE for
862 this purpose: the use of ALC specific LCT extension header EXT_FTI
863 [2] and the use of FDT.
865 The receiver of file delivery session MUST support delivery of FEC
866 Object Transmission Information using the EXT_FTI for the FDT
867 Instances carried using TOI value 0. For the TOI values other than 0
868 the receiver MUST support both methods: the use of EXT_FTI and the
869 use of FDT.
871 The FEC Object Transmission Information that needs to be delivered to
872 receivers MUST be exactly the same whether it is delivered using
873 EXT_FTI or using FDT (or both). Section 5.1 describes the required
874 FEC Object Transmission Information that MUST be delivered to
875 receivers for various FEC Encoding IDs. In addition, it describes the
876 delivery using EXT_FTI. Section 5.2 describes the delivery using FDT.
878 The FEC Object Transmission Information regarding a given TOI may be
879 available from several sources. In this case, it is RECOMMENDED that
880 the receiver of the file delivery session prioritizes the sources in
881 the following way (in the order of decreasing priority).
883 1. FEC Object Transmission Information that is available in EXT_FTI.
885 2. FEC Object Transmission Information that is available in the FDT.
887 5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information
889 As specified in [2], the EXT_FTI header extension is intended to
890 carry the FEC Object Transmission Information for an object in-band.
891 It is left up to individual implementations to decide how frequently
892 and in which ALC packets the EXT_FTI header extension is included. In
893 environments with higher packet loss rate, the EXT_FTI might need to
894 be included more frequently in ALC packets than in environments with
895 low error probability. The EXT_FTI MUST be included in at least one
896 sent ALC packet for each FDT Instance.
898 The ALC specification does not define the format or the processing of
899 the EXT_FTI header extension. The following sections specify EXT_FTI
900 when used in FLUTE.
902 In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint
903 field of the ALC/LCT header.
905 5.1.1 General EXT_FTI format
907 The general EXT_FTI format specifies the structure and those
908 attributes of FEC Object Transmission Information that are applicable
909 to any FEC Encoding ID.
911 0 1 2 3
912 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
913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914 | HET = 64 | HEL | |
915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
916 | Transfer Length |
917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 | FEC Instance ID | FEC Enc. ID Specific Format |
919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
921 Header Extension Type (HET), 8 bits:
923 64 as defined in [2].
925 Header Extension Length (HEL), 8 bits:
927 The length of the whole Header Extension field, expressed in
928 multiples of 32-bit words. This length includes the FEC Encoding ID
929 specific format part.
931 Transfer Length, 48 bits:
933 The length of the transport object that carries the file in bytes.
934 (This is the same as the file length if the file is not content
935 encoded.)
937 FEC Instance ID, optional, 16 bits:
939 This field is used for FEC Instance ID. It is only present if the
940 value of FEC Encoding ID is in the range of 128-255. When the value
941 of FEC Encoding ID is in the range of 0-127, this field is set to 0.
943 FEC Encoding ID Specific Format:
945 Different FEC encoding schemes will need different sets of encoding
946 parameters. Thus, the structure and length of this field depends on
947 FEC Encoding ID. The next sections specify structure of this field
948 for FEC Encoding ID numbers 0, 128, 129 and 130.
950 5.1.2 FEC Encoding ID specific formats for EXT_FTI
952 5.1.2.1 FEC Encoding IDs 0, 128, and 130
954 FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC
955 Encoding ID 128 is 'Small Block, Large Block and Expandable FEC'
956 (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC'
957 (Under-Specified) [7]. For these FEC Encoding IDs, the FEC Encoding
958 ID specific format of EXT_FTI is defined as follows.
960 0 1 2 3
961 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
962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
963 General EXT_FTI format | Encoding Symbol Length |
964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
965 | Maximum Source Block Length |
966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
968 Encoding Symbol Length, 16 bits:
970 Length of Encoding Symbol in bytes.
972 All Encoding Symbols of a transport object MUST be equal to this
973 length, with the optional exception of the last source symbol of the
974 last source block (so that redundant padding is not mandatory in this
975 last symbol). This last source symbol MUST be logically padded out
976 with zeroes when another Encoding Symbol is computed based on this
977 source symbol to ensure the same interpretation of this Encoding
978 Symbol value by the sender and receiver. However, this padding need
979 not be actually sent with the data of the last source symbol.
981 Maximum Source Block Length, 32 bits:
983 The maximum number of source symbols per source block.
985 This EXT_FTI specification requires that an algorithm is known to
986 both sender and receivers for determining the size of all source
987 blocks of the transport object that carries the file identified by
988 the TOI (or within the FDT Instance identified by the TOI and the FDT
989 Instance ID). The algorithm SHOULD be the same for all files using
990 the same FEC Encoding ID within a session.
992 Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
993 use.
995 For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only
996 well known way the receiver can determine the length of each source
997 block. Thus, the algorithm does two things: (a) it tells the receiver
998 the length of each particular source block as it is receiving packets
999 for that source block - this is essential to all of these FEC
1000 schemes; and, (b) it provides the source block structure immediately
1001 to the receiver so that the receiver can determine where to save
1002 recovered source blocks at the beginning - this is an optimization
1003 which is essential for some implementations.
1005 5.1.2.2 FEC Encoding ID 129
1007 Small Block Systematic FEC (Under-Specified). The FEC Encoding ID
1008 specific format of EXT_FTI is defined as follows.
1010 0 1 2 3
1011 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
1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1013 General EXT_FTI format | Encoding Symbol Length |
1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1015 | Maximum Source Block Length | Max. Num. of Encoding Symbols |
1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1018 Encoding Symbol Length, 16 bits:
1020 Length of Encoding Symbol in bytes.
1022 All Encoding Symbols of a transport object MUST be equal to this
1023 length, with the optional exception of the last source symbol of the
1024 last source block (so that redundant padding is not mandatory in this
1025 last symbol). This last source symbol MUST be logically padded out
1026 with zeroes when another Encoding Symbol is computed based on this
1027 source symbol to ensure the same interpretation of this Encoding
1028 Symbol value by the sender and receiver. However, this padding need
1029 not be actually sent with the data of the last source symbol.
1031 Maximum Source Block Length, 16 bits:
1033 The maximum number of source symbols per source block.
1035 Maximum Number of Encoding Symbols, 16 bits:
1037 Maximum number of Encoding Symbols that can be generated for a source
1038 block.
1040 This EXT_FTI specification requires that an algorithm is known to
1041 both sender and receivers for determining the size of all source
1042 blocks of the transport object that carries the file identified by
1043 the TOI (or within the FDT Instance identified by the TOI and the FDT
1044 Instance ID). The algorithm SHOULD be the same for all files using
1045 the same FEC Encoding ID within a session.
1047 Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
1048 use. For FEC Encoding ID 129 the FEC Payload ID in each data packet
1049 already contains the source block length for the source block
1050 corresponding to the Encoding Symbol carried in the data packet.
1051 Thus, the algorithm for computing source blocks for FEC Encoding ID
1052 129 could be to just use the source block lengths carried in data
1053 packets within the FEC Payload ID. However, the algorithm described
1054 in Section 5.1.2.3 is useful for the receiver to compute the source
1055 block structure at the beginning of the reception of data packets for
1056 the file. If the algorithm described in Section 5.1.2.3 is used then
1057 it MUST be the case that the source block lengths that appear in data
1058 packets agree with the source block lengths calculated by the
1059 algorithm.
1061 5.1.2.3 Algorithm for Computing Source Block Structure
1063 This algorithm computes a source block structure so that all source
1064 blocks are as close to being equal length as possible. A first number
1065 of source blocks are of the same larger length, and the remaining
1066 second number of source blocks are sent of the same smaller length.
1067 The total number of source blocks (N), the first number of source
1068 blocks (I), the second number of source blocks (N-I), the larger
1069 length (A_large) and the smaller length (A_small) are calculated
1070 thus,
1072 Input:
1074 B -- Maximum Source Block Length, i.e., the maximum number of
1075 source symbols per source block
1076 L -- Transfer Length in bytes
1077 E -- Encoding Symbol Length in bytes
1079 Output:
1080 N -- The number of source blocks into which the transport
1081 object is partitioned.
1083 The number and lengths of source symbols in each of the N
1084 source blocks.
1086 Algorithm:
1087 (a) The number of source symbols in the transport object is
1088 computed as T = L/E rounded up to the nearest integer.
1089 (b) The transport object is partitioned into N source blocks,
1090 where N = T/B rounded up to the nearest integer
1091 (c) The average length of a source block, A = T/N
1092 (this may be non-integer)
1093 (d) A_large = A rounded up to the nearest integer
1094 (it will always be the case that the value of A_large is at
1095 most B)
1096 (e) A_small = A rounded down to the nearest integer
1097 (if A is an integer A_small = A_large,
1098 and otherwise A_small = A_large - 1)
1099 (f) The fractional part of A, A_fraction = A - A_small
1100 (g) I = A_fraction * N
1101 (I is an integer between 0 and N-1)
1102 (h) Each of the first I source blocks consists of A_large source
1103 symbols, each source symbol is E bytes in length. Each of the
1104 remaining N-I source blocks consist of A_small source symbols,
1105 each source symbol is E bytes in length except that the last
1106 source symbol of the last source block is L-(((L-1)/E) rounded
1107 down to the nearest integer)*E bytes in length.
1109 Note, this algorithm does not imply implementation by floating point
1110 arithmetic and integer arithmetic may be used to avoid potential
1111 floating point rounding errors.
1113 5.2 Use of FDT for delivery of FEC Object Transmission Information
1115 The FDT delivers FEC Object Transmission Information for each file
1116 using an appropriate attribute within the "FDT-Instance" or the
1117 "File" element of the FDT structure. For future FEC Encoding IDs, if
1118 the attributes listed below do not fulfill the needs of describing
1119 the FEC Object Transmission Information then additional new
1120 attributes MAY be used.
1122 * "Transfer-Length" is semantically equivalent with the field
1123 "Transfer Length" of EXT_FTI.
1125 * "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the
1126 field "FEC Encoding ID" as carried in the Codepoint field of the
1127 ALC/LCT header.
1129 * "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the
1130 field "FEC Instance ID" of EXT_FTI.
1132 * "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
1133 with the field "Maximum Source Block Length" of EXT_FTI for FEC
1134 Encoding IDs 0, 128 and 130, and semantically equivalent with the
1135 field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID
1136 129.
1138 * "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with
1139 the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs
1140 0, 128, 129 and 130.
1142 * "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically
1143 equivalent with the field "Maximum Number of Encoding Symbols" of
1144 EXT_FTI for FEC Encoding ID 129.
1146 6. Describing file delivery sessions
1148 To start receiving a file delivery session, the receiver needs to
1149 know transport parameters associated with the session. Interpreting
1150 these parameters and starting the reception therefore represents the
1151 entry point from which thereafter the receiver operation falls into
1152 the scope of this specification. According to [2], the transport
1153 parameters of an ALC/LCT session that the receiver needs to know are:
1155 * The source IP address;
1157 * The number of channels in the session;
1159 * The destination IP address and port number for each channel in the
1160 session;
1162 * The Transport Session Identifier (TSI) of the session;
1164 * An indication that the session is a FLUTE session. The need to
1165 demultiplex objects upon reception is implicit in any use of
1166 FLUTE, and this fulfills the ALC requirement of an indication of
1167 whether or not a session carries packets for more than one object
1168 (all FLUTE sessions carry packets for more than one object);
1170 Optionally, the following parameters MAY be associated with the
1171 session (Note, the list is not exhaustive):
1173 * The start time and end time of the session;
1175 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1176 ID 0 is not used for the delivery of FDT;
1178 * Content Encoding format if optional content encoding of FDT
1179 Instance is used, e.g., compression;
1181 * Some information that tells receiver, in the first place, that the
1182 session contains files that are of interest.
1184 It is envisioned that these parameters would be described according
1185 to some session description syntax (such as SDP [12] or XML based)
1186 and held in a file which would be acquired by the receiver before the
1187 FLUTE session begins by means of some transport protocol (such as
1188 Session Announcement Protocol [11], email, HTTP [6], SIP [22], manual
1189 pre-configuration, etc.) However, the way in which the receiver
1190 discovers the above-mentioned parameters is out of scope of this
1191 document, as it is for LCT and ALC. In particular, this specification
1192 does not mandate or exclude any mechanism.
1194 7. Security Considerations
1196 The security considerations that apply to, and are described in, ALC
1197 [2], LCT [3] and FEC [4] also apply to FLUTE. In addition, any
1198 security considerations that apply to any congestion control building
1199 block used in conjunction with FLUTE also apply to FLUTE.
1201 Because of the use of FEC, FLUTE is especially vulnerable to
1202 denial-of-service attacks by attackers that try to send forged
1203 packets to the session which would prevent successful reconstruction
1204 or cause inaccurate reconstruction of large portions of the FDT or
1205 file by receivers. Like ALC, FLUTE is particularly affected by such
1206 an attack because many receivers may receive the same forged packet.
1207 A malicious attacker may spoof file packets and cause incorrect
1208 recovery of a file.
1210 Even more damaging, a malicious forger may spoof FDT Instance
1211 packets, for example sending packets with erroneous FDT-Instance
1212 fields. Many attacks can follow this approach. For instance a
1213 malicious attacker may alter the Content-Location field of TOI 'n',
1214 to make it point to a system file or a user configuration file.
1215 Then, TOI 'n' can carry a Trojan Horse or some other type of virus.
1216 It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at
1217 the receiver does not have write access to the system files or
1218 directories, or any other critical areas. As described for MIME
1219 [20][21], special consideration should be paid to the security
1220 implications of any MIME types that can cause the remote execution of
1221 any actions in the recipient's environment. Note, RFC 1521 [21]
1222 describes important security issues for this environment, even though
1223 its protocol is obsoleted by RFC 2048 [20].
1225 Another example is generating a bad Content-MD5 sum, leading
1226 receivers to reject the associated file that will be declared
1227 corrupted. The Content-Encoding can also be modified, which also
1228 prevents the receivers to correctly handle the associated file.
1229 These examples show that the FDT information is critical to the FLUTE
1230 delivery service.
1232 At the application level, it is RECOMMENDED that an integrity check
1233 on the entire received object be done once the object is
1234 reconstructed to ensure it is the same as the sent object, especially
1235 for objects that are FDT Instances. Moreover, in order to obtain
1236 strong cryptographic integrity protection a digital signature
1237 verifiable by the receiver SHOULD be used to provide this application
1238 level integrity check. However, if even one corrupted or forged
1239 packet is used to reconstruct the object, it is likely that the
1240 received object will be reconstructed incorrectly. This will
1241 appropriately cause the integrity check to fail and in this case the
1242 inaccurately reconstructed object SHOULD be discarded. Thus, the
1243 acceptance of a single forged packet can be an effective denial of
1244 service attack for distributing objects, but an object integrity
1245 check at least prevents inadvertent use of inaccurately reconstructed
1246 objects. The specification of an application level integrity check
1247 of the received object is outside the scope of this document.
1249 At the packet level, it is RECOMMENDED that a packet level
1250 authentication be used to ensure that each received packet is an
1251 authentic and uncorrupted packet containing FEC data for the object
1252 arriving from the specified sender. Packet level authentication has
1253 the advantage that corrupt or forged packets can be discarded
1254 individually and the received authenticated packets can be used to
1255 accurately reconstruct the object. Thus, the effect of a denial of
1256 service attack that injects forged packets is proportional only to
1257 the number of forged packets, and not to the object size. Although
1258 there is currently no IETF standard that specifies how to do
1259 multicast packet level authentication, TESLA [14] is a known
1260 multicast packet authentication scheme that would work.
1262 In addition to providing protection against reconstruction of
1263 inaccurate objects, packet level authentication can also provide some
1264 protection against denial of service attacks on the multiple rate
1265 congestion control. Attackers can try to inject forged packets with
1266 incorrect congestion control information into the multicast stream,
1267 thereby potentially adversely affecting network elements and
1268 receivers downstream of the attack, and much less significantly the
1269 rest of the network and other receivers. Thus, it is also
1270 RECOMMENDED that packet level authentication be used to protect
1271 against such attacks. TESLA [14] can also be used to some extent to
1272 limit the damage caused by such attacks. However, with TESLA a
1273 receiver can only determine if a packet is authentic several seconds
1274 after it is received, and thus an attack against the congestion
1275 control protocol can be effective for several seconds before the
1276 receiver can react to slow down the session reception rate.
1278 Reverse Path Forwarding checks SHOULD be enabled in all network
1279 routers and switches along the path from the sender to receivers to
1280 limit the possibility of a bad agent injecting forged packets into
1281 the multicast tree data path.
1283 A receiver with an incorrect or corrupted implementation of the
1284 multiple rate congestion control building block may affect health of
1285 the network in the path between the sender and the receiver, and may
1286 also affect the reception rates of other receivers joined to the
1287 session. It is therefore RECOMMENDED that receivers be required to
1288 identify themselves as legitimate before they receive the Session
1289 Description needed to join the session. How receivers identify
1290 themselves as legitimate is outside the scope of this document.
1292 Another vulnerability of FLUTE is the potential of receivers
1293 obtaining an incorrect Session Description for the session. The
1294 consequences of this could be that legitimate receivers with the
1295 wrong Session Description are unable to correctly receive the session
1296 content, or that receivers inadvertently try to receive at a much
1297 higher rate than they are capable of, thereby disrupting traffic in
1298 portions of the network. To avoid these problems, it is RECOMMENDED
1299 that measures be taken to prevent receivers from accepting incorrect
1300 Session Descriptions, e.g., by using source authentication to ensure
1301 that receivers only accept legitimate Session Descriptions from
1302 authorized senders. How this is done is outside the scope of this
1303 document.
1305 8. IANA Considerations
1307 No information in this specification is directly subject to IANA
1308 registration. However, building blocks components used by ALC may
1309 introduce additional IANA considerations. In particular, the FEC
1310 building block used by FLUTE does require IANA registration of the
1311 FEC codec used.
1313 9. Acknowledgements
1315 The following persons have contributed to this specification: Brian
1316 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1317 Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen and Lorenzo
1318 Vicisano. The authors would like to thank all the contributors for
1319 their valuable work in reviewing and providing feedback regarding
1320 this specification.
1322 Normative references
1324 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1325 Levels", RFC 2119, BCP 14, March 1997.
1327 [2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
1328 "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
1329 3450, December 2002.
1331 [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
1332 J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
1333 RFC 3451, December 2002.
1335 [4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
1336 J. Crowcroft, "Forward Error Correction (FEC) Building Block",
1337 RFC 3452, December 2002.
1339 [5] Mills, D., "Network Time Protocol (Version 3), Specification,
1340 Implementation and Analysis", RFC 1305, March 1992.
1342 [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1343 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
1344 HTTP/1.1", RFC 2616, June 1999.
1346 [7] Luby, M. and L. Vicisano, "Compact Forward Error Correction
1347 (FEC) Schemes", RFC 3695, February 2004.
1349 [8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
1350 Schema Part 1: Structures", W3C Recommendation, May 2001.
1352 [9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
1353 Recommendation, May 2001.
1355 Informative references
1357 [10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1358 Specification version 3.3", RFC 1950, May 1996.
1360 [11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
1361 Protocol", RFC 2974, October 2000.
1363 [12] Handley, M. and V. Jacobson, "Session Description Protocol",
1364 RFC 2327, April 1998.
1366 [13] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
1367 STD 5, August 1989.
1369 [14] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and
1370 Secure Source Authentication for Multicast, Network and
1371 Distributed System Security Symposium, NDSS 2001, pp. 35-46.",
1372 February 2001.
1374 [15] Holbrook, H., "A Channel Model for Multicast, Ph.D.
1375 Dissertation, Stanford University, Department of Computer
1376 Science, Stanford, California", August 2001.
1378 [16] Deutsch, P., "DEFLATE Compressed Data Format Specification
1379 version 1.3", RFC 1951, May 1996.
1381 [17] Deutsch, P., "GZIP file format specification version 4.3", RFC
1382 1952, May 1996.
1384 [18] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
1385 2633, June 1999.
1387 [19] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
1388 Language) XML-Signature Syntax and Processing", RFC 3275, March
1389 2002.
1391 [20] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
1392 Mail Extensions (MIME) Part Four: Registration Procedures", RFC
1393 2048, November 1996.
1395 [21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
1396 Three: Message Header Extensions for Non-ASCII Text", RFC 1521,
1397 November 1996.
1399 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1400 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1401 session initiation protocol", RFC 3261, June 2002.
1403 Authors' Addresses
1405 Toni Paila
1406 Nokia
1407 Itamerenkatu 11-13
1408 Helsinki FIN-00180
1409 Finland
1411 EMail: toni.paila@nokia.com
1413 Michael Luby
1414 Digital Fountain
1415 39141 Civic Center Dr.
1416 Suite 300
1417 Fremont, CA 94538
1418 USA
1420 EMail: luby@digitalfountain.com
1422 Rami Lehtonen
1423 TeliaSonera
1424 Hatanpaan valtatie 18
1425 Tampere FIN-33100
1426 Finland
1428 EMail: rami.lehtonen@teliasonera.com
1430 Vincent Roca
1431 INRIA Rhone-Alpes
1432 655, av. de l'Europe
1433 Montbonnot
1434 St Ismier cedex 38334
1435 France
1437 EMail: vincent.roca@inrialpes.fr
1439 Rod Walsh
1440 Nokia
1441 Visiokatu 1
1442 Tampere FIN-33720
1443 Finland
1445 EMail: rod.walsh@nokia.com
1447 Appendix A. Receiver operation (informative)
1449 This section gives an example how the receiver of the file delivery
1450 session may operate. Instead of a detailed state-by-state
1451 specification the following should be interpreted as a rough sequence
1452 of an envisioned file delivery receiver.
1454 1. The receiver obtains the description of the file delivery session
1455 identified by the pair: (source IP address, Transport Session
1456 Identifier). The receiver also obtains the destination IP
1457 addresses and respective ports associated with the file delivery
1458 session.
1460 2. The receiver joins the channels in order to receive packets
1461 associated with the file delivery session. The receiver may
1462 schedule this join operation utilizing the timing information
1463 contained in a possible description of the file delivery session.
1465 3. The receiver receives ALC/LCT packets associated with the file
1466 delivery session. The receiver checks that the packets match the
1467 declared Transport Session Identifier. If not, packets are
1468 silently discarded.
1470 4. While receiving, the receiver demultiplexes packets based on their
1471 TOI and stores the relevant packet information in an appropriate
1472 area for recovery of the corresponding file. Multiple files can be
1473 reconstructed concurrently.
1475 5. Receiver recovers an object. An object can be recovered when an
1476 appropriate set of packets containing Encoding Symbols for the
1477 transport object have been received. An appropriate set of packets
1478 is dependent on the properties of the FEC Encoding ID and FEC
1479 Instance ID, and on other information contained in the FEC Object
1480 Transmission Information.
1482 6. If the recovered object was an FDT Instance with FDT Instance ID
1483 'N', the receiver parses the payload of the instance 'N' of FDT
1484 and updates its FDT database accordingly. The receiver identifies
1485 FDT Instances within a file delivery session by the EXT_FDT header
1486 extension. Any object that is delivered using EXT_FDT header
1487 extension is an FDT Instance, uniquely identified by the FDT
1488 Instance ID. Note that TOI '0' is exclusively reserved for FDT
1489 delivery.
1491 7. If the object recovered is not an FDT Instance but a file, the
1492 receiver looks up its FDT database to get the properties described
1493 in the database, and assigns file with the given properties. The
1494 receiver also checks that received content length matches with the
1495 description in the database. Optionally, if MD5 checksum has been
1496 used, the receiver checks that calculated MD5 matches with the
1497 description in the FDT database.
1499 8. The actions the receiver takes with imperfectly received files
1500 (missing data, mismatching digestive, etc.) is outside the scope
1501 of this specification. When a file is recovered before the
1502 associated file description entry is available, a possible
1503 behavior is to wait until an FDT Instance is received that
1504 includes the missing properties.
1506 9. If the file delivery session end time has not been reached go back
1507 to 3. Otherwise end.
1509 Appendix B. Example of FDT Instance (informative)
1511
1512
1516
1520
1528
1530 Intellectual Property Statement
1532 The IETF takes no position regarding the validity or scope of any
1533 intellectual property or other rights that might be claimed to
1534 pertain to the implementation or use of the technology described in
1535 this document or the extent to which any license under such rights
1536 might or might not be available; neither does it represent that it
1537 has made any effort to identify any such rights. Information on the
1538 IETF's procedures with respect to rights in standards-track and
1539 standards-related documentation can be found in BCP-11. Copies of
1540 claims of rights made available for publication and any assurances of
1541 licenses to be made available, or the result of an attempt made to
1542 obtain a general license or permission for the use of such
1543 proprietary rights by implementors or users of this specification can
1544 be obtained from the IETF Secretariat.
1546 The IETF invites any interested party to bring to its attention any
1547 copyrights, patents or patent applications, or other proprietary
1548 rights which may cover technology that may be required to practice
1549 this standard. Please address the information to the IETF Executive
1550 Director.
1552 Full Copyright Statement
1554 Copyright (C) The Internet Society (2004). All Rights Reserved.
1556 This document and translations of it may be copied and furnished to
1557 others, and derivative works that comment on or otherwise explain it
1558 or assist in its implementation may be prepared, copied, published
1559 and distributed, in whole or in part, without restriction of any
1560 kind, provided that the above copyright notice and this paragraph are
1561 included on all such copies and derivative works. However, this
1562 document itself may not be modified in any way, such as by removing
1563 the copyright notice or references to the Internet Society or other
1564 Internet organizations, except as needed for the purpose of
1565 developing Internet standards in which case the procedures for
1566 copyrights defined in the Internet Standards process must be
1567 followed, or as required to translate it into languages other than
1568 English.
1570 The limited permissions granted above are perpetual and will not be
1571 revoked by the Internet Society or its successors or assignees.
1573 This document and the information contained herein is provided on an
1574 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1575 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1576 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1577 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1578 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1580 Acknowledgment
1582 Funding for the RFC Editor function is currently provided by the
1583 Internet Society.