< draft-ietf-rmt-flute-revised-14.txt   draft-ietf-rmt-flute-revised-15.txt >
Reliable Multicast Transport (RMT) T. Paila Reliable Multicast Transport (RMT) T. Paila
Internet-Draft Nokia Internet-Draft Nokia
Obsoletes: 3926 (if approved) R. Walsh Obsoletes: 3926 (if approved) R. Walsh
Intended status: Standards Track Tampere University of Technology Intended status: Standards Track Tampere University of Technology
Expires: September 13, 2012 M. Luby Expires: December 15, 2012 M. Luby
Qualcomm, Inc. Qualcomm, Inc.
V. Roca V. Roca
INRIA INRIA
R. Lehtonen R. Lehtonen
TeliaSonera TeliaSonera
March 12, 2012 June 13, 2012
FLUTE - File Delivery over Unidirectional Transport FLUTE - File Delivery over Unidirectional Transport
draft-ietf-rmt-flute-revised-14 draft-ietf-rmt-flute-revised-15
Abstract Abstract
This document defines FLUTE, a protocol for the unidirectional This document defines FLUTE, a protocol for the unidirectional
delivery of files over the Internet, which is particularly suited to delivery of files over the Internet, which is particularly suited to
multicast networks. The specification builds on Asynchronous Layered multicast networks. The specification builds on Asynchronous Layered
Coding, the base protocol designed for massively scalable multicast Coding, the base protocol designed for massively scalable multicast
distribution. This document obsoletes RFC3926. distribution. This document obsoletes RFC3926.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2012. This Internet-Draft will expire on December 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
1.1.3. Intended Environments . . . . . . . . . . . . . . . . 7 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 7
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions used in this Document . . . . . . . . . . . . . . 8 2. Conventions used in this Document . . . . . . . . . . . . . . 8
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 8 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. File delivery session . . . . . . . . . . . . . . . . . . 9 3.1. File delivery session . . . . . . . . . . . . . . . . . . 9
3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 11 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 11
3.3. Dynamics of FDT Instances within file delivery session . . 13 3.3. Dynamics of FDT Instances within file delivery session . . 13
3.4. Structure of FDT Instance packets . . . . . . . . . . . . 16 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 16
3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 17 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 17
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 18 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 18
3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 22 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 23
3.5. Multiplexing of files within a file delivery session . . . 23 3.5. Multiplexing of files within a file delivery session . . . 23
4. Channels, congestion control and timing . . . . . . . . . . . 23 4. Channels, congestion control and timing . . . . . . . . . . . 24
5. Delivering FEC Object Transmission Information . . . . . . . . 25 5. Delivering FEC Object Transmission Information . . . . . . . . 25
6. Describing file delivery sessions . . . . . . . . . . . . . . 26 6. Describing file delivery sessions . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 28 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 28
7.2. Attacks against the data flow . . . . . . . . . . . . . . 28 7.2. Attacks against the data flow . . . . . . . . . . . . . . 28
7.2.1. Access to confidential files . . . . . . . . . . . . . 28 7.2.1. Access to confidential files . . . . . . . . . . . . . 29
7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 29 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 29
7.3. Attacks against the session control parameters and 7.3. Attacks against the session control parameters and
associated Building Blocks . . . . . . . . . . . . . . . . 30 associated Building Blocks . . . . . . . . . . . . . . . . 31
7.3.1. Attacks against the Session Description . . . . . . . 31 7.3.1. Attacks against the Session Description . . . . . . . 31
7.3.2. Attacks against the FDT Instances . . . . . . . . . . 31 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 31
7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 32 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 32
7.3.4. Attacks against the associated Building Blocks . . . . 32 7.3.4. Attacks against the associated Building Blocks . . . . 32
7.4. Other Security Considerations . . . . . . . . . . . . . . 33 7.4. Other Security Considerations . . . . . . . . . . . . . . 33
7.5. Minimum Security Recommendations . . . . . . . . . . . . . 33 7.5. Minimum Security Recommendations . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Registration Request for XML Schema of FDT Instance . . . 34 8.1. Registration of the FDT Instance XML Namespace . . . . . . 34
8.2. Media-Type Registration Request for application/fdt+xml . 34 8.2. Registration of the FDT Instance XML Schema . . . . . . . 35
8.3. Content Encoding Algorithm Registration Request . . . . . 35 8.3. Registration of the application/fdt+xml Media-Type . . . . 35
8.3.1. Explicit IANA Assignment Guidelines . . . . . . . . . 35 8.4. Registration of the Content Encoding Algorithm . . . . . . 36
8.4. Registration of EXT_FDT LCT Header Extension Type . . . . 36 8.4.1. Explicit IANA Assignment Guidelines . . . . . . . . . 36
8.5. Registration of EXT_CENC LCT Header Extension Type . . . . 36 8.5. Registration of the EXT_FDT LCT Header Extension Type . . 36
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 8.6. Registration of the EXT_CENC LCT Header Extension Type . . 37
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. RFC3926 to draft-ietf-rmt-flute-revised-12 . . . . . . . . 37 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. RFC3926 to draft-ietf-rmt-flute-revised-12 . . . . . . . . 38
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative references . . . . . . . . . . . . . . . . . . . 40 12.1. Normative references . . . . . . . . . . . . . . . . . . . 40
12.2. Informative references . . . . . . . . . . . . . . . . . . 41 12.2. Informative references . . . . . . . . . . . . . . . . . . 42
Appendix A. Receiver operation (informative) . . . . . . . . . . 44
Appendix A. Receiver operation (informative) . . . . . . . . . . 43 Appendix B. Example of FDT Instance (informative) . . . . . . . . 45
Appendix B. Example of FDT Instance (informative) . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines FLUTE version 2, a protocol for unidirectional This document defines FLUTE version 2, a protocol for unidirectional
delivery of files over the Internet. This specification is not delivery of files over the Internet. This specification is not
backwards compatible with the previous experimental version defined backwards compatible with the previous experimental version defined
in [RFC3926] (see Section 11 for details). The specification builds in [RFC3926] (see Section 11 for details). The specification builds
on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base on Asynchronous Layered Coding (ALC), version 1 [RFC5775], the base
protocol designed for massively scalable multicast distribution. ALC protocol designed for massively scalable multicast distribution. ALC
defines transport of arbitrary binary objects. For file delivery defines transport of arbitrary binary objects. For file delivery
skipping to change at page 7, line 26 skipping to change at page 7, line 26
not require connectivity from receivers to a sender. Because of its not require connectivity from receivers to a sender. Because of its
low expectations, FLUTE works with most types of networks, including low expectations, FLUTE works with most types of networks, including
LANs, WANs, Intranets, the Internet, asymmetric networks, wireless LANs, WANs, Intranets, the Internet, asymmetric networks, wireless
networks, and satellite networks. networks, and satellite networks.
FLUTE is compatible with both IPv4 or IPv6 as no part of the packet FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
is IP version specific. FLUTE works with both multicast models: Any- is IP version specific. FLUTE works with both multicast models: Any-
Source Multicast (ASM) [RFC1112] and the Source-Specific Multicast Source Multicast (ASM) [RFC1112] and the Source-Specific Multicast
(SSM) [PAPER.SSM]. (SSM) [PAPER.SSM].
FLUTE is applicable for both Internet use, with a suitable congestion FLUTE is applicable for both shared networks, such as Internet, with
control building block, and provisioned/controlled systems, such as a suitable congestion control building block, and provisioned/
delivery over wireless broadcast radio systems. controlled networks, such as wireless broadcast radio systems, with a
traffic shaping building block.
1.1.4. Weaknesses 1.1.4. Weaknesses
FLUTE congestion control protocols depend on the ability of a FLUTE congestion control protocols depend on the ability of a
receiver to change multicast subscriptions between multicast groups receiver to change multicast subscriptions between multicast groups
supporting different rates and/or layered codings. If the network supporting different rates and/or layered codings. If the network
does not support this, then the FLUTE congestion control protocols does not support this, then the FLUTE congestion control protocols
may not be amenable to these networks. may not be amenable to these networks.
FLUTE can also be used for point-to-point (unicast) communications. FLUTE can also be used for point-to-point (unicast) communications.
skipping to change at page 8, line 40 skipping to change at page 8, line 41
by the file delivery protocol. by the file delivery protocol.
* Identifier of the file, expressed as a URI [RFC3986]. The * Identifier of the file, expressed as a URI [RFC3986]. The
identifier MAY provide a location for the file. In the above identifier MAY provide a location for the file. In the above
example: "http://www.example.com/docs/file.txt". example: "http://www.example.com/docs/file.txt".
* File name (usually, this can be concluded from the URI). In the * File name (usually, this can be concluded from the URI). In the
above example: "file.txt". above example: "file.txt".
* File type, expressed as Internet Media Types (often referred to as * File type, expressed as Internet Media Types (often referred to as
"MIME Media Types"). In the above example: "text/plain". "Media Types"). In the above example: "text/plain".
* File size, expressed in octets. In the above example: "5200". If * File size, expressed in octets. In the above example: "5200". If
the file is content encoded then this is the file size before the file is content encoded then this is the file size before
content encoding. content encoding.
* Content encoding of the file, within transport. In the above * Content encoding of the file, within transport. In the above
example, the file could be encoded using ZLIB [RFC1950]. In this example, the file could be encoded using ZLIB [RFC1950]. In this
case the size of the transmission object carrying the file would case the size of the transmission object carrying the file would
probably differ from the file size. The transmission object size probably differ from the file size. The transmission object size
is delivered to receivers as part of the FLUTE protocol. is delivered to receivers as part of the FLUTE protocol.
skipping to change at page 10, line 38 skipping to change at page 10, line 44
packets using IPv6, but some portions of the network may not be IPv6 packets using IPv6, but some portions of the network may not be IPv6
capable. Thus, there may be an IPv6 to IPv4 translator that changes capable. Thus, there may be an IPv6 to IPv4 translator that changes
the IP address of the packets to a different IPv4 address. In this the IP address of the packets to a different IPv4 address. In this
case, receivers in the IPv4 portion of the network will receive case, receivers in the IPv4 portion of the network will receive
packets containing the IPv4 address, and thus the TSI for them is packets containing the IPv4 address, and thus the TSI for them is
scoped by the IPv4 address. How the IP address of the sender to be scoped by the IPv4 address. How the IP address of the sender to be
used to scope the session by receivers is delivered to receivers, used to scope the session by receivers is delivered to receivers,
whether it is the sender's IP address or an intermediate IP address, whether it is the sender's IP address or an intermediate IP address,
is outside the scope of this document. is outside the scope of this document.
When FLUTE is used for file delivery over ALC the following rules When FLUTE is used for file delivery over ALC, the ALC/LCT session is
apply: called a file delivery session and the ALC/LCT concept of 'object'
denotes either a 'file' or a 'File Delivery Table Instance' (section
* The ALC/LCT session is called a file delivery session. 3.2).
* The ALC/LCT concept of 'object' denotes either a 'file' or a 'File Additionally, the following rules apply:
Delivery Table Instance' (section 3.2)
* The TOI field MUST be included in ALC packets sent within a FLUTE * The TOI field MUST be included in ALC packets sent within a FLUTE
session, with the exception that ALC packets sent in a FLUTE session, with the exception that ALC packets sent in a FLUTE
session with the Close Session (A) flag set to 1 (signaling the session with the Close Session (A) flag set to 1 (signaling the
end of the session) and that contain no payload (carrying no end of the session) and that contain no payload (carrying no
information for any file or FDT) SHALL NOT carry the TOI. See information for any file or FDT) SHALL NOT carry the TOI. See
section 5.1 of [RFC5651] for the LCT definition of the Close section 5.1 of [RFC5651] for the LCT definition of the Close
Session flag, and see section 4.2 of [RFC5775] for an example of Session flag, and see section 4.2 of [RFC5775] for an example of
the use of a TOI within an ALC packet. the use of a TOI within an ALC packet.
* The TOI value '0' is reserved for delivery of File Delivery Table * The TOI value '0' is reserved for the delivery of File Delivery
Instances. Each non expired File Delivery Table Instance is Table Instances. Each non expired File Delivery Table Instance is
uniquely identified by an FDT Instance ID within the EXT_FDT uniquely identified by an FDT Instance ID within the EXT_FDT
header defined in section 3.4.1. header defined in section 3.4.1.
* Each file in a file delivery session MUST be associated with a TOI * Each file in a file delivery session MUST be associated with a TOI
(>0) in the scope of that session. (>0) in the scope of that session.
* Information carried in the headers and the payload of a packet is * Information carried in the headers and the payload of a packet is
scoped by the source IP address and the TSI. Information scoped by the source IP address and the TSI. Information
particular to the object carried in the headers and the payload of particular to the object carried in the headers and the payload of
a packet is further scoped by the TOI for file objects, and is a packet is further scoped by the TOI for file objects, and is
skipping to change at page 11, line 45 skipping to change at page 12, line 7
and, if relevant, the FEC Instance ID) and, if relevant, the FEC Instance ID)
- Size of the transmission object carrying the file - Size of the transmission object carrying the file
- Aggregate rate of sending packets to all channels - Aggregate rate of sending packets to all channels
Attributes related to the file itself: Attributes related to the file itself:
- Name, Identification and Location of file (specified by the URI) - Name, Identification and Location of file (specified by the URI)
- MIME media type of file - Media type of file
- Size of file - Size of file
- Encoding of file - Encoding of file
- Message digest of file - Message digest of file
Some of these attributes MUST be included in the file description Some of these attributes MUST be included in the file description
entry for a file, others are optional, as defined in section 3.4.2. entry for a file, others are optional, as defined in section 3.4.2.
Logically, the FDT is a set of file description entries for files to Logically, the FDT is a set of file description entries for files to
be delivered in the session. Each file description entry MUST be delivered in the session. Each file description entry MUST
include the TOI for the file that it describes and the URI include the TOI for the file that it describes and the URI
skipping to change at page 14, line 21 skipping to change at page 14, line 24
* An FDT Instance is valid until its expiration time. The * An FDT Instance is valid until its expiration time. The
expiration time is expressed within the FDT Instance payload as an expiration time is expressed within the FDT Instance payload as an
UTF-8 decimal representation of a 32 bit unsigned integer. The UTF-8 decimal representation of a 32 bit unsigned integer. The
value of this integer represents the 32 most significant bits of a value of this integer represents the 32 most significant bits of a
64 bit Network Time Protocol (NTP) [RFC5905] time value. These 32 64 bit Network Time Protocol (NTP) [RFC5905] time value. These 32
bits provide an unsigned integer representing the time in seconds bits provide an unsigned integer representing the time in seconds
relative to 0 hours 1 January 1900 in case of the prime epoch (era relative to 0 hours 1 January 1900 in case of the prime epoch (era
0) [RFC5905]. The handling of time wraparound (to happen in 2036) 0) [RFC5905]. The handling of time wraparound (to happen in 2036)
requires to consider the associated epoch. In any case, both a requires to consider the associated epoch. In any case, both a
sender and a receiver can determine to which (136 year) epoch the sender and a receiver easily determine to which (136 year) epoch
FDT Instance expiration time value pertains to by choosing the the FDT Instance expiration time value pertains to by choosing the
epoch for which the expiration time is closest in time to the epoch for which the expiration time is closest in time to the
current time. current time.
Here is an example. Let us imagine a new FLUTE session is started Here is an example. Let us imagine a new FLUTE session is started
on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few on February 7th, 2036, 0h, i.e., at NTP time 4,294,944,000, a few
hours before the end of epoch 0. In order to define an FDT hours before the end of epoch 0. In order to define an FDT
Instance valid for the next 48 hours, The FLUTE sender sets an Instance valid for the next 48 hours, The FLUTE sender sets an
expiry time of 149,504. This FDT Instance will expire exactly on expiry time of 149,504. This FDT Instance will expire exactly on
February 9th, 2036, 0h. A client that receives this FDT Instance February 9th, 2036, 0h. A client that receives this FDT Instance
on the 7th, 0h, just after it has been sent, immediately on the 7th, 0h, just after it has been sent, immediately
skipping to change at page 16, line 4 skipping to change at page 16, line 7
techniques as explained for the case when there is a single file techniques as explained for the case when there is a single file
transmitted in a session. transmitted in a session.
In any case, how often the description of a file is sent in an FDT In any case, how often the description of a file is sent in an FDT
Instance, how often an FDT Instance is sent, and how much FEC Instance, how often an FDT Instance is sent, and how much FEC
protection is provided for an FDT Instance (if longer than one packet protection is provided for an FDT Instance (if longer than one packet
payload) are dependent on the particular application and are outside payload) are dependent on the particular application and are outside
the scope of this document. the scope of this document.
Sometimes the various attributes associated with files that are to be Sometimes the various attributes associated with files that are to be
delivered within the file delivery session are sent out-of-band delivered within the file delivery session are sent out-of-band. The
(rather than in-band, within one or several FDT Instances). The
details of how this is done are out of the scope of this document. details of how this is done are out of the scope of this document.
However, it is still RECOMMENDED that any out-of-band transmission be However, it is still RECOMMENDED that any out-of-band transmission be
managed in such a way that a receiver will be able to recover the managed in such a way that a receiver will be able to recover the
attributes associated with a file with as much or greater reliability attributes associated with a file with as much or greater reliability
as the receiver is able to receive enough packets containing encoding as the receiver is able to receive enough packets containing encoding
symbols to recover the file. For example, the probability of a symbols to recover the file. For example, the probability of a
randomly chosen receiver being able to recover a given file can often randomly chosen receiver being able to recover a given file can often
be estimated based on a statistical model of reception conditions, be estimated based on a statistical model of reception conditions,
the amount of data transmitted and the properties of any Forward the amount of data transmitted and the properties of any Forward
Error Correction in use. The recommendation above suggests that Error Correction in use. The recommendation above suggests that
mechanisms used for file attribute delivery should achieve higher a mechanisms used for file attribute delivery should achieve higher a
delivery probability than the file recovery probability. delivery probability than the file recovery probability. The sender
MAY also continue sending the various file attributes in-band, in
addition to the out-of-band transmission.
3.4. Structure of FDT Instance packets 3.4. Structure of FDT Instance packets
FDT Instances are carried in ALC packets with TOI = 0 and with an FDT Instances are carried in ALC packets with TOI = 0 and with an
additional REQUIRED LCT Header extension called the FDT Instance additional REQUIRED LCT Header extension called the FDT Instance
Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
ID that uniquely identifies FDT Instances within a file delivery ID that uniquely identifies FDT Instances within a file delivery
session. The FDT Instance Header is placed in the same way as any session. The FDT Instance Header is placed in the same way as any
other LCT extension header. There MAY be other LCT extension headers other LCT extension header. There MAY be other LCT extension headers
in use. in use.
The FDT Instance is encoded for transmission, like any other object, The FDT Instance is encoded for transmission, like any other object,
using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme) The using an FEC Scheme (which MAY be the Compact No-Code FEC Scheme).
LCT extension headers are followed by the FEC Payload ID, and finally The LCT extension headers are followed by the FEC Payload ID, and
the Encoding Symbols for the FDT Instance which contains one or more finally the Encoding Symbols for the FDT Instance which contains one
file description entries. A FDT Instance MAY span several ALC or more file description entries. A FDT Instance MAY span several
packets - the number of ALC packets is a function of the file ALC packets - the number of ALC packets is a function of the file
attributes associated with the FDT Instance. The FDT Instance Header attributes associated with the FDT Instance. The FDT Instance Header
is carried in each ALC packet carrying the FDT Instance. The FDT is carried in each ALC packet carrying the FDT Instance. The FDT
Instance Header is identical for all ALC/LCT packets for a particular Instance Header is identical for all ALC/LCT packets for a particular
FDT Instance. FDT Instance.
The overall format of ALC/LCT packets carrying an FDT Instance is The overall format of ALC/LCT packets carrying an FDT Instance is
depicted in the Figure 1 below. All integer fields are carried in depicted in the Figure 1 below. All integer fields are carried in
"big-endian" or "network order" format, that is, most significant "big-endian" or "network order" format, that is, most significant
byte (octet) first. As defined in [RFC5775], all ALC/LCT packets are byte (octet) first. As defined in [RFC5775], all ALC/LCT packets are
sent using UDP. sent using UDP.
skipping to change at page 17, line 51 skipping to change at page 17, line 51
This document specifies FLUTE version 2. Hence in any ALC packet This document specifies FLUTE version 2. Hence in any ALC packet
that carries FDT Instance and that belongs to the file delivery that carries FDT Instance and that belongs to the file delivery
session as specified in this specification MUST set this field to session as specified in this specification MUST set this field to
'2'. '2'.
FDT Instance ID, 20 bits: FDT Instance ID, 20 bits:
For each file delivery session the numbering of FDT Instances starts For each file delivery session the numbering of FDT Instances starts
from '0' and is incremented by one for each subsequent FDT Instance. from '0' and is incremented by one for each subsequent FDT Instance.
After reaching the maximum value (2^20-1), the numbering starts from After reaching the maximum value (2^20-1), the numbering starts from
the smallest FDT Instance value assigned to an expired FDT Instance. the smallest FDT Instance ID value assigned to an expired FDT
When wraparound from a greater FDT Instance ID value to a smaller FDT Instance. When wraparound from a greater FDT Instance ID value to a
Instance ID value occurs, the smaller FDT Instance ID value is smaller FDT Instance ID value occurs, the smaller FDT Instance ID
considered logically higher than the greater FDT Instance ID value. value is considered logically higher than the greater FDT Instance ID
value. Then, the subsequent FDT Instances are assigned the following
smallest FDT Instance ID value available in order to always keep the
FDT Instance ID values logically increasing.
Senders MUST NOT re-use an FDT Instance ID value that is already in Senders MUST NOT re-use an FDT Instance ID value that is already in
use for a non-expired FDT Instance. Sender behavior when all the FDT use for a non-expired FDT Instance. Sender behavior when all the FDT
Instance IDs are used by non expired FEC Instances is outside the Instance IDs are used by non expired FEC Instances is outside the
scope of this specification and left to individual implementations of scope of this specification and left to individual implementations of
FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID FLUTE. Receipt of an FDT Instance that reuses an FDT Instance ID
value that is currently used by a non expired FDT Instance SHOULD be value that is currently used by a non expired FDT Instance MUST be
considered as an error case. Receiver behavior in this case (e.g. considered as an error case. Receiver behavior in this case (e.g.
leave the session or ignore the new FDT Instance) is outside the leave the session or ignore the new FDT Instance) is outside the
scope of this specification and left to individual implementations of scope of this specification and left to individual implementations of
FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound FLUTE. Receivers MUST be ready to handle FDT Instance ID wraparound
and situations where missing FDT Instance IDs result in increments and situations where missing FDT Instance IDs result in increments
larger than one. larger than one.
3.4.2. Syntax of FDT Instance 3.4.2. Syntax of FDT Instance
The FDT Instance contains file description entries that provide the The FDT Instance contains file description entries that provide the
mapping functionality described in 3.2 above. mapping functionality described in 3.2 above.
The FDT Instance is an XML structure that has a single root element The FDT Instance is an Extensible Markup Language (XML) structure
"FDT-Instance". The "FDT-Instance" element MUST contain "Expires" that has a single root element "FDT-Instance". The "FDT-Instance"
attribute, which tells the expiration time of the FDT Instance. In element MUST contain "Expires" attribute, which tells the expiration
addition, the "FDT-Instance" element MAY contain the "Complete" time of the FDT Instance. In addition, the "FDT-Instance" element
attribute (boolean), which, when TRUE, signals that this "FDT MAY contain the "Complete" attribute, a boolean which can be either
Instance" includes the set of "File" entries that exhausts both the set to '1' or 'true' for TRUE, or '0' or 'false' for FALSE. When
set of files delivered so far and also the set of files to be TRUE, the "Complete" attribute signals that this "FDT Instance"
delivered in the session. This implies that no new data will be includes the set of "File" entries that exhausts both the set of
provided in future FDT Instances within this session (i.e., that files delivered so far and also the set of files to be delivered in
either FDT Instances with higher ID numbers will not be used or if the session. This implies that no new data will be provided in
they are used, will only provide identical file parameters to those future FDT Instances within this session (i.e., that either FDT
already given in this and previous FDT Instances). The "Complete" Instances with higher ID numbers will not be used or if they are
attribute is therefore used to provide a complete list of files in an used, will only provide identical file parameters to those already
entire FLUTE session (a "complete FDT"). given in this and previous FDT Instances). The "Complete" attribute
is therefore used to provide a complete list of files in an entire
FLUTE session (a "complete FDT"). Note that when all the FDT
Instances received so far have no "Complete" attribute, the receiver
MUST consider that the session is not complete and that new data MAY
be provided in future FDT Instances. This is equivalent to receiving
FDT Instances having the "Complete" attribute set to FALSE.
The "FDT-Instance" element MAY contain attributes that give common The "FDT-Instance" element MAY contain attributes that give common
parameters for all files of an FDT Instance. These attributes MAY parameters for all files of an FDT Instance. These attributes MAY
also be provided for individual files in the "File" element. Where also be provided for individual files in the "File" element. Where
the same attribute appears in both the "FDT-Instance" and the "File" the same attribute appears in both the "FDT-Instance" and the "File"
elements, the value of the attribute provided in the "File" element elements, the value of the attribute provided in the "File" element
takes precedence. takes precedence.
For each file to be declared in the given FDT Instance there is a For each file to be declared in the given FDT Instance there is a
single file description entry in the FDT Instance. Each entry is single file description entry in the FDT Instance. Each entry is
represented by element "File" which is a child element of the FDT represented by element "File" which is a child element of the FDT
Instance structure. Instance structure.
The attributes of "File" element in the XML structure represent the The attributes of "File" element in the XML structure represent the
attributes given to the file that is delivered in the file delivery attributes given to the file that is delivered in the file delivery
session. The value of the XML attribute name corresponds to MIME session. The value of the XML attribute name corresponds to MIME
field name and the XML attribute value corresponds to the value of field name and the XML attribute value corresponds to the value of
the MIME field body. Each "File" element MUST contain at least two the MIME field body [RFC2045]. Each "File" element MUST contain at
attributes "TOI" and "Content-Location". "TOI" MUST be assigned a least two attributes: "TOI" and "Content-Location". "TOI" MUST be
valid TOI value as described in section 3.3 above. "Content- assigned a valid TOI value as described in section 3.3. "Content-
Location" MUST be assigned a valid URI as defined in [RFC2616] which Location" [RFC2616] MUST be assigned a syntactically valid URI, as
identifies the object to be delivered, for example a URI with the defined in [RFC3986], which identifies the file to be delivered. For
"http" or "file" URI scheme. The semantics for any two "File" example it can be a URI with the "http" or "file" URI scheme. Only
elements declaring the same "Content-Location" but differing "TOI" is one "Content-Location" attribute is allowed for each file. The
that the element appearing in the FDT Instance with the greater FDT "Content-Location" field MUST be considered as a string that
Instance ID is considered to declare newer instance (e.g., version) identifies a file (i.e., two different strings are two different
of the same "File". identifiers). Any use of the "Content-Location" field to anything
else than to identify the object is out of scope of this
specification. The semantics for any two "File" elements declaring
the same "Content-Location" but differing "TOI" is that the element
appearing in the FDT Instance with the greater FDT Instance ID is
considered to declare newer instance (e.g., version) of the same
"File".
In addition to mandatory attributes, the "FDT-Instance" element and In addition to mandatory attributes, the "FDT-Instance" element and
the "File" element MAY contain other attributes of which the the "File" element MAY contain other attributes of which the
following are specifically pointed out. following are specifically pointed out.
* The attribute "Content-Type" SHOULD be included and, when present, * The attribute "Content-Type" SHOULD be included and, when present,
MUST be used for the purpose defined in [RFC2616]. MUST be used for the purpose defined in [RFC2616].
* Where the length is described, the attribute "Content-Length" MUST * Where the length is described, the attribute "Content-Length" MUST
be used for the purpose as defined in [RFC2616]. The transfer be used for the purpose as defined in [RFC2616]. The transfer
skipping to change at page 22, line 19 skipping to change at page 22, line 34
type="xs:base64Binary" type="xs:base64Binary"
use="optional"/> use="optional"/>
<xs:anyAttribute processContents="skip"/> <xs:anyAttribute processContents="skip"/>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
END END
Figure 3 Figure 3
Any valid FDT Instance MUST use the above XML Schema. This way FDT Any valid FDT Instance MUST use the above XML Schema. This way FDT
provides extensibility to support private attributes within the file provides extensibility to support private elements and private
description entries. Those could be, for example, the attributes attributes within the file description entries. Those could be, for
related to the delivery of the file (timing, packet transmission example, the attributes related to the delivery of the file (timing,
rate, etc.). Unsupported private attributes SHOULD be silently packet transmission rate, etc.). Unsupported private elements and
ignored by a FLUTE receiver. attributes SHOULD be silently ignored by a FLUTE receiver.
In case the basic FDT XML Schema is extended in terms of new In case the basic FDT XML Schema is extended in terms of new
descriptors (attributes or elements), for descriptors applying to a descriptors (attributes or elements), for descriptors applying to a
single file, those MUST be placed within the element "File". For single file, those MUST be placed within the element "File". For
descriptors applying to all files described by the current FDT descriptors applying to all files described by the current FDT
Instance, those MUST be placed within the element "FDT-Instance". It Instance, those MUST be placed within the element "FDT-Instance". It
is RECOMMENDED that the new attributes applied in the FDT are in the is RECOMMENDED that the new attributes applied in the FDT are in the
format of MIME fields and are either defined in the HTTP/1.1 format of message header fields and are either defined in the
specification [RFC2616], or another well-known specification, or in HTTP/1.1 specification [RFC2616], or another well-known
IANA registry [IANAmediatypes]. specification, or in an IANA registry [IANAheaderfields]. However
this specification doesn't prohibit the use of other formats to allow
private attributes to be used when interoperability is not a concern.
3.4.3. Content Encoding of FDT Instance 3.4.3. Content Encoding of FDT Instance
The FDT Instance itself MAY be content encoded, for example The FDT Instance itself MAY be content encoded, for example
compressed. This specification defines FDT Instance Content Encoding compressed. This specification defines FDT Instance Content Encoding
Header (EXT_CENC). EXT_CENC is a new fixed length LCT header Header (EXT_CENC). EXT_CENC is a new fixed length LCT header
extension [RFC5651]. The Header Extension Type (HET) for the extension [RFC5651]. The Header Extension Type (HET) for the
extension is 193. If the FDT Instance is content encoded, the extension is 193. If the FDT Instance is content encoded, the
EXT_CENC MUST be used to signal the content encoding type. In that EXT_CENC MUST be used to signal the content encoding type. In that
case, EXT_CENC header extension MUST be used in all ALC packets case, EXT_CENC header extension MUST be used in all ALC packets
skipping to change at page 23, line 38 skipping to change at page 24, line 6
with TOIs) in the file delivery session. All these objects, with TOIs) in the file delivery session. All these objects,
including the FDT Instances, MAY be multiplexed in any order and in including the FDT Instances, MAY be multiplexed in any order and in
parallel with each other within a session, i.e., packets for one file parallel with each other within a session, i.e., packets for one file
may be interleaved with packets for other files or other FDT may be interleaved with packets for other files or other FDT
Instances within a session. Instances within a session.
Multiple FDT Instances MAY be delivered in a single session using TOI Multiple FDT Instances MAY be delivered in a single session using TOI
= 0. In this case, it is RECOMMENDED that the sending of a previous = 0. In this case, it is RECOMMENDED that the sending of a previous
FDT Instance SHOULD end before the sending of the next FDT Instance FDT Instance SHOULD end before the sending of the next FDT Instance
starts. However, due to unexpected network conditions, packets for starts. However, due to unexpected network conditions, packets for
the FDT Instances MAY be interleaved. A receiver can determine which the FDT Instances might be interleaved. A receiver can determine
FDT Instance a packet contains information about since the FDT which FDT Instance a packet contains information about since the FDT
Instances are uniquely identified by their FDT Instance ID carried in Instances are uniquely identified by their FDT Instance ID carried in
the EXT_FDT headers. the EXT_FDT headers.
4. Channels, congestion control and timing 4. Channels, congestion control and timing
ALC/LCT has a concept of channels and congestion control. There are ALC/LCT has a concept of channels and congestion control. There are
four scenarios in which FLUTE is envisioned to be applied. four scenarios in which FLUTE is envisioned to be applied.
(a) Use of a single channel and a single-rate congestion control (a) Use of a single channel and a single-rate congestion control
protocol. protocol.
skipping to change at page 29, line 43 skipping to change at page 30, line 8
integrity service: integrity service:
* at the file level, the file MAY be digitally signed, for instance * at the file level, the file MAY be digitally signed, for instance
by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a
receiver to check the file integrity, once this latter has been receiver to check the file integrity, once this latter has been
fully decoded. Even if digital signatures are computationally fully decoded. Even if digital signatures are computationally
expensive, this calculation occurs only once per file, which is expensive, this calculation occurs only once per file, which is
usually acceptable; usually acceptable;
* at the packet level, each packet can be digitally signed * at the packet level, each packet can be digitally signed
[RMT-SIMPLE-AUTH]. A major limitation is the high computational [RFC6584]. A major limitation is the high computational and
and transmission overheads that this solution requires. To avoid transmission overheads that this solution requires. To avoid this
this problem, the signature may span a set of symbols (instead of problem, the signature may span a set of symbols (instead of a
a single one) in order to amortize the signature calculation, but single one) in order to amortize the signature calculation, but if
if a single symbol is missing, the integrity of the whole set a single symbol is missing, the integrity of the whole set cannot
cannot be checked; be checked;
* at the packet level, a Group Message Authentication Code (MAC) * at the packet level, a Group Message Authentication Code (MAC)
[RFC2104][RMT-SIMPLE-AUTH] scheme can be used, for instance by [RFC2104][RFC6584] scheme can be used, for instance by using HMAC-
using HMAC-SHA-256 with a secret key shared by all the group SHA-256 with a secret key shared by all the group members, senders
members, senders and receivers. This technique creates a and receivers. This technique creates a cryptographically secured
cryptographically secured digest of a packet that is sent along digest of a packet that is sent along with the packet. The Group
with the packet. The Group MAC scheme does not create prohibitive MAC scheme does not create prohibitive processing load nor
processing load nor transmission overhead, but it has a major transmission overhead, but it has a major limitation: it only
limitation: it only provides a group authentication/integrity provides a group authentication/integrity service since all group
service since all group members share the same secret group key, members share the same secret group key, which means that each
which means that each member can send a forged packet. It is member can send a forged packet. It is therefore restricted to
therefore restricted to situations where group members are fully situations where group members are fully trusted (or in
trusted (or in association with another technique as a pre-check); association with another technique as a pre-check);
* at the packet level, TESLA [RFC4082][RFC5776] is an attractive * at the packet level, TESLA [RFC4082][RFC5776] is an attractive
solution that is robust to losses, provides a true authentication/ solution that is robust to losses, provides a true authentication/
integrity service, and does not create any prohibitive processing integrity service, and does not create any prohibitive processing
load or transmission overhead. Yet checking a packet requires a load or transmission overhead. Yet checking a packet requires a
small delay (a second or more) after its reception; small delay (a second or more) after its reception;
* at the packet level, IPsec/ESP [RFC4303] can be used to check the * at the packet level, IPsec/ESP [RFC4303] can be used to check the
integrity and authenticate the sender of all the packets being integrity and authenticate the sender of all the packets being
exchanged in a session (see Section 7.5). exchanged in a session (see Section 7.5).
skipping to change at page 31, line 50 skipping to change at page 32, line 12
Corrupting the FDT Instances is also a way to make the reception Corrupting the FDT Instances is also a way to make the reception
process more costly than it should be. This can be achieved by process more costly than it should be. This can be achieved by
changing the FEC Object Transmission Information when the FEC Object changing the FEC Object Transmission Information when the FEC Object
Transmission Information is included in the FDT Instance. For Transmission Information is included in the FDT Instance. For
example, an attacker may corrupt the FDT Instance in such a way that example, an attacker may corrupt the FDT Instance in such a way that
Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
Encoding ID 2. This may significantly increase the processing load Encoding ID 2. This may significantly increase the processing load
while compromising FEC decoding. while compromising FEC decoding.
More generally, because FDT Instance data is structured using the XML
language by means of an XML media type, many of the security
considerations described in [RFC3023] and [RFC3470] also apply to
such data.
It is therefore RECOMMENDED that measures be taken to guarantee the It is therefore RECOMMENDED that measures be taken to guarantee the
integrity and to check the sender's identity of the FDT Instances. integrity and to check the sender's identity of the FDT Instances.
To that purpose, one of the counter-measures mentioned above To that purpose, one of the counter-measures mentioned above
(Section 7.2.2) SHOULD be used. These measures will either be (Section 7.2.2) SHOULD be used. These measures will either be
applied on a packet level, or globally over the whole FDT Instance applied on a packet level, or globally over the whole FDT Instance
object. Additionally, XML digital signatures [RFC3275] are a way to object. Additionally, XML digital signatures [RFC3275] are a way to
protect the FDT Instance by digitally signing it. When there is no protect the FDT Instance by digitally signing it. When there is no
packet level integrity verification scheme, it is RECOMMENDED to rely packet level integrity verification scheme, it is RECOMMENDED to rely
on XML digital signatures of the FDT Instances. on XML digital signatures of the FDT Instances.
skipping to change at page 33, line 13 skipping to change at page 33, line 29
packet has not yet been authenticated. Therefore TESLA will not packet has not yet been authenticated. Therefore TESLA will not
prevent DoS attacks where an attacker makes the receiver believe that prevent DoS attacks where an attacker makes the receiver believe that
a congestion occurred. This is an issue for the receiver, but this a congestion occurred. This is an issue for the receiver, but this
will not compromise the network. Other authentication methods that will not compromise the network. Other authentication methods that
do not feature this delayed authentication could be preferred, or a do not feature this delayed authentication could be preferred, or a
group MAC scheme could be used in parallel to TESLA to prevent group MAC scheme could be used in parallel to TESLA to prevent
attacks launched from outside of the group. attacks launched from outside of the group.
7.4. Other Security Considerations 7.4. Other Security Considerations
Lastly, we note that the security considerations that apply to, and The security considerations that apply to, and are described in, ALC
are described in, ALC [RFC5775], LCT [RFC5651] and FEC [RFC5052] also [RFC5775], LCT [RFC5651] and FEC [RFC5052] also apply to FLUTE as
apply to FLUTE as FLUTE builds on those specifications. In addition, FLUTE builds on those specifications. In addition, any security
any security considerations that apply to any congestion control considerations that apply to any congestion control building block
building block used in conjunction with FLUTE also apply to FLUTE. used in conjunction with FLUTE also apply to FLUTE.
Even if FLUTE defines a purely unidirectional delivery service,
without any feedback information that would be sent to the sender,
security considerations MAY require bidirectional communications.
For instance if an automated key management scheme is used, a
bidirectional point-to-point channel is often needed to establish a
shared secret between each receiver and the sender. Each shared
secret can then be used to distribute additional keys to the
associated receiver (e.g., traffic encryption keys).
As an example [MBMSsecurity] details a complete security framework
for the 3GPP Multimedia Broadcast/Multicast Service (MBMS) that
relies on FLUTE/ALC for Download Sessions. It relies on
bidirectional point-to-point communications for User Equipment
authentication and for key distribution, using the MIKEY protocol
[RFC3830]. Because this security framework is specific to this use
case, it cannot be reused as such for generic security
recommendations in this specification. Instead the following section
introduces Minimum Security Recommendations.
7.5. Minimum Security Recommendations 7.5. Minimum Security Recommendations
We now introduce a mandatory to implement but not necessarily to use We now introduce a mandatory to implement but not necessarily to use
security configuration, in the sense of [RFC3365]. Since FLUTE security configuration, in the sense of [RFC3365]. Since FLUTE
relies on ALC/LCT, it inherits the "baseline secure ALC operation" of relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
[RFC5775]. More precisely, security is achieved by means of IPsec/ [RFC5775]. More precisely, security is achieved by means of IPsec/
ESP in transport mode. [RFC4303] explains that ESP can be used to ESP in transport mode. [RFC4303] explains that ESP can be used to
potentially provide confidentiality, data origin authentication, potentially provide confidentiality, data origin authentication,
content integrity, anti-replay and (limited) traffic flow content integrity, anti-replay and (limited) traffic flow
skipping to change at page 33, line 43 skipping to change at page 34, line 30
of long lived sessions. of long lived sessions.
Therefore, the RECOMMENDED solution for FLUTE provides per-packet Therefore, the RECOMMENDED solution for FLUTE provides per-packet
security, with data origin authentication, integrity verification and security, with data origin authentication, integrity verification and
anti-replay. This is sufficient to prevent most of the in-band anti-replay. This is sufficient to prevent most of the in-band
attacks listed above. If confidentiality is required, a per-packet attacks listed above. If confidentiality is required, a per-packet
encryption SHOULD also be used. encryption SHOULD also be used.
8. IANA Considerations 8. IANA Considerations
This specification contains five separate items for IANA This specification contains six separate items for IANA
Considerations: Considerations:
1. Registration Request for XML Schema of FDT Instance. 1. Registration of the FDT Instance XML Namespace.
2. Media-Type Registration Request for application/fdt+xml. 2. Registration of the FDT Instance XML Schema.
3. Content Encoding Algorithm Registration Request. 3. Registration of the application/fdt+xml Media-Type.
4. Registration of the EXT_FDT LCT Header Extension Type 4. Registration of the Content Encoding Algorithm.
5. Registration of the EXT_CENC LCT Header Extension Type 5. Registration of the EXT_FDT LCT Header Extension Type
8.1. Registration Request for XML Schema of FDT Instance 6. Registration of the EXT_CENC LCT Header Extension Type
8.1. Registration of the FDT Instance XML Namespace
Document [RFC3688] defines an IANA maintained registry of XML Document [RFC3688] defines an IANA maintained registry of XML
documents used within IETF protocols. The following is the documents used within IETF protocols. The following is the
registration request for the FDT XML schema. registration request for the FDT Instance XML Namespace.
URI: urn:ietf:params:xml:ns:fdt
Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
XML: N/A
8.2. Registration of the FDT Instance XML Schema
Document [RFC3688] defines an IANA maintained registry of XML
documents used within IETF protocols. The following is the
registration request for the FDT Instance XML Schema.
URI: urn:ietf:params:xml:schema:fdt
Registrant Contact: Toni Paila (toni.paila (at) nokia.com) Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
XML: The XML Schema specified in Section 3.4.2 XML: The XML Schema specified in Section 3.4.2
8.2. Media-Type Registration Request for application/fdt+xml 8.3. Registration of the application/fdt+xml Media-Type
This section provides the registration request, as per [RFC4288], IANA is asked to register a new namespace in the IETF XML Registry
[RFC4289] and [RFC3023], to be submitted to IANA following IESG (http://www.iana.org/assignments/xml-registry/ns.html) [RFC3688],
approval. using the following registration template:
Type name: application Type name: application
Subtype name: fdt+xml Subtype name: fdt+xml
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: charset="utf-8"
Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
characters [RFC3629] and must be well-formed XML.
Additional content and transfer encodings may be used with fdt+xml Encoding considerations: binary (the FLUTE file delivery protocol
files, with the appropriate encoding for any specific file being does not impose any restriction on the objects it carries and in
entirely dependent upon the deployed application. particular on the FDT Instance itself)
Restrictions on usage: Only for usage with FDT Instances which are Restrictions on usage: none
valid according to the XML schema of section 3.4.2.
Security considerations: fdt+xml data is passive, and does not Security considerations: fdt+xml data is passive, and does not
generally represent a unique or new security threat. However, there generally represent a unique or new security threat. However, there
is some risk in sharing any kind of data, in that unintentional is some risk in sharing any kind of data, in that unintentional
information may be exposed, and that risk applies to fdt+xml data as information may be exposed, and that risk applies to fdt+xml data as
well. well.
Interoperability considerations: None Interoperability considerations: None
Published specification: The present document including section Published specification: The present document including section
3.4.2. The specified FDT Instance functions as an actual media 3.4.2. The specified FDT Instance functions as an actual media
format of use to the general Internet community and thus media type format of use to the general Internet community and thus media type
registration under the Standards Tree is appropriate to maximize registration under the Standards Tree is appropriate to maximize
interoperability. interoperability.
Applications which use this media type: Not restricted to any Applications which use this media type: file and object delivery
particular application applications and protocols (e.g., FLUTE).
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): An FDT Instance may use the extension ".fdt" File extension(s): ".fdt" (e.g., if there is a need to store an
but this is not required. FDT Instance as a file);
Macintosh File Type Code(s): none Macintosh File Type Code(s): none
Person and email address to contact for further information: Toni Person and email address to contact for further information: Toni
Paila (toni.paila (at) nokia.com) Paila (toni.paila@nokia.com)
Intended usage: Common Intended usage: Common
Author/Change controller: IETF Author/Change controller: IETF
8.3. Content Encoding Algorithm Registration Request 8.4. Registration of the Content Encoding Algorithm
Values of Content Encoding Algorithms are subject to IANA Values of Content Encoding Algorithms are subject to IANA
registration. The value of Content Encoding Algorithm is a numeric registration. The value of Content Encoding Algorithm is a numeric
non-negative index. In this document, the range of values for non-negative index. In this document, the range of values for
Content Encoding Algorithms is 0 to 255. This specification already Content Encoding Algorithms is 0 to 255. This specification already
assigns the values 0, 1, 2 and 3 as described in section 3.4.3. assigns the values 0, 1, 2 and 3 as described in section 3.4.3.
8.3.1. Explicit IANA Assignment Guidelines 8.4.1. Explicit IANA Assignment Guidelines
This document defines a name-space called "Content Encoding This document defines a name-space called "Content Encoding
Algorithms". Algorithms".
IANA has established and manages the new registry for the "FLUTE IANA has established and manages the new registry for the "FLUTE
Content Encoding Algorithm" name-space. The values that can be Content Encoding Algorithm" name-space. The values that can be
assigned within this name-space are numeric indexes in the range [0, assigned within this name-space are numeric indexes in the range [0,
255], boundaries included. Assignment requests are granted on a 255], boundaries included. Assignment requests are granted on a
"Specification Required" basis as defined in [RFC5226]. Note that "Specification Required" basis as defined in [RFC5226]. Note that
the values 0, 1, 2 and 3 of this registry are already assigned by the values 0, 1, 2 and 3 of this registry are already assigned by
this document as described in section 3.4.3. this document as described in section 3.4.3.
8.4. Registration of EXT_FDT LCT Header Extension Type 8.5. Registration of the EXT_FDT LCT Header Extension Type
This document registers value 192 for the EXT_FDT LCT Header This document registers value 192 for the EXT_FDT LCT Header
Extension defined in Section 3.4.1. Extension defined in Section 3.4.1.
8.5. Registration of EXT_CENC LCT Header Extension Type 8.6. Registration of the EXT_CENC LCT Header Extension Type
This document registers value 193 for the EXT_CENC LCT Header This document registers value 193 for the EXT_CENC LCT Header
Extension defined in Section 3.4.3. Extension defined in Section 3.4.3.
9. Acknowledgments 9. Acknowledgments
The following persons have contributed to this specification: Brian The following persons have contributed to this specification: Brian
Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington, Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington,
Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica and Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis
Francis Dupont. The authors would like to thank all the contributors Dupont, Peter Saint-Andre and Don Gillies. The authors would like to
for their valuable work in reviewing and providing feedback regarding thank all the contributors for their valuable work in reviewing and
this specification. providing feedback regarding this specification.
10. Contributors 10. Contributors
Jani Peltotalo Jani Peltotalo
Tampere University of Technology Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1) P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101 Tampere FIN-33101
Finland Finland
Email: jani.peltotalo (at) tut.fi Email: jani.peltotalo (at) tut.fi
skipping to change at page 38, line 19 skipping to change at page 39, line 14
Added clarification on XML-DSIG in the end of Section 3. Added clarification on XML-DSIG in the end of Section 3.
Revised the use of word "complete" in the Section 3.2. Revised the use of word "complete" in the Section 3.2.
Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance". Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance".
Clarified the FDT Instance ID wrap-around in the end of Clarified the FDT Instance ID wrap-around in the end of
Section 3.4.1. Section 3.4.1.
Clarification for "Complete FDT" in the Section 3.4.2. Clarifications for "Complete FDT" in the Section 3.4.2.
Added semantics for the case two TOIs refer to same Content-Location. Added semantics for the case two TOIs refer to same Content-Location.
Now it is in line how 3GPP and DVB interpret the case. Now it is in line how 3GPP and DVB interpret the case.
In the Section 3.4.2 XML Schema of FDT instance is modified to In the Section 3.4.2 XML Schema of FDT instance is modified to
various advices. For example, extension by element was missing but various advices. For example, extension by element was missing but
is now supported. Also namespace definition is changed to URN is now supported. Also namespace definition is changed to URN
format. format.
Clarified FDT-schema extensibility in the end of Section 3.4.2. Clarified FDT-schema extensibility in the end of Section 3.4.2.
skipping to change at page 40, line 44 skipping to change at page 41, line 38
October 2004. October 2004.
[XML-Schema-Part-2] [XML-Schema-Part-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, Second Edition", W3C Recommendation,
http://www.w3.org/TR/xmlschema-2/, October 2004. http://www.w3.org/TR/xmlschema-2/, October 2004.
[RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, Note: this Control (WEBRC) Building Block", RFC 3738, April 2004.
reference is to a target document of a lower maturity Note: the RFC3738 reference is to a target document of a
level and some caution should be used since it may be less lower maturity level and some caution should be used since
stable than the present document. , April 2004. it may be less stable than the present document.
[RFC4303] Kent, S., "Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
12.2. Informative references 12.2. Informative references
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", "FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004. RFC 3926, October 2004.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998. Application Protocols", RFC 2357, June 1998.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML)
within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, May 1996. RFC 1952, May 1996.
[IANAmediatypes] [IANAheaderfields]
IANA, "IANA Media Types registry", IANA, "Permanent and Provisional Message Header Field
URL: http://www.iana.org/assignments/media-types/. Names registries", URL: http://www.iana.org/assignments/
message-headers/perm-headers.html, URL: http://
www.iana.org/assignments/message-headers/
prov-headers.html.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", [RFC1112] Deering, S., "Host Extensions for IP Multicasting",
RFC 1112, STD 5, August 1989. RFC 1112, STD 5, August 1989.
skipping to change at page 42, line 17 skipping to change at page 43, line 20
RFC 3365, August 2002. RFC 3365, August 2002.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
RFC 4289, December 2005.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: session initiation protocol", RFC 3261, Schooler, "SIP: session initiation protocol", RFC 3261,
June 2002. June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004. January 2004.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
skipping to change at page 42, line 51 skipping to change at page 43, line 47
"Timed Efficient Stream Loss-Tolerant Authentication "Timed Efficient Stream Loss-Tolerant Authentication
(TESLA): Multicast Source Authentication Transform (TESLA): Multicast Source Authentication Transform
Introduction", RFC 4082, June 2005. Introduction", RFC 4082, June 2005.
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed
Efficient Stream Loss-Tolerant Authentication (TESLA) in Efficient Stream Loss-Tolerant Authentication (TESLA) in
the Asynchronous Layered Coding (ALC) and NACK-Oriented the Asynchronous Layered Coding (ALC) and NACK-Oriented
Reliable Multicast (NORM) Protocols", RFC 5776, Reliable Multicast (NORM) Protocols", RFC 5776,
April 2010. April 2010.
[RMT-SIMPLE-AUTH] [RFC6584] Roca, V., "Simple Authentication Schemes for the
Roca, V., "Simple Authentication Schemes for the ALC and Asynchronous Layered Coding (ALC) and NACK-Oriented
NORM Protocols", Reliable Multicast (NORM) Protocols", RFC 6584,
draft-ietf-rmt-simple-auth-for-alc-norm-06.txt (work in April 2012.
progress), December 2011.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[MBMSsecurity]
"3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G
Security; Security of Multimedia Broadcast/Multicast
Service (MBMS) (Release 10)", URL: http://www.3gpp.org/
ftp/Specs/archive/33_series/33.246/, December 2010.
Appendix A. Receiver operation (informative) Appendix A. Receiver operation (informative)
This section gives an example how the receiver of the file delivery This section gives an example how the receiver of the file delivery
session may operate. Instead of a detailed state-by-state session may operate. Instead of a detailed state-by-state
specification the following should be interpreted as a rough sequence specification the following should be interpreted as a rough sequence
of an envisioned file delivery receiver. of an envisioned file delivery receiver.
1. The receiver obtains the description of the file delivery session 1. The receiver obtains the description of the file delivery session
identified by the pair: (source IP address, Transport Session identified by the pair: (source IP address, Transport Session
 End of changes. 61 change blocks. 
167 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/