idnits 2.17.1
draft-ietf-rmt-flute-07.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 8 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 (December 11, 2003) is 7441 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)
** Downref: Normative reference to an Experimental draft:
draft-ietf-rmt-bb-fec-supp-compact (ref. '7')
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Obsolete informational reference (is this intentional?): RFC 2633 (ref.
'17') (Obsoleted by RFC 3851)
Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: June 10, 2004 M. Luby
4 Digital Fountain
5 R. Lehtonen
6 TeliaSonera
7 V. Roca
8 INRIA Rhone-Alpes
9 R. Walsh
10 Nokia
11 December 11, 2003
13 FLUTE - File Delivery over Unidirectional Transport
14 draft-ietf-rmt-flute-07.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 June 10, 2004.
38 Copyright Notice
40 Copyright (C) The Internet Society (2003). 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 . . . 9
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 . . . . . . . . . . . . . . . . . . . 12
66 3.4.3 Content Encoding of FDT Instance . . . . . . . . . . . . . . 14
67 3.5 Multiplexing of files within a file delivery session . . . . 15
68 4. Channels, congestion control and timing . . . . . . . . . . 16
69 5. Delivering FEC Object Transmission Information . . . . . . . 17
70 5.1 Use of EXT_FTI for delivery of FEC Object Transmission
71 Information . . . . . . . . . . . . . . . . . . . . . . . . 18
72 5.1.1 General EXT_FTI format . . . . . . . . . . . . . . . . . . . 18
73 5.1.2 FEC Encoding ID specific formats for EXT_FTI . . . . . . . . 19
74 5.2 Use of FDT for delivery of FEC Object Transmission
75 Information . . . . . . . . . . . . . . . . . . . . . . . . 22
76 6. Describing file delivery sessions . . . . . . . . . . . . . 23
77 7. Security Considerations . . . . . . . . . . . . . . . . . . 24
78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
80 Normative references . . . . . . . . . . . . . . . . . . . . 26
81 Informative references . . . . . . . . . . . . . . . . . . . 27
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
83 A. Receiver operation (informative) . . . . . . . . . . . . . . 29
84 B. Example of FDT Instance (informative) . . . . . . . . . . . 30
85 Intellectual Property and Copyright Statements . . . . . . . 31
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 FEC Object Transmission Information is to be delivered within a
124 file delivery session. Section 6 defines the required parameters for
125 describing file delivery sessions in a general case. Section 7
126 outlines security considerations regarding file delivery with FLUTE.
127 Last, there are two informative appendixes. The first appendix gives
128 an example of File Delivery Table. The second appendix describes an
129 envisioned receiver operation for the receiver of the file delivery
130 session.
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 files which enable user applications to
161 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 delivery. FLUTE
180 requires connectivity between a sender and receivers but does not
181 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. Thus, the inherent raw scalability of FLUTE is unlimited.
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) [12] and the Source-Specific Multicast
189 (SSM) [14].
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 "www.ex.com/docs/file.txt". Using the example, the following
233 properties describe the properties that need to be conveyed by the
234 file delivery protocol.
236 * Globally unique identifier of the file, expressed as either
237 absolute or relative URI. This is used as an identifier and
238 optionally also as a location for the file. In the above example:
239 "www.ex.com/docs/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 SMIME [17] as the
263 content encoding type for files with this authentication wrapper,
264 and one could use XML-DSIG [18] to digitally sign an FDT Instance.
266 3.1 File delivery session
268 ALC is a protocol instantiation of Layered Coding Transport building
269 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
270 this document we will use the concept ALC/LCT session to collectively
271 denote the interchangeable terms ALC session and LCT session.
273 An ALC/LCT session consists of a set of logically grouped ALC/LCT
274 channels associated with a single sender sending packets with ALC/LCT
275 headers for one or more objects. An ALC/LCT channel is defined by the
276 combination of a sender and an address associated with the channel by
277 the sender. A receiver joins a channel to start receiving the data
278 packets sent to the channel by the sender, and a receiver leaves a
279 channel to stop receiving data packets from the channel.
281 One of the fields carried in the ALC/LCT header is the Transport
282 Session Identifier (TSI). The TSI is scoped by the source IP address,
283 and the (source IP address, TSI) pair uniquely identifies a session,
284 i.e., the receiver uses this pair carried in each packet to uniquely
285 identify from which session the packet was received. In case multiple
286 objects are carried within a session another field within the ALC/LCT
287 header, the Transport Object Identifier (TOI), identifies from which
288 object within the session the data in the packet was generated. Note
289 that each object is associated with a unique TOI within the scope of
290 a session.
292 When FLUTE is used for file delivery over ALC the following rules
293 apply:
295 * The ALC/LCT session is called file delivery session.
297 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
298 Delivery Table Instance' (section 3.2)
300 * The TOI field MUST be included in ALC packets sent within a FLUTE
301 session, with the exception that ALC packets sent in a FLUTE
302 session with the Close Session (A) flag set to 1 (signaling the
303 end of the session) and containing no payload MAY omit the TOI.
304 See Section 5.1 of RFC 3451 [3] for the LCT definition of the
305 Close Session flag, and see Section 4.2 of RFC 3450 [2] for an
306 example of its use within an ALC packet.
308 * The TOI value '0' is reserved for delivery of File Delivery Table
309 Instances. Each File Delivery Table Instance is uniquely
310 identified by an FDT Instance ID.
312 * Each file in a file delivery session MUST be associated with a TOI
313 (>0) in the scope of that session.
315 * Information carried in the headers and the payload of a packet is
316 scoped by the source IP address and the TSI. Information
317 particular to the object carried in the headers and the payload of
318 a packet is further scoped by the TOI for file objects, and is
319 further scoped by both the TOI and the FDT Instance ID for FDT
320 Instance objects.
322 3.2 File Delivery Table
324 The File Delivery Table (FDT) provides a means to describe various
325 attributes associated with files that are to be delivered within the
326 file delivery session. The following lists are examples of such
327 attributes, and are not intended to be mutually exclusive nor
328 exhaustive.
330 Attributes related to the delivery of file:
332 - TOI value that represents the file
334 - FEC Instance ID
336 - FEC Object Transmission Information
338 - Size of the transport object carrying the file
340 - Aggregate rate of sending packets to all channels
342 Attributes related to the file itself:
344 - Name, Identification and Location of file (specified by the URI)
346 - MIME media type of file
348 - Size of file
350 - Encoding of file
352 - Message digest of file
354 Some of these attributes MUST be included in the file description
355 entry for a file, others are optional, as defined in section 3.4.2.
357 Logically, the FDT is a set of file description entries for files to
358 be delivered in the session. Each file description entry MUST include
359 the TOI for the file that it describes and the URI indicating the
360 location of the file. The TOI is included in each ALC/LCT data packet
361 during the delivery of the file, and thus the TOI carried in the file
362 description entry is how the receiver determines which ALC/LCT data
363 packets contain information about which file. Each file description
364 entry may also contain one or more descriptors that map the
365 above-mentioned attributes to the file.
367 Each file delivery session MUST have an FDT that is local to the
368 given session. The FDT MUST provide a file description entry mapped
369 to a TOI for each file appearing within the session. An object that
370 is delivered within the ALC session, but not described in the FDT, is
371 not considered a 'file' belonging to the file delivery session.
372 Handling of these unmapped TOIs (TOIs that are not resolved by the
373 FDT) is out of scope of this specification.
375 Within the file delivery session the FDT is delivered as FDT
376 Instances. An FDT Instance contains one or more file description
377 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
378 superset of, or complement any other FDT Instance. A certain FDT
379 Instance may be repeated several times during a session, even after
380 subsequent FDT Instances (with higher FDT Instance ID numbers) have
381 been transmitted. Each FDT Instance contains at least a single file
382 description entry and at most the complete FDT of the file delivery
383 session.
385 A receiver of the file delivery session keeps an FDT database for
386 received file description entries. The receiver maintains the
387 database, for example, upon reception of FDT Instances. Thus, at any
388 given time the contents of the FDT database represent the receiver's
389 current view of the FDT of the file delivery session. Since each
390 receiver behaves independently of other receivers, it SHOULD NOT be
391 assumed that the contents of the FDT database are the same for all
392 the receivers of a given file delivery session.
394 Since FDT database is an abstract concept, the structure and the
395 maintaining of the FDT database are left to individual
396 implementations and are thus out of scope of this specification.
398 3.3 Dynamics of FDT Instances within file delivery session
400 The following rules define the dynamics of the FDT Instances within a
401 file delivery session:
403 * For every file delivered within a file delivery session there MUST
404 be a file description entry included in at least one FDT Instance
405 sent within the session. A file description entry contains at a
406 minimum the mapping between the TOI and the URI.
408 * An FDT Instance MAY appear in any part of the file delivery
409 session and packets for an FDT Instance MAY be interleaved with
410 packets for other files or other FDT Instances within a session.
412 * The TOI value of '0' MUST be reserved for delivery of FDT
413 Instances. The use of other TOI values for FDT Instances is
414 outside the scope of this specification.
416 * FDT Instance is identified by the use of a new fixed length LCT
417 Header Extension EXT_FDT (defined later in this section). Each FDT
418 Instance is uniquely identified within the file delivery session
419 by its FDT Instance ID. Any ALC/LCT packet carrying FDT Instance
420 (indicated by TOI = 0) MUST include EXT_FDT.
422 * It is RECOMMENDED that FDT Instance that contains the file
423 description entry for a file is sent prior to the sending of the
424 described file within a file delivery session.
426 * Within a file delivery session, any TOI MAY be described more than
427 once. An example: previous FDT Instance 0 describes TOI of value
428 '3'. Now, subsequent FDT Instances can either keep TOI '3'
429 unmodified on the table, not to include it or complement the
430 description. However, subsequent FDT Instances MUST NOT change the
431 parameters already described for a specific TOI.
433 * An FDT Instance is valid until its expiration time. The expiration
434 time is expressed within the FDT Instance payload as a 32 bit data
435 field. The value of the data field represents the 32 most
436 significant bits of a 64 bit Network Time Protocol (NTP) [5] time
437 value. These 32 bits provide an unsigned integer representing the
438 time in seconds relative to 0 hours 1 January 1900. Handling of
439 wrap-around of the 32 bit time is outside the scope of NTP and
440 FLUTE.
442 * The receiver SHOULD NOT use a received FDT Instance to interpret
443 packets received beyond the expiration time of the FDT Instance.
445 * A sender MUST use an expiry time in the future upon creation of an
446 FDT Instance.
448 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
449 The default is to use FEC Encoding ID 0 for the sending of FDT
450 Instances. (Note that since FEC Encoding ID 0 is the default for
451 FLUTE, this implies that Source Block Number and Encoding Symbol
452 ID lengths both default to 16 bytes each.)
454 Generally, a receiver needs to receive an FDT Instance describing a
455 file before it is able to recover the file itself. In this sense FDT
456 Instances are of higher priority than files. Thus, it is RECOMMENDED
457 that FDT Instances describing a file be sent with at least as much
458 reliability within a session (more often or with more FEC protection)
459 as the files they describe. In particular, if FDT Instances are
460 generally longer than one Encoding Symbol in length it is RECOMMENDED
461 that an FEC code that can provide protection against loss be used for
462 delivering FDT Instances, i.e., in this case it is RECOMMENDED not to
463 use FEC Encoding ID 0. How often the description of a file is sent in
464 an FDT Instance or how much FEC protection is provided for each FDT
465 Instance (if the FDT Instance is longer than one Encoding Symbol) is
466 dependent on the particular application and outside the scope of this
467 document.
469 3.4 Structure of FDT Instance packets
471 FDT Instances are carried in ALC packets with TOI = 0 and with an
472 additional REQUIRED LCT Header extension called the FDT Instance
473 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
474 ID that uniquely identifies FDT Instances within a file delivery
475 session. The FDT Instance Header is placed in the same way as any
476 other LCT extension header. There MAY be other LCT extension headers
477 in use.
479 The LCT extension headers are followed by the FEC Payload ID, and
480 finally the Encoding Symbols for the FDT Instance which contains one
481 or more file description entries. The FDT Instance MAY span over
482 several ALC packets - the number of ALC packets is a function of the
483 FEC Object Transmission Information associated to this FDT Instance.
484 The FDT Instance Header is carried in each ALC packet carrying the
485 FDT Instance. The FDT Instance Header is identical for all ALC/LCT
486 packets for a particular FDT Instance.
488 The overall format of ALC/LCT packets carrying an FDT Instance is
489 depicted in the Figure 1 below. All integer fields are carried in
490 "big-endian" or "network order" format, that is, most significant
491 byte (octet) first. As defined in [2], all ALC/LCT packets are sent
492 using UDP.
494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
495 | UDP header |
496 | |
497 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
498 | Default LCT header (with TOI = 0) |
499 | |
500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
501 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
502 | |
503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
504 | FEC Payload ID |
505 | |
506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
507 | Encoding Symbol for FDT Instance |
508 | ... |
509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
510 Figure 1 - Overall FDT Packet
512 3.4.1 Format of FDT Instance Header
514 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
515 LCT header extension [3]. The Header Extension Type (HET) for the
516 extension is 192. Its format is defined below:
518 0 1 2 3
519 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
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | HET = 192 | V | FDT Instance ID |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
524 Version of FLUTE (V), 4 bits:
526 This document specifies FLUTE version 1. Hence in any ALC packet that
527 carries FDT Instance and that belongs to the file delivery session as
528 specified in this specification MUST set this field to '1'.
530 FDT Instance ID, 20 bits:
532 For each file delivery session the numbering of FDT Instances starts
533 from '0' and is incremented by exactly one for each subsequent FDT
534 Instance. After reaching the maximum value (2^20-1), the numbering
535 starts again from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is
536 considered higher than 2^20-1. Receiver handling of wraparound and
537 other special situations (for example, missing FDT Instance IDs
538 resulting in longer increments than one) is left out of this
539 specification to individual implementations of FLUTE.
541 3.4.2 Syntax of FDT Instance
543 The FDT Instance contains file description entries that provide the
544 mapping functionality described in 3.2 above.
546 The FDT Instance is an XML structure that has a single root element
547 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
548 attribute, which tells the expiry time of the FDT Instance. In
549 addition, the "FDT-Instance" element MAY contain "Complete" attribute
550 (boolean), which MAY be used to signal that the given FDT Instance is
551 the last FDT Instance to be expected on this file delivery session.
552 For each file to be declared in the given FDT Instance there is a
553 single file description entry in the FDT Instance. Each entry is
554 represented by element "File" which is a child element of the FDT
555 Instance structure.
557 The attributes of "File" element in the XML structure represent the
558 attributes given to the file that is delivered in the file delivery
559 session. Each "File" element MUST contain at least two attributes
560 "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI
561 value as described in section 3.3 above. "Content-Location" MUST be
562 assigned a valid URI as defined in [6].
564 In addition to mandatory attributes, the "File" entity MAY contain
565 other attributes of which the following are specifically pointed out.
567 * If the MIME type of the file is described, attribute
568 "Content-Type" MUST be used for the purpose as defined in [6].
570 * If the length of the file is described, attribute "Content-Length"
571 MUST be used for the purpose as defined in [6]. If the length of
572 the file is different than the length of the transport object that
573 carries it (the file was content encoded before transport),
574 another attribute "Transfer-Length" MAY be used. The attribute
575 "Transfer-Length" specifies the size of the transport object in
576 bytes.
578 * If the content encoding scheme of the file is described, attribute
579 "Content-Encoding" MUST be used for the purpose as defined in [6].
581 * If the MD5 message digest of the file is described, attribute
582 "Content-MD5" MUST be used for the purpose as defined in [6].
584 * The FEC Object Transmission Information attributes as described in
585 section 5.2.
587 The following specifies the XML Schema [8][9] for FDT Instance:
589
590
594
595
596
597
598
599
600
601
603
605
607
609
611
613
615
617
619
621
623
624
625
626
627
628
629
631 Any XML document that conforms with the above XML Schema is a valid
632 FDT. This way FDT provides extensibility to support private
633 attributes within the file description entries. Those could be, for
634 example, the attributes related to the delivery of the file (timing,
635 packet transmission rate, etc.).
637 In case the basic FDT XML Schema is extended in terms of new
638 descriptors, those MUST be placed within the attributes of the
639 element "File". It is RECOMMENDED that the new descriptors applied in
640 the FDT are in the format of MIME fields and are either defined in
641 HTTP/1.1 specification [6] or otherwise well-known specification.
643 3.4.3 Content Encoding of FDT Instance
645 The FDT Instance itself MAY be content encoded, for example
646 compressed. This specification defines FDT Instance Content Encoding
647 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific
648 LCT header extension [3]. The Header Extension Type (HET) for the
649 extension is 193. If the FDT Instance is content encoded, the
650 EXT_CENC MUST be used to signal the content encoding type. In that
651 case, EXT_CENC header extension MUST be used in all ALC packets
652 carrying the same FDT Instance ID. Consequently, when EXT_CENC header
653 is used, it MUST be used together with a proper FDT Instance Header
654 (EXT_FDT). Within a file delivery session, FDT Instances that are not
655 content encoded and FDT Instances that are content encoded MAY both
656 appear. If content encoding is not used for a given FDT Instance, the
657 EXT_CENC MUST NOT be used in any packet carrying the FDT Instance.
658 The format of EXT_CENC is defined below:
660 0 1 2 3
661 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
662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
663 | HET = 193 | CENC | Reserved |
664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
666 Content Encoding Algoritm (CENC), 8 bits:
668 This field signals the content encoding algorithm used in the FDT
669 Instance payload. The definition of this field is outside the scope
670 of this specification. Applicable content encoding algorithms
671 include, for example, ZLIB [10], DEFLATE [15] and GZIP [16].
673 Reserved, 16 bits:
675 This field MUST be set to all '0'.
677 3.5 Multiplexing of files within a file delivery session
679 The delivered files are carried as transport objects (identified with
680 TOIs) in the file delivery session. All these objects, including the
681 FDT Instances, MAY be multiplexed in any order and in parallel with
682 each other within a session, i.e., packets for one file MAY be
683 interleaved with packets for other files or other FDT Instances
684 within a session.
686 Multiple FDT Instances MAY be delivered in a single session using TOI
687 = 0. In this case, it is RECOMMENDED that the sending of a previous
688 FDT Instance SHOULD end before the sending of the next FDT Instance
689 starts. However, due to unexpected network conditions, packets for
690 the FDT Instances MAY be interleaved. A receiver can determine which
691 FDT Instance a packet contains information about since the FDT
692 Instances are uniquely identified by their FDT Instance ID carried in
693 the EXT_FDT headers.
695 4. Channels, congestion control and timing
697 ALC/LCT has a concept of channels and congestion control. There are
698 four scenarios FLUTE is envisioned to be applied.
700 (a) Use a single channel and a single-rate congestion control
701 protocol.
703 (b) Use multiple channels and a multiple-rate congestion control
704 protocol. In this case the FDT Instances MAY be delivered on more
705 than one channel.
707 (c) Use a single channel without congestion control supplied by ALC,
708 but only when in a controlled network environment where flow/
709 congestion control is being provided by other means.
711 (d) Use multiple channels without congestion control supplied by ALC,
712 but only when in a controlled network environment where flow/
713 congestion control is being provided by other means. In this case
714 the FDT Instances MAY be delivered on more than one channel.
716 When using just one channel for a file delivery session, as in (a)
717 and (c), the notion of 'prior' and 'after' are intuitively defined
718 for the delivery of objects with respect to their delivery times.
720 However, if multiple channels are used, as in (b) and (d), it is not
721 straightforward to state that an object was delivered 'prior' to the
722 other. An object may begin to be delivered on one or more of those
723 channels before the delivery of a second object begins. However, the
724 use of multiple channels/layers may complete the delivery of the
725 second object before the first. This is not a problem when objects
726 are delivered sequentially using a single channel. Thus, if the
727 application of FLUTE has a mandatory or critical requirement that the
728 first transport object must complete 'prior' to the second one, it is
729 RECOMMENDED that only a single channel is used for the file delivery
730 session.
732 Furthermore, if multiple channels are used then a receiver joined to
733 the session at a low reception rate will only be joined to the lower
734 layers of the session. Thus, since the reception of FDT Instances is
735 of higher priority than the reception of files (because the reception
736 of files depends on the reception of an FDT Instance describing it),
737 the following is RECOMMENDED:
739 1. The layers to which packets for FDT Instances are sent SHOULD NOT
740 be biased towards those layers to which lower rate receivers are
741 not joined. For example, it is ok to put all the packets for an
742 FDT Instance into the lowest layer (if this layer carries enough
743 packets to deliver the FDT to higher rate receivers in a
744 reasonable amount of time), but it is not ok to put all the
745 packets for an FDT Instance into the higher layers that only high
746 rate receivers will receive.
748 2. If FDT Instances are generally longer than one Encoding Symbol in
749 length and some packets for FDT Instances are sent to layers that
750 lower rate receivers do not receive, an FEC Encoding other than
751 FEC Encoding ID 0 SHOULD be used to deliver FDT Instances. This
752 is because in this case, even when there is no packet loss in the
753 network, a lower rate receiver will not receive all packets sent
754 for an FDT Instance.
756 5. Delivering FEC Object Transmission Information
758 FLUTE inherits the use of FEC building block [4] from ALC. When using
759 FLUTE for file delivery over ALC the FEC Object Transmission
760 Information MUST be delivered in-band within the file delivery
761 session. In this section, two methods are specified for FLUTE for
762 this purpose: the use of ALC specific LCT extension header EXT_FTI
763 [2], and, the use of FDT.
765 The receiver of file delivery session MUST support delivery of FEC
766 Object Transmission Information using the EXT_FTI for the FDT
767 Instances carried using TOI value 0. For the TOI values other than 0
768 the receiver MUST support both methods: the use of EXT_FTI and the
769 use of FDT.
771 The FEC Object Transmission Information that needs to be delivered to
772 receivers MUST be exactly the same whether it is delivered using
773 EXT_FTI or using FDT (or both). Section 5.1 describes the required
774 FEC Object Transmission Information that MUST be delivered to
775 receivers for various FEC Encoding IDs. In addition, it describes the
776 delivery using EXT_FTI. Section 5.2 describes the delivery using FDT.
778 The FEC Object Transmission Information regarding a given TOI may be
779 available from several sources. In this case, it is RECOMMENDED that
780 the receiver of the file delivery session prioritizes the sources in
781 the following way (in the order of decreasing priority).
783 1. FEC Object Transmission Information that is available in EXT_FTI.
785 2. FEC Object Transmission Information that is available in the FDT.
787 5.1 Use of EXT_FTI for delivery of FEC Object Transmission Information
789 As specified in [2], the EXT_FTI header extension is intended to
790 carry in band the FEC Object Transmission Information for an object.
791 It is left up to individual implementations to decide how frequently
792 and in which ALC packets the EXT_FTI header extension is included. In
793 environments with higher packet loss rate, the EXT_FTI might need to
794 be included more frequently in ALC packets than in environments with
795 low error probability. The EXT_FTI MUST be included in at least one
796 sent ALC packet for each FDT Instance.
798 The ALC specification does not define the format or the processing of
799 the EXT_FTI header extension. The following sections specify EXT_FTI
800 when used in FLUTE.
802 In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint
803 field of the ALC/LCT header.
805 5.1.1 General EXT_FTI format
807 The general EXT_FTI format specifies the structure and those
808 attributes of FEC Object Transmission Information that are applicable
809 to any FEC Encoding ID.
811 0 1 2 3
812 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
813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814 | HET = 64 | HEL | |
815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
816 | Transfer Length |
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
818 | FEC Instance ID | FEC Enc. ID Specific Format |
819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
821 Header Extension Type (HET), 8 bits:
823 64 as defined in [2]
825 Header Extension Length (HEL), 8 bits:
827 The length of the whole Header Extension field, expressed in
828 multiples of 32-bit words. This length includes the FEC Encoding ID
829 specific format part.
831 Transfer Length, 48 bits:
833 The length of the transport object that carries the file in bytes.
835 (This is the same as the file length if the file is not content
836 encoded.)
838 FEC Instance ID, optional, 16 bits:
840 This field is used for FEC Instance ID. It is only present if the
841 value of FEC Encoding ID is in the range of 128-255. When the value
842 of FEC Encoding ID is in the range of 0-127, this field is set to 0.
844 FEC Encoding ID Specific Format:
846 Different FEC encoding schemes will need different sets of encoding
847 parameters. Thus, the structure and length of this field depends on
848 FEC Encoding ID. The next sections specify structure of this field
849 for FEC Encoding ID numbers 0, 128, 129 and 130.
851 5.1.2 FEC Encoding ID specific formats for EXT_FTI
853 5.1.2.1 FEC Encoding IDs 0, 128, and 130
855 FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC
856 Encoding ID 128 is 'Small Block, Large Block and Expandable FEC'
857 (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC'
858 (Under-Specified) [7]. For these FEC Encoding IDs, the FEC Encoding
859 ID specific format of EXT_FTI is defined as follows.
861 0 1 2 3
862 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
863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 General EXT_FTI format | Encoding Symbol Length |
865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 | Maximum Source Block Length |
867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
869 Encoding Symbol Length, 16 bits:
871 Length of Encoding Symbol in bytes.
873 All Encoding Symbols of a transport object MUST be equal to this
874 length, with the optional exception of the last source symbol of the
875 last source block (so that redundant padding is not mandatory in this
876 last symbol). This last source symbol MUST be logically padded out
877 with zeroes when another Encoding Symbol is computed based on this
878 source symbol to ensure the same interpretation of this Encoding
879 Symbol value by the sender and receiver. However, this padding need
880 not be actually sent with the data of the last source symbol.
882 Maximum Source Block Length, 32 bits
883 The maximum number of source symbols per source block.
885 This EXT_FTI specification requires that an algorithm is known to
886 both sender and receivers for determining the size of all source
887 blocks of the transport object that carries the file identified by
888 the TOI (or within the FDT Instance identified by the TOI and the FDT
889 Instance ID). The algorithm SHOULD be the same for all files using
890 the same FEC Encoding ID within a session.
892 Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
893 use.
895 For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only
896 well known way the receiver can determine the length of each source
897 block. Thus, the algorithm does two things: (a) it tells the receiver
898 the length of each particular source block as it is receiving packets
899 for that source block - this is essential to all of these FEC
900 schemes; and, (b) it provides the source block structure immediately
901 to the receiver so that the receiver can determine where to save
902 recovered source blocks at the beginning - this is an optimization
903 which is essential for some implementations.
905 5.1.2.2 FEC Encoding ID 129
907 Small Block Systematic FEC (Under-Specified). The FEC Encoding ID
908 specific format of EXT_FTI is defined as follows.
910 0 1 2 3
911 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
912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
913 General EXT_FTI format | Encoding Symbol Length |
914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915 | Maximum Source Block Length | Max. Num. of Encoding Symbols |
916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 Encoding Symbol Length, 16 bits:
920 Length of Encoding Symbol in bytes.
922 Maximum Source Block Length, 16 bits:
924 The maximum number of source symbols per source block.
926 Maximum Number of Encoding Symbols, 16 bits:
928 Maximum number of Encoding Symbols that can be generated for a source
929 block.
931 All Encoding Symbols of a transport object MUST be equal to this
932 length, with the optional exception of the last source symbol of the
933 last source block (so that redundant padding is not mandatory in this
934 last symbol). This last source symbol MUST be logically padded out
935 with zeroes when another Encoding Symbol is computed based on this
936 source symbol to ensure the same interpretation of this Encoding
937 Symbol value by the sender and receiver. However, this padding need
938 not be actually sent with the data of the last source symbol.
940 This EXT_FTI specification requires that an algorithm is known to
941 both sender and receivers for determining the size of all source
942 blocks of the transport object that carries the file identified by
943 the TOI (or within the FDT Instance identified by the TOI and the FDT
944 Instance ID). The algorithm SHOULD be the same for all files using
945 the same FEC Encoding ID within a session.
947 Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this
948 use. For FEC Encoding ID 129 the FEC Payload ID in each data packet
949 already contains the source block length for the source block
950 corresponding to the Encoding Symbol carried in the data packet.
951 Thus, the algorithm for computing source blocks for FEC Encoding ID
952 129 could be to just use the source block lengths carried in data
953 packets within the FEC Payload ID. However, the algorithm described
954 in Section 5.1.2.3 is useful for the receiver to compute the source
955 block structure at the beginning of the reception of data packets for
956 the file. If the algorithm described in Section 5.1.2.3 is used then
957 it MUST be the case that the source block lengths that appear in data
958 packets agree with the source block lengths calculated by the
959 algorithm.
961 5.1.2.3 Algorithm for Computing Source Block Structure
963 This algorithm computes a source block structure so that all source
964 blocks are as close to being equal length as possible. A first number
965 of source blocks are of the same larger length, and the remaining
966 second number of source blocks are sent of the same smaller length.
967 The total number of source blocks (N), the first number of source
968 blocks (I), the second number of source blocks (N-I), the larger
969 length (A_large) and the smaller length (A_small) are calculated
970 thus,
972 Input:
973 B -- Maximum Source Block Length, i.e., the maximum number of
974 source symbols per source block
975 L -- Transfer Length in bytes
976 E -- Encoding Symbol Length in bytes
978 Output:
980 N -- The number of source blocks into which the transport
981 object is partitioned.
983 The number and lengths of source symbols in each of the N
984 source blocks.
986 Algorithm:
987 (a) The number of source symbols in the transport object is
988 computed as T = L/E rounded up to the nearest integer.
989 (b) The transport object is partitioned into N source blocks,
990 where N = T/B rounded up to the nearest integer
991 (c) The average length of a source block, A = T/N
992 (this may be non-integer)
993 (d) A_large = A rounded up to the nearest integer
994 (it will always be the case that the value of A_large is at
995 most B)
996 (e) A_small = A rounded down to the nearest integer
997 (if A is an integer A_small = A_large,
998 and otherwise A_small = A_large - 1)
999 (f) The fractional part of A, A_fraction = A - A_small
1000 (g) I = A_fraction * N
1001 (I is an integer between 0 and N-1)
1002 (h) Each of the first I source blocks consists of A_large source
1003 symbols, each source symbol is E bytes in length. Each of the
1004 remaining N-I source blocks consist of A_small source symbols,
1005 each source symbol is E bytes in length except that the last
1006 source symbol of the last source block is L-(((L-1)/E) rounded
1007 down to the nearest integer)*E bytes in length.
1009 5.2 Use of FDT for delivery of FEC Object Transmission Information
1011 The FDT delivers FEC Object Transmission Information for each file
1012 using an appropriate attribute within the "File" element of the FDT
1013 structure. For future FEC Encoding IDs, if the attributes listed
1014 below do not fulfil the needs of describing the FEC Object
1015 Transmission Information then additional new attributes MAY be used.
1017 * "Transfer-Length" is semantically equivalent with the field
1018 "Transfer Length" of EXT_FTI.
1020 * "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the
1021 field "FEC Instance ID" of EXT_FTI.
1023 * "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
1024 with the field "Maximum Source Block Length" of EXT_FTI for FEC
1025 Encoding IDs 0, 128 and 130, and semantically equivalent with the
1026 field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID
1027 129.
1029 * "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with
1030 the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs
1031 0, 128, 129 and 130.
1033 * "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically
1034 equivalent with the field "Maximum Number of Encoding Symbols" of
1035 EXT_FTI for FEC Encoding ID 129.
1037 6. Describing file delivery sessions
1039 To start receiving a file delivery session, the receiver needs to
1040 know transport parameters associated with the session. Interpreting
1041 these parameters and starting the reception therefore represents the
1042 entry point from which thereafter the receiver operation falls into
1043 the scope of this specification. According to [2], the transport
1044 parameters of an ALC/LCT session that the receiver needs to know are:
1046 * The source IP address;
1048 * The number of channels in the session;
1050 * The destination IP address and port number for each channel in the
1051 session;
1053 * The Transport Session Identifier (TSI) of the session;
1055 * An indication that the session carries packets for more than one
1056 object, and this indicates that the TOI field is included in sent
1057 packets;
1059 Optionally, the following parameters MAY be associated with the
1060 session (Note, the list is not exhaustive):
1062 * The start time and end time of the session;
1064 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1065 ID 0 is not used for the delivery of FDT;
1067 * Content Encoding format if optional content encoding of FDT
1068 Instance is used, e.g., compression;
1070 * Some information that tells receiver, in the first place, that the
1071 session contains files that are of interest
1073 How the receiver acquires the above-mentioned parameters is out of
1074 scope of this document. The specification, in particular, does not
1075 mandate or exclude any mechanism. The description can be conveyed to
1076 the receiver via techniques such as Session Announcement Protocol
1077 [11], email, accessing URL, manual configuration, etc. Similarly the
1078 format of this session description is out of the scope of this
1079 document.
1081 7. Security Considerations
1083 The same security consideration that apply to ALC and to the LCT, FEC
1084 and the congestion control building block used in conjunction with
1085 FLUTE also apply to FLUTE.
1087 Because of the use of FEC, FLUTE is especially vulnerable to
1088 denial-of-service attacks by attackers that try to send forged
1089 packets to the session which would prevent successful reconstruction
1090 or cause inaccurate reconstruction of large portions of the FDT or
1091 file by receivers. Like ALC, FLUTE is particularly affected by such
1092 an attack because many receivers may receive the same forged packet.
1093 A malicious attacker may spoof file packets and cause incorrect
1094 recovery of a file.
1096 Even more damaging, a malicious forger may spoof FDT Instance
1097 packets, for example sending packets with erroneous FDT-Instance
1098 fields. Many attacks can follow this approach. For instance a
1099 malicious attacker may alter the Content-Location field of TOI 'n',
1100 to make it point to a system file or a user configuration file.
1101 Then, TOI 'n' can carry a Trojan horse or some other type of virus.
1102 It is thus RECOMMENDED that the FLUTE delivery service at the
1103 receiver does not have write access to the system files or
1104 directories, or any other critical areas. Another example is
1105 generating a bad Content-MD5 sum, leading receivers to reject the
1106 associated file that will be declared corrupted. The Content-Encoding
1107 can also be modified, which also prevents the receivers to correctly
1108 handle the associated file. These examples show that the FDT
1109 information is critical to the FLUTE delivery service.
1111 At the application level, it is RECOMMENDED that an integrity check
1112 on the entire received object be done once the object is
1113 reconstructed to ensure it is the same as the sent object, especially
1114 for objects that are FDT Instances. Moreover, in order to obtain
1115 strong cryptographic integrity protection a digital signature
1116 verifiable by the receiver SHOULD be used to provide this application
1117 level integrity check. However, if even one corrupted or forged
1118 packet is used to reconstruct the object, it is likely that the
1119 received object will be reconstructed incorrectly. This will
1120 appropriately cause the integrity check to fail and in this case the
1121 inaccurately reconstructed object SHOULD be discarded. Thus, the
1122 acceptance of a single forged packet can be an effective denial of
1123 service attack for distributing objects, but an object integrity
1124 check at least prevents inadvertent use of inaccurately reconstructed
1125 objects. The specification of an application level integrity check
1126 of the received object is outside the scope of this document.
1128 At the packet level, it is RECOMMENDED that a packet level
1129 authentication be used to ensure that each received packet is an
1130 authentic and uncorrupted packet containing FEC data for the object
1131 arriving from the specified sender. Packet level authentication has
1132 the advantage that corrupt or forged packets can be discarded
1133 individually and the received authenticated packets can be used to
1134 accurately reconstruct the object. Thus, the effect of a denial of
1135 service attack that injects forged packets is proportional only to
1136 the number of forged packets, and not to the object size. Although
1137 there is currently no IETF standard that specifies how to do
1138 multicast packet level authentication, TESLA [13] is a known
1139 multicast packet authentication scheme that would work.
1141 In addition to providing protection against reconstruction of
1142 inaccurate objects, packet level authentication can also provide some
1143 protection against denial of service attacks on the multiple rate
1144 congestion control. Attackers can try to inject forged packets with
1145 incorrect congestion control information into the multicast stream,
1146 thereby potentially adversely affecting network elements and
1147 receivers downstream of the attack, and much less significantly the
1148 rest of the network and other receivers. Thus, it is also
1149 RECOMMENDED that packet level authentication be used to protect
1150 against such attacks. TESLA [13] can also be used to some extent to
1151 limit the damage caused by such attacks. However, with TESLA a
1152 receiver can only determine if a packet is authentic several seconds
1153 after it is received, and thus an attack against the congestion
1154 control protocol can be effective for several seconds before the
1155 receiver can react to slow down the session reception rate.
1157 Reverse Path Forwarding checks SHOULD be enabled in all network
1158 routers and switches along the path from the sender to receivers to
1159 limit the possibility of a bad agent injecting forged packets into
1160 the multicast tree data path.
1162 A receiver with an incorrect or corrupted implementation of the
1163 multiple rate congestion control building block may affect health of
1164 the network in the path between the sender and the receiver, and may
1165 also affect the reception rates of other receivers joined to the
1166 session. It is therefore RECOMMENDED that receivers be required to
1167 identify themselves as legitimate before they receive the Session
1168 Description needed to join the session. How receivers identify
1169 themselves as legitimate is outside the scope of this document.
1171 Another vulnerability of FLUTE is the potential of receivers
1172 obtaining an incorrect Session Description for the session. The
1173 consequences of this could be that legitimate receivers with the
1174 wrong Session Description are unable to correctly receive the session
1175 content, or that receivers inadvertently try to receive at a much
1176 higher rate than they are capable of, thereby disrupting traffic in
1177 portions of the network. To avoid these problems, it is RECOMMENDED
1178 that measures be taken to prevent receivers from accepting incorrect
1179 Session Descriptions, e.g., by using source authentication to ensure
1180 that receivers only accept legitimate Session Descriptions from
1181 authorized senders. How this is done is outside the scope of this
1182 document.
1184 8. IANA Considerations
1186 No information in this specification is directly subject to IANA
1187 registration. However, building blocks components used by ALC may
1188 introduce additional IANA considerations. In particular, the FEC
1189 building block used by FLUTE does require IANA registration of the
1190 FEC codecs used.
1192 9. Acknowledgements
1194 The following persons have contributed to this specification: Brian
1195 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1196 Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen and Lorenzo
1197 Vicisano. The authors would like to thank all the contributors for
1198 their valuable work in reviewing and providing feedback regarding
1199 this specification.
1201 Normative references
1203 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1204 Levels", RFC 2119, BCP 14, March 1997.
1206 [2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft,
1207 "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC
1208 3450, December 2002.
1210 [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
1211 J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
1212 RFC 3451, December 2002.
1214 [4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
1215 J. Crowcroft, "Forward Error Correction (FEC) Building Block",
1216 RFC 3452, December 2002.
1218 [5] Mills, D., "Network Time Protocol (Version 3), Specification,
1219 Implementation and Analysis", RFC 1305, March 1992.
1221 [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1222 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
1223 HTTP/1.1", RFC 2616, June 1999.
1225 [7] Luby, M. and L. Vicisano, "Compact Forward Error Correction
1226 (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-compact-01 (work in
1227 progress), May 2003.
1229 [8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
1230 Schema Part 1: Structures", W3C Recommendation, May 2001.
1232 [9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
1233 Recommendation, May 2001.
1235 Informative references
1237 [10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1238 Specification version 3.3", RFC 1950, May 1996.
1240 [11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
1241 Protocol", RFC 2974, October 2000.
1243 [12] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
1244 STD 5, August 1989.
1246 [13] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and
1247 Secure Source Authentication for Multicast, Network and
1248 Distributed System Security Symposium, NDSS 2001, pp. 35-46.",
1249 February 2001.
1251 [14] Holbrook, H., "A Channel Model for Multicast, Ph.D.
1252 Dissertation, Stanford University, Department of Computer
1253 Science, Stanford, California", August 2001.
1255 [15] Deutsch, P., "DEFLATE Compressed Data Format Specification
1256 version 1.3", RFC 1951, May 1996.
1258 [16] Deutsch, P., "GZIP file format specification version 4.3", RFC
1259 1952, May 1996.
1261 [17] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
1262 2633, June 1999.
1264 [18] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
1265 Language) XML-Signature Syntax and Processing", RFC 3275, March
1266 2002.
1268 Authors' Addresses
1270 Toni Paila
1271 Nokia
1272 Itamerenkatu 11-13
1273 Helsinki FIN-00180
1274 Finland
1276 EMail: toni.paila@nokia.com
1278 Michael Luby
1279 Digital Fountain
1280 39141 Civic Center Dr.
1281 Suite 300
1282 Fremont, CA 94538
1283 USA
1285 EMail: luby@digitalfountain.com
1287 Rami Lehtonen
1288 TeliaSonera
1289 Hatanpaan valtatie 18
1290 Tampere FIN-33100
1291 Finland
1293 EMail: rami.lehtonen@teliasonera.com
1295 Vincent Roca
1296 INRIA Rhone-Alpes
1297 655, av. de l'Europe
1298 Montbonnot
1299 St Ismier cedex 38334
1300 France
1302 EMail: vincent.roca@inrialpes.fr
1304 Rod Walsh
1305 Nokia
1306 Visiokatu 1
1307 Tampere FIN-33720
1308 Finland
1310 EMail: rod.walsh@nokia.com
1312 Appendix A. Receiver operation (informative)
1314 This section gives an example how the receiver of the file delivery
1315 session may operate. Instead of a detailed state-by-state
1316 specification the following should be interpreted as a rough sequence
1317 of an envisioned file delivery receiver.
1319 1. The receiver obtains the description of the file delivery session
1320 identified by the pair: (source IP address, Transport Session
1321 Identifier). The receiver also obtains the destination IP
1322 addresses and respective ports associated with the file delivery
1323 session.
1325 2. The receiver joins the channels in order to receive packets
1326 associated with the file delivery session. The receiver may
1327 schedule this join operation utilizing the timing information
1328 contained in a possible description of the file delivery session.
1330 3. The receiver receives ALC/LCT packets associated with the file
1331 delivery session. The receiver checks that the packets match the
1332 declared Transport Session Identifier. If not, packets are
1333 silently discarded.
1335 4. While receiving, the receiver demultiplexes packets based on their
1336 TOI and stores the relevant packet information in an appropriate
1337 area for recovery of the corresponding file. Multiple files can be
1338 reconstructed concurrently.
1340 5. Receiver recovers an object. An object can be recovered when an
1341 appropriate set of packets containing Encoding Symbols for the
1342 transport object have been received. An appropriate set of packets
1343 is dependent on the properties of the FEC Encoding ID and FEC
1344 Instance ID, and on other information contained in the FEC Object
1345 Transmission Information.
1347 6. If the recovered object was an FDT Instance with FDT Instance ID
1348 'N', the receiver parses the payload of the instance 'N' of FDT
1349 and updates its FDT database accordingly. The receiver identifies
1350 FDT Instances within a file delivery session by the EXT_FDT header
1351 extension. Any object that is delivered using EXT_FDT header
1352 extension is an FDT Instance, uniquely identified by the FDT
1353 Instance ID. Note that TOI '0' is exclusively reserved for FDT
1354 delivery.
1356 7. If the object recovered is not an FDT Instance but a file, the
1357 receiver looks up its FDT database to get the properties described
1358 in the database, and assigns file with the given properties. The
1359 receiver also checks that received content length matches with the
1360 description in the database. Optionally, if MD5 checksum has been
1361 used, the receiver checks that calculated MD5 matches with the
1362 description in the FDT database.
1364 8. The actions the receiver takes with imperfectly received files
1365 (missing data, mismatching digestive, etc.) is outside the scope
1366 of this specification. When a file is recovered before the
1367 associated file description entry is available, a possible
1368 behavior is to wait until an FDT Instance is received that
1369 includes the missing properties.
1371 9. If the file delivery session end time has not been reached go back
1372 to 3. Otherwise end.
1374 Appendix B. Example of FDT Instance (informative)
1376
1377
1381
1385
1393
1395 Intellectual Property Statement
1397 The IETF takes no position regarding the validity or scope of any
1398 intellectual property or other rights that might be claimed to
1399 pertain to the implementation or use of the technology described in
1400 this document or the extent to which any license under such rights
1401 might or might not be available; neither does it represent that it
1402 has made any effort to identify any such rights. Information on the
1403 IETF's procedures with respect to rights in standards-track and
1404 standards-related documentation can be found in BCP-11. Copies of
1405 claims of rights made available for publication and any assurances of
1406 licenses to be made available, or the result of an attempt made to
1407 obtain a general license or permission for the use of such
1408 proprietary rights by implementors or users of this specification can
1409 be obtained from the IETF Secretariat.
1411 The IETF invites any interested party to bring to its attention any
1412 copyrights, patents or patent applications, or other proprietary
1413 rights which may cover technology that may be required to practice
1414 this standard. Please address the information to the IETF Executive
1415 Director.
1417 Full Copyright Statement
1419 Copyright (C) The Internet Society (2003). All Rights Reserved.
1421 This document and translations of it may be copied and furnished to
1422 others, and derivative works that comment on or otherwise explain it
1423 or assist in its implementation may be prepared, copied, published
1424 and distributed, in whole or in part, without restriction of any
1425 kind, provided that the above copyright notice and this paragraph are
1426 included on all such copies and derivative works. However, this
1427 document itself may not be modified in any way, such as by removing
1428 the copyright notice or references to the Internet Society or other
1429 Internet organizations, except as needed for the purpose of
1430 developing Internet standards in which case the procedures for
1431 copyrights defined in the Internet Standards process must be
1432 followed, or as required to translate it into languages other than
1433 English.
1435 The limited permissions granted above are perpetual and will not be
1436 revoked by the Internet Society or its successors or assignees.
1438 This document and the information contained herein is provided on an
1439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1445 Acknowledgment
1447 Funding for the RFC Editor function is currently provided by the
1448 Internet Society.