[要約] RFC 3926は、FLUTE（File Delivery over Unidirectional Transport）プロトコルに関するものであり、大容量ファイルの効率的な配信を目的としています。このプロトコルは、信頼性のある単方向トランスポート上でのファイル配信を実現するための仕様を提供しています。
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）The Internet Society（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を定義します。これは、マルチキャストネットワークに特に適しています。この仕様は、非常にスケーラブルなマルチキャスト分布用に設計されたベースプロトコルである非同期層コーディングに基づいています。
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
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.
このドキュメントでは、インターネット上のファイルの単方向配信のプロトコルであるフルートバージョン1を定義しています。この仕様は、非同期層コーディング（ALC）、バージョン1 [2]、大規模なマルチキャスト分布用に設計された基本プロトコルに基づいています。ALCは、任意のバイナリオブジェクトの輸送を定義します。ただし、ファイル配信アプリケーションの場合、オブジェクトの単なる輸送では十分ではありません。最終システムは、オブジェクトが実際に表すものを知る必要があります。このドキュメントは、Fluteと呼ばれる手法を指定します。これは、受信オブジェクトに受信機がそれらのパラメーターを割り当てることができるように、ファイルのプロパティを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は、フルートによるファイル配信に関するセキュリティ上の考慮事項の概要を示しています。最後に、2つの有益な付録があります。最初の付録では、ファイル配信セッションの受信機の想定される受信機操作について説明します。2番目の付録は、ファイル配信テーブルの例を示しています。
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.
上記の条件が満たされるとすぐに、この仕様をIETF提案標準として再提出することは、RMTの意図です。
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 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.
フルートは、数秒以上の配達セッションを使用して、多くのホストへの大小のファイルの配信に適用できます。たとえば、フルートは、多くのホストに同時に大規模なソフトウェアアップデートを提供するために使用できます。また、連続しているがセグメント化された字幕のための時間並んだテキストなどのデータを使用することもできます。これは、ALCとLCTからのレイヤー化継承を潜在的に活用して、セッションの豊かさをネットワークの輻輳状態に拡大する可能性があります。また、メタデータ、たとえばユーザーアプリケーションがマルチメディアセッションにアクセスできるようにする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は、IPマルチキャストの固有のスケーラビリティを犠牲にすることなく、ALCおよび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 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は、LAN、WAN、イントラネット、インターネット、非対称ネットワーク、ワイヤレスネットワーク、衛星ネットワークなど、あらゆる種類のネットワークで本質的に動作します。
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].
フルートは、パケットの一部がIPバージョンに固有のものではないため、IPv4またはIPv6の両方と互換性があります。フルートは、任意のソースマルチキャスト（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.
フルートは、適切な輻輳制御ビルディングブロックを備えたインターネット使用の両方に適用できます。また、ワイヤレスブロードキャストラジオシステムを介した配信などのプロビジョニング/制御システムです。
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 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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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はフルートの基本輸送を提供するため、フルートは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.
例として、「http://www.example.com/docs/file.txt」で言及されている5200バイトファイルを考えてみましょう。この例を使用して、次のプロパティは、ファイル配信プロトコルによって伝達される必要があるプロパティを説明しています。
* 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/ file.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 Media Typeとして表現されたファイルタイプ（通常、これはファイル名の拡張機能からも結論付けることができます）。上記の例では、「テキスト/プレーン」。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セッションは、1つ以上のオブジェクトの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ヘッダーで運ばれるフィールドの1つは、トランスポートセッション識別子（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 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アドレスを割り当てられていない場合、その代わりに、送信者が送信したパケットの一時的なIPアドレスを含むレシーバーが受信できるパケットを割り当てた場合、TSIは送信者のこの一時的なIPアドレスによってスコープされますセッションの期間。例として、送信者は、受信機がアクセスできる送信者に一時的にIPアドレスを割り当てるネットワークアドレス変換（NAT）デバイスの背後にある場合があります。受信者が受信したパケットに表示されます。別の例として、送信者は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を携帯してはなりません。CloseセッションフラグのLCT定義については、RFC 3451 [3]のセクション5.1 [3]を参照し、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データパケットがどのファイルに関する情報を含むかを決定する方法です。各ファイルの説明エントリには、上記の属性をファイルにマッピングする1つ以上の記述子が含まれる場合があります。
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 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.
各ファイル配信セッションには、指定されたセッションにローカルのFDTが必要です。FDTは、セッション内に表示されるファイルごとにTOIにマッピングされたファイル説明エントリを提供する必要があります。ALCセッション内で配信されるが、FDTで説明されていないオブジェクトは、ファイル配信セッションに属する「ファイル」とは見なされません。これらのマップされていない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の1つ以上のファイル説明エントリが含まれています。任意のFDTインスタンスは、他のFDTインスタンスのサブセット、スーパーセット、または補完するものに等しくなります。後続のFDTインスタンス（FDTインスタンスID番号が高い）が送信された後でも、セッション中に特定のFDTインスタンスを数回繰り返すことができます。各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.
* ファイル配信セッション内で配信されるすべてのファイルについて、セッション内に送信された少なくとも1つの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とフルートの範囲外です。
* 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).
* 送信者は、送信者の現在の時間（SCT）に比べてFDTインスタンスを作成すると、将来有効期限を使用する必要があります。
* 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インスタンスの送信に使用できます。デフォルトは、FDTインスタンスの送信にFECエンコードID 0を使用することです。（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 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インスタンスを受信する必要があります。この意味で、FDTインスタンスはファイルよりも優先されます。したがって、ファイルを記述するFDTインスタンスは、セッション内で少なくとも多くの信頼性（より頻繁に、またはより多くのFEC保護）を記述するファイルと同じくらい多くの信頼性で送信することをお勧めします。特に、FDTインスタンスが長さのパケットペイロードを1つ以上長くする場合、損失に対する保護を提供するFECコードをFDTインスタンスの提供に使用することをお勧めします。ファイルの説明がFDTインスタンスで送信される頻度または各FDTインスタンスにFEC保護の量（FDTインスタンスが1つのパケットペイロードより長い場合）は、特定のアプリケーションとこのドキュメントの範囲外に依存します。
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が続き、最後に1つ以上のファイル説明エントリを含むFDTインスタンスのエンコードシンボルが続きます。FDTインスタンスはいくつかのALCパケットにまたがる場合があります - ALCパケットの数は、FDTインスタンスに関連付けられたファイル属性の関数です。FDTインスタンスヘッダーは、FDTインスタンスを運ぶ各ALCパケットで運ばれます。FDTインスタンスヘッダーは、特定のFDTインスタンスのすべてのALC/LCTパケットと同じです。
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.
FDTインスタンスを運ぶALC/LCTパケットの全体的な形式を、以下の図1に示します。すべての整数フィールドは、「ビッグエンディアン」または「ネットワーク注文」形式で運ばれます。つまり、最も重要なバイト（オクテット）です。[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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
各ファイル配信セッションのFDTインスタンスの番号は「0」から始まり、その後のFDTインスタンスごとに1つずつ増加します。最大値（2^20-1）に達した後、番号付けは「0」から再び開始されます。2^20-1から0のラップアラウンドが発生すると、0は2^20-1を超えると見なされます。ラップアラウンドのために以前のFDTインスタンスID番号を再利用する新しいFDTインスタンスは、同じIDで以前のFDTインスタンスを暗黙的に期限切れにしない場合があります。フルート送信者は、同じIDを使用して以前のFDTインスタンスが期限切れになった後、ラップアラウンドIDを使用してFDTインスタンスのみを構築および配信することが合理的です。ただし、FDTインスタンスIDラップアラウンドおよびその他の特別な状況（たとえば、FDTインスタンスIDが欠落しているため、1よりも大きな増分になる）を処理するための必須の受信者動作は、この仕様の範囲外で、フルートの個々の実装に任されています。
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インスタンスは、単一のルート要素「FDTインスタンス」を持つXML構造です。「FDTインスタンス」要素には、「有効期限」属性を含める必要があります。これにより、FDTインスタンスの有効期限がわかります。さらに、「FDT-Instance」要素には、「完全な」属性（boolean）が含まれている場合があります。これは、このセッション内の将来のFDTインスタンスで新しいデータが提供されないことを示しています（つまり、FDTインスタンスが高い場合のどちらかのFDTインスタンスがID番号は使用されないか、使用されている場合は、これと以前のFDTインスタンスで既に与えられたものと同じファイルパラメーターのみを提供します）。たとえば、これは、フルートセッション全体（「完全な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-Instance」要素には、FDTインスタンスのすべてのファイルに共通のパラメーターを提供する属性が含まれる場合があります。これらの属性は、「ファイル」要素内の個々のファイルに対しても提供される場合があります。「FDT-Instance」と「ファイル」要素の両方に同じ属性が表示される場合、「ファイル」要素で提供される属性の値が優先されます。
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インスタンスに単一のファイル説明エントリがあります。各エントリは、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構造の「ファイル」要素の属性は、ファイル配信セッションで配信されるファイルに与えられた属性を表します。XML属性名の値はMIMEフィールド名に対応し、XML属性値はMIMEフィールドボディの値に対応します。各「ファイル」要素には、少なくとも2つの属性「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タイプが記載されている場合、[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メッセージダイジェストが記載されている場合、[6]で定義されているように、属性「Content-MD5」を目的に使用する必要があります。
* The FEC Object Transmission Information attributes as described in section 5.2.
* セクション5.2で説明されているFECオブジェクト伝送情報属性。
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>
<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"
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スキーマが新しい記述子の観点から拡張されている場合、単一のファイルに適用する属性の場合、それらは要素「ファイル」の属性内に配置する必要があります。現在のFDTインスタンスで説明されているすべてのファイルに適用される属性の場合、それらは要素「FDT-Instance」内に配置する必要があります。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 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:
FDTインスタンス自体は、たとえば圧縮されたコンテンツエンコードされている場合があります。この仕様では、FDTインスタンスコンテンツをエンコードヘッダー（Ext_Cenc）を定義します。ext_cencは、新しい固定長、ALC PI固有のLCTヘッダー拡張です[3]。拡張機能のヘッダーエクステンションタイプ（HET）は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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インスタンスを含むこれらすべてのオブジェクトは、セッション内で任意の順序で互いに並行して多重化される場合があります。つまり、1つのファイルのパケットは、セッション内の他のファイルまたは他の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を使用して、1回のセッションで複数のFDTインスタンスを配信できます。この場合、次のFDTインスタンスの送信が開始される前に、以前のFDTインスタンスの送信が終了することをお勧めします。ただし、予期しないネットワーク条件により、FDTインスタンスのパケットがインターリーブされる場合があります。受信者は、FDTインスタンスがext_FDTヘッダーに掲載されたFDTインスタンスIDによって一意に識別されるため、パケットにどのFDTインスタンスが含まれているかを決定できます。
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
ALC/LCTには、チャネルと輻輳制御の概念があります。フルートが適用されると想定される4つのシナリオがあります。
(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）のように、ファイル配信セッションに1つのチャネルのみを使用する場合、「前」と「後」の概念は、配信時間に関してオブジェクトの配信のために直感的に定義されます。
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）のように複数のチャネルが使用されている場合、オブジェクトが他のチャネルに「前」に配信されたと述べるのは簡単ではありません。オブジェクトは、2番目のオブジェクトの配信が開始される前に、これらのチャネルの1つ以上で配信され始める場合があります。ただし、複数のチャネル/レイヤーを使用すると、最初のチャネル前に2番目のオブジェクトの配信が完了する場合があります。これは、1つのチャネルを使用してオブジェクトが連続的に配信される場合、問題ではありません。したがって、フルートの適用に、最初のトランスポートオブジェクトが2番目のオブジェクトに「以前」を完了する必要があるという必須または重要な要件がある場合、ファイル配信セッションには単一のチャネルのみが使用されることをお勧めします。
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 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.
1. FDTインスタンスのパケットが送信されるレイヤーは、低レートレシーバーが結合されないレイヤーに偏ってはなりません。たとえば、FDTインスタンスのすべてのパケットを最小レイヤーに配置しても構いません（このレイヤーが適切な時間で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インスタンスが一般に長さの1つのエンコードシンボルよりも長く、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.
フルートは、ALCからのFECビルディングブロック[4]の使用を継承します。ALCを介したファイル配信にフルートを使用する場合、FECオブジェクト伝送情報は、ファイル配信セッション内でバンド内で配信する必要があります。このセクションでは、この目的のためにフルートに2つの方法を指定します。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オブジェクト伝送情報の配信をサポートする必要があります。。
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.
受信機に配信する必要があるFECオブジェクトトランスミッション情報は、ext_ftiを使用するか、FDT（またはその両方）を使用して配信されるかどうかにかかわらず、まったく同じでなければなりません。セクション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パケットが含まれているかを決定するために、個々の実装に任されます。パケット損失率が高い環境では、ext_ftiは、誤差確率が低い環境よりもALCパケットに頻繁に含める必要がある場合があります。ext_ftiは、FDTインスタンスごとに少なくとも1つの送信された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.
フルートでは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
ヘッダーエクステンションタイプ（HET）、8ビット：
64 as defined in [2].
[2]で定義されている64。
Header Extension Length (HEL), 8 bits: 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.
ヘッダー拡張長（HEL）、8ビット：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に依存します。次のセクションでは、ID番号0、128、129、および130をエンコードするFECのこのフィールドの構造を指定します。
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のID固有のFECをエンコードする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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ID 0、128、130のFECをエンコードする場合、このアルゴリズムは、受信者が各ソースブロックの長さを決定できる唯一の知られている方法です。したがって、アルゴリズムは次の2つのことを行います。（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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,
このアルゴリズムは、ソースブロック構造を計算して、すべてのソースブロックが可能な限り等しい長さに近づくようにします。ソースブロックの最初の数は同じ長さで、残りの2番目のソースブロックの数は同じ長さで送信されます。ソースブロックの総数（n）、ソースブロックの最初の数（i）、ソースブロックの2番目の数（n-i）、より大きな長さ（a_large）、およびより小さな長さ（a_small）が計算されます。
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-最大ソースブロック長、つまりソースブロックごとのソース記号の最大数 - バイトの転送長 - バイトのシンボル長をエンコードする
Output: N -- The number of source blocks into which the transport object is partitioned.
出力：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（これは非integerである可能性があります）（d）a_large = a最寄りの整数に丸められている（常にa_largeの値がせいぜいbであることがある）それ以外の場合は、a_small = a_large -1）（f）aの分数部分、a_fraction = a -a_small（g）i = a_fraction * n（iは0からn -1の間の整数です）（h）ソースブロックは、A_LARGEソースシンボルで構成され、各ソースシンボルは長さのEバイトです。残りのn-iソースブロックのそれぞれは、a_smallソースシンボルで構成されています。各ソースシンボルは長さの長さです。整数）*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.
* 「トランスファーレングス」は、ext_ftiのフィールド「転送長」と意味的に同等です。
* "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ヘッダーのコードポイントフィールドにあるフィールド「FECエンコード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インスタンス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-OTI-MAXIMUM-SOURCE-BLOCK-LENGTH」は、IDS 0、128、および130をエンコードするFECのext_ftiのフィールド「最大ソースブロック長」と意味的に同等であり、フィールド「最大ソースブロック長」のフィールド「最大ソースブロック長」と意味的に同等です。ID 129のFECエンコードの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-OTI-ENCODING-SYMBOL-LENGTH」は、IDS 0、128、129、および130をコードするFECの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-Max-Number-of-Encoding-Symbols」は、FEC Encoding 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およびFECインスタンスIDデフォルトのFECエンコードID 0がFDTの配信には使用されていない場合。
* 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]に適用および説明されているセキュリティ上の考慮事項も、フルートに適用されます。さらに、フルートに関連して使用される混雑制御ビルディングブロックに適用されるセキュリティ上の考慮事項もフルートに適用されます。
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 attack because many receivers may receive the same forged packet. A malicious attacker may spoof file packets and cause incorrect recovery of a file.
FECの使用により、フルートは攻撃者によるサービス拒否攻撃に対して特に脆弱であり、セッションに偽造パケットを送信しようとするため、再構成の成功を妨げたり、受信者によるFDTまたはファイルの大部分の不正確な再構築を引き起こします。ALCと同様に、多くのレシーバーが同じ鍛造パケットを受け取る可能性があるため、フルートは特にそのような攻撃の影響を受けます。悪意のある攻撃者は、ファイルパケットをスプーフィングし、ファイルの誤った回復を引き起こす可能性があります。
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].
さらに有害なことに、悪意のあるForgerはFDTインスタンスパケットをスプーフィングする可能性があります。たとえば、誤ったFDTインスタンスフィールドでパケットを送信します。多くの攻撃はこのアプローチに従うことができます。たとえば、悪意のある攻撃者は、toi 'n'のコンテンツロケーションフィールドを変更して、システムファイルまたはユーザー構成ファイルを指す場合があります。次に、toi 'n'はトロイの木馬または他のタイプのウイルスを運ぶことができます。したがって、レシーバーのフルート配信サービスには、システムファイルまたはディレクトリ、またはその他の重要な領域への書き込みアクセスがないことを強くお勧めします。MIME [20] [21]で説明されているように、受信者の環境でのアクションのリモート実行を引き起こす可能性のある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.
別の例は、不良なコンテンツ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インスタンスであるオブジェクトの場合、送信オブジェクトと同じであることを確認するために、オブジェクトが再構築されたら、受信オブジェクト全体の整合性チェックを実行することをお勧めします。さらに、強力な暗号整合性保護を取得するには、受信機が検証可能なデジタル署名を使用して、このアプリケーションレベルの整合性チェックを提供する必要があります。ただし、オブジェクトを再構築するために破損したパケットまたは偽造パケットが1つさえ使用されている場合、受信オブジェクトが誤って再構築される可能性があります。これにより、整合性チェックが適切に失敗し、この場合、不正確に再構築されたオブジェクトを破棄する必要があります。したがって、単一の鍛造パケットの受け入れは、オブジェクトを配布するための効果的なサービス拒否攻撃になる可能性がありますが、オブジェクトの整合性チェックは、少なくとも不正確に再構築されたオブジェクトの不注意な使用を防ぎます。受信したオブジェクトのアプリケーションレベルの整合性チェックの仕様は、このドキュメントの範囲外です。
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 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.
パケットレベルでは、パケットレベルの認証を使用して、受信した各パケットが、指定された送信者から到着するオブジェクトのFECデータを含む本物で腐敗していないパケットであることを確認することをお勧めします。パケットレベルの認証には、破損したパケットまたは偽造パケットを個別に破棄できるという利点があり、受信した認証されたパケットを使用してオブジェクトを正確に再構築できます。したがって、鍛造パケットを注入するサービス拒否攻撃の効果は、オブジェクトサイズではなく、偽造パケットの数にのみ比例します。現在、マルチキャストパケットレベルの認証を行う方法を指定する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.
不正確なオブジェクトの再構築に対する保護を提供することに加えて、パケットレベル認証は、複数のレートの輻輳制御に対するサービス拒否攻撃に対するある程度の保護を提供することもできます。攻撃者は、誤った混雑制御情報をマルチキャストストリームに誤ったパケットを注入しようとすることができます。これにより、攻撃の下流のネットワーク要素やレシーバーに潜在的に悪影響を及ぼし、ネットワークやその他のレシーバーの残りの部分にはそれほど有意ではありません。したがって、パケットレベル認証を使用して、そのような攻撃から保護することもお勧めします。Tesla [14]は、そのような攻撃によって引き起こされる損害を制限するために、ある程度使用することもできます。ただし、Teslaでは、受信機が受信してから数秒後にパケットが本物であるかどうかを判断することができるため、受信機が反応してセッション受信率を遅くすることができるようになる前に、渋滞制御プロトコルに対する攻撃は数秒間有効になります。
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 that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
フルートのもう1つの脆弱性は、セッションのセッションの説明が誤っている可能性があることです。この結果、セッションの説明が間違っている正当な受信者がセッションコンテンツを正しく受信できないこと、または受信者が誤って能力よりもはるかに高いレートで受け取ることを試み、それによりネットワークの一部のトラフィックを破壊することです。これらの問題を回避するために、レシーバーが誤ったセッションの説明を受け入れるのを防ぐための措置を講じることをお勧めします。これがどのように行われるかは、このドキュメントの範囲外です。
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の考慮事項を導入する場合があります。特に、フルートで使用される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.
次の人がこの仕様に貢献しています：ブライアン・アダムソン、マーク・ハンドリー、エサ・ジャロネン、ロジャー・ケルモード、ジュハ・ペッカ・ルーマ、ジャニ・ペルトタロ、サミ・ペルトタロ、トピ・ポージョラニン、ロレンツォ・ヴィジサノ。著者は、この仕様に関するフィードバックをレビューし、提供する際の貴重な仕事について、すべての貢献者に感謝したいと思います。
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 3451、2002年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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 3452、2002年12月。
[5] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[5] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、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。and N. Mendelsohn、「XML Schemaパート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 Schema Part 2：DataTypes」、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 2974、2000年10月。
[12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[12] Handley、M。and 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、pp。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。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、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。、「Secure/Multipurpose Internet Mail拡張機能（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-Signature構文と処理」、RFC 3275、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）パート4：登録手順」、RFC 2048、1996年11月。
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November 1996.
[21] ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCIIテキストのメッセージヘッダー拡張機能」、RFC 1521、1996年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：SESSION INIATIATION Protocol"、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インスタンスIDによって一意に識別されるFDTインスタンスです。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 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.
7. 回復したオブジェクトがFDTインスタンスではなくファイルである場合、受信者はFDTデータベースを調べてデータベースに記載されているプロパティを取得し、特定のプロパティでファイルを割り当てます。また、受信者は、データベースの説明とコンテンツの長さの一致を受け取ったチェックもチェックします。オプションでは、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>
Authors' Addresses
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
トニ・パイラ・ノキア・イタメレンカトゥ11-13ヘルシンキフィン-00180フィンランド
EMail: toni.paila@nokia.com
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 USA
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont、CA 94538 USA
EMail: luby@digitalfountain.com
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland
ラミ・レートネン・テリアソネラ・ハタンパン・ヴァルタティティ18タンペレフィン-33100フィンランド
EMail: rami.lehtonen@teliasonera.com
Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe Montbonnot St Ismier cedex 38334 France
Vincent Roca Inria Rhone-Alpes 655、av。de l'uteol montbonnot st ismier cedex 38334フランス
EMail: vincent.roca@inrialpes.fr
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
ロッド・ウォルシュ・ノキア・ヴィジオカトゥ1タンペレフィン-33720フィンランド
EMail: rod.walsh@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。