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