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