[要約] RFC 3926は、単方向（一方向）のマルチキャスト通信において、任意のファイルを効率的かつ確実に配信するためのプロトコル「FLUTE (File Delivery over Unidirectional Transport)」の仕様を定義しています。LCTトランスポートおよびFEC（前方誤り訂正）ビルディングブロックを基盤とし、ファイルメタデータ（FDT）の伝達やパケット化手順を規定しています。衛星放送やモバイル放送（DVB-H等）などの環境において、多数の受信者に対して一斉にファイルを配布するための標準的な手段を提供することを目的としています。
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
FLUTE: 単方向トランスポートによるファイル配信
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).
Copyright (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を定義します。FLUTEは、特にマルチキャストネットワークに適しています。この仕様は、大規模なマルチキャスト配信を目的に設計された基盤プロトコルである非同期レイヤ符号化（ALC）に基づいています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. はじめに .......................................................2
1.1. Applicability Statement . . . . . . . . . . . . . . . . 3
1.1. 適用範囲 .................................................3
1.1.1. The Target Application Space . . . . . . . . . . 3
1.1.1. 想定するアプリケーション領域 .....................3
1.1.2. The Target Scale . . . . . . . . . . . . . . . . 4
1.1.2. 目標スケール .....................................4
1.1.3. Intended Environments . . . . . . . . . . . . . 4
1.1.3. 意図された環境 ...................................4
1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . 4
1.1.4. 弱点 .............................................4
2. Conventions used in this Document. . . . . . . . . . . . . . . 5
2. この文書で使用する規約 .........................................5
3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ファイル配信 ...................................................5
3.1. File delivery session . . . . . . . . . . . . . . . . . 6
3.1. ファイル配信セッション ...................................6
3.2. File Delivery Table. . . . . . . . . . . . . . . . . . . 8
3.2. ファイル配信テーブル .....................................8
3.3. Dynamics of FDT Instances within file delivery session . 9
3.3. ファイル配信セッション内のFDTインスタンスの動作
3.4. Structure of FDT Instance packets. . . . . . . . . . . . 11
3.4. FDTインスタンスパケットの構造 ...........................11
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.5. Multiplexing of files within a file delivery session . . 17
4. Channels, congestion control and timing . . . . . . . . . . . 18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
Informative References . . . . . . . . . . . . . . . . . . . . 30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
3.4.1. Format of FDT Instance Header . . . . . . . . . 12
3.4.1. FDTインスタンスヘッダーの形式 ...................12
3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . 13
3.4.2. FDTインスタンスの構文 ...........................13
3.4.3. Content Encoding of FDT Instance . . . . . . . . 16
3.4.3. FDTインスタンスのコンテンツエンコーディング .....16
3.5. Multiplexing of files within a file delivery session . . 17
3.5. ファイル配信セッション内でのファイルの多重化 ............17
4. Channels, congestion control and timing . . . . . . . . . . . 18
4. チャネル、輻輳制御、タイミング ................................18
5. Delivering FEC Object Transmission Information . . . . . . . . 19
5. FECオブジェクト伝送情報の配信 .................................19
5.1. Use of EXT_FTI for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 20
5.1. FECオブジェクトトランスミッション情報の配信のためのEXT_FTIの使用 ..20
5.1.1. General EXT_FTI format . . . . . . . . . . . . . 20
5.1.1. 一般的なEXT_FTI形式 .............................20
5.1.2. FEC Encoding ID specific formats for EXT_FTI . . 21
5.1.2. EXT_FTI用のFECエンコードID固有の形式 ............21
5.2. Use of FDT for delivery of FEC Object Transmission
Information. . . . . . . . . . . . . . . . . . . . . . . 25
5.2. FECオブジェクト伝送情報の配信にFDTを使用する方法 ........25
6. Describing file delivery sessions. . . . . . . . . . . . . . . 25
6. ファイル配信セッションの説明 ..................................25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. セキュリティに関する考慮事項 ..................................26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. IANAの考慮事項 ................................................29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
9. 謝辞 ..........................................................29
Normative References . . . . . . . . . . . . . . . . . . . . . 29
規範的な参考文献 ..............................................29
Informative References . . . . . . . . . . . . . . . . . . . . 30
Informative References ........................................30
A. Receiver operation (informative) . . . . . . . . . . . . . . . 32
A. 受信側の動作例（情報提供） ....................................32
B. Example of FDT Instance (informative). . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
B. FDTインスタンスの例（情報提供） ...............................34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 35
著作権に関する声明 ............................................35
This document defines FLUTE version 1, a protocol for unidirectional delivery of files over the Internet. The specification builds on Asynchronous Layered Coding (ALC), version 1 [2], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications mere transport of objects is not enough, however. The end systems need to know what the objects actually represent. This document specifies a technique called FLUTE - a mechanism for signaling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Consequently, throughout this document the term 'file' relates to an 'object' as discussed in ALC. Although this specification frequently makes use of multicast addressing as an example, the techniques are similarly applicable for use with unicast addressing.
この文書では、インターネット上でファイルを一方向に配信するプロトコルであるFLUTEバージョン1を定義します。この仕様は、大規模なマルチキャスト配信を目的に設計された基盤プロトコル、非同期レイヤ符号化（ALC）バージョン1 [2] に基づいています。ALCは任意のバイナリオブジェクトを転送しますが、ファイル配信アプリケーションでは、オブジェクトを転送するだけでは不十分です。エンドシステムは、オブジェクトが何を表しているのかを知る必要があります。この文書では、ファイルの属性をALCの概念に対応付けて通知し、受信側が受信したオブジェクトにそれらの属性を割り当てられるようにする仕組み、FLUTEを規定します。したがって、この文書では「ファイル」を、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では、FLUTEにおける輻輳制御とチャネルの使用を説明します。セクション5では、ファイル配信セッション内でFEC（前方誤り訂正）オブジェクト伝送情報を配信する方法を定めます。セクション6では、一般的なファイル配信セッションの記述に必要なパラメーターを定めます。セクション7では、FLUTEによるファイル配信のセキュリティ上の考慮事項を示します。最後に、情報提供を目的とする付録が2つあります。付録Aではファイル配信セッションの受信側の動作例を示し、付録Bではファイル配信テーブルの例を示します。
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.
このメモには、RFC 2357に従って信頼性のあるマルチキャストトランスポートプロトコルを完全に規定するために必要な定義の一部が含まれています。RFC 2357によれば、インターネットで信頼性のあるマルチキャストプロトコルを使用するには、適切な輻輳制御方式が必要です。
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）は、この仕様を「実験的」カテゴリのRFCとして公開します。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMTは、上記の条件が満たされ次第、この仕様をIETFの提案標準として再提出する意向です。
FLUTE is applicable to the delivery of large and small files to many hosts, using delivery sessions of several seconds or more. For instance, FLUTE could be used for the delivery of large software updates to many hosts simultaneously. It could also be used for continuous, but segmented, data such as time-lined text for subtitling - potentially leveraging its layering inheritance from ALC and LCT to scale the richness of the session to the congestion status 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.
FLUTEは、数秒以上の配信セッションを使って、多数のホストに大小さまざまなファイルを配信する用途に適しています。たとえば、多数のホストに大規模なソフトウェア更新を同時に配信できます。また、字幕用の時間情報付きテキストなど、連続しているものの分割されたデータの配信にも利用できます。この用途では、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.
大規模な拡張性は、FLUTEの主要な設計目標です。IPマルチキャストは本質的に大規模な配信に適していますが、提供されるベストエフォート型サービスには、セッション管理機能、輻輳制御、信頼性がありません。FLUTEはALCとIPマルチキャストを利用してこれらを提供しながら、IPマルチキャスト本来の拡張性を損ないません。
All of the environmental requirements and considerations that apply to the ALC building block [2] and to any additional building blocks that FLUTE uses also apply to FLUTE.
ALCビルディングブロック[2]およびフルートが使用する追加のビルディングブロックに適用されるすべての環境要件と考慮事項もフルートに適用されます。
FLUTE 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では送信者から受信者への接続性が必要ですが、受信者から送信者への接続性は必要ありません。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バージョンに依存しないため、FLUTEはIPv4とIPv6のどちらにも対応します。また、FLUTEはAny-Source Multicast（ASM）[13] とSource-Specific Multicast（SSM）[15] の両方のマルチキャストモデルで動作します。
FLUTE is applicable for both Internet use, with a suitable congestion control building block, and provisioned/controlled systems, such as delivery over wireless broadcast radio systems.
FLUTEは、適切な輻輳制御ビルディングブロックを備えたインターネット環境と、無線ブロードキャストによる配信など、帯域が確保され制御されたシステムの両方に適用できます。
Some networks are not amenable to some congestion control protocols that could be used with FLUTE. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
FLUTEで使用できる輻輳制御プロトコルに適さないネットワークもあります。特に衛星ネットワークや無線ネットワークでは、セッションに固定の送信レートが割り当てられている場合があり、受信者が受信レートを効果的に下げる手段がないことがあります。
FLUTE provides reliability using the FEC building block. This will reduce the error rate as seen by applications. However, FLUTE does not provide a method for senders to verify the reception success of receivers, and the specification of such a method is outside the scope of this document.
FLUTEはFECビルディングブロックを使って信頼性を高め、アプリケーションから見た誤り率を下げます。ただし、送信者が受信者による受信の成功を確認する方法は提供しません。そのような方法の規定は、この文書の範囲外です。
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].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "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はFLUTEの基本的なトランスポートを提供するため、FLUTEは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.
例として、URI「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メディアタイプで表すファイル種別（通常はファイル名の拡張子からも判別できます）。上記の例では「text/plain」です。MIMEタイプがファイル拡張子とは別に明示され、その値が拡張子から推定されるMIMEタイプと異なる場合は、明示された値をMIMEタイプとして使用しなければなりません (MUST)。
* 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] を使ってファイルをエンコードできます。この場合、ファイルを格納するトランスポートオブジェクトのサイズは、元のファイルサイズと異なることがあります。トランスポートオブジェクトのサイズは、FLUTEプロトコルの一部として受信者に伝達されます。
* 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] を使ったり、FDTインスタンスにデジタル署名を付ける際にXML-DSIG [19] を使ったりできます。
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は、Layered Coding Transportビルディングブロック（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）の組がセッションを一意に識別します。つまり、受信者は各パケットに含まれるこの組を使って、パケットがどのセッションから届いたかを識別します。1つのセッションで複数のオブジェクトを転送する場合、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アドレスの範囲内で識別されます。たとえば、送信者がNAT（ネットワークアドレス変換）装置の背後にあり、その装置が受信者から到達可能な一時IPアドレスを送信者に割り当てる場合、TSIはNATが割り当て、受信パケットに現れるIPアドレスの範囲内で識別されます。別の例として、送信者がIPv6でパケットを送信しても、ネットワークの一部がIPv6に対応していないため、IPv6/IPv4変換器がパケットの送信元IPアドレスを別のIPv4アドレスに変換する場合があります。この場合、ネットワークのIPv4部分にいる受信者にはそのIPv4アドレスを含むパケットが届くため、TSIはそのIPv4アドレスの範囲内で識別されます。固定アドレスか一時アドレスかを問わず、セッション識別に使う送信者の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.
* FLUTEセッション内で送信するALCパケットにはTOIフィールドを含めなければなりません (MUST)。ただし、セッション終了を通知するClose Session (A) フラグを1に設定し、ペイロードを含まない（ファイルやFDTの情報を運ばない）ALCパケットにはTOIを含めてはなりません (MUST NOT)。Close SessionフラグのLCTでの定義はRFC 3451 [3] のセクション5.1を、ALCパケットでの使用例はRFC 3450 [2] のセクション4.2を参照してください。
* The TOI value '0' is reserved for delivery of File Delivery Table Instances. Each File Delivery Table Instance is uniquely identified by an FDT Instance ID.
* TOI値 '0'は、ファイル配信テーブルインスタンスの配信のために予約されています。各ファイル配信テーブルインスタンスは、FDTインスタンスIDによって一意に識別されます。
* Each file in a file delivery session MUST be associated with a TOI (>0) in the scope of that session.
* ファイル配信セッションの各ファイルは、そのセッションの範囲内のTOI（> 0）に関連付けられていなければなりません (MUST)。
* 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 Instance 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.
これらの属性のうち、ファイルの説明エントリに含めなければならないもの (MUST) と、任意のものがあります。詳細はセクション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を含めなければなりません (MUST)。ファイルの配信中、各ALC/LCTデータパケットにはTOIが含まれます。受信者は、説明エントリの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がなければなりません (MUST)。FDTには、セッション内で配信する各ファイルについて、TOIに対応付けられたファイル説明エントリを含めなければなりません (MUST)。ALCセッション内で配信されてもFDTに記述されていないオブジェクトは、ファイル配信セッションに属する「ファイル」とは見なされません。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 Instance 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データベースを持つと想定すべきではありません (SHOULD NOT)。
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データベースは抽象的な概念であるため、その構造と管理方法は個々の実装に委ねられており、この仕様の範囲外です。
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インスタンスにファイルの説明エントリが含まれなければなりません (MUST)。ファイルの説明エントリには、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インスタンスはファイル配信セッションのどの時点でも送信できます (MAY)。FDTインスタンスのパケットは、セッション内の他のファイルや他のFDTインスタンスのパケットと交互に送信できます (MAY)。
* 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インスタンスの配信のために予約しなければなりません (MUST)。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を含めなければなりません (MUST)。
* 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インスタンスは、そのファイルをファイル配信セッション内で送信する前に送信することが推奨されます (SHOULD)。
* 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を複数回記述してもかまいません (MAY)。たとえば、先行するFDTインスタンス0がTOI「3」を記述している場合、後続のFDTインスタンスでは、TOI「3」の記述を変更せずに維持する、記述を省略する、または情報を補完できます。ただし、後続のFDTインスタンスは、特定のTOIについてすでに記述されたパラメーターを変更してはなりません (MUST NOT)。
* 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ビットのNetwork Time Protocol（NTP）[5] 時刻値の上位32ビットです。この32ビット値は、1900年1月1日0時を起点とする秒数を表す符号なし整数です。32ビット時刻値のラップアラウンド処理は、NTPおよびFLUTEの範囲外です。
* The receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.
* 受信者は、FDTインスタンスの有効期限を過ぎて受信したパケットの解釈に、そのFDTインスタンスを使用すべきではありません (SHOULD NOT)。
* A sender MUST use an expiry time in the future upon creation of an FDT Instance relative to its Sender Current Time (SCT).
* 送信者はFDTインスタンスを作成する際、送信者現在時刻（SCT）より後の有効期限を設定しなければなりません (MUST)。
* 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.)
* FDTインスタンスの送信には、任意のFEC Encoding IDを使用してもかまいません (MAY)。既定ではFEC Encoding ID 0を使用します。FLUTEではFEC Encoding ID 0が既定であるため、Source Block NumberとEncoding Symbol 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インスタンスは、そのファイルと同等以上の信頼性でセッション内に送信することが推奨されます (SHOULD)（送信頻度を高める、またはFEC保護を強化するなど）。特に、FDTインスタンスが1パケットのペイロードより長い場合は、損失から保護するFEC符号を使って配信することが推奨されます (SHOULD)。ファイルの記述をFDTインスタンスで送信する頻度や、各FDTインスタンス（1パケットのペイロードより長い場合）に適用するFEC保護の量は、個々のアプリケーションに依存するため、この文書では規定しません。
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 Instance Headerと呼ばれる必須のLCTヘッダー拡張も付加します (MUST)。FDT Instance Header（EXT_FDT）には、ファイル配信セッション内でFDTインスタンスを一意に識別するFDT Instance IDが含まれます。このヘッダーは、他のLCT拡張ヘッダーと同じ方法で配置します。他のLCT拡張ヘッダーを併用してもかまいません (MAY)。
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 Payload IDが続き、最後に、1つ以上のファイル説明エントリを含むFDTインスタンスのEncoding Symbolが続きます。FDTインスタンスは複数のALCパケットにまたがることがあります (MAY)。必要なALCパケット数は、そのFDTインスタンスに関連付けられたファイル属性によって決まります。FDTインスタンスを含む各ALCパケットには、FDT Instance Headerを含めます。同じ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 Instance Header（EXT_FDT）は、新しい固定長のALC PI固有LCTヘッダー拡張[3]です。この拡張のHeader Extension Type（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'.
この文書ではFLUTEバージョン1を規定します。したがって、この仕様に定めるファイル配信セッションに属し、FDTインスタンスを運ぶすべてのALCパケットでは、このフィールドを「1」に設定しなければなりません (MUST)。
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」から始まり、後続の各インスタンスで1ずつ増加します。最大値（2^20-1）に達すると、番号は再び「0」から始まります。2^20-1から0に折り返した場合、0は2^20-1より大きい値として扱います。折り返しによって以前のFDT Instance IDを再利用した新しいFDTインスタンスを送信しても、同じIDを持つ以前のインスタンスが暗黙に失効するわけではありません。以前のインスタンスが失効してから、そのIDを再利用するインスタンスを構築して配信するのが妥当です。ただし、FDT Instance IDの折り返しや、IDの欠落によって増分が1を超える場合などの特殊な状況における受信側の必須動作は、この仕様の範囲外であり、FLUTEの各実装に委ねられます。
The FDT Instance contains file description entries that provide the mapping functionality described in 3.2 above.
FDTインスタンスには、前述のセクション3.2で説明した対応付け機能を提供するファイル説明エントリが含まれます。
The FDT Instance is an XML structure that has a single root element "FDT-Instance". The "FDT-Instance" element MUST contain "Expires" attribute, which tells the expiry time of the FDT Instance. In addition, the "FDT-Instance" element MAY contain the "Complete" attribute (boolean), which, when TRUE, signals that no new data will be provided in future FDT Instances within this session (i.e., that either FDT Instances with higher ID numbers will not be used or if they are used, will only provide identical file parameters to those already given in this and previous FDT Instances). For example, this may be used to provide a complete list of files in an entire FLUTE session (a "complete FDT").
FDTインスタンスは、単一のルート要素「FDT-Instance」を持つXML構造です。「FDT-Instance」要素には、そのFDTインスタンスの有効期限を示す「Expires」属性を含めなければなりません (MUST)。また、「FDT-Instance」要素には「Complete」ブール属性を含めてもかまいません (MAY)。この属性がTRUEの場合、このセッションでは今後のFDTインスタンスで新しいデータが提供されないことを示します。つまり、より大きなIDを持つFDTインスタンスを使用しないか、使用する場合でも、このインスタンスおよび以前のインスタンスですでに示されたものと同一のファイルパラメーターだけを提供します。たとえば、FLUTEセッション全体のファイル一覧（「完全なFDT」）を提供するために使用できます。
The "FDT-Instance" element MAY contain attributes that give common parameters for all files of an FDT Instance. These attributes MAY also be provided for individual files in the "File" element. Where the same attribute appears in both the "FDT-Instance" and the "File" elements, the value of the attribute provided in the "File" element takes precedence.
「FDT-Instance」要素には、そのFDTインスタンス内のすべてのファイルに共通するパラメーターを示す属性を含めてもかまいません (MAY)。個々のファイルについては、「File」要素にも同じ属性を指定してもかまいません (MAY)。属性が「FDT-Instance」要素と「File」要素の両方に現れる場合は、「File」要素に指定された値を優先します。
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インスタンスで宣言する各ファイルについて、そのインスタンス内にファイル説明エントリを1つ設けます。各エントリは、FDTインスタンス構造の子要素である「File」要素で表します。
The attributes of "File" element in the XML structure represent the attributes given to the file that is delivered in the file delivery session. The value of the XML attribute name corresponds to MIME field name and the XML attribute value corresponds to the value of the MIME field body. Each "File" element MUST contain at least two attributes "TOI" and "Content-Location". "TOI" MUST be assigned a valid TOI value as described in section 3.3 above. "Content-Location" MUST be assigned a valid URI as defined in [6].
XML構造の「File」要素の属性は、ファイル配信セッションで配信するファイルに付与する属性を表します。XML属性名はMIMEフィールド名に対応し、XML属性値はMIMEフィールド本文の値に対応します。各「File」要素には、少なくとも「TOI」と「Content-Location」の2つの属性を含めなければなりません (MUST)。「TOI」には前述のセクション3.3で説明した有効なTOI値を設定しなければなりません (MUST)。「Content-Location」には[6]で定義された有効なURIを設定しなければなりません (MUST)。
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-Instance」要素と「File」要素には、以下に特記する属性を含めてもかまいません (MAY)。
* Where the MIME type is described, the attribute "Content-Type" MUST be used for the purpose as defined in [6].
* MIMEタイプを記述する場合は、[6]で定義された用途に「Content-Type」属性を使用しなければなりません (MUST)。
* 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]で定義された用途に「Content-Length」属性を使用しなければなりません (MUST)。転送長とは、転送されるオブジェクトのバイト数です。FECデコーダーでファイルのソースブロックを復元するにはソースブロック構造が必要であり、転送長はその構造を正しく決定するために必要となることが多いため、転送長を受信者に伝えることが重要です。ファイルを転送前にコンテンツエンコードし、「Content-Encoding」属性を使用する場合、通常、元のファイルサイズと転送長は異なります。転送前にコンテンツエンコードしない場合は、転送長は元のファイルサイズと同じであり、「Content-Length」も転送長を表します。一方、転送前に圧縮するなどしてコンテンツエンコードする場合、転送長は通常、元のファイルサイズと異なります。この場合、転送長を伝えるために「Transfer-Length」属性を使用してもかまいません (MAY)。
* Where the content encoding scheme is described, the attribute "Content-Encoding" MUST be used for the purpose as defined in [6].
* コンテンツエンコーディング方式を記述する場合は、[6]で定義された用途に「Content-Encoding」属性を使用しなければなりません (MUST)。
* 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」属性を使用しなければなりません (MUST)。
* 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スキーマを新しい記述子で拡張する場合、単一のファイルに適用する属性は「File」要素の属性として配置しなければなりません (MUST)。現在のFDTインスタンスが記述するすべてのファイルに適用する属性は、「FDT-Instance」要素内に配置しなければなりません (MUST)。FDTに追加する記述子はMIMEフィールド形式とし、HTTP/1.1仕様[6]またはその他の広く知られた仕様で定義することが推奨されます (SHOULD)。
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インスタンス自体を、たとえば圧縮によってコンテンツエンコードしてもかまいません (MAY)。この仕様では、FDT Instance Content Encoding Header（EXT_CENC）を定義します。EXT_CENCは、ALC PI固有の新しい固定長LCTヘッダー拡張[3]です。この拡張のHeader Extension Type（HET）は193です。FDTインスタンスをコンテンツエンコードする場合は、エンコーディング方式を通知するためにEXT_CENCを使用しなければなりません (MUST)。その場合、同じFDT Instance IDを持つすべてのALCパケットでEXT_CENCを使用しなければなりません (MUST)。したがって、EXT_CENCヘッダーは適切なFDT Instance Header（EXT_FDT）と併用しなければなりません (MUST)。ファイル配信セッションには、コンテンツエンコードされたFDTインスタンスと、エンコードされていないFDTインスタンスの両方が含まれてもかまいません (MAY)。特定のFDTインスタンスをコンテンツエンコードしない場合、そのインスタンスを運ぶパケットでEXT_CENCを使用してはなりません (MUST NOT)。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:
Content Encoding Algorithm（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」に設定しなければなりません (MUST)。
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インスタンスを含むこれらのオブジェクトは、セッション内で任意の順序に多重化し、並行して送信してもかまいません (MAY)。つまり、1つのファイルのパケットを、同じセッション内の他のファイルまたはFDTインスタンスのパケットと交互に送信してもかまいません (MAY)。
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インスタンスを配信してもかまいません (MAY)。この場合、先行するFDTインスタンスの送信を次のインスタンスの送信開始前に終了することが推奨されます (SHOULD)。また、先行するインスタンスの送信は次のインスタンスの送信開始前に終了すべきです (SHOULD)。ただし、予期しないネットワーク状況によって、各FDTインスタンスのパケットが交互に届くことがあります (MAY)。FDTインスタンスはEXT_FDTヘッダー内のFDT Instance IDで一意に識別されるため、受信者はパケットがどのインスタンスの情報を含むかを判別できます。
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
ALC/LCTには、チャネルと輻輳制御の概念があります。FLUTEの用途として、次の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インスタンスを複数のチャネルで配信してもかまいません (MAY)。
(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インスタンスを複数のチャネルで配信してもかまいません (MAY)。
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つ目のオブジェクトの配信が1つ以上のチャネルですでに始まっていることがあります。一方、複数のチャネルやレイヤを使うと、1つ目より先に2つ目のオブジェクトの配信が完了する場合があります。単一チャネルでオブジェクトを順番に配信する場合、この問題は起きません。したがって、FLUTEアプリケーションで1つ目のトランスポートオブジェクトを2つ目より先に完了させることが必須または重要な要件である場合は、ファイル配信セッションで単一チャネルだけを使用することが推奨されます (SHOULD)。
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インスタンスが必要なため）、次の方法が推奨されます (SHOULD)。
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インスタンスのパケット送信先レイヤは、低レートの受信者が参加していないレイヤに偏らせるべきではありません (SHOULD NOT)。たとえば、低位レイヤが高レート受信者に妥当な時間内に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つのEncoding Symbolより長く、FDTインスタンスの一部のパケットを低レート受信者が受信しないレイヤに送る場合は、FEC Encoding ID 0以外のFEC符号を使ってFDTインスタンスを配信すべきです (SHOULD)。この場合、ネットワークでパケット損失が起きなくても、低レート受信者はFDTインスタンス向けの全パケットを受信できないためです。
FLUTE inherits the use of FEC building block [4] from ALC. When using FLUTE for file delivery over ALC the FEC Object Transmission Information MUST be delivered in-band within the file delivery session. In this section, two methods are specified for FLUTE for this purpose: the use of ALC specific LCT extension header EXT_FTI [2] and the use of FDT.
FLUTEはALCからFECビルディングブロック[4]を継承します。ALC上のファイル配信にFLUTEを使う場合、FECオブジェクト伝送情報をファイル配信セッション内で帯域内配信しなければなりません (MUST)。この目的のため、本セクションでは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オブジェクト伝送情報の配信に対応しなければなりません (MUST)。TOI値が0以外の場合、受信者はEXT_FTIを使う方法とFDTを使う方法の両方に対応しなければなりません (MUST)。
The FEC Object Transmission Information that needs to be delivered to receivers MUST be exactly the same whether it is delivered using EXT_FTI or using FDT (or both). Section 5.1 describes the required FEC Object Transmission Information that MUST be delivered to receivers for various FEC Encoding IDs. In addition, it describes the delivery using EXT_FTI. Section 5.2 describes the delivery using FDT.
EXT_FTI、FDT、またはその両方を使う場合、受信者に配信するFECオブジェクト伝送情報は完全に同一でなければなりません (MUST)。セクション5.1では、各FEC Encoding IDについて受信者に配信しなければならないFECオブジェクト伝送情報 (MUST) と、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オブジェクト伝送情報を複数の情報源から取得できる場合があります。この場合、ファイル配信セッションの受信者は、次の順（優先度の高い順）で情報源を優先することが推奨されます (SHOULD)。
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パケットに含める必要がある場合があります。各FDTインスタンスについて、少なくとも1つの送信ALCパケットにEXT_FTIを含めなければなりません (MUST)。
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ヘッダー拡張の形式や処理方法を定めていません。以下の各節では、FLUTEで使用するEXT_FTIを規定します。
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header.
FLUTEでは、FEC Encoding ID（8ビット）はALC/LCTヘッダーのCodepointフィールドに格納されます。
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.
Header Extension Length（HEL）、8ビット：ヘッダー拡張フィールド全体の長さを32ビットワード数で表します。この長さには、FEC Encoding 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 Instance IDに使用します。FEC Encoding IDの値が128～255の場合にのみ存在します。FEC Encoding 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 Encoding IDによって異なります。次の各節では、FEC Encoding ID 0、128、129、130について、このフィールドの構造を定めます。
FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC' (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC' (Under-Specified) [7]. For these FEC Encoding IDs, the FEC Encoding ID specific format of EXT_FTI is defined as follows.
FEC Encoding ID 0は「Compact No-Code FEC」（完全規定）[7]、FEC Encoding ID 128は「Small Block, Large Block and Expandable FEC」（未規定部分あり）[4]、FEC Encoding ID 130は「Compact FEC」（未規定部分あり）[7]です。これらのFEC Encoding IDに対するEXT_FTIの固有形式を以下に定めます。
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:
Encoding Symbol Length、16ビット：
Length of Encoding Symbol in bytes.
Encoding Symbolのバイト単位の長さです。
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.
トランスポートオブジェクト内のすべてのEncoding Symbolは、最後のソースブロックにある最後のソースシンボルを例外として、この長さでなければなりません (MUST)。この最後のシンボルには、冗長なパディングを必ずしも付ける必要はありません。この最後のソースシンボルを基に別のEncoding Symbolを計算する場合、送信側と受信側で値の解釈が一致するよう、最後のソースシンボルを論理的にゼロで埋めなければなりません (MUST)。ただし、そのパディングを最後のソースシンボルのデータとともに実際に送信する必要はありません。
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 Instance IDで識別されるFDTインスタンス）のすべてのソースブロックのサイズを決定するアルゴリズムを、送信者と受信者の双方が把握している必要があります。そのアルゴリズムは、セッション内で同じFEC Encoding IDを使うすべてのファイルで共通にすることが推奨されます (SHOULD)。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use.
セクション5.1.2.3では、この用途に使うことが推奨されるアルゴリズムを説明します (SHOULD)。
For the FEC Encoding IDs 0, 128 and 130, this algorithm is the only well known way the receiver can determine the length of each source block. Thus, the algorithm does two things: (a) it tells the receiver the length of each particular source block as it is receiving packets for that source block - this is essential to all of these FEC schemes; and, (b) it provides the source block structure immediately to the receiver so that the receiver can determine where to save recovered source blocks at the beginning of the reception of data packets for the file - this is an optimization which is essential for some implementations.
FEC Encoding ID 0、128、130では、このアルゴリズムが、受信者が各ソースブロックの長さを判断するための既知の唯一の方法です。したがって、このアルゴリズムには2つの役割があります。(a) ソースブロックのパケットを受信しながら、そのブロックの長さを受信者に知らせます。これは、これらすべてのFEC方式で不可欠です。(b) データパケットの受信開始時にソースブロック構造を受信者に知らせ、復元したソースブロックの保存先を判断できるようにします。これは一部の実装に不可欠な最適化です。
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID specific format of EXT_FTI is defined as follows.
Small Block Systematic FEC（未規定部分あり）。EXT_FTIのFEC Encoding 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.
Encoding Symbolのバイト単位の長さです。
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.
トランスポートオブジェクト内のすべてのEncoding Symbolは、最後のソースブロックにある最後のソースシンボルを例外として、この長さでなければなりません (MUST)。この最後のシンボルには、冗長なパディングを必ずしも付ける必要はありません。この最後のソースシンボルを基に別のEncoding Symbolを計算する場合、送信側と受信側で値の解釈が一致するよう、最後のソースシンボルを論理的にゼロで埋めなければなりません (MUST)。ただし、そのパディングを最後のソースシンボルのデータとともに実際に送信する必要はありません。
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.
ソースブロックについて生成できるEncoding Symbol数の最大値です。
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 Instance IDで識別されるFDTインスタンス）のすべてのソースブロックのサイズを決定するアルゴリズムを、送信者と受信者の双方が把握している必要があります。そのアルゴリズムは、セッション内で同じFEC Encoding IDを使うすべてのファイルで共通にすることが推奨されます (SHOULD)。
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では、この用途に使うことが推奨されるアルゴリズムを説明します (SHOULD)。FEC Encoding ID 129では、各データパケットのFEC Payload IDに、そのパケット内のEncoding Symbolに対応するソースブロックの長さがすでに含まれています。そのため、このIDのソースブロック構造を計算する際は、FEC Payload ID内のデータパケットに含まれる長さだけを使う方法もあります。ただし、セクション5.1.2.3のアルゴリズムを使えば、ファイルのデータパケットを受信し始めた時点でソースブロック構造を計算できます。このアルゴリズムを使う場合、データパケットに含まれるソースブロック長は、アルゴリズムで計算した長さと一致しなければなりません (MUST)。
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,
このアルゴリズムは、各ソースブロックの長さができるだけ均等になるようにソースブロック構造を計算します。先頭のI個のソースブロックは同じ大きい長さとし、残りのN-I個は同じ小さい長さとします。ソースブロックの総数（N）、先頭側のブロック数（I）、残りのブロック数（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 -- 最大ソースブロック長（ソースブロックあたりのソースシンボル数の最大値） L -- バイト単位の転送長 E -- バイト単位のEncoding Symbol長
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 = ceil(L/E) として計算します。(b) オブジェクトを N 個のソースブロックに分割します。N = ceil(T/B) です。(c) ソースブロックの平均長を A = T/N とします（整数とは限りません）。(d) A_large = ceil(A) とします（A_large は常に B 以下です）。(e) A_small = floor(A) とします。A が整数なら A_small = A_large、整数でなければ A_small = A_large - 1 です。(f) A の小数部分を A_fraction = A - A_small とします。(g) I = A_fraction * N とします（I は0以上N未満の整数です）。(h) 先頭I個のソースブロックはそれぞれA_large個のソースシンボルで構成し、各シンボルの長さはEバイトです。残りのN-I個はそれぞれA_small個のソースシンボルで構成します。各シンボルの長さはEバイトですが、最後のソースブロックの最後のソースシンボルだけは、L - (floor((L-1)/E) * E) バイトです。
Note, this algorithm does not imply implementation by floating point arithmetic and integer arithmetic may be used to avoid potential floating point rounding errors.
このアルゴリズムは浮動小数点演算で実装することを要求するものではありません。浮動小数点の丸め誤差を避けるため、整数演算を使用できます。
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure. For future FEC Encoding IDs, if the attributes listed below do not fulfill the needs of describing the FEC Object Transmission Information then additional new attributes MAY be used.
FDTは、FDT構造の「FDT-Instance」要素または「File」要素に適切な属性を指定して、各ファイルのFECオブジェクト伝送情報を配信します。将来のFEC Encoding IDで、以下の属性だけでは情報を記述する要件を満たせない場合、新しい属性を追加してもかまいません (MAY)。
* "Transfer-Length" is semantically equivalent with the field "Transfer Length" of EXT_FTI.
* 「Transfer-Length」は、EXT_FTIの「Transfer Length」フィールドと意味的に同等です。
* "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the field "FEC Encoding ID" as carried in the Codepoint field of the ALC/LCT header.
* 「FEC-OTI-FEC-Encoding-ID」は、ALC/LCTヘッダーのCodepointフィールドに格納される「FEC Encoding ID」と意味的に同等です。
* "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the field "FEC Instance ID" of EXT_FTI.
* 「FEC-OTI-FEC-Instance-ID」は、EXT_FTIの「FEC Instance ID」フィールドと意味的に同等です。
* "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding IDs 0, 128 and 130, and semantically equivalent with the field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID 129.
* 「FEC-OTI-Maximum-Source-Block-Length」は、FEC Encoding ID 0、128、130の場合はEXT_FTIの「Maximum Source Block Length」フィールドと意味的に同等であり、FEC Encoding ID 129の場合もEXT_FTIの同名フィールドと意味的に同等です。
* "FEC-OTI-Encoding-Symbol-Length" is semantically equivalent with the field "Encoding Symbol Length" of EXT_FTI for FEC Encoding IDs 0, 128, 129 and 130.
* 「FEC-OTI-Encoding-Symbol-Length」は、FEC Encoding ID 0、128、129、130の場合のEXT_FTIの「Encoding Symbol Length」フィールドと意味的に同等です。
* "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の「Maximum Number of Encoding Symbols」フィールドと意味的に同等です。
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).
* セッションがFLUTEセッションであることを示す情報。受信時にオブジェクトを分離する必要があることは、FLUTEを使う場合に当然伴います。この情報によって、セッションが複数のオブジェクトのパケットを含むかどうかを示すALCの要件を満たします（すべてのFLUTEセッションは複数オブジェクトのパケットを含みます）。
Optionally, the following parameters MAY be associated with the session (Note, the list is not exhaustive):
任意で、以下のパラメーターをセッションに関連付けてもかまいません (MAY)。なお、以下は網羅的な一覧ではありません。
* 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;
* FDTの配信に既定のFEC Encoding ID 0を使用しない場合のFEC Encoding IDとFEC Instance ID。
* Content Encoding format if optional content encoding of FDT Instance is used, e.g., compression;
* FDTインスタンスを任意にコンテンツエンコードする場合のコンテンツエンコーディング形式（たとえば圧縮方式）。
* Some information that tells receiver, in the first place, that the session contains files that are of interest.
* セッションに受信者が必要とするファイルが含まれることを、受信者に事前に知らせる情報。
It is envisioned that these parameters would be described according to some session description syntax (such as SDP [12] or XML based) and held in a file which would be acquired by the receiver before the FLUTE session begins by means of some transport protocol (such as Session Announcement Protocol [11], email, HTTP [6], SIP [22], manual pre-configuration, etc.) However, the way in which the receiver discovers the above-mentioned parameters is out of scope of this document, as it is for LCT and ALC. In particular, this specification does not mandate or exclude any mechanism.
これらのパラメーターは、SDP [12] やXMLベースの形式など、何らかのセッション記述構文で記述し、セッション記述プロトコル[11]、電子メール、HTTP [6]、SIP [22]、手動の事前設定などのトランスポート手段を使ってFLUTEセッション開始前に受信者が取得するファイルに格納することを想定しています。ただし、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を使用するため、FLUTEは、セッションに偽造パケットを送り込み、受信者によるFDTやファイルの大部分の復元を妨げたり、不正確な復元を引き起こしたりするサービス拒否攻撃に特に弱いです。ALCと同様に、多数の受信者が同じ偽造パケットを受け取る可能性があるため、FLUTEはこの種の攻撃の影響を受けやすくなります。悪意ある攻撃者はファイルのパケットを偽装して、ファイルを誤って復元させることもできます。
Even more damaging, a malicious forger may spoof FDT Instance packets, for example sending packets with erroneous FDT-Instance fields. Many attacks can follow this approach. For instance a malicious attacker may alter the Content-Location field of TOI 'n', to make it point to a system file or a user configuration file. Then, TOI 'n' can carry a Trojan Horse or some other type of virus. It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at the receiver does not have write access to the system files or directories, or any other critical areas. As described for MIME [20][21], special consideration should be paid to the security implications of any MIME types that can cause the remote execution of any actions in the recipient's environment. Note, RFC 1521 [21] describes important security issues for this environment, even though its protocol is obsoleted by RFC 2048 [20].
さらに深刻な攻撃として、攻撃者がFDTインスタンスのパケットを偽装し、誤ったFDT-Instanceフィールドを含むパケットを送信することがあります。この方法では、たとえばTOI「n」のContent-Locationフィールドを改ざんし、システムファイルやユーザー設定ファイルを指すようにできます。その結果、TOI「n」にトロイの木馬などのウイルスを含めることが可能になります。したがって、受信側のFLUTE配信サービスには、システムファイルやディレクトリなどの重要領域への書き込み権限を与えないことを強く推奨します (SHOULD)。MIME [20][21]で説明されているように、受信者の環境で処理を遠隔実行させる可能性のあるMIMEタイプについては、セキュリティ上の影響を特に考慮してください。RFC 1521 [21]のプロトコルはRFC 2048 [20]によって廃止されていますが、RFC 1521にはこの環境に関する重要なセキュリティ上の問題が記載されています。
Another example is generating a bad Content-MD5 sum, leading receivers to reject the associated file that will be declared corrupted. The Content-Encoding can also be modified, which also prevents the receivers to correctly handle the associated file. These examples show that the FDT information is critical to the FLUTE delivery service.
別の例として、不正なContent-MD5値を生成すると、受信者は関連ファイルを破損ファイルと判断して拒否することになります。Content-Encodingを改ざんした場合も、受信者がファイルを正しく処理できなくなります。これらの例は、FDT情報がFLUTE配信サービスにとって重要であることを示しています。
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インスタンスを復元した後、送信されたオブジェクトと同一であることを確認するために、オブジェクト全体の完全性を検査することが推奨されます (SHOULD)。強い暗号学的完全性保護を実現するには、受信者が検証できるデジタル署名を使って、このアプリケーション層の完全性検査を行うことが推奨されます (SHOULD)。ただし、破損または偽造されたパケットが1つでも復元に使われると、受信オブジェクトは誤って復元される可能性が高くなります。その場合、完全性検査は失敗し、誤って復元されたオブジェクトを破棄すべきです (SHOULD)。したがって、偽造パケットを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データを含むことを確認するため、パケット認証を使うことが推奨されます (SHOULD)。パケット認証を使えば、破損または偽造されたパケットを個別に破棄でき、認証済みパケットを使ってオブジェクトを正確に復元できます。したがって、偽造パケットを注入するサービス拒否攻撃の影響はオブジェクトのサイズではなく、偽造パケット数だけに比例します。現在、マルチキャストのパケット認証方法を規定する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.
パケット認証は、不正確なオブジェクトの復元を防ぐだけでなく、複数レート輻輳制御に対するサービス拒否攻撃への保護にも役立ちます。攻撃者は、誤った輻輳制御情報を含む偽造パケットをマルチキャストストリームに注入し、攻撃経路より下流のネットワーク要素や受信者に悪影響を与えることがあります。ネットワークの他の部分や他の受信者への影響は、これより小さくなります。この種の攻撃を防ぐためにも、パケット認証を使うことが推奨されます (SHOULD)。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.
送信者から受信者までの経路上にあるすべてのネットワークルーターとスイッチで、マルチキャストツリーのデータ経路に不正なノードが偽造パケットを注入する可能性を抑えるため、リバースパス転送チェックを有効にすべきです (SHOULD)。
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.
複数レート輻輳制御ビルディングブロックの実装に誤りや破損がある受信者は、送信者から受信者までの経路のネットワーク状態や、同じセッションに参加している他の受信者の受信レートに影響することがあります。そのため、セッション参加に必要なセッション記述を受け取る前に、受信者が正規の利用者であることを確認することが推奨されます (SHOULD)。受信者が正規の利用者であることを確認する方法は、この文書の範囲外です。
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.
FLUTEには、受信者が誤ったセッション記述を取得する可能性もあります。その結果、正しいセッション記述を取得できなかった正規の受信者がセッションの内容を正しく受信できなくなったり、受信者が処理能力を大幅に上回るレートで受信しようとしてネットワークの一部のトラフィックを妨げたりすることがあります。こうした問題を避けるため、受信者が誤ったセッション記述を受け入れないよう対策を講じることが推奨されます (SHOULD)。たとえば、送信元認証を使い、認可された送信者からの正当なセッション記述だけを受信者が受け入れるようにします。具体的な方法は、この文書の範囲外です。
No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by FLUTE does require IANA registration of the FEC codec used.
この仕様の情報は、IANA登録の直接の対象ではありません。ただし、ALCが使用するビルディングブロックの構成要素によっては、追加のIANA上の考慮事項が生じることがあります。特に、FLUTEが使用するFECビルディングブロックでは、使用するFECコーデックをIANAに登録する必要があります。
The following persons have contributed to this specification: Brian Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, Jani Peltotalo, Sami Peltotalo, Topi Pohjolainen, and Lorenzo Vicisano. The authors would like to thank all the contributors for their valuable work in reviewing and providing feedback regarding this specification.
この仕様には、Brian Adamson、Mark Handley、Esa Jalonen、Roger Kermode、Juha-Pekka Luoma、Jani Peltotalo、Sami Peltotalo、Topi Pohjolainen、Lorenzo Vicisanoの各氏が貢献しました。著者は、仕様のレビューとフィードバックに貴重な労力を提供したすべての貢献者に感謝します。
Normative References
規範的な参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[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., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[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., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[5] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[5] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[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., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[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 Part 1: Structures", W3C Recommendation, May 2001.
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001.
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, May 2001.
Informative References
Informative References
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[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., and J. Tygar, "Efficient and Secure Source Authentication for Multicast, Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46.", February 2001.
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California", August 2001.
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California", August 2001.
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[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 Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[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., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[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., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November 1996.
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 1521, November 1996.
[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., and E. Schooler, "SIP: session initiation protocol", RFC 3261, June 2002.
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アドレス, Transport Session Identifier）の組で識別されるファイル配信セッションの記述を取得します。また、そのセッションに関連付けられた宛先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パケットを受信します。パケットが宣言されたTransport Session Identifierに一致することを確認し、一致しないパケットは通知せずに破棄します。
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. 受信者はオブジェクトを復元します。トランスポートオブジェクトのEncoding Symbolを含む適切なパケット集合を受信すると、オブジェクトを復元できます。必要なパケット集合は、FEC Encoding IDとFEC Instance 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 Instance ID「N」のFDTインスタンスである場合、受信者はそのFDTインスタンスのペイロードを解析し、それに応じてFDTデータベースを更新します。受信者はEXT_FDTヘッダー拡張を使って、ファイル配信セッション内のFDTインスタンスを識別します。EXT_FDTヘッダー拡張を使って配信するオブジェクトはすべてFDTインスタンスであり、FDT Instance IDで一意に識別されます。TOI「0」はFDTの配信専用に予約されています。
7. If the object recovered is not an FDT Instance but a file, the receiver looks up its FDT database to get the properties described in the database, and assigns file with the given properties. The receiver also checks that received content length matches with the 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に戻ります。達していれば終了します。
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl="http://www.example.com/flute"
xsi:schemaLocation="http://www.example.com/flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
Authors' Addresses
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
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
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland
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'Europe Montbonnot St Ismier cedex 38334 France
EMail: vincent.roca@inrialpes.fr
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
EMail: rod.walsh@nokia.com
Full Copyright Statement
著作権に関する声明
Copyright (C) The Internet Society (2004).
Copyright (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に含まれる権利、ライセンス、制限の対象です。同BCPに別段の定めがある場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その代表者またはスポンサーとなっている組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示または黙示を問わず、すべての保証を否認します。これには、ここに記載された情報の使用がいかなる権利も侵害しないことについての保証や、商品性または特定目的への適合性に関する黙示の保証が含まれますが、これらに限定されません。
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へお知らせいただくよう呼びかけます。情報はietf-ipr@ietf.org宛てにお送りください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyが行っています。