Network Working Group T. Paila
Request for Comments: 3926 Nokia
Category: Experimental M. Luby
Digital Fountain
R. Lehtonen
TeliaSonera
V. Roca
INRIA Rhone-Alpes
R. Walsh
Nokia
October 2004
Network Working Group T. Paila
Request for Comments: 3926 Nokia
Category: Experimental M. Luby
Digital Fountain
R. Lehtonen
TeliaSonera
V. Roca
INRIA Rhone-Alpes
R. Walsh
Nokia
October 2004
FLUTE - File Delivery over Unidirectional Transport
长笛-通过单向传输传递文件
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.
本文档定义了FLUTE，这是一种通过Internet单向传递文件的协议，特别适用于多播网络。该规范建立在异步分层编码的基础上，异步分层编码是为大规模可伸缩多播分发而设计的基本协议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.5. Multiplexing of files within a file delivery session . . 17
4. Channels, congestion control and timing . . . . . . . . . . . 18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
Informative References . . . . . . . . . . . . . . . . . . . . 30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.5. Multiplexing of files within a file delivery session . . 17
4. Channels, congestion control and timing . . . . . . . . . . . 18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
Informative References . . . . . . . . . . . . . . . . . . . . 30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
This document defines FLUTE version 1, a protocol for unidirectional delivery of files over the Internet. The specification builds on Asynchronous Layered Coding (ALC), version 1 [2], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications mere transport of objects is not enough, however. The end systems need to know what the objects actually represent. This document specifies a technique called FLUTE - a mechanism for signaling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Consequently, throughout this document the term 'file' relates to an 'object' as discussed in ALC. Although this specification frequently makes use of multicast addressing as an example, the techniques are similarly applicable for use with unicast addressing.
本文档定义了FLUTE版本1，这是一种通过Internet单向传递文件的协议。该规范建立在异步分层编码（ALC）版本1[2]的基础上，该版本是为大规模可伸缩多播分发而设计的基本协议。ALC定义了任意二进制对象的传输。然而，对于文件传递应用程序，仅仅传输对象是不够的。终端系统需要知道对象实际代表什么。本文档指定了一种称为“长笛”的技术，这是一种将文件属性发送信号并映射到ALC概念的机制，允许接收者为接收到的对象分配这些参数。因此，在本文件中，“文件”一词与ALC中讨论的“对象”相关。尽管本规范经常以多播寻址为例，但这些技术同样适用于单播寻址。
This document defines a specific transport application of ALC, adding the following specifications:
本文件定义了ALC的特定运输应用，增加了以下规范：
- Definition of a file delivery session built on top of ALC, including transport details and timing constraints.
- 在ALC之上构建的文件传递会话的定义，包括传输详细信息和时间限制。
- In-band signalling of the transport parameters of the ALC session.
- ALC会话传输参数的带内信令。
- In-band signalling of the properties of delivered files.
- 传送文件属性的带内信令。
- Details associated with the multiplexing of multiple files within a session.
- 与会话中多个文件的多路复用相关的详细信息。
This specification is structured as follows. Section 3 begins by defining the concept of the file delivery session. Following that it introduces the File Delivery Table that forms the core part of this specification. Further, it discusses multiplexing issues of transport objects within a file delivery session. Section 4 describes the use of congestion control and channels with FLUTE. Section 5 defines how the Forward Error Correction (FEC) Object Transmission Information is to be delivered within a file delivery session. Section 6 defines the required parameters for describing file delivery sessions in a general case. Section 7 outlines security considerations regarding file delivery with FLUTE. Last, there are two informative appendices. The first appendix describes an envisioned receiver operation for the receiver of the file delivery session. The second appendix gives an example of File Delivery Table.
本规范的结构如下所示。第3节首先定义文件交付会话的概念。随后介绍了构成本规范核心部分的文件传递表。此外，本文还讨论了文件传递会话中传输对象的多路复用问题。第4节描述了拥塞控制的使用和具有长笛的信道。第5节定义了如何在文件传递会话中传递前向纠错（FEC）对象传输信息。第6节定义了在一般情况下描述文件交付会话所需的参数。第7节概述了有关使用FLUTE交付文件的安全注意事项。最后，有两个资料性附录。第一个附录描述了文件传递会话的接收者的预期接收者操作。第二个附录给出了文件交付表的示例。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357. As per RFC2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC2357完全指定可靠多播传输协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
在等待此类方案可用或现有方案被证明足够时，可靠多播传输工作组（RMT）在“实验性”类别中发布此评论请求。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT的目的是，一旦满足上述条件，立即将本规范作为IETF建议的标准重新提交。
FLUTE is applicable to the delivery of large and small files to many hosts, using delivery sessions of several seconds or more. For instance, FLUTE could be used for the delivery of large software updates to many hosts simultaneously. It could also be used for continuous, but segmented, data such as time-lined text for subtitling - potentially leveraging its layering inheritance from ALC and LCT to scale the richness of the session to the congestion status
FLUTE适用于使用几秒钟或更长时间的传递会话向许多主机传递大小文件。例如，FLUTE可用于同时向多台主机交付大型软件更新。它还可以用于连续但分段的数据，例如用于字幕的时间线文本——潜在地利用其来自ALC和LCT的分层继承，将会话的丰富性扩展到拥塞状态
of the network. It is also suitable for the basic transport of metadata, for example SDP [12] files which enable user applications to access multimedia sessions.
网络的一部分。它还适用于元数据的基本传输，例如SDP[12]文件，它允许用户应用程序访问多媒体会话。
Massive scalability is a primary design goal for FLUTE. IP multicast is inherently massively scalable, but the best effort service that it provides does not provide session management functionality, congestion control or reliability. FLUTE provides all of this using ALC and IP multicast without sacrificing any of the inherent scalability of IP multicast.
大规模的可扩展性是长笛的主要设计目标。IP多播本质上是大规模可扩展的，但它提供的尽力而为服务不提供会话管理功能、拥塞控制或可靠性。FLUTE使用ALC和IP多播提供了所有这些功能，而不会牺牲IP多播固有的可伸缩性。
All of the environmental requirements and considerations that apply to the ALC building block [2] and to any additional building blocks that FLUTE uses also apply to FLUTE.
适用于ALC构造块[2]和FLUTE使用的任何其他构造块的所有环境要求和注意事项也适用于FLUTE。
FLUTE can be used with both multicast and unicast delivery, but it's primary application is for unidirectional multicast file delivery. FLUTE requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. FLUTE inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks.
长笛可以用于多播和单播传输，但它的主要应用是单向多播文件传输。FLUTE需要发送方和接收方之间的连接，但不需要从接收方到发送方的连接。长笛天生适用于所有类型的网络，包括局域网、广域网、内部网、互联网、非对称网络、无线网络和卫星网络。
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-Source Multicast (ASM) [13] and the Source-Specific Multicast (SSM) [15].
FLUTE与IPv4或IPv6兼容，因为数据包的任何部分都不是特定于IP版本的。FLUTE同时适用于两种多播模型：任意源多播（ASM）[13]和源特定多播（SSM）[15]。
FLUTE is applicable for both Internet use, with a suitable congestion control building block, and provisioned/controlled systems, such as delivery over wireless broadcast radio systems.
FLUTE既适用于具有适当拥塞控制构建块的互联网使用，也适用于供应/控制系统，例如通过无线广播系统交付。
Some networks are not amenable to some congestion control protocols that could be used with FLUTE. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
有些网络不适用于某些可与FLUTE一起使用的拥塞控制协议。具体地，对于卫星或无线网络，可能没有用于接收器有效降低其接收速率的机制，因为可能存在分配给会话的固定传输速率。
FLUTE provides reliability using the FEC building block. This will reduce the error rate as seen by applications. However, FLUTE does not provide a method for senders to verify the reception success of receivers, and the specification of such a method is outside the scope of this document.
FLUTE使用FEC构建块提供可靠性。这将降低应用程序所看到的错误率。然而，FLUTE并未为发送方提供验证接收方接收成功的方法，此类方法的规范不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The terms "object" and "transport object" are consistent with the definitions in ALC [2] and LCT [3]. The terms "file" and "source object" are pseudonyms for "object".
术语“对象”和“传输对象”与ALC[2]和LCT[3]中的定义一致。术语“文件”和“源对象”是“对象”的笔名。
Asynchronous Layered Coding [2] is a protocol designed for delivery of arbitrary binary objects. It is especially suitable for massively scalable, unidirectional, multicast distribution. ALC provides the basic transport for FLUTE, and thus FLUTE inherits the requirements of ALC.
异步分层编码[2]是为传送任意二进制对象而设计的协议。它特别适用于大规模可扩展、单向的多播分发。ALC为Sleet提供了基本的传输，因此Sleet继承了ALC的要求。
This specification is designed for the delivery of files. The core of this specification is to define how the properties of the files are carried in-band together with the delivered files.
本规范旨在交付文件。本规范的核心是定义文件的属性如何与交付的文件一起带在一起。
As an example, let us consider a 5200 byte file referred to by "http://www.example.com/docs/file.txt". Using the example, the following properties describe the properties that need to be conveyed by the file delivery protocol.
举个例子，让我们考虑一个5200字节的文件。http://www.example.com/docs/file.txt". 使用该示例，以下属性描述了需要通过文件传递协议传递的属性。
* Identifier of the file, expressed as a URI. This identifier may be globally unique. The identifier may also provide a location for the file. In the above example: "http://www.example.com/docs/ file.txt".
* 文件的标识符，表示为URI。此标识符可能是全局唯一的。标识符还可以提供文件的位置。在上面的示例中：http://www.example.com/docs/ txt文件”。
* File name (usually, this can be concluded from the URI). In the above example: "file.txt".
* 文件名（通常可以从URI得出结论）。在上面的示例中：“file.txt”。
* File type, expressed as MIME media type (usually, this can also be concluded from the extension of the file name). In the above example: "text/plain". If an explicit value for the MIME type is provided separately from the file extension and does not match the MIME type of the file extension then the explicitly provided value MUST be used as the MIME type.
* 文件类型，表示为MIME媒体类型（通常也可以从文件名的扩展名得出结论）。在上面的示例中：“text/plain”。如果MIME类型的显式值与文件扩展名分开提供，并且与文件扩展名的MIME类型不匹配，则必须将显式提供的值用作MIME类型。
* File size, expressed in bytes. In the above example: "5200". If the file is content encoded then this is the file size before content encoding.
* 文件大小，以字节表示。在上面的例子中：“5200”。如果文件是内容编码的，则这是内容编码之前的文件大小。
* Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [10]. In this case the size of the transport object carrying the file would probably differ from the file size. The transport object size is delivered to receivers as part of the FLUTE protocol.
* 传输中文件的内容编码。在上面的示例中，可以使用ZLIB[10]对文件进行编码。在这种情况下，承载文件的传输对象的大小可能与文件大小不同。传输对象大小作为长笛协议的一部分传递给接收器。
* Security properties of the file such as digital signatures, message digests, etc. For example, one could use S/MIME [18] as the content encoding type for files with this authentication wrapper, and one could use XML-DSIG [19] to digitally sign an FDT Instance.
* 文件的安全属性，如数字签名、消息摘要等。例如，可以使用S/MIME[18]作为具有此身份验证包装器的文件的内容编码类型，也可以使用XML-DSIG[19]对FDT实例进行数字签名。
ALC is a protocol instantiation of Layered Coding Transport building block (LCT) [3]. Thus ALC inherits the session concept of LCT. In this document we will use the concept ALC/LCT session to collectively denote the interchangeable terms ALC session and LCT session.
ALC是分层编码传输构造块（LCT）的协议实例[3]。因此，ALC继承了LCT的会话概念。在本文件中，我们将使用ALC/LCT会话概念来共同表示ALC会话和LCT会话这两个可互换术语。
An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender sending packets with ALC/LCT headers for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
ALC/LCT会话由一组逻辑分组的ALC/LCT通道组成，这些通道与单个发送方关联，该发送方为一个或多个对象发送带有ALC/LCT头的数据包。ALC/LCT信道由发送方和发送方与信道关联的地址的组合定义。接收机加入信道以开始接收发送方发送到信道的数据包，接收机离开信道以停止从信道接收数据包。
One of the fields carried in the ALC/LCT header is the Transport Session Identifier (TSI). The TSI is scoped by the source IP address, and the (source IP address, TSI) pair uniquely identifies a session, i.e., the receiver uses this pair carried in each packet to uniquely identify from which session the packet was received. In case multiple objects are carried within a session, the Transport Object Identifier (TOI) field within the ALC/LCT header identifies from which object the data in the packet was generated. Note that each object is associated with a unique TOI within the scope of a session.
ALC/LCT报头中包含的字段之一是传输会话标识符（TSI）。TSI由源IP地址确定范围，并且（源IP地址，TSI）对唯一地标识会话，即，接收器使用每个分组中携带的该对来唯一地标识从哪个会话接收分组。如果一个会话中携带了多个对象，则ALC/LCT报头中的传输对象标识符（TOI）字段将标识数据包中的数据是从哪个对象生成的。请注意，每个对象都与会话范围内的唯一TOI相关联。
If the sender is not assigned a permanent IP address accessible to receivers, but instead, packets that can be received by receivers containing a temporary IP address for packets sent by the sender, then the TSI is scoped by this temporary IP address of the sender for the duration of the session. As an example, the sender may be behind a Network Address Translation (NAT) device that temporarily assigns
如果没有为发送方分配接收方可访问的永久IP地址，而是指接收方可接收的包含发送方发送的数据包的临时IP地址的数据包，则TSI在会话期间的作用域为发送方的该临时IP地址。例如，发送方可能在临时分配的网络地址转换（NAT）设备后面
an IP address for the sender that is accessible to receivers, and in this case the TSI is scoped by the temporary IP address assigned by the NAT that will appear in packets received by the receiver. As another example, the sender may send its original packets using IPv6, but some portions of the network may not be IPv6 capable and thus there may be an IPv6 to IPv4 translator that changes the IP address of the packets to a different IPv4 address. In this case, receivers in the IPv4 portion of the network will receive 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 used to scope the session by receivers is delivered to receivers, whether it is a permanent IP address or a temporary IP address, is outside the scope of this document.
接收方可访问的发送方IP地址，在这种情况下，TSI的范围由NAT分配的临时IP地址确定，该地址将出现在接收方接收的数据包中。作为另一示例，发送方可以使用IPv6发送其原始分组，但是网络的某些部分可能不支持IPv6，因此可能存在将分组的IP地址更改为不同IPv4地址的IPv6到IPv4转换器。在这种情况下，网络IPv4部分中的接收器将接收包含IPv4地址的数据包，因此它们的TSI由IPv4地址限定。接收方将用于确定会话范围的发送方IP地址如何传递给接收方，无论是永久IP地址还是临时IP地址，都不在本文档的范围之内。
When FLUTE is used for file delivery over ALC the following rules apply:
当FLUTE用于通过ALC传递文件时，以下规则适用：
* The ALC/LCT session is called file delivery session.
* ALC/LCT会话称为文件传递会话。
* The ALC/LCT concept of 'object' denotes either a 'file' or a 'File Delivery Table Instance' (section 3.2)
* “对象”的ALC/LCT概念表示“文件”或“文件传递表实例”（第3.2节）
* 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 Close Session (A) flag set to 1 (signaling the end of the session) and that contain no payload (carrying no information for any file or FDT) SHALL NOT carry the TOI. See Section 5.1 of RFC 3451 [3] for the LCT definition of the Close Session flag, and see Section 4.2 of RFC 3450 [2] for an example of its use within an ALC packet.
* TOI字段必须包含在长笛会话中发送的ALC数据包中，但在长笛会话中发送的ALC数据包（关闭会话（a）标志设置为1（表示会话结束）且不包含有效负载（不包含任何文件或FDT的信息）不得携带TOI。有关关闭会话标志的LCT定义，请参见RFC 3451[3]的第5.1节，在ALC数据包中使用该标志的示例，请参见RFC 3450[2]的第4.2节。
* The TOI value '0' is reserved for delivery of File Delivery Table Instances. Each File Delivery Table Instance is uniquely identified by an FDT Instance ID.
* TOI值“0”保留用于传递文件传递表实例。每个文件传递表实例都由FDT实例ID唯一标识。
* Each file in a file delivery session MUST be associated with a TOI (>0) in the scope of that session.
* 文件传递会话中的每个文件都必须与该会话范围内的TOI（>0）相关联。
* Information carried in the headers and the payload of a packet is scoped by the source IP address and the TSI. Information 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 further scoped by both the TOI and the FDT Instance ID for FDT Instance objects.
* 数据包的报头和有效载荷中携带的信息由源IP地址和TSI限定范围。对于文件对象，报头中携带的特定于对象的信息和数据包的有效载荷由TOI进一步限定范围，对于FDT实例对象，由TOI和FDT实例ID进一步限定范围。
The File Delivery Table (FDT) provides a means to describe various attributes associated with files that are to be delivered within the file delivery session. The following lists are examples of such attributes, and are not intended to be mutually exclusive nor exhaustive.
文件传递表（FDT）提供了一种方法来描述与文件传递会话中要传递的文件相关联的各种属性。以下列表是此类属性的示例，并非相互排斥或详尽无遗。
Attributes related to the delivery of file:
与文件传递相关的属性：
- TOI value that represents the file
- 表示文件的TOI值
- FEC Object Transmission Information (including the FEC Encoding ID and, if relevant, the FEC Instance ID)
- FEC对象传输信息（包括FEC编码ID和FEC实例ID（如果相关））
- Size of the transport object carrying the file
- 承载文件的传输对象的大小
- Aggregate rate of sending packets to all channels
- 向所有通道发送数据包的聚合速率
Attributes related to the file itself:
与文件本身相关的属性：
- Name, Identification and Location of file (specified by the URI)
- 文件的名称、标识和位置（由URI指定）
- MIME media type of file
- 文件的MIME媒体类型
- Size of file
- 文件大小
- Encoding of file
- 文件编码
- Message digest of file
- 文件的消息摘要
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.
其中一些属性必须包含在文件的文件描述条目中，其他属性是可选的，如第3.4.2节所定义。
Logically, the FDT is a set of file description entries for files to be delivered in the session. Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file. The TOI is included in each ALC/LCT data packet during the delivery of the file, and thus the TOI carried in the file description entry is how the receiver determines which ALC/LCT data packets contain information about which file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
从逻辑上讲，FDT是会话中要传递的文件的一组文件描述条目。每个文件描述条目必须包括它所描述的文件的TOI和标识该文件的URI。在文件的传递期间，TOI包括在每个ALC/LCT数据分组中，因此，文件描述条目中携带的TOI是接收方确定哪些ALC/LCT数据分组包含关于哪个文件的信息的方式。每个文件描述条目还可以包含一个或多个描述符，这些描述符将上述属性映射到文件。
Each file delivery session MUST have an FDT that is local to the given session. The FDT MUST provide a file description entry mapped to a TOI for each file appearing within the session. An object that is delivered within the ALC session, but not described in the FDT, is
每个文件传递会话必须具有给定会话本地的FDT。FDT必须为会话中出现的每个文件提供映射到TOI的文件描述条目。在ALC会话中交付但FDT中未描述的对象是
not considered a 'file' belonging to the file delivery session. Handling of these unmapped TOIs (TOIs that are not resolved by the FDT) is out of scope of this specification.
不认为是属于文件传递会话的“文件”。处理这些未映射的TOI（FDT未解析的TOI）超出本规范的范围。
Within the file delivery session the FDT is delivered as FDT Instances. An FDT Instance contains one or more file description entries of the FDT. Any FDT Instance can be equal to, a subset of, a superset of, or complement any other FDT Instance. A certain FDT Instance may be repeated several times during a session, even after subsequent FDT Instances (with higher FDT Instance ID numbers) have been transmitted. Each FDT Instance contains at least a single file description entry and at most the complete FDT of the file delivery session.
在文件传递会话中，FDT作为FDT实例传递。FDT实例包含FDT的一个或多个文件描述条目。任何FDT实例都可以等于、子集、超集或补充任何其他FDT实例。某个FDT实例可能在会话期间重复多次，即使在随后的FDT实例（具有更高的FDT实例ID号）被传输之后也是如此。每个FDT实例至少包含一个文件描述条目，最多包含文件传递会话的完整FDT。
A receiver of the file delivery session keeps an FDT database for received file description entries. The receiver maintains the database, for example, upon reception of FDT Instances. Thus, at any given time the contents of the FDT database represent the receiver's current view of the FDT of the file delivery session. Since each receiver behaves independently of other receivers, it SHOULD NOT be assumed that the contents of the FDT database are the same for all the receivers of a given file delivery session.
文件传递会话的接收者为接收到的文件描述条目保留FDT数据库。接收器维护数据库，例如，在接收FDT实例时。因此，在任何给定的时间，FDT数据库的内容表示接收方对文件交付会话的FDT的当前视图。由于每个接收器的行为独立于其他接收器，因此不应假设FDT数据库的内容对于给定文件传递会话的所有接收器都是相同的。
Since FDT database is an abstract concept, the structure and the maintaining of the FDT database are left to individual implementations and are thus out of scope of this specification.
由于FDT数据库是一个抽象概念，因此FDT数据库的结构和维护由单独的实现来决定，因此超出了本规范的范围。
The following rules define the dynamics of the FDT Instances within a file delivery session:
以下规则定义文件传递会话中FDT实例的动态：
* For every file delivered within a file delivery session there MUST be a file description entry included in at least one FDT Instance sent within the session. A file description entry contains at a minimum the mapping between the TOI and the URI.
* 对于在文件传递会话中传递的每个文件，必须在会话中发送的至少一个FDT实例中包含一个文件描述条目。文件描述条目至少包含TOI和URI之间的映射。
* An FDT Instance MAY appear in any part of the file delivery session and packets for an FDT Instance MAY be interleaved with packets for other files or other FDT Instances within a session.
* FDT实例可出现在文件递送会话的任何部分中，并且FDT实例的分组可与会话内的其它文件或其它FDT实例的分组交错。
* The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values for FDT Instances is outside the scope of this specification.
* 必须保留“0”的TOI值以传递FDT实例。FDT实例使用其他TOI值不在本规范范围内。
* FDT Instance is identified by the use of a new fixed length LCT Header Extension EXT_FDT (defined later in this section). Each FDT Instance is uniquely identified within the file delivery session by its FDT Instance ID. Any ALC/LCT packet carrying FDT Instance (indicated by TOI = 0) MUST include EXT_FDT.
* FDT实例通过使用新的固定长度LCT标头扩展EXT_FDT（本节稍后定义）来识别。每个FDT实例在文件传递会话中通过其FDT实例ID进行唯一标识。任何携带FDT实例的ALC/LCT数据包（由TOI=0表示）必须包含EXT_FDT。
* It is RECOMMENDED that FDT Instance that contains the file description entry for a file is sent prior to the sending of the described file within a file delivery session.
* 建议在文件传递会话中发送所述文件之前，先发送包含文件描述条目的FDT实例。
* Within a file delivery session, any TOI > 0 MAY be described more than once. An example: previous FDT Instance 0 describes TOI of value '3'. Now, subsequent FDT Instances can either keep TOI '3' unmodified on the table, not include it, or complement the description. However, subsequent FDT Instances MUST NOT change the parameters already described for a specific TOI.
* 在文件传递会话中，任何TOI>0都可以被描述多次。例如：前面的FDT实例0描述了值为“3”的TOI。现在，后续FDT实例可以保持TOI“3”在表中未修改，不包括它，或者补充说明。但是，后续FDT实例不得更改已为特定TOI描述的参数。
* An FDT Instance is valid until its expiration time. The expiration time is expressed within the FDT Instance payload as a 32 bit data field. The value of the data field represents the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [5] time value. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900. Handling of wraparound of the 32 bit time is outside the scope of NTP and FLUTE.
* FDT实例在其过期之前是有效的。失效时间在FDT实例有效负载中表示为32位数据字段。数据字段的值表示64位网络时间协议（NTP）[5]时间值的32个最高有效位。这32位提供一个无符号整数，表示相对于1900年1月1日0小时的时间（以秒为单位）。32位时间的环绕处理不在NTP和FLUTE的范围内。
* The receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.
* 接收器不应使用接收到的FDT实例来解释在FDT实例过期之后接收到的数据包。
* A sender MUST use an expiry time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT).
* 发送方必须在将来创建FDT实例时使用相对于其发送方当前时间（SCT）的到期时间。
* Any FEC Encoding ID MAY be used for the sending of FDT Instances. The default is to use FEC Encoding ID 0 for the sending of FDT Instances. (Note that since FEC Encoding ID 0 is the default for FLUTE, this implies that Source Block Number and Encoding Symbol ID lengths both default to 16 bits each.)
* 任何FEC编码ID均可用于发送FDT实例。默认情况下，使用FEC编码ID 0发送FDT实例。（注意，由于FEC编码ID 0是长笛的默认值，这意味着源块编号和编码符号ID长度都默认为16位。）
Generally, a receiver needs to receive an FDT Instance describing a file before it is able to recover the file itself. In this sense FDT Instances are of higher priority than files. Thus, it is RECOMMENDED that FDT Instances describing a file be sent with at least as much reliability within a session (more often or with more FEC protection) as the files they describe. In particular, if FDT Instances are longer than one packet payload in length it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering FDT Instances. How often the description of a file is sent in an FDT
通常，接收器需要接收描述文件的FDT实例，然后才能恢复文件本身。从这个意义上讲，FDT实例的优先级高于文件。因此，建议描述文件的FDT实例在会话中至少以其描述的文件的可靠性（更频繁或具有更多FEC保护）发送。特别是，如果FDT实例的长度超过一个数据包有效载荷，则建议使用提供丢失保护的FEC代码来交付FDT实例。文件描述在FDT中发送的频率
Instance or how much FEC protection is provided for each FDT Instance (if the FDT Instance is longer than one packet payload) is dependent on the particular application and outside the scope of this document.
实例或为每个FDT实例提供多少FEC保护（如果FDT实例长于一个数据包有效载荷）取决于特定应用，不在本文档范围内。
FDT Instances are carried in ALC packets with TOI = 0 and with an additional REQUIRED LCT Header extension called the FDT Instance Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance ID that uniquely identifies FDT Instances within a file delivery session. The FDT Instance Header is placed in the same way as any other LCT extension header. There MAY be other LCT extension headers in use.
FDT实例在TOI=0的ALC数据包中传输，并带有一个称为FDT实例头的额外必需LCT头扩展。FDT实例头（EXT_FDT）包含唯一标识文件传递会话中FDT实例的FDT实例ID。FDT实例头的放置方式与任何其他LCT扩展头的放置方式相同。可能正在使用其他LCT扩展标头。
The LCT extension headers are followed by the FEC Payload ID, and finally the Encoding Symbols for the FDT Instance which contains one or more file description entries. A FDT Instance MAY span several ALC packets - the number of ALC packets is a function of the file attributes associated with the FDT Instance. The FDT Instance Header is carried in each ALC packet carrying the FDT Instance. The FDT Instance Header is identical for all ALC/LCT packets for a particular FDT Instance.
LCT扩展头后面跟着FEC有效负载ID，最后是包含一个或多个文件描述条目的FDT实例的编码符号。FDT实例可能跨越多个ALC包-ALC包的数量是与FDT实例相关联的文件属性的函数。FDT实例报头携带在携带FDT实例的每个ALC包中。对于特定FDT实例的所有ALC/LCT数据包，FDT实例头是相同的。
The overall format of ALC/LCT packets carrying an FDT Instance is depicted in the Figure 1 below. All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. As defined in [2], all ALC/LCT packets are sent using UDP.
下面的图1描述了携带FDT实例的ALC/LCT数据包的总体格式。所有整数字段都以“big-endian”或“network-order”格式携带，也就是说，首先是最高有效字节（octet）。如[2]中所定义，所有ALC/LCT数据包都使用UDP发送。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default LCT header (with TOI = 0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) for FDT Instance |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
图1-总体FDT数据包
FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific LCT header extension [3]. The Header Extension Type (HET) for the extension is 192. Its format is defined below:
FDT实例头（EXT_FDT）是一种新的固定长度、ALC PI特定LCT头扩展[3]。扩展的头扩展类型（HET）为192。其格式定义如下：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version of FLUTE (V), 4 bits:
长笛版本（V），4位：
This document specifies FLUTE version 1. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '1'.
本文件规定了长笛版本1。因此，在任何携带FDT实例且属于本规范中指定的文件传递会话的ALC数据包中，必须将此字段设置为“1”。
FDT Instance ID, 20 bits:
FDT实例ID，20位：
For each file delivery session the numbering of FDT Instances starts from '0' and is incremented by one for each subsequent FDT Instance. After reaching the maximum value (2^20-1), the numbering starts again from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is considered higher than 2^20-1. A new FDT Instance reusing a previous FDT Instance ID number, due to wraparound, may not implicitly expire the previous FDT Instance with the same ID. It would be reasonable for
对于每个文件传递会话，FDT实例的编号从“0”开始，并为每个后续FDT实例增加一个。达到最大值（2^20-1）后，编号再次从“0”开始。当从2^20-1到0发生环绕时，0被认为高于2^20-1。重新使用先前FDT实例ID号的新FDT实例，由于环绕，可能不会隐式使具有相同ID的先前FDT实例过期。这对于
FLUTE Senders to only construct and deliver FDT Instances with wraparound IDs after the previous FDT Instance using the same ID has expired. However, mandatory receiver behavior for handling FDT Instance ID wraparound and other special situations (for example, missing FDT Instance IDs resulting in larger increments than one) is outside the scope of this specification and left to individual implementations of FLUTE.
在使用相同ID的前一个FDT实例过期后，长笛发送方仅构造和交付具有环绕ID的FDT实例。但是，用于处理FDT实例ID环绕和其他特殊情况（例如，缺少FDT实例ID导致增量大于1）的强制接收器行为不在本规范的范围内，由FLUTE的单独实现决定。
The FDT Instance contains file description entries that provide the mapping functionality described in 3.2 above.
FDT实例包含提供上述3.2中所述映射功能的文件描述条目。
The FDT Instance is an XML structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain "Expires" attribute, which tells the expiry time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute (boolean), which, when TRUE, signals that no new data will be provided in future FDT Instances within this session (i.e., that either FDT Instances with higher ID numbers will not be used or if they are used, will only provide identical file parameters to those already given in this and previous FDT Instances). For example, this may be used to provide a complete list of files in an entire FLUTE session (a "complete FDT").
FDT实例是一个XML结构，它有一个根元素“FDT实例”。“FDT Instance”元素必须包含“Expires”属性，该属性告诉FDT实例的过期时间。此外，“FDT Instance”元素可能包含“Complete”属性（布尔值），如果为TRUE，则表示此会话中的未来FDT实例中不会提供新数据（即，不会使用ID号较高的FDT实例，或者如果使用了FDT实例，则只会提供与此FDT实例和以前FDT实例中已给出的文件参数相同的文件参数）。例如，这可用于提供整个FLUTE会话中的完整文件列表（“完整FDT”）。
The "FDT-Instance" element MAY contain attributes that give common parameters for all files of an FDT Instance. These attributes MAY also be provided for individual files in the "File" element. Where the same attribute appears in both the "FDT-Instance" and the "File" elements, the value of the attribute provided in the "File" element takes precedence.
“FDT实例”元素可能包含为FDT实例的所有文件提供公共参数的属性。还可以为“File”元素中的单个文件提供这些属性。如果相同属性同时出现在“FDT实例”和“文件”元素中，则“文件”元素中提供的属性值优先。
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 represented by element "File" which is a child element of the FDT Instance structure.
对于给定FDT实例中要声明的每个文件，FDT实例中有一个文件描述条目。每个条目由元素“File”表示，该元素是FDT实例结构的子元素。
The attributes of "File" element in the XML structure represent the attributes given to the file that is delivered in the file delivery session. The value of the XML attribute name corresponds to MIME field name and the XML attribute value corresponds to the value of the MIME field body. Each "File" element MUST contain at least two attributes "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI value as described in section 3.3 above. "Content-Location" MUST be assigned a valid URI as defined in [6].
XML结构中“File”元素的属性表示在文件传递会话中传递的文件的属性。XML属性名的值对应于MIME字段名，XML属性值对应于MIME字段正文的值。每个“文件”元素必须至少包含两个属性“TOI”和“内容位置”。“TOI”必须按照上述第3.3节所述分配有效的TOI值。必须为“内容位置”分配[6]中定义的有效URI。
In addition to mandatory attributes, the "FDT-Instance" element and the "File" element MAY contain other attributes of which the following are specifically pointed out.
除强制属性外，“FDT实例”元素和“文件”元素还可能包含其他属性，具体指出了以下属性。
* Where the MIME type is described, the attribute "Content-Type" MUST be used for the purpose as defined in [6].
* 如果描述了MIME类型，则属性“Content type”必须用于[6]中定义的用途。
* Where the length is described, the attribute "Content-Length" MUST be used for the purpose as defined in [6]. The transfer length is defined to be the length of the object transported in bytes. It is often important to convey the transfer length to receivers, because the source block structure needs to be known for the FEC decoder to be applied to recover source blocks of the file, and the transfer length is often needed to properly determine the source block structure of the file. There generally will be a difference between the length of the original file and the transfer length if content encoding is applied to the file before transport, and thus the "Content-Encoding" attribute is used. If the file is not content encoded before transport (and thus the "Content-Encoding" attribute is not used) then the transfer length is the length of the original file, and in this case the "Content-Length" is also the transfer length. However, if the file is content encoded before transport (and thus the "Content-Encoding" attribute is used), e.g., if compression is applied before transport to reduce the number of bytes that need to be transferred, then the transfer length is generally different than the length of the original file, and in this case the attribute "Transfer-Length" MAY be used to carry the transfer length.
* 如果描述了长度，则属性“内容长度”必须用于[6]中定义的目的。传输长度定义为以字节为单位传输的对象的长度。将传输长度传递给接收机通常很重要，因为要应用FEC解码器来恢复文件的源块，需要知道源块结构，并且通常需要传输长度来正确确定文件的源块结构。如果在传输之前对文件应用内容编码，则原始文件的长度和传输长度之间通常会有差异，因此使用“内容编码”属性。如果文件在传输之前未进行内容编码（因此未使用“内容编码”属性），则传输长度是原始文件的长度，在这种情况下，“内容长度”也是传输长度。然而，如果文件在传输之前进行内容编码（因此使用“内容编码”属性），例如，如果在传输之前应用压缩以减少需要传输的字节数，则传输长度通常不同于原始文件的长度，在这种情况下，属性“传输长度”可用于承载传输长度。
* Where the content encoding scheme is described, the attribute "Content-Encoding" MUST be used for the purpose as defined in [6].
* 在描述内容编码方案的情况下，属性“内容编码”必须用于[6]中定义的目的。
* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose as defined in [6].
* 如果描述了MD5消息摘要，则属性“Content-MD5”必须用于[6]中定义的目的。
* The FEC Object Transmission Information attributes as described in section 5.2.
* FEC对象传输信息属性如第5.2节所述。
The following specifies the XML Schema [8][9] for FDT Instance:
下面指定FDT实例的XML模式[8][9]：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fl="http://www.example.com/flute"
elementFormDefault:xs="qualified"
targetNamespace:xs="http://www.example.com/flute">
<xs:element name="FDT-Instance">
<xs:complexType>
<xs:sequence>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fl="http://www.example.com/flute"
elementFormDefault:xs="qualified"
targetNamespace:xs="http://www.example.com/flute">
<xs:element name="FDT-Instance">
<xs:complexType>
<xs:sequence>
<xs:element name="File" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:element name="File" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
Any valid FDT Instance must use the above XML Schema. This way FDT provides extensibility to support private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.).
任何有效的FDT实例都必须使用上述XML模式。通过这种方式，FDT提供了可扩展性，以支持文件描述条目中的私有属性。例如，这些可以是与文件的交付相关的属性（定时、分组传输速率等）。
In case the basic FDT XML Schema is extended in terms of new descriptors, for attributes applying to a single file, those MUST be placed within the attributes of the element "File". For attributes applying to all files described by the current FDT Instance, those MUST be placed within the element "FDT-Instance". It is RECOMMENDED that the new descriptors applied in the FDT are in the format of MIME fields and are either defined in the HTTP/1.1 specification [6] or another well-known specification.
如果基本FDT XML模式根据新描述符进行扩展，对于应用于单个文件的属性，这些属性必须放在元素“file”的属性中。对于应用于当前FDT实例描述的所有文件的属性，这些属性必须放置在元素“FDT实例”中。建议FDT中应用的新描述符采用MIME字段格式，并在HTTP/1.1规范[6]或其他著名规范中定义。
The FDT Instance itself MAY be content encoded, for example compressed. This specification defines FDT Instance Content Encoding Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific LCT header extension [3]. The Header Extension Type (HET) for the
FDT实例本身可以是内容编码的，例如压缩的。本规范定义了FDT实例内容编码头（EXT_CENC）。EXT_CENC是一种新的固定长度、ALC PI特定的LCT头扩展[3]。文件的标题扩展类型（HET）
extension is 193. If the FDT Instance is content encoded, the 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 carrying the same FDT Instance ID. Consequently, when EXT_CENC header is used, it MUST be used together with a proper FDT Instance Header (EXT_FDT). Within a file delivery session, FDT Instances that are not content encoded and FDT Instances that are content encoded MAY both appear. If content encoding is not used for a given FDT Instance, the EXT_CENC MUST NOT be used in any packet carrying the FDT Instance. The format of EXT_CENC is defined below:
分机号码是193。如果FDT实例是内容编码的，则必须使用EXT_CENC来表示内容编码类型。在这种情况下，所有携带相同FDT实例ID的ALC数据包中必须使用EXT_CENC头扩展。因此，当使用EXT_CENC头时，它必须与适当的FDT实例头（EXT_FDT）一起使用。在文件传递会话中，可能同时出现未进行内容编码的FDT实例和进行内容编码的FDT实例。如果给定FDT实例未使用内容编码，则EXT_CENC不得用于承载FDT实例的任何数据包。EXT_CENC的格式定义如下：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content Encoding Algorithm (CENC), 8 bits:
内容编码算法（CENC），8位：
This field signals the content encoding algorithm used in the FDT Instance payload. The definition of this field is outside the scope of this specification. Applicable content encoding algorithms include, for example, ZLIB [10], DEFLATE [16] and GZIP [17].
此字段表示FDT实例有效负载中使用的内容编码算法。此字段的定义不在本规范的范围内。适用的内容编码算法包括，例如，ZLIB[10]、DEFLATE[16]和GZIP[17]。
Reserved, 16 bits:
保留，16位：
This field MUST be set to all '0'.
此字段必须全部设置为“0”。
The delivered files are carried as transport objects (identified with TOIs) in the file delivery session. All these objects, 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 MAY be interleaved with packets for other files or other FDT Instances within a session.
在文件传递会话中，传递的文件作为传输对象（用TOI标识）携带。所有这些对象，包括FDT实例，可以在会话中以任何顺序并彼此并行地复用，即，一个文件的分组可以与会话中其他文件或其他FDT实例的分组交织。
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 FDT Instance SHOULD end before the sending of the next FDT Instance starts. However, due to unexpected network conditions, packets for the FDT Instances MAY be interleaved. A receiver can determine which FDT Instance a packet contains information about since the FDT Instances are uniquely identified by their FDT Instance ID carried in the EXT_FDT headers.
可以使用TOI=0在单个会话中交付多个FDT实例。在这种情况下，建议在开始发送下一个FDT实例之前，结束发送前一个FDT实例。然而，由于意外的网络条件，FDT实例的分组可能被交错。接收器可以确定数据包包含关于哪个FDT实例的信息，因为FDT实例由EXT_FDT报头中携带的FDT实例ID唯一标识。
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
ALC/LCT具有信道和拥塞控制的概念。有四种情况下，长笛是设想应用。
(a) Use a single channel and a single-rate congestion control protocol.
(a) 使用单通道和单速率拥塞控制协议。
(b) Use multiple channels and a multiple-rate congestion control protocol. In this case the FDT Instances MAY be delivered on more than one channel.
(b) 使用多通道和多速率拥塞控制协议。在这种情况下，FDT实例可以在多个信道上交付。
(c) Use a single channel without congestion control supplied by ALC, but only when in a controlled network environment where flow/ congestion control is being provided by other means.
(c) 使用没有ALC提供的拥塞控制的单通道，但仅在通过其他方式提供流量/拥塞控制的受控网络环境中使用。
(d) Use multiple channels without congestion control supplied by ALC, but only when in a controlled network environment where flow/ congestion control is being provided by other means. In this case the FDT Instances MAY be delivered on more than one channel.
(d) 使用没有ALC提供的拥塞控制的多个通道，但仅在通过其他方式提供流量/拥塞控制的受控网络环境中使用。在这种情况下，FDT实例可以在多个信道上交付。
When using just one channel for a file delivery session, as in (a) and (c), the notion of 'prior' and 'after' are intuitively defined for the delivery of objects with respect to their delivery times.
如（a）和（c）中所述，在文件传递会话中仅使用一个通道时，“之前”和“之后”的概念是根据对象的传递时间直观地定义的。
However, if multiple channels are used, as in (b) and (d), it is not straightforward to state that an object was delivered 'prior' to the other. An object may begin to be delivered on one or more of those channels before the delivery of a second object begins. However, the use of multiple channels/layers may complete the delivery of the second object before the first. This is not a problem when objects are delivered sequentially using a single channel. Thus, if the application of FLUTE has a mandatory or critical requirement that the first transport object must complete 'prior' to the second one, it is RECOMMENDED that only a single channel is used for the file delivery session.
但是，如果使用了多个通道，如（b）和（d）中所述，则不能直接说明对象是“在”另一个之前交付的。在第二个对象的交付开始之前，可以在一个或多个通道上开始交付对象。然而，使用多个通道/层可能会在第一个对象之前完成第二个对象的交付。当使用单个通道按顺序交付对象时，这不是问题。因此，如果FLUTE的应用具有强制性或关键性要求，即第一个传输对象必须在第二个传输对象之前完成，则建议仅将单个通道用于文件传递会话。
Furthermore, if multiple channels are used then a receiver joined to the session at a low reception rate will only be joined to the lower layers of the session. Thus, since the reception of FDT Instances is of higher priority than the reception of files (because the reception of files depends on the reception of an FDT Instance describing it), the following is RECOMMENDED:
此外，如果使用多个信道，则以低接收速率加入会话的接收机将仅加入会话的较低层。因此，由于FDT实例的接收比文件的接收具有更高的优先级（因为文件的接收取决于描述它的FDT实例的接收），因此建议如下：
1. The layers to which packets for FDT Instances are sent SHOULD NOT be biased towards those layers to which lower rate receivers are not joined. For example, it is ok to put all the packets for an FDT Instance into the lowest layer (if this layer carries enough
1. FDT实例的数据包发送到的层不应偏向低速率接收器未连接到的层。例如，可以将FDT实例的所有数据包放入最底层（如果该层承载足够的数据包）
packets to deliver the FDT to higher rate receivers in a reasonable amount of time), but it is not ok to put all the packets for an FDT Instance into the higher layers that only high rate receivers will receive.
数据包将在合理的时间内将FDT发送到更高速率的接收器），但将FDT实例的所有数据包放入只有高速率接收器才能接收的更高层是不合适的。
2. If FDT Instances are generally longer than one Encoding Symbol in length and some packets for FDT Instances are sent to layers that lower rate receivers do not receive, an FEC Encoding other than FEC Encoding ID 0 SHOULD be used to deliver FDT Instances. This is because in this case, even when there is no packet loss in the network, a lower rate receiver will not receive all packets sent for an FDT Instance.
2. 如果FDT实例的长度通常大于一个编码符号，并且FDT实例的一些数据包被发送到低速率接收器不接收的层，则应使用FEC编码ID 0以外的FEC编码来交付FDT实例。这是因为在这种情况下，即使网络中没有分组丢失，低速率接收器也不会接收为FDT实例发送的所有分组。
FLUTE inherits the use of FEC building block [4] from ALC. When using FLUTE for file delivery over ALC the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. In this section, two methods are specified for FLUTE for this purpose: the use of ALC specific LCT extension header EXT_FTI [2] and the use of FDT.
FLUTE继承了ALC对FEC构建块[4]的使用。当通过ALC使用FLUTE进行文件传递时，FEC对象传输信息必须在文件传递会话内的频带内传递。在本节中，为此目的，为FLUTE指定了两种方法：使用ALC专用LCT扩展头EXT_FTI[2]和使用FDT。
The receiver of file delivery session MUST support delivery of FEC Object Transmission Information using the EXT_FTI for the FDT Instances carried using TOI value 0. For the TOI values other than 0 the receiver MUST support both methods: the use of EXT_FTI and the use of FDT.
对于使用TOI值0携带的FDT实例，文件传递会话的接收方必须支持使用EXT_FTI传递FEC对象传输信息。对于除0以外的TOI值，接收器必须支持两种方法：使用EXT_FTI和使用FDT。
The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using FDT (or both). Section 5.1 describes the required FEC Object Transmission Information that MUST be delivered to receivers for various FEC Encoding IDs. In addition, it describes the delivery using EXT_FTI. Section 5.2 describes the delivery using FDT.
无论是使用EXT_FTI还是使用FDT（或两者兼而有之），需要交付给接收机的FEC对象传输信息必须完全相同。第5.1节描述了各种FEC编码ID必须发送给接收机的所需FEC对象传输信息。此外，它还使用EXT_FTI描述了交付。第5.2节描述了使用FDT的交付。
The FEC Object Transmission Information regarding a given TOI may be available from several sources. In this case, it is RECOMMENDED that the receiver of the file delivery session prioritizes the sources in the following way (in the order of decreasing priority).
关于给定TOI的FEC对象传输信息可以从多个源获得。在这种情况下，建议文件传递会话的接收者按以下方式（按优先级降低的顺序）对源进行优先级排序。
1. FEC Object Transmission Information that is available in EXT_FTI.
1. 在EXT_FTI中可用的FEC对象传输信息。
2. FEC Object Transmission Information that is available in the FDT.
2. FDT中可用的FEC对象传输信息。
As specified in [2], the EXT_FTI header extension is intended to carry the FEC Object Transmission Information for an object in-band. It is left up to individual implementations to decide how frequently and in which ALC packets the EXT_FTI header extension is included. In environments with higher packet loss rate, the EXT_FTI might need to be included more frequently in ALC packets than in environments with low error probability. The EXT_FTI MUST be included in at least one sent ALC packet for each FDT Instance.
如[2]中所述，EXT_FTI报头扩展旨在携带带内对象的FEC对象传输信息。将EXT_FTI头扩展包含在ALC数据包中的频率和位置留给各个实现来决定。在丢包率较高的环境中，与错误概率较低的环境相比，可能需要在ALC数据包中更频繁地包含EXT_FTI。对于每个FDT实例，EXT_FTI必须包含在至少一个发送的ALC数据包中。
The ALC specification does not define the format or the processing of the EXT_FTI header extension. The following sections specify EXT_FTI when used in FLUTE.
ALC规范未定义EXT_FTI头扩展的格式或处理。以下各节详细说明了在长笛中使用EXT_FTI。
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header.
在FLUTE中，FEC编码ID（8位）携带在ALC/LCT报头的码点字段中。
The general EXT_FTI format specifies the structure and those attributes of FEC Object Transmission Information that are applicable to any FEC Encoding ID.
通用EXT_FTI格式指定适用于任何FEC编码ID的FEC对象传输信息的结构和属性。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
标题扩展类型（HET），8位：
64 as defined in [2].
64如[2]中所定义。
Header Extension Length (HEL), 8 bits:
标题扩展长度（HEL），8位：
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This length includes the FEC Encoding ID specific format part.
整个标头扩展字段的长度，以32位字的倍数表示。该长度包括FEC编码ID特定格式部分。
Transfer Length, 48 bits:
传输长度，48位：
The length of the transport object that carries the file in bytes. (This is the same as the file length if the file is not content encoded.)
以字节为单位承载文件的传输对象的长度。（如果文件未进行内容编码，则与文件长度相同。）
FEC Instance ID, optional, 16 bits:
FEC实例ID，可选，16位：
This field is used for FEC Instance ID. It is only present if the value of FEC Encoding ID is in the range of 128-255. When the value of FEC Encoding ID is in the range of 0-127, this field is set to 0.
此字段用于FEC实例ID。仅当FEC编码ID的值在128-255范围内时，此字段才存在。当FEC编码ID的值在0-127范围内时，此字段设置为0。
FEC Encoding ID Specific Format:
FEC编码ID特定格式：
Different FEC encoding schemes will need different sets of encoding parameters. Thus, the structure and length of this field depends on FEC Encoding ID. The next sections specify structure of this field for FEC Encoding ID numbers 0, 128, 129, and 130.
不同的FEC编码方案需要不同的编码参数集。因此，该字段的结构和长度取决于FEC编码ID。下一节为FEC编码ID号0、128、129和130指定该字段的结构。
FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC' (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC' (Under-Specified) [7]. For these FEC Encoding IDs, the FEC Encoding ID specific format of EXT_FTI is defined as follows.
FEC编码ID 0为“紧凑无代码FEC”（完全指定）[7]。FEC编码ID 128为“小数据块、大数据块和可扩展FEC”（未指定）[4]。FEC编码ID 130为“紧凑FEC”（未指定）[7]。对于这些FEC编码ID，EXT_FTI的FEC编码ID特定格式定义如下。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
编码符号长度，16位：
Length of Encoding Symbol in bytes.
编码符号的长度（字节）。
All Encoding Symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this
传输对象的所有编码符号都必须等于此长度，但最后一个源块的最后一个源符号除外（因此在此情况下，冗余填充不是必需的）
last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding does not actually need to be sent with the data of the last source symbol.
最后一个符号）。当基于此源符号计算另一个编码符号时，最后一个源符号必须在逻辑上用零填充，以确保发送方和接收方对此编码符号值的解释相同。但是，这个填充实际上不需要与最后一个源符号的数据一起发送。
Maximum Source Block Length, 32 bits:
最大源块长度，32位：
The maximum number of source symbols per source block.
每个源块的最大源符号数。
This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session.
该EXT_FTI规范要求发送方和接收方都知道一种算法，用于确定传输对象的所有源块的大小，该传输对象承载由TOI标识的文件（或在由TOI和FDT实例ID标识的FDT实例内）。对于会话中使用相同FEC编码ID的所有文件，算法应相同。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use.
第5.1.2.3节描述了推荐用于此用途的算法。
For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only well known way the receiver can determine the length of each source block. Thus, the algorithm does two things: (a) it tells the receiver the length of each particular source block as it is receiving packets for that source block - this is essential to all of these FEC schemes; and, (b) it provides the source block structure immediately to the receiver so that the receiver can determine where to save recovered source blocks at the beginning of the reception of data packets for the file - this is an optimization which is essential for some implementations.
对于FEC编码ID 0、128和130，该算法是接收机确定每个源块长度的唯一众所周知的方法。因此，该算法做了两件事：（a）它在接收每个特定源块的数据包时告诉接收器每个特定源块的长度——这对所有这些FEC方案都是至关重要的；并且，（b）它立即向接收器提供源块结构，以便接收器能够在开始接收文件的数据包时确定将恢复的源块保存在何处-这是一种优化，对于一些实现来说是必不可少的。
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID specific format of EXT_FTI is defined as follows.
小块系统FEC（未指定）。EXT_FTI的FEC编码ID特定格式定义如下。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length | Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
General EXT_FTI format | Encoding Symbol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Source Block Length | Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
编码符号长度，16位：
Length of Encoding Symbol in bytes.
编码符号的长度（字节）。
All Encoding Symbols of a transport object MUST be equal to this length, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol.
传输对象的所有编码符号必须等于此长度，但最后一个源块的最后一个源符号除外（因此，在最后一个符号中，冗余填充不是必需的）。当基于此源符号计算另一个编码符号时，最后一个源符号必须在逻辑上用零填充，以确保发送方和接收方对此编码符号值的解释相同。但是，此填充实际上不需要与最后一个源符号的数据一起发送。
Maximum Source Block Length, 16 bits:
最大源块长度，16位：
The maximum number of source symbols per source block.
每个源块的最大源符号数。
Maximum Number of Encoding Symbols, 16 bits:
编码符号的最大数量，16位：
Maximum number of Encoding Symbols that can be generated for a source block.
可为源块生成的最大编码符号数。
This EXT_FTI specification requires that an algorithm is known to both sender and receivers for determining the size of all source blocks of the transport object that carries the file identified by the TOI (or within the FDT Instance identified by the TOI and the FDT Instance ID). The algorithm SHOULD be the same for all files using the same FEC Encoding ID within a session.
该EXT_FTI规范要求发送方和接收方都知道一种算法，用于确定传输对象的所有源块的大小，该传输对象承载由TOI标识的文件（或在由TOI和FDT实例ID标识的FDT实例内）。对于会话中使用相同FEC编码ID的所有文件，算法应相同。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use. For FEC Encoding ID 129 the FEC Payload ID in each data packet already contains the source block length for the source block corresponding to the Encoding Symbol carried in the data packet. Thus, the algorithm for computing source blocks for FEC Encoding ID 129 could be to just use the source block lengths carried in data packets within the FEC Payload ID. However, the algorithm described in Section 5.1.2.3 is useful for the receiver to compute the source block structure at the beginning of the reception of data packets for the file. If the algorithm described in Section 5.1.2.3 is used then it MUST be the case that the source block lengths that appear in data packets agree with the source block lengths calculated by the algorithm.
第5.1.2.3节描述了推荐用于此用途的算法。对于FEC编码ID 129，每个数据分组中的FEC有效载荷ID已经包含与数据分组中携带的编码符号相对应的源块的源块长度。因此，用于计算FEC编码ID 129的源块的算法可以是仅使用FEC有效载荷ID内的数据分组中携带的源块长度，第5.1.2.3节中描述的算法有助于接收器在开始接收文件数据包时计算源块结构。如果使用第5.1.2.3节中描述的算法，则数据包中出现的源块长度必须与算法计算的源块长度一致。
This algorithm computes a source block structure so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are sent of the same smaller length. The total number of source blocks (N), the first number of
该算法计算源块结构，使所有源块的长度尽可能接近相等。第一数量的源块具有相同的较大长度，剩余的第二数量的源块以相同的较小长度发送。源块的总数（N），第一个
source blocks (I), the second number of source blocks (N-I), the larger length (A_large) and the smaller length (A_small) are calculated thus,
由此计算源块（I）、第二个源块数（N-I）、较大长度（A_大）和较小长度（A_小），
Input: B -- Maximum Source Block Length, i.e., the maximum number of source symbols per source block L -- Transfer Length in bytes E -- Encoding Symbol Length in bytes
输入：B——最大源块长度，即每个源块的最大源符号数L——以字节为单位的传输长度e——以字节为单位的编码符号长度
Output: N -- The number of source blocks into which the transport object is partitioned.
Output:N——传输对象被划分到的源块数。
The number and lengths of source symbols in each of the N source blocks.
N个源块中每个源符号的数量和长度。
Algorithm: (a) The number of source symbols in the transport object is computed as T = L/E rounded up to the nearest integer. (b) The transport object is partitioned into N source blocks, where N = T/B rounded up to the nearest integer (c) The average length of a source block, A = T/N (this may be non-integer) (d) A_large = A rounded up to the nearest integer (it will always be the case that the value of A_large is at most B) (e) A_small = A rounded down to the nearest integer (if A is an integer A_small = A_large, and otherwise A_small = A_large - 1) (f) The fractional part of A, A_fraction = A - A_small (g) I = A_fraction * N (I is an integer between 0 and N-1) (h) Each of the first I source blocks consists of A_large source symbols, each source symbol is E bytes in length. Each of the remaining N-I source blocks consist of A_small source symbols, each source symbol is E bytes in length except that the last source symbol of the last source block is L-(((L-1)/E) rounded down to the nearest integer)*E bytes in length.
算法：（a）传输对象中的源符号数计算为T=L/E，四舍五入到最接近的整数。（b） 传输对象被划分为N个源块，其中N=T/b四舍五入到最接近的整数（c）源块的平均长度，a=T/N（这可能是非整数）（d）a_large=a四舍五入到最接近的整数（a_large的值最多为b）（e）A_small=A四舍五入到最接近的整数（如果A是整数A_small=A_large，否则A_small=A_large-1）（f）A的小数部分，A_分数=A-A_small（g）I=A_分数*N（I是介于0和N-1之间的整数）（h）前I个源块中的每个由A_大源符号组成，每个源符号的长度为E字节。其余N-I个源块中的每个都由一个小源符号组成，每个源符号的长度为E字节，但最后一个源块的最后一个源符号的长度为L-（（L-1）/E）四舍五入到最接近的整数）*E字节。
Note, this algorithm does not imply implementation by floating point arithmetic and integer arithmetic may be used to avoid potential floating point rounding errors.
注意，此算法并不意味着使用浮点算法实现，可以使用整数算法来避免潜在的浮点舍入错误。
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure. For future FEC Encoding IDs, if the attributes listed below do not fulfill the needs of describing the FEC Object Transmission Information then additional new attributes MAY be used.
FDT使用FDT结构的“FDT实例”或“文件”元素中的适当属性为每个文件传递FEC对象传输信息。对于未来的FEC编码id，如果下面列出的属性不满足描述FEC对象传输信息的需要，则可以使用额外的新属性。
* "Transfer-Length" is semantically equivalent with the field "Transfer Length" of EXT_FTI.
* “Transfer Length”在语义上与EXT_FTI的字段“Transfer Length”等价。
* "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the field "FEC Encoding ID" as carried in the Codepoint field of the ALC/LCT header.
* “FEC-OTI-FEC-Encoding-ID”在语义上等同于在ALC/LCT报头的Codepoint字段中携带的字段“FEC-Encoding-ID”。
* "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the field "FEC Instance ID" of EXT_FTI.
* “FEC OTI FEC Instance ID”在语义上与EXT_FTI的字段“FEC Instance ID”等价。
* "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding IDs 0, 128 and 130, and semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID 129.
* 对于FEC编码ID 0、128和130，“FEC OTI最大源块长度”在语义上与EXT_FTI的字段“最大源块长度”等价，对于FEC编码ID 129，与EXT_FTI的字段“最大源块长度”在语义上等价。
* "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs 0, 128, 129 and 130.
* 对于FEC编码ID 0、128、129和130，“FEC OTI编码符号长度”在语义上等同于EXT_FTI的字段“编码符号长度”。
* "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically equivalent with the field "Maximum Number of Encoding Symbols" of EXT_FTI for FEC Encoding ID 129.
* “FEC OTI最大编码符号数”在语义上等同于用于FEC编码ID 129的EXT_FTI的字段“最大编码符号数”。
To start receiving a file delivery session, the receiver needs to know transport parameters associated with the session. Interpreting these parameters and starting the reception therefore represents the entry point from which thereafter the receiver operation falls into the scope of this specification. According to [2], the transport parameters of an ALC/LCT session that the receiver needs to know are:
要开始接收文件传递会话，接收方需要知道与会话相关联的传输参数。因此，解释这些参数并开始接收代表入口点，此后接收器操作从该入口点落入本规范的范围。根据[2]，接收机需要知道的ALC/LCT会话的传输参数为：
* The source IP address;
* 源IP地址；
* The number of channels in the session;
* 会话中的频道数；
* The destination IP address and port number for each channel in the session;
* 会话中每个通道的目标IP地址和端口号；
* The Transport Session Identifier (TSI) of the session;
* 会话的传输会话标识符（TSI）；
* An indication that the session is a FLUTE session. The need to demultiplex objects upon reception is implicit in any use of FLUTE, and this fulfills the ALC requirement of an indication of whether or not a session carries packets for more than one object (all FLUTE sessions carry packets for more than one object).
* 表示该会话是长笛会话的指示。接收时解复用对象的需要隐含在任何长笛的使用中，这满足ALC要求，即指示会话是否携带多个对象的数据包（所有长笛会话携带多个对象的数据包）。
Optionally, the following parameters MAY be associated with the session (Note, the list is not exhaustive):
可选地，以下参数可能与会话关联（注意，列表并非详尽无遗）：
* The start time and end time of the session;
* 会话的开始时间和结束时间；
* FEC Encoding ID and FEC Instance ID when the default FEC Encoding ID 0 is not used for the delivery of FDT;
* 当默认FEC编码ID 0未用于FDT的传递时，FEC编码ID和FEC实例ID；
* Content Encoding format if optional content encoding of FDT Instance is used, e.g., compression;
* 内容编码格式，如果使用FDT实例的可选内容编码，例如压缩；
* Some information that tells receiver, in the first place, that the session contains files that are of interest.
* 一些信息首先告诉接收者会话包含感兴趣的文件。
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [12] or XML based) and held in a file which would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as Session Announcement Protocol [11], email, HTTP [6], SIP [22], manual pre-configuration, etc.) However, the way in which the receiver discovers the above-mentioned parameters is out of scope of this document, as it is for LCT and ALC. In particular, this specification does not mandate or exclude any mechanism.
可以设想，这些参数将根据一些会话描述语法（例如SDP[12]或基于XML）进行描述，并保存在一个文件中，该文件将在长笛会话开始之前通过一些传输协议（例如会话公告协议[11]、电子邮件、HTTP[6]、SIP[22]由接收器获取但是，与LCT和ALC一样，接收器发现上述参数的方式超出了本文件的范围。特别是，本规范不强制或排除任何机制。
The security considerations that apply to, and are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE.
适用于ALC[2]、LCT[3]和FEC[4]并在其中描述的安全注意事项也适用于FLUTE。此外，适用于与FLUTE一起使用的任何拥塞控制构建块的任何安全注意事项也适用于FLUTE。
Because of the use of FEC, FLUTE is especially vulnerable to denial-of-service attacks by attackers that try to send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the FDT or file by receivers. Like ALC, FLUTE is particularly affected by such an
由于使用FEC，FLUTE特别容易受到攻击者的拒绝服务攻击，攻击者试图向会话发送伪造数据包，这将阻止成功重建或导致接收器对大部分FDT或文件进行不准确的重建。和ALC一样，长笛也特别受到这样的影响
attack because many receivers may receive the same forged packet. A malicious attacker may spoof file packets and cause incorrect recovery of a file.
攻击，因为许多接收者可能收到相同的伪造数据包。恶意攻击者可能伪造文件包并导致文件的错误恢复。
Even more damaging, a malicious forger may spoof FDT Instance packets, for example sending packets with erroneous FDT-Instance fields. Many attacks can follow this approach. For instance a malicious attacker may alter the Content-Location field of TOI 'n', to make it point to a system file or a user configuration file. Then, TOI 'n' can carry a Trojan Horse or some other type of virus. It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at the receiver does not have write access to the system files or directories, or any other critical areas. As described for MIME [20][21], special consideration should be paid to the security implications of any MIME types that can cause the remote execution of any actions in the recipient's environment. Note, RFC 1521 [21] describes important security issues for this environment, even though its protocol is obsoleted by RFC 2048 [20].
更具破坏性的是，恶意伪造者可能欺骗FDT实例数据包，例如发送具有错误FDT实例字段的数据包。许多攻击都可以遵循这种方法。例如，恶意攻击者可能会更改TOI“n”的内容位置字段，使其指向系统文件或用户配置文件。然后，TOI'n'可以携带特洛伊木马或其他类型的病毒。因此，强烈建议接收器处的长笛传送服务不具有对系统文件或目录或任何其他关键区域的写入权限。如MIME[20][21]所述，应特别考虑任何MIME类型的安全影响，这些MIME类型可能导致在接收方环境中远程执行任何操作。注意，RFC 1521[21]描述了该环境的重要安全问题，尽管其协议已被RFC 2048[20]淘汰。
Another example is generating a bad Content-MD5 sum, leading receivers to reject the associated file that will be declared corrupted. The Content-Encoding can also be modified, which also prevents the receivers to correctly handle the associated file. These examples show that the FDT information is critical to the FLUTE delivery service.
另一个示例是生成错误的Content-MD5和，导致接收方拒绝将被声明为已损坏的关联文件。还可以修改内容编码，这也会阻止接收者正确处理相关文件。这些示例表明，FDT信息对长笛交付服务至关重要。
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed to ensure it is the same as the sent object, especially for objects that are FDT Instances. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be used to provide this application level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail and, in this case, the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial of service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application level integrity check of the received object is outside the scope of this document.
在应用程序级别，建议在重构对象后对整个接收对象进行完整性检查，以确保其与发送对象相同，尤其是对于FDT实例的对象。此外，为了获得强大的密码完整性保护，应使用可由接收器验证的数字签名来提供此应用程序级完整性检查。但是，如果使用一个损坏或伪造的数据包来重建对象，则很可能会错误地重建接收到的对象。这将适当地导致完整性检查失败，在这种情况下，应丢弃不准确的重建对象。因此，接受单个伪造数据包可能是分发对象的有效拒绝服务攻击，但对象完整性检查至少可以防止无意中使用不准确的重构对象。接收对象的应用程序级完整性检查规范不在本文档范围内。
At the packet level, it is RECOMMENDED that a packet level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing FEC data for the object arriving from the specified sender. Packet level authentication has the advantage that corrupt or forged packets can be discarded
在数据包级别，建议使用数据包级别的身份验证，以确保每个接收到的数据包都是真实且未损坏的数据包，其中包含来自指定发送方的对象的FEC数据。数据包级身份验证的优点是可以丢弃损坏或伪造的数据包
individually and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial of service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work.
单独和接收到的经过身份验证的数据包可用于准确地重建对象。因此，注入伪造数据包的拒绝服务攻击的效果仅与伪造数据包的数量成正比，而与对象大小无关。尽管目前没有IETF标准规定如何进行多播数据包级认证，但TESLA[14]是一个已知的多播数据包认证方案，可以工作。
In addition to providing protection against reconstruction of inaccurate objects, packet level authentication can also provide some protection against denial of service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet level authentication be used to protect against such attacks. TESLA [14] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate.
除了针对不准确对象的重建提供保护外，数据包级身份验证还可以针对多速率拥塞控制上的拒绝服务攻击提供一些保护。攻击者可以尝试向多播流中注入带有不正确拥塞控制信息的伪造数据包，从而可能对攻击下游的网络元素和接收器产生不利影响，更不用说对网络其余部分和其他接收器产生不利影响了。因此，还建议使用数据包级身份验证来防止此类攻击。特斯拉[14]也可以在一定程度上用于限制此类攻击造成的损害。然而，对于特斯拉，接收器只能在接收到数据包几秒钟后确定数据包是否真实，因此对拥塞控制协议的攻击可以有效几秒钟，然后接收器才能做出反应以降低会话接收速率。
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
反向路径转发检查应在从发送方到接收方的所有网络路由器和交换机中启用，以限制坏代理将伪造数据包注入多播树数据路径的可能性。
A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.
具有多速率拥塞控制构建块的不正确或损坏的实现的接收器可能影响发送方和接收器之间路径中的网络健康，并且还可能影响加入会话的其他接收器的接收速率。因此，建议要求接收者在接收加入会话所需的会话描述之前将自己标识为合法。接收人如何认定自己合法不在本文件范围内。
Another vulnerability of FLUTE is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure
FLUTE的另一个漏洞是接收器可能获得不正确的会话描述。这可能导致具有错误会话描述的合法接收器无法正确接收会话内容，或者接收器无意中尝试以远高于其能力的速率接收，从而中断网络部分中的通信。为了避免这些问题，建议采取措施防止接收者接受不正确的会话描述，例如通过使用源身份验证来确保
that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
接收方只接受来自授权发送方的合法会话描述。如何做到这一点超出了本文件的范围。
No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by FLUTE does require IANA registration of the FEC codec used.
本规范中的任何信息均不直接受IANA注册的约束。但是，ALC使用的构建块组件可能会引入额外的IANA注意事项。特别是，FLUTE使用的FEC构建块确实需要对所使用的FEC编解码器进行IANA注册。
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen, and Lorenzo Vicisano. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification.
以下人员对本规范做出了贡献：Brian Adamson、Mark Handley、Esa Jalonen、Roger Kermode、Juha Pekka Luoma、Jani Peltotalo、Sami Peltotalo、Topi Pohjolainen和Lorenzo Vicisano。作者要感谢所有贡献者在审查和提供有关本规范的反馈方面所做的宝贵工作。
Normative References
规范性引用文件
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[2] Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[3] Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Handley，M.，和J.Crowcroft，“分层编码传输（LCT）构建块”，RFC 34512002年12月。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[4] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[5] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[5] Mills，D.，“网络时间协议（版本3）规范，实施”，RFC13051992年3月。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[6] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[7] Luby，M.和L.Vicisano，“紧凑前向纠错（FEC）方案”，RFC 3695，2004年2月。
[8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, May 2001.
[8] Thompson，H.，Beech，D.，Maloney，M.和N.Mendelsohn，“XML模式第1部分：结构”，W3C建议，2001年5月。
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001.
[9] Biron，P.和A.Malhotra，“XML模式第2部分：数据类型”，W3C建议，2001年5月。
Informative References
资料性引用
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[10] Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[12] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[13] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[14] Perrig, A., Canetti, R., Song, D., and J. Tygar, "Efficient and Secure Source Authentication for Multicast, Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46.", February 2001.
[14] Perrig，A.，Canetti，R.，Song，D.，和J.Tygar，“多播、网络和分布式系统安全研讨会的高效和安全源认证，NDSS 2001，第35-46页”，2001年2月。
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California", August 2001.
[15] Holbrook，H.，“多播的信道模型，博士论文，斯坦福大学，计算机科学系，斯坦福，加利福尼亚”，2001年8月。
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[16] Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[17] Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC 1952，1996年5月。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[18] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[19] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[19] Eastlake，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[20] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[20] Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 20481996年11月。
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November 1996.
[21] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 15211996年11月。
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: session initiation protocol", RFC 3261, June 2002.
[22] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
Appendix A. Receiver operation (informative)
附录A.接收器操作（资料性）
This section gives an example how the receiver of the file delivery session may operate. Instead of a detailed state-by-state specification the following should be interpreted as a rough sequence of an envisioned file delivery receiver.
本节给出了文件传递会话的接收者如何操作的示例。以下内容应解释为设想的文件交付接收者的大致顺序，而不是详细的逐州说明。
1. The receiver obtains the description of the file delivery session identified by the pair: (source IP address, Transport Session Identifier). The receiver also obtains the destination IP addresses and respective ports associated with the file delivery session.
1. 接收方获得由该对标识的文件传递会话的描述：（源IP地址，传输会话标识符）。接收器还获得与文件传递会话相关联的目标IP地址和相应端口。
2. The receiver joins the channels in order to receive packets associated with the file delivery session. The receiver may schedule this join operation utilizing the timing information contained in a possible description of the file delivery session.
2. 接收器加入信道以便接收与文件传递会话相关联的分组。接收器可利用包含在文件递送会话的可能描述中的定时信息来调度该加入操作。
3. The receiver receives ALC/LCT packets associated with the file delivery session. The receiver checks that the packets match the declared Transport Session Identifier. If not, packets are silently discarded.
3. 接收器接收与文件传递会话相关联的ALC/LCT数据包。接收方检查数据包是否与声明的传输会话标识符匹配。否则，数据包将被悄悄丢弃。
4. While receiving, the receiver demultiplexes packets based on their TOI and stores the relevant packet information in an appropriate area for recovery of the corresponding file. Multiple files can be reconstructed concurrently.
4. 在接收时，接收器基于分组的TOI来解复用分组，并将相关分组信息存储在适当的区域中以恢复相应的文件。可以同时重建多个文件。
5. Receiver recovers an object. An object can be recovered when an appropriate set of packets containing Encoding Symbols for the transport object have been received. An appropriate set of packets is dependent on the properties of the FEC Encoding ID and FEC Instance ID, and on other information contained in the FEC Object Transmission Information.
5. 接收器恢复一个对象。当接收到包含传输对象的编码符号的适当分组集时，可以恢复对象。适当的分组集合取决于FEC编码ID和FEC实例ID的属性，以及FEC对象传输信息中包含的其他信息。
6. If the recovered object was an FDT Instance with FDT Instance ID 'N', the receiver parses the payload of the instance 'N' of FDT and updates its FDT database accordingly. The receiver identifies FDT Instances within a file delivery session by the EXT_FDT header extension. Any object that is delivered using EXT_FDT header extension is an FDT Instance, uniquely identified by the FDT Instance ID. Note that TOI '0' is exclusively reserved for FDT delivery.
6. 如果恢复的对象是FDT实例ID为“N”的FDT实例，则接收器解析FDT实例“N”的有效载荷，并相应地更新其FDT数据库。接收方通过EXT_FDT头扩展名识别文件传递会话中的FDT实例。使用EXT_FDT头扩展交付的任何对象都是FDT实例，由FDT实例ID唯一标识。请注意，TOI“0”是专为FDT交付保留的。
7. If the object recovered is not an FDT Instance but a file, the receiver looks up its FDT database to get the properties described in the database, and assigns file with the given properties. The receiver also checks that received content length matches with the
7. 如果恢复的对象不是FDT实例而是文件，则接收器将查找其FDT数据库以获取数据库中描述的属性，并使用给定的属性分配文件。接收器还检查接收的内容长度是否与
description in the database. Optionally, if MD5 checksum has been used, the receiver checks that calculated MD5 matches with the description in the FDT database.
数据库中的描述。或者，如果使用了MD5校验和，则接收器检查计算出的MD5是否与FDT数据库中的描述匹配。
8. The actions the receiver takes with imperfectly received files (missing data, mismatching digestive, etc.) is outside the scope of this specification. When a file is recovered before the associated file description entry is available, a possible behavior is to wait until an FDT Instance is received that includes the missing properties.
8. 接收器对未完全接收的文件（数据丢失、不匹配等）采取的措施不在本规范的范围内。在关联的文件描述条目可用之前恢复文件时，可能的行为是等待接收到包含丢失属性的FDT实例。
9. If the file delivery session end time has not been reached go back to 3. Otherwise end.
9. 如果尚未达到文件传递会话结束时间，请返回3。否则就结束了。
Appendix B. Example of FDT Instance (informative)
附录B.FDT实例示例（资料性）
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl="http://www.example.com/flute"
xsi:schemaLocation="http://www.example.com/flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl="http://www.example.com/flute"
xsi:schemaLocation="http://www.example.com/flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
Authors' Addresses
作者地址
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
Toni Paila Nokia Itamerenkatu 11-13芬兰赫尔辛基FIN-00180
EMail: toni.paila@nokia.com
EMail: toni.paila@nokia.com
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 USA
迈克尔·鲁比数字喷泉39141美国加利福尼亚州弗里蒙特市公民中心博士套房300号94538
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18坦佩雷FIN-33100芬兰
EMail: rami.lehtonen@teliasonera.com
EMail: rami.lehtonen@teliasonera.com
Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe Montbonnot St Ismier cedex 38334 France
文森特·罗卡在罗纳阿尔卑斯山脉655号，av。欧洲蒙博诺圣伊斯梅尔塞德克斯法国38334
EMail: vincent.roca@inrialpes.fr
EMail: vincent.roca@inrialpes.fr
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
罗德·沃尔什诺基亚Visiokatu 1坦佩雷FIN-33720芬兰
EMail: rod.walsh@nokia.com
EMail: rod.walsh@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。