idnits 2.17.1
draft-ietf-rmt-flute-revised-16.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 27, 2012) is 4320 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 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref.
'XML-Schema-Part-1'
-- Possible downref: Non-RFC (?) normative reference: ref.
'XML-Schema-Part-2'
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Downref: Normative reference to an Experimental RFC: RFC 3738
-- Obsolete informational reference (is this intentional?): RFC 3926
(Obsoleted by RFC 6726)
-- Obsolete informational reference (is this intentional?): RFC 4566
(Obsoleted by RFC 8866)
-- Obsolete informational reference (is this intentional?): RFC 5751
(Obsoleted by RFC 8551)
-- Obsolete informational reference (is this intentional?): RFC 3447
(Obsoleted by RFC 8017)
Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Reliable Multicast Transport (RMT) T. Paila
3 Internet-Draft Nokia
4 Obsoletes: 3926 (if approved) R. Walsh
5 Intended status: Standards Track Tampere University of Technology
6 Expires: December 29, 2012 M. Luby
7 Qualcomm, Inc.
8 V. Roca
9 INRIA
10 R. Lehtonen
11 TeliaSonera
12 June 27, 2012
14 FLUTE - File Delivery over Unidirectional Transport
15 draft-ietf-rmt-flute-revised-16
17 Abstract
19 This document defines FLUTE, a protocol for the unidirectional
20 delivery of files over the Internet, which is particularly suited to
21 multicast networks. The specification builds on Asynchronous Layered
22 Coding, the base protocol designed for massively scalable multicast
23 distribution. This document obsoletes RFC3926.
25 Status of this Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on December 29, 2012.
42 Copyright Notice
44 Copyright (c) 2012 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 This document may contain material from IETF Documents or IETF
58 Contributions published or made publicly available before November
59 10, 2008. The person(s) controlling the copyright in some of this
60 material may not have granted the IETF Trust the right to allow
61 modifications of such material outside the IETF Standards Process.
62 Without obtaining an adequate license from the person(s) controlling
63 the copyright in such materials, this document may not be modified
64 outside the IETF Standards Process, and derivative works of it may
65 not be created outside the IETF Standards Process, except to format
66 it for publication as an RFC or to translate it into languages other
67 than English.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
72 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
73 1.1.1. The Target Application Space . . . . . . . . . . . . . 6
74 1.1.2. The Target Scale . . . . . . . . . . . . . . . . . . . 6
75 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 7
76 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 7
77 2. Conventions used in this Document . . . . . . . . . . . . . . 8
78 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 8
79 3.1. File delivery session . . . . . . . . . . . . . . . . . . 9
80 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 11
81 3.3. Dynamics of FDT Instances within file delivery session . . 13
82 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 16
83 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 17
84 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 18
85 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 23
86 3.5. Multiplexing of files within a file delivery session . . . 23
87 4. Channels, congestion control and timing . . . . . . . . . . . 24
88 5. Delivering FEC Object Transmission Information . . . . . . . . 25
89 6. Describing file delivery sessions . . . . . . . . . . . . . . 27
90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
91 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 28
92 7.2. Attacks against the data flow . . . . . . . . . . . . . . 28
93 7.2.1. Access to confidential files . . . . . . . . . . . . . 29
94 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 29
95 7.3. Attacks against the session control parameters and
96 associated Building Blocks . . . . . . . . . . . . . . . . 31
97 7.3.1. Attacks against the Session Description . . . . . . . 31
98 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 31
99 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 32
100 7.3.4. Attacks against the associated Building Blocks . . . . 32
101 7.4. Other Security Considerations . . . . . . . . . . . . . . 33
102 7.5. Minimum Security Recommendations . . . . . . . . . . . . . 34
103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
104 8.1. Registration of the FDT Instance XML Namespace . . . . . . 34
105 8.2. Registration of the FDT Instance XML Schema . . . . . . . 35
106 8.3. Registration of the application/fdt+xml Media-Type . . . . 35
107 8.4. Creation of the FLUTE Content Encoding Algorithms
108 registry . . . . . . . . . . . . . . . . . . . . . . . . . 36
109 8.5. Registration of LCT Header Extension Types . . . . . . . . 36
110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
111 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
112 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37
113 11.1. RFC3926 to draft-ietf-rmt-flute-revised-12 . . . . . . . . 37
114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
115 12.1. Normative references . . . . . . . . . . . . . . . . . . . 40
116 12.2. Informative references . . . . . . . . . . . . . . . . . . 41
118 Appendix A. Receiver operation (informative) . . . . . . . . . . 44
119 Appendix B. Example of FDT Instance (informative) . . . . . . . . 45
120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
122 1. Introduction
124 This document defines FLUTE version 2, a protocol for unidirectional
125 delivery of files over the Internet. This specification is not
126 backwards compatible with the previous experimental version defined
127 in [RFC3926] (see Section 11 for details). The specification builds
128 on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base
129 protocol designed for massively scalable multicast distribution. ALC
130 defines transport of arbitrary binary objects. For file delivery
131 applications mere transport of objects is not enough, however. The
132 end systems need to know what the objects actually represent. This
133 document specifies a technique called FLUTE - a mechanism for
134 signaling and mapping the properties of files to concepts of ALC in a
135 way that allows receivers to assign those parameters for received
136 objects. Consequently, throughout this document the term 'file'
137 relates to an 'object' as discussed in ALC. Although this
138 specification frequently makes use of multicast addressing as an
139 example, the techniques are similarly applicable for use with unicast
140 addressing.
142 This document defines a specific transport application of ALC, adding
143 the following specifications:
145 - Definition of a file delivery session built on top of ALC,
146 including transport details and timing constraints.
148 - In-band signaling of the transport parameters of the ALC session.
150 - In-band signaling of the properties of delivered files.
152 - Details associated with the multiplexing of multiple files within
153 a session.
155 This specification is structured as follows. Section 3 begins by
156 defining the concept of the file delivery session. Following that it
157 introduces the File Delivery Table that forms the core part of this
158 specification. Further, it discusses multiplexing issues of
159 transmission objects within a file delivery session. Section 4
160 describes the use of congestion control and channels with FLUTE.
161 Section 5 defines how the Forward Error Correction (FEC) Object
162 Transmission Information is to be delivered within a file delivery
163 session. Section 6 defines the required parameters for describing
164 file delivery sessions in a general case. Section 7 outlines
165 security considerations regarding file delivery with FLUTE. Last,
166 there are two informative appendices. Appendix A describes an
167 envisioned receiver operation for the receiver of the file delivery
168 session. Readers who want to see a simple example of FLUTE in
169 operation should refer to Appendix A right away. Appendix B gives an
170 example of a File Delivery Table.
172 This specification contains part of the definitions necessary to
173 fully specify a Reliable Multicast Transport protocol in accordance
174 with [RFC2357].
176 This document obsoletes [RFC3926] which contained a previous version
177 of this specification and was published in the "Experimental"
178 category. This Proposed Standard specification is thus based on
179 [RFC3926] updated according to accumulated experience and growing
180 protocol maturity since the publication of [RFC3926]. Said
181 experience applies both to this specification itself and to
182 congestion control strategies related to the use of this
183 specification.
185 The differences between [RFC3926] and this document are listed in
186 Section 11.
188 This document updates ALC [RFC5775] and Layered Coding Transport
189 (LCT) [RFC5651] in the sense it defines two new header extensions,
190 EXT_FDT and EXT_CENC.
192 1.1. Applicability Statement
194 1.1.1. The Target Application Space
196 FLUTE is applicable to the delivery of large and small files to many
197 hosts, using delivery sessions of several seconds or more. For
198 instance, FLUTE could be used for the delivery of large software
199 updates to many hosts simultaneously. It could also be used for
200 continuous, but segmented, data such as time-lined text for
201 subtitling - potentially leveraging its layering inheritance from ALC
202 and LCT to scale the richness of the session to the congestion status
203 of the network. It is also suitable for the basic transport of
204 metadata, for example SDP [RFC4566] files which enable user
205 applications to access multimedia sessions.
207 1.1.2. The Target Scale
209 Massive scalability is a primary design goal for FLUTE. IP multicast
210 is inherently massively scalable, but the best effort service that it
211 provides does not provide session management functionality,
212 congestion control or reliability. FLUTE provides all of this using
213 ALC and IP multicast without sacrificing any of the inherent
214 scalability of IP multicast.
216 1.1.3. Intended Environments
218 All of the environmental requirements and considerations that apply
219 to the RMT Building Blocks used by FLUTE shall also apply to FLUTE.
220 These are the ALC protocol instantiation [RFC5775], the Layered
221 Coding Transport (LCT) Building Block [RFC5651] and the FEC Building
222 Block [RFC5052].
224 FLUTE can be used with both multicast and unicast delivery, but it's
225 primary application is for unidirectional multicast file delivery.
226 FLUTE requires connectivity between a sender and receivers but does
227 not require connectivity from receivers to a sender. Because of its
228 low expectations, FLUTE works with most types of networks, including
229 LANs, WANs, Intranets, the Internet, asymmetric networks, wireless
230 networks, and satellite networks.
232 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
233 is IP version specific. FLUTE works with both multicast models: Any-
234 Source Multicast (ASM) [RFC1112] and the Source-Specific Multicast
235 (SSM) [PAPER.SSM].
237 FLUTE is applicable for both shared networks, such as Internet, with
238 a suitable congestion control building block, and provisioned/
239 controlled networks, such as wireless broadcast radio systems, with a
240 traffic shaping building block.
242 1.1.4. Weaknesses
244 FLUTE congestion control protocols depend on the ability of a
245 receiver to change multicast subscriptions between multicast groups
246 supporting different rates and/or layered codings. If the network
247 does not support this, then the FLUTE congestion control protocols
248 may not be amenable to these networks.
250 FLUTE can also be used for point-to-point (unicast) communications.
251 At a minimum, implementations of ALC MUST support the Wave and
252 Equation Based Rate Control (WEBRC) [RFC3738] multiple rate
253 congestion control scheme [RFC5775]. However, since WEBRC has been
254 designed for massively scalable multicast flows, it is not clear how
255 appropriate it is to the particular case of unicast flows. Using a
256 separate point-to-point congestion control scheme is another
257 alternative. How to do that is outside the scope of the present
258 document.
260 FLUTE provides reliability using the FEC building block. This will
261 reduce the error rate as seen by applications. However, FLUTE does
262 not provide a method for senders to verify the reception success of
263 receivers, and the specification of such a method is outside the
264 scope of this document.
266 2. Conventions used in this Document
268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
270 document are to be interpreted as described in [RFC2119].
272 The terms "object" and "transmission object" are consistent with the
273 definitions in ALC [RFC5775] and LCT [RFC5651]. The terms "file" and
274 "source object" are pseudonyms for "object".
276 3. File delivery
278 Asynchronous Layered Coding [RFC5775] is a protocol designed for
279 delivery of arbitrary binary objects. It is especially suitable for
280 massively scalable, unidirectional, multicast distribution. ALC
281 provides the basic transport for FLUTE, and thus FLUTE inherits the
282 requirements of ALC.
284 This specification is designed for the delivery of files. The core
285 of this specification is to define how the properties of the files
286 are carried in-band together with the delivered files.
288 As an example, let us consider a 5200 byte file referred to by
289 "http://www.example.com/docs/file.txt". Using the example, the
290 following properties describe the properties that need to be conveyed
291 by the file delivery protocol.
293 * Identifier of the file, expressed as a URI [RFC3986]. The
294 identifier MAY provide a location for the file. In the above
295 example: "http://www.example.com/docs/file.txt".
297 * File name (usually, this can be concluded from the URI). In the
298 above example: "file.txt".
300 * File type, expressed as Internet Media Types (often referred to as
301 "Media Types"). In the above example: "text/plain".
303 * File size, expressed in octets. In the above example: "5200". If
304 the file is content encoded then this is the file size before
305 content encoding.
307 * Content encoding of the file, within transport. In the above
308 example, the file could be encoded using ZLIB [RFC1950]. In this
309 case the size of the transmission object carrying the file would
310 probably differ from the file size. The transmission object size
311 is delivered to receivers as part of the FLUTE protocol.
313 * Security properties of the file such as digital signatures,
314 message digests, etc. For example, one could use S/MIME [RFC5751]
315 as the content encoding type for files with this authentication
316 wrapper, and one could use XML-DSIG [RFC3275] to digitally sign
317 the file. XML-DSIG can also be used to provide tamper prevention
318 e.g., on the Content-Location field. Content encoding is applied
319 to file data before FEC protection.
321 For each unique file, FLUTE encodes the attributes listed above and
322 other attributes as children of an XML file element. A table of XML
323 file elements is transmitted as a special file called a 'File
324 Delivery Table' (FDT) which is further described in the next
325 subsection and in section 3.2
327 3.1. File delivery session
329 ALC is a protocol instantiation of Layered Coding Transport building
330 block (LCT) [RFC5651]. Thus ALC inherits the session concept of LCT.
331 In this document we will use the concept ALC/LCT session to
332 collectively denote the interchangeable terms ALC session and LCT
333 session.
335 An ALC/LCT session consists of a set of logically grouped ALC/LCT
336 channels associated with a single sender sending ALC/LCT packets for
337 one or more objects. An ALC/LCT channel is defined by the
338 combination of a sender and an address associated with the channel by
339 the sender. A receiver joins a channel to start receiving the data
340 packets sent to the channel by the sender, and a receiver leaves a
341 channel to stop receiving data packets from the channel.
343 One of the fields carried in the ALC/LCT header is the Transport
344 Session Identifier (TSI), an integer carried in a field of size 16,
345 32, or 48 bits (note that the TSI may be carried by other means in
346 which case it is absent from the LCT header [RFC5651]). The (source
347 IP address, TSI) pair uniquely identifies a session. Note that the
348 TSI is scoped by the IP address, so the same TSI may be used by
349 several source IP addresses at once. Thus, the receiver uses the
350 (source IP address, TSI) pair from each packet to uniquely identify
351 the session sending each packet. When a session carries multiple
352 objects, the Transmission Object Identifier (TOI) field within the
353 ALC/LCT header names the object used to generate each packet. Note
354 that each object is associated with a unique TOI within the scope of
355 a session.
357 A FLUTE session consistent with this specification MUST use FLUTE
358 version 2 as specified in this document. Thus, all sessions
359 consistent with this specification MUST set the FLUTE version to 2.
360 The FLUTE version is carried within the EXT_FDT extension header
361 (defined in section 3.4.1) in the ALC/LCT layer. A FLUTE session
362 consistent with this specification MUST use ALC version 1 as
363 specified in [RFC5775], and LCT version 1 as specified in [RFC5651].
365 If multiple FLUTE sessions are sent to a channel then receivers MUST
366 determine the FLUTE protocol version, based on version fields and the
367 (source IP address, TSI) carried in the ALC/LCT header of the packet.
368 Note that when a receiver first begins receiving packets, it might
369 not know the FLUTE protocol version, as not every LCT packet carries
370 the EXT_FDT header (containing the FLUTE protocol version.) A new
371 receiver MAY keep an open binding in the LCT protocol layer between
372 the TSI and the FLUTE protocol version, until the EXT_FDT header
373 arrives. Alternately, a new receiver MAY discover a binding between
374 TSI and FLUTE protocol version via a session discovery protocol that
375 is out of scope in this document.
377 If the sender's IP address is not accessible to receivers, then
378 packets that can be received by receivers contain an intermediate IP
379 address. In this case the TSI is scoped by this intermediate IP
380 address of the sender for the duration of the session. As an
381 example, the sender may be behind a Network Address Translation (NAT)
382 device that temporarily assigns an IP address for the sender. In
383 this case the TSI is scoped by the intermediate IP address assigned
384 by the NAT. As another example, the sender may send its original
385 packets using IPv6, but some portions of the network may not be IPv6
386 capable. Thus, there may be an IPv6 to IPv4 translator that changes
387 the IP address of the packets to a different IPv4 address. In this
388 case, receivers in the IPv4 portion of the network will receive
389 packets containing the IPv4 address, and thus the TSI for them is
390 scoped by the IPv4 address. How the IP address of the sender to be
391 used to scope the session by receivers is delivered to receivers,
392 whether it is the sender's IP address or an intermediate IP address,
393 is outside the scope of this document.
395 When FLUTE is used for file delivery over ALC, the ALC/LCT session is
396 called a file delivery session and the ALC/LCT concept of 'object'
397 denotes either a 'file' or a 'File Delivery Table Instance' (section
398 3.2).
400 Additionally, the following rules apply:
402 * The TOI field MUST be included in ALC packets sent within a FLUTE
403 session, with the exception that ALC packets sent in a FLUTE
404 session with the Close Session (A) flag set to 1 (signaling the
405 end of the session) and that contain no payload (carrying no
406 information for any file or FDT) SHALL NOT carry the TOI. See
407 section 5.1 of [RFC5651] for the LCT definition of the Close
408 Session flag, and see section 4.2 of [RFC5775] for an example of
409 the use of a TOI within an ALC packet.
411 * The TOI value '0' is reserved for the delivery of File Delivery
412 Table Instances. Each non expired File Delivery Table Instance is
413 uniquely identified by an FDT Instance ID within the EXT_FDT
414 header defined in section 3.4.1.
416 * Each file in a file delivery session MUST be associated with a TOI
417 (>0) in the scope of that session.
419 * Information carried in the headers and the payload of a packet is
420 scoped by the source IP address and the TSI. Information
421 particular to the object carried in the headers and the payload of
422 a packet is further scoped by the TOI for file objects, and is
423 further scoped by both the TOI and the FDT Instance ID for FDT
424 Instance objects.
426 3.2. File Delivery Table
428 The File Delivery Table (FDT) provides a means to describe various
429 attributes associated with files that are to be delivered within the
430 file delivery session. The following lists are examples of such
431 attributes, and are not intended to be mutually exclusive nor
432 exhaustive.
434 Attributes related to the delivery of file:
436 - TOI value that represents the file
438 - FEC Object Transmission Information (including the FEC Encoding ID
439 and, if relevant, the FEC Instance ID)
441 - Size of the transmission object carrying the file
443 - Aggregate rate of sending packets to all channels
445 Attributes related to the file itself:
447 - Name, Identification and Location of file (specified by the URI)
449 - Media type of file
451 - Size of file
453 - Encoding of file
455 - Message digest of file
457 Some of these attributes MUST be included in the file description
458 entry for a file, others are optional, as defined in section 3.4.2.
460 Logically, the FDT is a set of file description entries for files to
461 be delivered in the session. Each file description entry MUST
462 include the TOI for the file that it describes and the URI
463 identifying the file. The TOI carried in each file description entry
464 is how FLUTE names the ALC/LCT data packets used for delivery of the
465 file. Each file description entry may also contain one or more
466 descriptors that map the above-mentioned attributes to the file.
468 Each file delivery session MUST have an FDT that is local to the
469 given session. The FDT MUST provide a file description entry mapped
470 to a TOI for each file appearing within the session. An object that
471 is delivered within the ALC session, but not described in the FDT,
472 other than the FDT itself, is not considered a 'file' belonging to
473 the file delivery session. This object received with an unmapped TOI
474 (Non-zero TOI that is not resolved by the FDT) SHOULD in general be
475 ignored by a FLUTE receiver. The details of how to do that is out of
476 scope of this specification.
478 Note that a client that joins an active file delivery session MAY
479 receive data packets for a TOI > 0 before receiving any FDT Instance
480 (see Section 3.3 for recommendations on how to limit the probability
481 this occurs). Even if the TOI is not mapped to any file description
482 entry, this is hopefully a transient situation. When this happens,
483 system performance might be improved by caching such packets within a
484 reasonable time window and storage size. Such optimizations are use-
485 case and implementation specific and further details are beyond the
486 scope of this document.
488 Within the file delivery session the FDT is delivered as FDT
489 Instances. An FDT Instance contains one or more file description
490 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
491 superset of, overlap with or complement any other FDT Instance. A
492 certain FDT Instance may be repeated multiple times during a session,
493 even after subsequent FDT Instances (with higher FDT Instance ID
494 numbers) have been transmitted. Each FDT Instance contains at least
495 a single file description entry and at most the exhaustive set of
496 file description entries of the files being delivered in the file
497 delivery session.
499 A receiver of the file delivery session keeps an FDT database for
500 received file description entries. The receiver maintains the
501 database, for example, upon reception of FDT Instances. Thus, at any
502 given time the contents of the FDT database represent the receiver's
503 current view of the FDT of the file delivery session. Since each
504 receiver behaves independently of other receivers, it SHOULD NOT be
505 assumed that the contents of the FDT database are the same for all
506 the receivers of a given file delivery session.
508 Since the FDT database is an abstract concept, the structure and the
509 maintenance of the FDT database are left to individual
510 implementations and are thus out of scope of this specification.
512 3.3. Dynamics of FDT Instances within file delivery session
514 The following rules define the dynamics of the FDT Instances within a
515 file delivery session:
517 * For every file delivered within a file delivery session there MUST
518 be a file description entry included in at least one FDT Instance
519 sent within the session. A file description entry contains at a
520 minimum the mapping between the TOI and the URI.
522 * An FDT Instance MAY appear in any part of the file delivery
523 session and packets for an FDT Instance MAY be interleaved with
524 packets for other files or other FDT Instances within a session.
526 * The TOI value of '0' MUST be reserved for delivery of FDT
527 Instances. The use of other TOI values (i.e., an integer > 0) for
528 FDT Instances is outside the scope of this specification.
530 * The FDT Instance is identified by the use of a new fixed length
531 LCT Header Extension EXT_FDT (defined later in this section.)
532 Each non expired FDT Instance is uniquely identified within the
533 file delivery session by its FDT Instance ID, carried by the
534 EXT_FDT Header Extension. Any ALC/LCT packet carrying an FDT
535 Instance MUST include EXT_FDT.
537 * It is RECOMMENDED that an FDT Instance that contains the file
538 description entry for a file is sent at least once before sending
539 the described file within a file delivery session. This
540 recommendation is intended to minimize the amount of file data
541 which may be received by receivers in advance of the FDT Instance
542 containing the entry for a file (such data must either be
543 speculatively buffered or discarded). Note that this possibility
544 cannot be completely eliminated since the first transmission of
545 FDT data might be lost.
547 * Within a file delivery session, any TOI > 0 MAY be described more
548 than once. An example: previous FDT Instance 0 describes TOI of
549 value '3'. Now, subsequent FDT Instances can either keep TOI '3'
550 unmodified on the table, not include it, or augment the
551 description. However, subsequent FDT Instances MUST NOT change
552 the parameters already described for a specific TOI.
554 * An FDT Instance is valid until its expiration time. The
555 expiration time is expressed within the FDT Instance payload as an
556 UTF-8 decimal representation of a 32 bit unsigned integer. The
557 value of this integer represents the 32 most significant bits of a
558 64 bit Network Time Protocol (NTP) [RFC5905] time value. These 32
559 bits provide an unsigned integer representing the time in seconds
560 relative to 0 hours 1 January 1900 in case of the prime epoch (era
561 0) [RFC5905]. The handling of time wraparound (to happen in 2036)
562 requires to consider the associated epoch. In any case, both a
563 sender and a receiver easily determine to which (136 year) epoch
564 the FDT Instance expiration time value pertains to by choosing the
565 epoch for which the expiration time is closest in time to the
566 current time.
568 Here is an example. Let us imagine a new FLUTE session is started
569 on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few
570 hours before the end of epoch 0. In order to define an FDT
571 Instance valid for the next 48 hours, The FLUTE sender sets an
572 expiry time of 149,504. This FDT Instance will expire exactly on
573 February 9th, 2036, 0h. A client that receives this FDT Instance
574 on the 7th, 0h, just after it has been sent, immediately
575 understands this value corresponds to epoch 1. A client that
576 joins the session on February 8th, 0h, i.e., at NTP time 63,104,
577 epoch 1, immediately understands that the 149,504 NTP timestamp
578 corresponds to epoch 1.
580 * The space of FDT Instance IDs is limited by the associated field
581 size (i.e., 20 bits) in the EXT_FDT header extension
582 (Section 3.4.1). Therefore senders should take care to always
583 have a large enough supply of available FDT Instance IDs when
584 specifying FDT expiration times.
586 * The receiver MUST NOT use a received FDT Instance to interpret
587 packets received beyond the expiration time of the FDT Instance.
589 * A sender MUST use an expiration time in the future upon creation
590 of an FDT Instance relative to its Sender Current Time (SCT).
592 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
593 The default is to use the Compact No-code FEC Encoding ID 0
594 [RFC5445] for the sending of FDT Instances. (Note that since FEC
595 Encoding ID 0 is the default for FLUTE, this implies that Source
596 Block Number and Encoding Symbol ID lengths both default to 16
597 bits each.)
599 * If the receiver does not support the FEC scheme indicated by the
600 FEC Encoding ID, the receiver MUST NOT decode the associated FDT.
602 * It is RECOMMENDED that the mechanisms used for file attribute
603 delivery SHOULD achieve a delivery probability that is higher than
604 the file recovery probability and the file attributes SHOULD be
605 delivered at this higher priority before the delivery of the
606 associated files begins.
608 Generally, a receiver needs to receive an FDT Instance describing a
609 file before it is able to recover the file itself. In this sense FDT
610 Instances are of higher priority than files. Additionally, a FLUTE
611 sender SHOULD assume receivers will not receive all packets
612 pertaining to FDT Instances. The way FDT Instances are transmitted
613 has a large impact on satisfying the recommendation above. When
614 there is a single file transmitted in the session, one way to satisfy
615 the recommendation above is to repeatedly transmit on a regular
616 enough basis FDT Instances describing the file while the file is
617 being transmitted. If an FDT Instance is longer than one packet
618 payload in length, it is RECOMMENDED that an FEC code that provides
619 protection against loss be used for delivering this FDT Instance.
620 When there are multiple files in a session concurrently being
621 transmitted to receivers, the way the FDT Instances are structured
622 and transmitted also has a large impact. As an example, a way to
623 satisfy the recommendation above is to transmit an FDT Instance that
624 describes all files currently being transmitted, and to transmit this
625 FDT Instance reliably, using the same techniques as explained for the
626 case when there is a single file transmitted in a session. If
627 instead the concurrently transmitted files are described in separate
628 FDT Instances, another way to satisfy this recommendation is to
629 transmit all the relevant FDT Instances reliably, using the same
630 techniques as explained for the case when there is a single file
631 transmitted in a session.
633 In any case, how often the description of a file is sent in an FDT
634 Instance, how often an FDT Instance is sent, and how much FEC
635 protection is provided for an FDT Instance (if longer than one packet
636 payload) are dependent on the particular application and are outside
637 the scope of this document.
639 Sometimes the various attributes associated with files that are to be
640 delivered within the file delivery session are sent out-of-band. The
641 details of how this is done are out of the scope of this document.
642 However, it is still RECOMMENDED that any out-of-band transmission be
643 managed in such a way that a receiver will be able to recover the
644 attributes associated with a file with as much or greater reliability
645 as the receiver is able to receive enough packets containing encoding
646 symbols to recover the file. For example, the probability of a
647 randomly chosen receiver being able to recover a given file can often
648 be estimated based on a statistical model of reception conditions,
649 the amount of data transmitted and the properties of any Forward
650 Error Correction in use. The recommendation above suggests that
651 mechanisms used for file attribute delivery should achieve higher a
652 delivery probability than the file recovery probability. The sender
653 MAY also continue sending the various file attributes in-band, in
654 addition to the out-of-band transmission.
656 3.4. Structure of FDT Instance packets
658 FDT Instances are carried in ALC packets with TOI = 0 and with an
659 additional REQUIRED LCT Header extension called the FDT Instance
660 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
661 ID that uniquely identifies FDT Instances within a file delivery
662 session. The FDT Instance Header is placed in the same way as any
663 other LCT extension header. There MAY be other LCT extension headers
664 in use.
666 The FDT Instance is encoded for transmission, like any other object,
667 using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme).
668 The LCT extension headers are followed by the FEC Payload ID, and
669 finally the Encoding Symbols for the FDT Instance which contains one
670 or more file description entries. A FDT Instance MAY span several
671 ALC packets - the number of ALC packets is a function of the file
672 attributes associated with the FDT Instance. The FDT Instance Header
673 is carried in each ALC packet carrying the FDT Instance. The FDT
674 Instance Header is identical for all ALC/LCT packets for a particular
675 FDT Instance.
677 The overall format of ALC/LCT packets carrying an FDT Instance is
678 depicted in the Figure 1 below. All integer fields are carried in
679 "big-endian" or "network order" format, that is, most significant
680 byte (octet) first. As defined in [RFC5775], all ALC/LCT packets are
681 sent using UDP.
683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
684 | UDP header |
685 | |
686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
687 | Default LCT header (with TOI = 0) |
688 | |
689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
690 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
691 | |
692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
693 | FEC Payload ID |
694 | |
695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
696 FLUTE Payload: Encoding Symbol(s)
697 ~ (for FDT Instance in a FDT packet) ~
699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
701 Figure 1: Overall FDT Packet
703 3.4.1. Format of FDT Instance Header
705 The FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI
706 specific LCT header extension [RFC5651]. The Header Extension Type
707 (HET) for the extension is 192. Its format is defined below:
709 0 1 2 3
710 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
711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
712 | HET = 192 | V | FDT Instance ID |
713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
715 Figure 2
717 Version of FLUTE (V), 4 bits:
719 This document specifies FLUTE version 2. Hence in any ALC packet
720 that carries FDT Instance and that belongs to the file delivery
721 session as specified in this specification MUST set this field to
722 '2'.
724 FDT Instance ID, 20 bits:
726 For each file delivery session the numbering of FDT Instances starts
727 from '0' and is incremented by one for each subsequent FDT Instance.
728 After reaching the maximum value (2^20-1), the numbering starts from
729 the smallest FDT Instance ID value assigned to an expired FDT
730 Instance. When wraparound from a greater FDT Instance ID value to a
731 smaller FDT Instance ID value occurs, the smaller FDT Instance ID
732 value is considered logically higher than the greater FDT Instance ID
733 value. Then, the subsequent FDT Instances are assigned the following
734 smallest FDT Instance ID value available in order to always keep the
735 FDT Instance ID values logically increasing.
737 Senders MUST NOT re-use an FDT Instance ID value that is already in
738 use for a non-expired FDT Instance. Sender behavior when all the FDT
739 Instance IDs are used by non expired FEC Instances is outside the
740 scope of this specification and left to individual implementations of
741 FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID
742 value that is currently used by a non expired FDT Instance MUST be
743 considered as an error case. Receiver behavior in this case (e.g.
744 leave the session or ignore the new FDT Instance) is outside the
745 scope of this specification and left to individual implementations of
746 FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound
747 and situations where missing FDT Instance IDs result in increments
748 larger than one.
750 3.4.2. Syntax of FDT Instance
752 The FDT Instance contains file description entries that provide the
753 mapping functionality described in 3.2 above.
755 The FDT Instance is an Extensible Markup Language (XML) structure
756 that has a single root element "FDT-Instance". The "FDT-Instance"
757 element MUST contain "Expires" attribute, which tells the expiration
758 time of the FDT Instance. In addition, the "FDT-Instance" element
759 MAY contain the "Complete" attribute, a boolean which can be either
760 set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE. When
761 TRUE, the "Complete" attribute signals that this "FDT Instance"
762 includes the set of "File" entries that exhausts both the set of
763 files delivered so far and also the set of files to be delivered in
764 the session. This implies that no new data will be provided in
765 future FDT Instances within this session (i.e., that either FDT
766 Instances with higher ID numbers will not be used or if they are
767 used, will only provide identical file parameters to those already
768 given in this and previous FDT Instances). The "Complete" attribute
769 is therefore used to provide a complete list of files in an entire
770 FLUTE session (a "complete FDT"). Note that when all the FDT
771 Instances received so far have no "Complete" attribute, the receiver
772 MUST consider that the session is not complete and that new data MAY
773 be provided in future FDT Instances. This is equivalent to receiving
774 FDT Instances having the "Complete" attribute set to FALSE.
776 The "FDT-Instance" element MAY contain attributes that give common
777 parameters for all files of an FDT Instance. These attributes MAY
778 also be provided for individual files in the "File" element. Where
779 the same attribute appears in both the "FDT-Instance" and the "File"
780 elements, the value of the attribute provided in the "File" element
781 takes precedence.
783 For each file to be declared in the given FDT Instance there is a
784 single file description entry in the FDT Instance. Each entry is
785 represented by element "File" which is a child element of the FDT
786 Instance structure.
788 The attributes of "File" element in the XML structure represent the
789 attributes given to the file that is delivered in the file delivery
790 session. The value of the XML attribute name corresponds to MIME
791 field name and the XML attribute value corresponds to the value of
792 the MIME field body [RFC2045]. Each "File" element MUST contain at
793 least two attributes: "TOI" and "Content-Location". "TOI" MUST be
794 assigned a valid TOI value as described in section 3.3. "Content-
795 Location" [RFC2616] MUST be assigned a syntactically valid URI, as
796 defined in [RFC3986], which identifies the file to be delivered. For
797 example it can be a URI with the "http" or "file" URI scheme. Only
798 one "Content-Location" attribute is allowed for each file. The
799 "Content-Location" field MUST be considered as a string that
800 identifies a file (i.e., two different strings are two different
801 identifiers). Any use of the "Content-Location" field to anything
802 else than to identify the object is out of scope of this
803 specification. The semantics for any two "File" elements declaring
804 the same "Content-Location" but differing "TOI" is that the element
805 appearing in the FDT Instance with the greater FDT Instance ID is
806 considered to declare newer instance (e.g., version) of the same
807 "File".
809 In addition to mandatory attributes, the "FDT-Instance" element and
810 the "File" element MAY contain other attributes of which the
811 following are specifically pointed out.
813 * The attribute "Content-Type" SHOULD be included and, when present,
814 MUST be used for the purpose defined in [RFC2616].
816 * Where the length is described, the attribute "Content-Length" MUST
817 be used for the purpose as defined in [RFC2616]. The transfer
818 length is defined to be the length of the object transported in
819 octets. It is often important to convey the transfer length to
820 receivers, because the source block structure needs to be known
821 for the FEC decoder to be applied to recover source blocks of the
822 file, and the transfer length is often needed to properly
823 determine the source block structure of the file. There generally
824 will be a difference between the length of the original file and
825 the transfer length if content encoding is applied to the file
826 before transport, and thus the "Content-Encoding" attribute is
827 used. If the file is not content encoded before transport (and
828 thus the "Content-Encoding" attribute is not used) then the
829 transfer length is the length of the original file, and in this
830 case the "Content-Length" is also the transfer length. However,
831 if the file is content encoded before transport (and thus the
832 "Content-Encoding" attribute is used), e.g., if compression is
833 applied before transport to reduce the number of octets that need
834 to be transferred, then the transfer length is generally different
835 than the length of the original file, and in this case the
836 attribute "Transfer-Length" MAY be used to carry the transfer
837 length.
839 * Whenever content encoding is applied the attribute "Content-
840 Encoding" MUST be included. Whenever the attribute "Content-
841 Encoding" is included it MUST be used as described in [RFC2616].
843 * Where the MD5 message digest is described, the attribute "Content-
844 MD5" MUST be used for the purpose as defined in [RFC2616]. Note
845 that the goal is to provide a decoded object integrity service in
846 front of transmission and/or FLUTE/ALC processing errors (the
847 collision probability is in that case negligible). It MUST NOT be
848 regarded as a security mechanism (see Section 7 to that purpose).
850 * The FEC Object Transmission Information attributes as described in
851 section 5.2.
853 The following specifies the XML Schema
854 [XML-Schema-Part-1][XML-Schema-Part-2] for FDT Instance:
856 BEGIN
857
858
862
863
864
865
866
868
869
872
876
879
882
885
888
891
894
897
900
901
902
903
904
906
907
910
913
916
919
922
925
928
931
934
937
940
943
946
947
948
949 END
951 Figure 3
953 Any valid FDT Instance MUST use the above XML Schema. This way FDT
954 provides extensibility to support private elements and private
955 attributes within the file description entries. Those could be, for
956 example, the attributes related to the delivery of the file (timing,
957 packet transmission rate, etc.). Unsupported private elements and
958 attributes SHOULD be silently ignored by a FLUTE receiver.
960 In case the basic FDT XML Schema is extended in terms of new
961 descriptors (attributes or elements), for descriptors applying to a
962 single file, those MUST be placed within the element "File". For
963 descriptors applying to all files described by the current FDT
964 Instance, those MUST be placed within the element "FDT-Instance". It
965 is RECOMMENDED that the new attributes applied in the FDT are in the
966 format of message header fields and are either defined in the
967 HTTP/1.1 specification [RFC2616], or another well-known
968 specification, or in an IANA registry [IANAheaderfields]. However
969 this specification doesn't prohibit the use of other formats to allow
970 private attributes to be used when interoperability is not a concern.
972 3.4.3. Content Encoding of FDT Instance
974 The FDT Instance itself MAY be content encoded, for example
975 compressed. This specification defines FDT Instance Content Encoding
976 Header (EXT_CENC). EXT_CENC is a new fixed length LCT header
977 extension [RFC5651]. The Header Extension Type (HET) for the
978 extension is 193. If the FDT Instance is content encoded, the
979 EXT_CENC MUST be used to signal the content encoding type. In that
980 case, EXT_CENC header extension MUST be used in all ALC packets
981 carrying the same FDT Instance ID. Consequently, when EXT_CENC
982 header is used, it MUST be used together with a proper FDT Instance
983 Header (EXT_FDT). Within a file delivery session, FDT Instances that
984 are not content encoded and FDT Instances that are content encoded
985 MAY both appear. If content encoding is not used for a given FDT
986 Instance, the EXT_CENC MUST NOT be used in any packet carrying the
987 FDT Instance. The format of EXT_CENC is defined below:
989 0 1 2 3
990 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
991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
992 | HET = 193 | CENC | Reserved |
993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
995 Figure 4
997 Content Encoding Algorithm (CENC), 8 bits:
999 This field signals the content encoding algorithm used in the FDT
1000 Instance payload. This subsection reserves the Content Encoding
1001 Algorithm values 0, 1, 2 and 3 for null, ZLIB [RFC1950], DEFLATE
1002 [RFC1951] and GZIP [RFC1952] respectively.
1004 Reserved, 16 bits:
1006 This field MUST be set to all '0'. This field MUST be ignored on
1007 reception.
1009 3.5. Multiplexing of files within a file delivery session
1011 The delivered files are carried as transmission objects (identified
1012 with TOIs) in the file delivery session. All these objects,
1013 including the FDT Instances, MAY be multiplexed in any order and in
1014 parallel with each other within a session, i.e., packets for one file
1015 may be interleaved with packets for other files or other FDT
1016 Instances within a session.
1018 Multiple FDT Instances MAY be delivered in a single session using TOI
1019 = 0. In this case, it is RECOMMENDED that the sending of a previous
1020 FDT Instance SHOULD end before the sending of the next FDT Instance
1021 starts. However, due to unexpected network conditions, packets for
1022 the FDT Instances might be interleaved. A receiver can determine
1023 which FDT Instance a packet contains information about since the FDT
1024 Instances are uniquely identified by their FDT Instance ID carried in
1025 the EXT_FDT headers.
1027 4. Channels, congestion control and timing
1029 ALC/LCT has a concept of channels and congestion control. There are
1030 four scenarios in which FLUTE is envisioned to be applied.
1032 (a) Use of a single channel and a single-rate congestion control
1033 protocol.
1035 (b) Use of multiple channels and a multiple-rate congestion control
1036 protocol. In this case the FDT Instances MAY be delivered on more
1037 than one channel.
1039 (c) Use of a single channel without congestion control supplied by
1040 ALC, but only when in a controlled network environment where flow/
1041 congestion control is being provided by other means.
1043 (d) Use of multiple channels without congestion control supplied by
1044 ALC, but only when in a controlled network environment where flow/
1045 congestion control is being provided by other means. In this case
1046 the FDT Instances MAY be delivered on more than one channel.
1048 When using just one channel for a file delivery session, as in (a)
1049 and (c), the notion of 'prior' and 'after' are intuitively defined
1050 for the delivery of objects with respect to their delivery times.
1052 However, if multiple channels are used, as in (b) and (d), it is not
1053 straightforward to state that an object was delivered 'prior' to the
1054 other. An object may begin to be delivered on one or more of those
1055 channels before the delivery of a second object begins. However, the
1056 use of multiple channels/layers may complete the delivery of the
1057 second object before the first. This is not a problem when objects
1058 are delivered sequentially using a single channel. Thus, if the
1059 application of FLUTE has a mandatory or critical requirement that the
1060 first transmission object must complete 'prior' to the second one, it
1061 is RECOMMENDED that only a single channel is used for the file
1062 delivery session.
1064 Furthermore, if multiple channels are used then a receiver joined to
1065 the session at a low reception rate will only be joined to the lower
1066 layers of the session. Thus, since the reception of FDT Instances is
1067 of higher priority than the reception of files (because the reception
1068 of files depends on the reception of an FDT Instance describing it),
1069 the following is RECOMMENDED:
1071 1. The layers to which packets for FDT Instances are sent SHOULD NOT
1072 be biased towards those layers to which lower rate receivers are
1073 not joined. For example, it is okay to put all the packets for an
1074 FDT Instance into the lowest layer (if this layer carries enough
1075 packets to deliver the FDT to higher rate receivers in a
1076 reasonable amount of time), but it is not okay to put all the
1077 packets for an FDT Instance into the higher layers that only high
1078 rate receivers will receive.
1080 2. If FDT Instances are generally longer than one Encoding Symbol in
1081 length and some packets for FDT Instances are sent to layers that
1082 lower rate receivers do not receive, an FEC Encoding other than
1083 Compact No-code FEC Encoding ID 0 [RFC5445] SHOULD be used to
1084 deliver FDT Instances. This is because in this case, even when
1085 there is no packet loss in the network, a lower rate receiver will
1086 not receive all packets sent for an FDT Instance.
1088 5. Delivering FEC Object Transmission Information
1090 FLUTE inherits the use of FEC building block [RFC5052] from ALC.
1091 When using FLUTE for file delivery over ALC the FEC Object
1092 Transmission Information MUST be delivered in-band within the file
1093 delivery session. There are two methods to achieve this: the use of
1094 ALC specific LCT extension header EXT_FTI [RFC5775] and the use of
1095 FDT. The latter method is specified in this section. The use of
1096 EXT_FTI requires repetition of the FEC Object Transmission
1097 Information to ensure reception (though not necessarily in every
1098 packet) and thus may entail higher overhead than the use of the FDT,
1099 but may also provide more timely delivery of the FEC Object
1100 Transmission Information.
1102 The receiver of file delivery session MUST support delivery of FEC
1103 Object Transmission Information using the EXT_FTI for the FDT
1104 Instances carried using TOI value 0. For the TOI values other than 0
1105 the receiver MUST support both methods: the use of EXT_FTI and the
1106 use of FDT.
1108 The FEC Object Transmission Information that needs to be delivered to
1109 receivers MUST be exactly the same whether it is delivered using
1110 EXT_FTI or using FDT (or both). The FEC Object Transmission
1111 Information that MUST be delivered to receivers is defined by the FEC
1112 Scheme. This section describes the delivery using FDT.
1114 The FEC Object Transmission Information regarding a given TOI may be
1115 available from several sources. In this case, it is RECOMMENDED that
1116 the receiver of the file delivery session prioritize the sources in
1117 the following way (in the order of decreasing priority).
1119 1. FEC Object Transmission Information that is available in EXT_FTI.
1121 2. FEC Object Transmission Information that is available in the FDT.
1123 The FDT delivers FEC Object Transmission Information for each file
1124 using an appropriate attribute within the "FDT-Instance" or the
1125 "File" element of the FDT structure.
1127 * "Transfer-Length" carries the Transfer-Length Object Transmission
1128 Information element defined in [RFC5052].
1130 * "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object
1131 Transmission Information element defined in [RFC5052], as carried
1132 in the Codepoint field of the ALC/LCT header.
1134 * "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object
1135 Transmission Information element defined in [RFC5052] for Under-
1136 specified FEC Schemes.
1138 * "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum Source
1139 Block Length" Object Transmission Information element defined in
1140 [RFC5052], if required by the FEC Scheme.
1142 * "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding Symbol
1143 Length" Object Transmission Information element defined in
1144 [RFC5052], if required by the FEC Scheme.
1146 * "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Maximum
1147 Number of Encoding Symbols" Object Transmission Information
1148 element defined in [RFC5052], if required by the FEC Scheme.
1150 * "FEC-OTI-Scheme-specific-information" carries the "encoded scheme-
1151 specific FEC Object Transmission Information" as defined in
1152 [RFC5052], if required by the FEC Scheme.
1154 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
1155 carried in the Codepoint field of the ALC/LCT header. When the FEC
1156 Object Transmission Information for this TOI is delivered through the
1157 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
1158 Codepoint field of all packets for this TOI MUST be the same.
1160 6. Describing file delivery sessions
1162 To start receiving a file delivery session, the receiver needs to
1163 know transport parameters associated with the session. Interpreting
1164 these parameters and starting the reception therefore represents the
1165 entry point from which thereafter the receiver operation falls into
1166 the scope of this specification. According to [RFC5775], the
1167 transport parameters of an ALC/LCT session that the receiver needs to
1168 know are:
1170 * The source IP address;
1172 * The number of channels in the session;
1174 * The destination IP address and port number for each channel in the
1175 session;
1177 * The Transport Session Identifier (TSI) of the session;
1179 * An indication that the session is a FLUTE session. The need to
1180 demultiplex objects upon reception is implicit in any use of
1181 FLUTE, and this fulfills the ALC requirement of an indication of
1182 whether or not a session carries packets for more than one object
1183 (all FLUTE sessions carry packets for more than one object).
1185 Optionally, the following parameters MAY be associated with the
1186 session (Note, the list is not exhaustive):
1188 * The start time and end time of the session;
1190 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1191 ID 0 is not used for the delivery of FDT;
1193 * Content Encoding format if optional content encoding of FDT
1194 Instance is used, e.g., compression;
1196 * Some information that tells receiver, in the first place, that the
1197 session contains files that are of interest;
1199 * Definition and configuration of congestion control mechanism for
1200 the session;
1202 * Security parameters relevant for the session;
1204 * FLUTE version number.
1206 It is envisioned that these parameters would be described according
1207 to some session description syntax (such as SDP [RFC4566] or XML
1208 based) and held in a file which would be acquired by the receiver
1209 before the FLUTE session begins by means of some transport protocol
1210 (such as Session Announcement Protocol (SAP) [RFC2974], email, HTTP
1211 [RFC2616], SIP [RFC3261], manual pre-configuration, etc.) However,
1212 the way in which the receiver discovers the above-mentioned
1213 parameters is out of scope of this document, as it is for LCT and
1214 ALC. In particular, this specification does not mandate or exclude
1215 any mechanism.
1217 7. Security Considerations
1219 7.1. Problem Statement
1221 A content delivery system is potentially subject to attacks. Attacks
1222 may target:
1224 * the network (to compromise the routing infrastructure, e.g., by
1225 creating congestion),
1227 * the Content Delivery Protocol (CDP) (e.g., to compromise the
1228 normal behavior of FLUTE), or
1230 * the content itself (e.g., to corrupt the files being transmitted).
1232 These attacks can be launched either:
1234 * against the data flow itself (e.g., by sending forged packets),
1236 * against the session control parameters (e.g., by corrupting the
1237 session description, the FDT Instances, or the ALC/LCT control
1238 parameters) that are sent either in-band or out-of-band, or
1240 * against some associated building blocks (e.g., the congestion
1241 control component).
1243 In the following sections we provide more details on these possible
1244 attacks and sketch some possible counter-measures. We provide
1245 recommendations in Section 7.5.
1247 7.2. Attacks against the data flow
1249 Let us consider attacks against the data flow first. At least, the
1250 following types of attacks exist:
1252 * attacks that are meant to give access to a confidential file
1253 (e.g., in case of a non-free content) and
1255 * attacks that try to corrupt the file being transmitted (e.g., to
1256 inject malicious code within a file, or to prevent a receiver from
1257 using a file, which is a kind of Denial of Service, DoS).
1259 7.2.1. Access to confidential files
1261 Access control to the file being transmitted is typically provided by
1262 means of encryption. This encryption can be done over the whole file
1263 i.e., before applying FEC protection (e.g., by the content provider,
1264 before submitting the file to FLUTE), or be done on a packet per
1265 packet basis (e.g., when IPsec/ESP is used [RFC4303], see
1266 Section 7.5). If confidentiality is a concern, it is RECOMMENDED
1267 that one of these solutions be used.
1269 7.2.2. File corruption
1271 Protection against corruptions (e.g., if an attacker sends forged
1272 packets) is achieved by means of a content integrity verification/
1273 sender authentication scheme. This service can be provided at the
1274 file level i.e., before applying content encoding and forward error
1275 correction encoding. In that case a receiver has no way to identify
1276 which symbol(s) is(are) corrupted if the file is detected as
1277 corrupted. This service can also be provided at the packet level
1278 i.e., after applying content encoding and forward error correction
1279 encoding, on a packet by packet basis. In this case, after removing
1280 all corrupted packets, the file may be in some cases recovered from
1281 the remaining correct packets.
1283 Integrity protection applied at the file level has the advantage of
1284 lower overhead since only relatively few bits are added to provide
1285 the integrity protection compared to the file size. However it has
1286 the disadvantage that it cannot distinguish between correct packets
1287 and corrupt packets and therefore correct packets, which may form the
1288 majority of packets received, may be unusable. Integrity protection
1289 applied at the packet level has the advantage that it can distinguish
1290 between correct and corrupt packets at the cost of additional per
1291 packet overhead.
1293 Several techniques can provide this source authentication/content
1294 integrity service:
1296 * at the file level, the file MAY be digitally signed, for instance
1297 by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a
1298 receiver to check the file integrity, once this latter has been
1299 fully decoded. Even if digital signatures are computationally
1300 expensive, this calculation occurs only once per file, which is
1301 usually acceptable;
1303 * at the packet level, each packet can be digitally signed
1304 [RFC6584]. A major limitation is the high computational and
1305 transmission overheads that this solution requires. To avoid this
1306 problem, the signature may span a set of symbols (instead of a
1307 single one) in order to amortize the signature calculation, but if
1308 a single symbol is missing, the integrity of the whole set cannot
1309 be checked;
1311 * at the packet level, a Group Message Authentication Code (MAC)
1312 [RFC2104][RFC6584] scheme can be used, for instance by using HMAC-
1313 SHA-256 with a secret key shared by all the group members, senders
1314 and receivers. This technique creates a cryptographically secured
1315 digest of a packet that is sent along with the packet. The Group
1316 MAC scheme does not create prohibitive processing load nor
1317 transmission overhead, but it has a major limitation: it only
1318 provides a group authentication/integrity service since all group
1319 members share the same secret group key, which means that each
1320 member can send a forged packet. It is therefore restricted to
1321 situations where group members are fully trusted (or in
1322 association with another technique as a pre-check);
1324 * at the packet level, TESLA [RFC4082][RFC5776] is an attractive
1325 solution that is robust to losses, provides a true authentication/
1326 integrity service, and does not create any prohibitive processing
1327 load or transmission overhead. Yet checking a packet requires a
1328 small delay (a second or more) after its reception;
1330 * at the packet level, IPsec/ESP [RFC4303] can be used to check the
1331 integrity and authenticate the sender of all the packets being
1332 exchanged in a session (see Section 7.5).
1334 Techniques relying on public key cryptography (digital signatures and
1335 TESLA during the bootstrap process, when used) require that public
1336 keys be securely associated to the entities. This can be achieved by
1337 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
1338 pre-distributing the public keys of each group member.
1340 Techniques relying on symmetric key cryptography (Group MAC) require
1341 that a secret key be shared by all group members. This can be
1342 achieved by means of a group key management protocol, or simply by
1343 pre-distributing the secret key (but this manual solution has many
1344 limitations).
1346 It is up to the developer and deployer, who know the security
1347 requirements and features of the target application area, to define
1348 which solution is the most appropriate. Nonetheless, in case there
1349 is any concern of the threat of file corruption, it is RECOMMENDED
1350 that at least one of these techniques be used.
1352 7.3. Attacks against the session control parameters and associated
1353 Building Blocks
1355 Let us now consider attacks against the session control parameters
1356 and the associated building blocks. The attacker has at least the
1357 following opportunities to launch an attack:
1359 * the attack can target the session description,
1361 * the attack can target the FDT Instances,
1363 * the attack can target the ALC/LCT parameters, carried within the
1364 LCT header or
1366 * the attack can target the FLUTE associated building blocks, for
1367 instance the multiple rate congestion control protocol.
1369 The consequences of these attacks are potentially serious, since they
1370 might compromise the behavior of content delivery system itself.
1372 7.3.1. Attacks against the Session Description
1374 A FLUTE receiver may potentially obtain an incorrect Session
1375 Description for the session. The consequence of this is that
1376 legitimate receivers with the wrong Session Description are unable to
1377 correctly receive the session content, or that receivers
1378 inadvertently try to receive at a much higher rate than they are
1379 capable of, thereby possibly disrupting other traffic in the network.
1381 To avoid these problems, it is RECOMMENDED that measures be taken to
1382 prevent receivers from accepting incorrect Session Descriptions. One
1383 such measure is source authentication to ensure that receivers only
1384 accept legitimate Session Descriptions from authorized senders. How
1385 these measures are achieved is outside the scope of this document
1386 since this session description is usually carried out-of-band.
1388 7.3.2. Attacks against the FDT Instances
1390 Corrupting the FDT Instances is one way to create a Denial of Service
1391 attack. For example, the attacker changes the MD5 sum associated to
1392 a file. This possibly leads a receiver to reject the files received,
1393 no matter whether the files have been correctly received or not.
1395 Corrupting the FDT Instances is also a way to make the reception
1396 process more costly than it should be. This can be achieved by
1397 changing the FEC Object Transmission Information when the FEC Object
1398 Transmission Information is included in the FDT Instance. For
1399 example, an attacker may corrupt the FDT Instance in such a way that
1400 Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
1401 Encoding ID 2. This may significantly increase the processing load
1402 while compromising FEC decoding.
1404 More generally, because FDT Instance data is structured using the XML
1405 language by means of an XML media type, many of the security
1406 considerations described in [RFC3023] and [RFC3470] also apply to
1407 such data.
1409 It is therefore RECOMMENDED that measures be taken to guarantee the
1410 integrity and to check the sender's identity of the FDT Instances.
1411 To that purpose, one of the counter-measures mentioned above
1412 (Section 7.2.2) SHOULD be used. These measures will either be
1413 applied on a packet level, or globally over the whole FDT Instance
1414 object. Additionally, XML digital signatures [RFC3275] are a way to
1415 protect the FDT Instance by digitally signing it. When there is no
1416 packet level integrity verification scheme, it is RECOMMENDED to rely
1417 on XML digital signatures of the FDT Instances.
1419 7.3.3. Attacks against the ALC/LCT parameters
1421 By corrupting the ALC/LCT header (or header extensions) one can
1422 execute attacks on underlying ALC/LCT implementation. For example,
1423 sending forged ALC packets with the Close Session flag (A) set to one
1424 can lead the receiver to prematurely close the session. Similarly,
1425 sending forged ALC packets with the Close Object flag (B) set to one
1426 can lead the receiver to prematurely give up the reception of an
1427 object.
1429 It is therefore RECOMMENDED that measures be taken to guarantee the
1430 integrity and to check the sender's identity of the ALC packets
1431 received. To that purpose, one of the counter-measures mentioned
1432 above (Section 7.2.2) SHOULD be used.
1434 7.3.4. Attacks against the associated Building Blocks
1436 Let us first focus on the congestion control building block, that may
1437 be used in the ALC session. A receiver with an incorrect or
1438 corrupted implementation of the multiple rate congestion control
1439 building block may affect the health of the network in the path
1440 between the sender and the receiver. That may also affect the
1441 reception rates of other receivers who joined the session.
1443 When congestion control building block is applied with FLUTE, it is
1444 therefore RECOMMENDED that receivers be required to identify
1445 themselves as legitimate before they receive the Session Description
1446 needed to join the session. How receivers identify themselves as
1447 legitimate is outside the scope of this document. If authenticating
1448 a receiver does not prevent this latter to launch an attack, it will
1449 enable the network operator to identify him and to take counter-
1450 measures.
1452 When congestion control building block is applied with FLUTE, it is
1453 also RECOMMENDED that a packet level authentication scheme be used,
1454 as explained in Section 7.2.2. Some of them, like TESLA, only
1455 provide a delayed authentication service, whereas congestion control
1456 requires a rapid reaction. It is therefore RECOMMENDED [RFC5775]
1457 that a receiver using TESLA quickly reduces its subscription level
1458 when the receiver believes that a congestion did occur, even if the
1459 packet has not yet been authenticated. Therefore TESLA will not
1460 prevent DoS attacks where an attacker makes the receiver believe that
1461 a congestion occurred. This is an issue for the receiver, but this
1462 will not compromise the network. Other authentication methods that
1463 do not feature this delayed authentication could be preferred, or a
1464 group MAC scheme could be used in parallel to TESLA to prevent
1465 attacks launched from outside of the group.
1467 7.4. Other Security Considerations
1469 The security considerations that apply to, and are described in, ALC
1470 [RFC5775], LCT [RFC5651] and FEC [RFC5052] also apply to FLUTE as
1471 FLUTE builds on those specifications. In addition, any security
1472 considerations that apply to any congestion control building block
1473 used in conjunction with FLUTE also apply to FLUTE.
1475 Even if FLUTE defines a purely unidirectional delivery service,
1476 without any feedback information that would be sent to the sender,
1477 security considerations MAY require bidirectional communications.
1478 For instance if an automated key management scheme is used, a
1479 bidirectional point-to-point channel is often needed to establish a
1480 shared secret between each receiver and the sender. Each shared
1481 secret can then be used to distribute additional keys to the
1482 associated receiver (e.g., traffic encryption keys).
1484 As an example [MBMSsecurity] details a complete security framework
1485 for the 3GPP Multimedia Broadcast/Multicast Service (MBMS) that
1486 relies on FLUTE/ALC for Download Sessions. It relies on
1487 bidirectional point-to-point communications for User Equipment
1488 authentication and for key distribution, using the MIKEY protocol
1489 [RFC3830]. Because this security framework is specific to this use
1490 case, it cannot be reused as such for generic security
1491 recommendations in this specification. Instead the following section
1492 introduces Minimum Security Recommendations.
1494 7.5. Minimum Security Recommendations
1496 We now introduce a mandatory to implement but not necessarily to use
1497 security configuration, in the sense of [RFC3365]. Since FLUTE
1498 relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
1499 [RFC5775]. More precisely, security is achieved by means of IPsec/
1500 ESP in transport mode. [RFC4303] explains that ESP can be used to
1501 potentially provide confidentiality, data origin authentication,
1502 content integrity, anti-replay and (limited) traffic flow
1503 confidentiality. [RFC5775] specifies that the data origin
1504 authentication, content integrity and anti-replay services SHALL be
1505 supported, and that the confidentiality service is RECOMMENDED. If a
1506 short lived session MAY rely on manual keying, it is also RECOMMENDED
1507 that an automated key management scheme be used, especially in case
1508 of long lived sessions.
1510 Therefore, the RECOMMENDED solution for FLUTE provides per-packet
1511 security, with data origin authentication, integrity verification and
1512 anti-replay. This is sufficient to prevent most of the in-band
1513 attacks listed above. If confidentiality is required, a per-packet
1514 encryption SHOULD also be used.
1516 8. IANA Considerations
1518 This specification contains six separate items for IANA
1519 Considerations:
1521 1. Registration of the FDT Instance XML Namespace.
1523 2. Registration of the FDT Instance XML Schema.
1525 3. Registration of the application/fdt+xml Media-Type.
1527 4. Registration of the Content Encoding Algorithms.
1529 5. Registration of two LCT Header Extension Types.
1531 8.1. Registration of the FDT Instance XML Namespace
1533 Please register the following new XML Namespace in the IETF XML
1534 Registry [RFC3688].
1535 http://www.iana.org/assignments/xml-registry/ns.html
1537 URI: urn:ietf:params:xml:ns:fdt
1538 Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
1540 XML: N/A
1542 8.2. Registration of the FDT Instance XML Schema
1544 Please register the following new XML Schema in the IETF XML Registry
1545 [RFC3688]. http://www.iana.org/assignments/xml-registry/schema.html
1547 URI: urn:ietf:params:xml:schema:fdt
1549 Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
1551 XML: The XML Schema specified in Section 3.4.2
1553 8.3. Registration of the application/fdt+xml Media-Type
1555 Please register a new Application XML Media Type in the Media Types
1556 registry, according to [RFC3023].
1557 http://www.iana.org/assignments/media-types/application/
1559 Type name: application
1561 Subtype name: fdt+xml
1563 Required parameters: none
1565 Optional parameters: charset="utf-8"
1567 Encoding considerations: binary (the FLUTE file delivery protocol
1568 does not impose any restriction on the objects it carries and in
1569 particular on the FDT Instance itself)
1571 Restrictions on usage: none
1573 Security considerations: fdt+xml data is passive, and does not
1574 generally represent a unique or new security threat. However, there
1575 is some risk in sharing any kind of data, in that unintentional
1576 information may be exposed, and that risk applies to fdt+xml data as
1577 well.
1579 Interoperability considerations: None
1581 Published specification: [[RFCxxxx]], especially noting section
1582 3.4.2. The specified FDT Instance functions as an actual media
1583 format of use to the general Internet community and thus media type
1584 registration under the Standards Tree is appropriate to maximize
1585 interoperability.
1587 Applications which use this media type: file and object delivery
1588 applications and protocols (e.g., FLUTE).
1590 Additional information:
1592 Magic number(s): none
1593 File extension(s): ".fdt" (e.g., if there is a need to store an
1594 FDT Instance as a file);
1595 Macintosh File Type Code(s): none
1597 Person and email address to contact for further information: Toni
1598 Paila (toni.paila@nokia.com)
1600 Intended usage: Common
1602 Author/Change controller: IETF
1604 8.4. Creation of the FLUTE Content Encoding Algorithms registry
1606 Please create a new registry, "FLUTE Content Encoding Algorithms",
1607 with a reference to [[RFCxxxx]] Section 3.4.3. The registry entries
1608 will consist of a numeric value from 0 to 255, inclusive, and may be
1609 registered using the Specification Required policy [RFC5226].
1611 The initial contents of the registry are as follows, with unspecified
1612 values available for new registrations:
1614 +-------+----------------+-------------+
1615 | Value | Algorithm name | Reference |
1616 +-------+----------------+-------------+
1617 | 0 | null | [[RFCxxxx]] |
1618 | 1 | ZLIB | [RFC1950] |
1619 | 2 | DEFLATE | [RFC1951] |
1620 | 3 | GZIP | [RFC1952] |
1621 +-------+----------------+-------------+
1623 8.5. Registration of LCT Header Extension Types
1625 Please register two new entries in the Layered Coding Transport (LCT)
1626 Header Extension Types registry [RFC5651], as follows:
1628 +--------+----------+---------------------------+
1629 | Number | Name | Reference |
1630 +--------+----------+---------------------------+
1631 | 192 | EXT_FDT | [[RFCxxxx]] Section 3.4.1 |
1632 | 193 | EXT_CENC | [[RFCxxxx]] Section 3.4.3 |
1633 +--------+----------+---------------------------+
1635 9. Acknowledgments
1637 The following persons have contributed to this specification: Brian
1638 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1639 Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington,
1640 Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis
1641 Dupont, Peter Saint-Andre, Don Gillies and Barry Leiba. The authors
1642 would like to thank all the contributors for their valuable work in
1643 reviewing and providing feedback regarding this specification.
1645 10. Contributors
1647 Jani Peltotalo
1648 Tampere University of Technology
1649 P.O. Box 553 (Korkeakoulunkatu 1)
1650 Tampere FIN-33101
1651 Finland
1652 Email: jani.peltotalo (at) tut.fi
1654 Sami Peltotalo
1655 Tampere University of Technology
1656 P.O. Box 553 (Korkeakoulunkatu 1)
1657 Tampere FIN-33101
1658 Finland
1659 Email: sami.peltotalo (at) tut.fi
1661 Magnus Westerlund
1662 Ericsson Research
1663 Ericsson AB
1664 SE-164 80 Stockholm
1665 Sweden
1666 EMail: magnus.westerlund (at) ericsson.com
1668 Thorsten Lohmar
1669 Ericsson Research (EDD)
1670 Ericsson Allee 1
1671 52134 Herzogenrath
1672 Germany
1673 EMail: thorsten.lohmar (at) ericsson.com
1675 11. Change Log
1677 11.1. RFC3926 to draft-ietf-rmt-flute-revised-12
1679 Incremented FLUTE protocol version from 1 to 2, due to concerns about
1680 backwards compatibility. For instance, the LCT header changed
1681 between RFC 3451 and [RFC5651]. In RFC 3451, the T and R fields of
1682 the LCT header respectively indicate the presence of Sender Current
1683 Time and Expected Residual Time. In [RFC5651], these fields MUST be
1684 set to zero and MUST be ignored by receivers (instead the EXT_TIME
1685 extension headers can convey this information if needed). Thus,
1686 [RFC5651] is not backwards compatible with RFC 3451, even though both
1687 have the same LCT version 1. FLUTE version 1 as specified in
1688 [RFC3926] MUST use RFC 3451. FLUTE version 2 as specified in this
1689 document MUST use [RFC5651]. Therefore an implementation that relies
1690 on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE
1691 as specified in this document.
1693 Updated dependencies to other RFCs to revised versions, e.g., changed
1694 ALC reference from RFC 3450 to [RFC5775], changed LCT reference from
1695 RFC 3451 to [RFC5651], etc.
1697 Two additional items are added in the IANA considerations section,
1698 specifically the registration of two values in the LCT Header
1699 Extension Types registry (192 for EXT_FDT and 193 for EXT_CENC).
1701 Added clarification for the use of FLUTE for unicast communications
1702 in Section 1.1.4.
1704 Clarified how to reliably deliver the FDT in Section 3.3 and the
1705 possibility of using an out-of-band delivery of FDT information.
1707 Clarified how to address FDT Instance expiration time wraparound with
1708 the notion of "epoch" of NTPv4 in Section 3.3.
1710 Clarified what should be considered as erroneous situations in
1711 Section 3.4.1 (definition of FDT Instance ID). In particular a
1712 receiver MUST be ready to handle FDT Instance ID wraparounds and
1713 missing FDT Instances.
1715 Updated the security section to define IPsec/ESP as a mandatory to
1716 implement security solution in Section 7.5.
1718 Removed the 'Statement of Intent' from the Section 1. The statement
1719 of intent was meant to clarify the "Experimental" status of
1720 [RFC3926]. It does not apply to this draft that is intended for
1721 "Standard Track" submission.
1723 Added clarification on XML-DSIG in the end of Section 3.
1725 Revised the use of word "complete" in the Section 3.2.
1727 Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance".
1729 Clarified the FDT Instance ID wrap-around in the end of
1730 Section 3.4.1.
1732 Clarifications for "Complete FDT" in the Section 3.4.2.
1734 Added semantics for the case two TOIs refer to same Content-Location.
1735 Now it is in line how 3GPP and DVB interpret the case.
1737 In the Section 3.4.2 XML Schema of FDT instance is modified to
1738 various advices. For example, extension by element was missing but
1739 is now supported. Also namespace definition is changed to URN
1740 format.
1742 Clarified FDT-schema extensibility in the end of Section 3.4.2.
1744 The CENC value allocation is added in the end of Section 3.4.3.
1746 Section 5 is modified so that EXT_FTI and the FEC issues are replaced
1747 by a reference to LCT specification. We count on revised LCT
1748 specification to specify the EXT_FTI.
1750 Added a clarifying paragraph on the use of Codepoint in the very end
1751 of Section 5.
1753 Reworked Section 8 - IANA Considerations. Now it contains three IANA
1754 registration requests:
1756 * Registration Request for XML Schema of FDT Instance
1757 (urn:ietf:params:xml:schema:fdt)
1759 * Media-Type Registration Request for application/fdt+xml
1761 * Content Encoding Algorithm Registration Request (ietf:rmt:cenc)
1763 Added Section 10 - Contributors.
1765 Revised list of both Normative as well as Informative references.
1767 Added a clarification that receiver should ignore reserved bits of
1768 Header Extension type 193 upon reception.
1770 Minor changes to remove forward references (use before definition) or
1771 refer to forward reference sections.
1773 Elaborate on just what kind of networks cannot support FLUTE
1774 congestion control (1.1.4)
1776 In Section 3.2 revise "several" (meaning 3-n vs. "couple" = 2) to
1777 "multiple" (meaning 2-n)
1779 Move Section 3.3 requirement to send FDT more reliably than files, to
1780 a bulleted RECOMMENDED requirement, making check-off easier for
1781 testers.
1783 Sharpen Section 3.3 definition that future FDT file instances can
1784 "augment" (meaning enhance) rather than "complement" (sometimes
1785 meaning negate, which is not allowed) the file parameters.
1787 Elaborate in Section 3.3 and Section 4 that FEC Encoding ID = 0 is
1788 Compact No-code FEC, so that the reader doesn't have to search other
1789 RFCs to understand these protocol constants used by FLUTE.
1791 Require in Section 3.3 that FLUTE receivers SHALL NOT attempt to
1792 decode FDTs if they do not understand the FEC Encoding ID
1794 Remove restriction of Section 3.3 in bullet #4 that TOI=0 for the
1795 FDT, to be consistent with Appendix, bullet 6, and elsewhere. An FDT
1796 is signaled by an FDT Instance ID, NOT only by TOI = 0.
1798 Standardize on the term "expiration time" and avoid using the
1799 redundant but possibly confusing term "expiry time".
1801 To interwork with experimental flute, stipulate in Section 3.1 that
1802 only 1 instantiation of all 3 protocols FLUTE, ALC, and LCT, can be
1803 associated with a session (source IP-Address, TSI) and mention in
1804 Section 6 that you may (optionally) derive the FLUTE version from the
1805 file delivery session description.
1807 Use a software writing tool to lower reading grade level and simplify
1808 Section 3.1.
1810 12. References
1812 12.1. Normative references
1814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1815 Requirement Levels", RFC 2119, BCP 14, March 1997.
1817 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
1818 Layered Coding (ALC) Protocol Instantiation", RFC 5775,
1819 April 2010.
1821 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
1822 Transport (LCT) Building Block", RFC 5651, October 2009.
1824 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
1825 Correction (FEC) Building Block", RFC 5052, August 2007.
1827 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
1828 Schemes", RFC 5445, March 2009.
1830 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
1831 Time Protocol Version 4: Protocol and Algorithms
1832 Specification", RFC 5905, June 2010.
1834 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1835 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1836 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1838 [XML-Schema-Part-1]
1839 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1840 "XML Schema Part 1: Structures Second Edition", W3C
1841 Recommendation, http://www.w3.org/TR/xmlschema-1/,
1842 October 2004.
1844 [XML-Schema-Part-2]
1845 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1846 Second Edition", W3C Recommendation,
1847 http://www.w3.org/TR/xmlschema-2/, October 2004.
1849 [RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media
1850 Types", RFC 3023, January 2001.
1852 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1853 IANA Considerations Section in RFCs", RFC 5226, May 2008.
1855 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
1856 Control (WEBRC) Building Block", RFC 3738, April 2004.
1857 Note: the RFC3738 reference is to a target document of a
1858 lower maturity level and some caution should be used since
1859 it may be less stable than the present document.
1861 [RFC4303] Kent, S., "Encapsulating Security Payload (ESP)",
1862 RFC 4303, December 2005.
1864 12.2. Informative references
1866 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
1867 "FLUTE - File Delivery over Unidirectional Transport",
1868 RFC 3926, October 2004.
1870 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
1871 Criteria for Evaluating Reliable Multicast Transport and
1872 Application Protocols", RFC 2357, June 1998.
1874 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1875 Resource Identifier (URI): Generic Syntax", STD 66,
1876 RFC 3986, January 2005.
1878 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
1879 the Use of Extensible Markup Language (XML)
1880 within IETF Protocols", BCP 70, RFC 3470, January 2003.
1882 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1883 Extensions (MIME) Part One: Format of Internet Message
1884 Bodies", RFC 2045, November 1996.
1886 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1887 Specification version 3.3", RFC 1950, May 1996.
1889 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
1890 version 1.3", RFC 1951, May 1996.
1892 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
1893 RFC 1952, May 1996.
1895 [IANAheaderfields]
1896 IANA, "Permanent and Provisional Message Header Field
1897 Names registries", URL: http://www.iana.org/assignments/
1898 message-headers/perm-headers.html, URL: http://
1899 www.iana.org/assignments/message-headers/
1900 prov-headers.html.
1902 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
1903 Announcement Protocol", RFC 2974, October 2000.
1905 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "Session
1906 Description Protocol", RFC 4566, July 2006.
1908 [RFC1112] Deering, S., "Host Extensions for IP Multicasting",
1909 RFC 1112, STD 5, August 1989.
1911 [PAPER.SSM]
1912 Holbrook, H., "A Channel Model for Multicast, Ph.D.
1913 Dissertation, Stanford University, Department of Computer
1914 Science, Stanford, California", August 2001.
1916 [RFC3365] Schiller, J., "Strong Security Requirements for Internet
1917 Engineering Task Force Standard Protocols", BCP 61,
1918 RFC 3365, August 2002.
1920 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
1921 Mail Extensions (S/MIME) Version 3.2 Message
1922 Specification", RFC 5751, January 2010.
1924 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
1925 Language) XML-Signature Syntax and Processing", RFC 3275,
1926 March 2002.
1928 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1929 A., Peterson, J., Sparks, R., Handley, M., and E.
1930 Schooler, "SIP: session initiation protocol", RFC 3261,
1931 June 2002.
1933 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688,
1934 January 2004.
1936 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1937 Standards (PKCS) #1: RSA Cryptography Specifications
1938 Version 2.1", RFC 3447, February 2003.
1940 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1941 Hashing for Message Authentication", RFC 2104,
1942 February 1997.
1944 [RFC4082] Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe,
1945 "Timed Efficient Stream Loss-Tolerant Authentication
1946 (TESLA): Multicast Source Authentication Transform
1947 Introduction", RFC 4082, June 2005.
1949 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed
1950 Efficient Stream Loss-Tolerant Authentication (TESLA) in
1951 the Asynchronous Layered Coding (ALC) and NACK-Oriented
1952 Reliable Multicast (NORM) Protocols", RFC 5776,
1953 April 2010.
1955 [RFC6584] Roca, V., "Simple Authentication Schemes for the
1956 Asynchronous Layered Coding (ALC) and NACK-Oriented
1957 Reliable Multicast (NORM) Protocols", RFC 6584,
1958 April 2012.
1960 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
1961 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
1962 August 2004.
1964 [MBMSsecurity]
1965 "3rd Generation Partnership Project; Technical
1966 Specification Group Services and System Aspects; 3G
1967 Security; Security of Multimedia Broadcast/Multicast
1968 Service (MBMS) (Release 10)", URL: http://www.3gpp.org/
1969 ftp/Specs/archive/33_series/33.246/, December 2010.
1971 Appendix A. Receiver operation (informative)
1973 This section gives an example how the receiver of the file delivery
1974 session may operate. Instead of a detailed state-by-state
1975 specification the following should be interpreted as a rough sequence
1976 of an envisioned file delivery receiver.
1978 1. The receiver obtains the description of the file delivery session
1979 identified by the pair: (source IP address, Transport Session
1980 Identifier). The receiver also obtains the destination IP
1981 addresses and respective ports associated with the file delivery
1982 session.
1984 2. The receiver joins the channels in order to receive packets
1985 associated with the file delivery session. The receiver may
1986 schedule this join operation utilizing the timing information
1987 contained in a possible description of the file delivery session.
1989 3. The receiver receives ALC/LCT packets associated with the file
1990 delivery session. The receiver checks that the packets match the
1991 declared Transport Session Identifier. If not, packets are
1992 silently discarded.
1994 4. While receiving, the receiver demultiplexes packets based on
1995 their TOI and stores the relevant packet information in an
1996 appropriate area for recovery of the corresponding file.
1997 Multiple files can be reconstructed concurrently.
1999 5. Receiver recovers an object. An object can be recovered when an
2000 appropriate set of packets containing Encoding Symbols for the
2001 transmission object have been received. An appropriate set of
2002 packets is dependent on the properties of the FEC Encoding ID and
2003 FEC Instance ID, and on other information contained in the FEC
2004 Object Transmission Information.
2006 6. Objects with TOI = 0 are reserved for FDT Instances. All FDT
2007 Instances are signaled by including an EXT_FDT header extension
2008 in the LCT header. The EXT_FDT header contains an FDT Instance
2009 ID (i.e., an FDT version number.) If the object has an FDT
2010 Instance ID 'N', the receiver parses the payload of the instance
2011 'N' of FDT and updates its FDT database accordingly.
2013 7. If the object recovered is not an FDT Instance but a file, the
2014 receiver looks up its FDT database to get the properties
2015 described in the database, and assigns the file the given
2016 properties. The receiver also checks that the received content
2017 length matches with the description in the database. Optionally,
2018 if MD5 checksum has been used, the receiver checks that the
2019 calculated MD5 matches the description in the FDT database.
2021 8. The actions the receiver takes with imperfectly received files
2022 (missing data, mismatching digestive, etc.) is outside the scope
2023 of this specification. When a file is recovered before the
2024 associated file description entry is available, a possible
2025 behavior is to wait until an FDT Instance is received that
2026 includes the missing properties.
2028 9. If the file delivery session end time has not been reached go
2029 back to 3. Otherwise end.
2031 Appendix B. Example of FDT Instance (informative)
2033
2034
2038
2042
2050
2052 Authors' Addresses
2054 Toni Paila
2055 Nokia
2056 Itamerenkatu 11-13
2057 Helsinki 00180
2058 Finland
2060 Email: toni.paila@nokia.com
2062 Rod Walsh
2063 Tampere University of Technology
2064 P.O. Box 553 (Korkeakoulunkatu 1)
2065 Tampere FI-33101
2066 Finland
2068 Email: roderick.walsh@tut.fi
2070 Michael Luby
2071 Qualcomm, Inc.
2072 3165 Kifer Rd.
2073 Santa Clara, CA 95051
2074 USA
2076 Email: luby@qualcomm.com
2078 Vincent Roca
2079 INRIA
2080 655, av. de l'Europe
2081 Inovallee; Montbonnot
2082 ST ISMIER cedex 38334
2083 France
2085 Email: vincent.roca@inria.fr
2087 Rami Lehtonen
2088 TeliaSonera
2089 Hatanpaan valtatie 18
2090 Tampere FIN-33100
2091 Finland
2093 Email: rami.lehtonen@teliasonera.com