RFC3926 日本語訳
3926 FLUTE - File Delivery over Unidirectional Transport. T. Paila, M.Luby, R. Lehtonen, V. Roca, R. Walsh. October 2004. (Format: TXT=81224 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
Pailaがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3926年のノキアカテゴリ: 実験的なデジタルM.のINRIAローヌアルプR.ウォルシュノキアLuby噴水R.レヒトネンTeliaSonera V.ロカ2004年10月
FLUTE - File Delivery over Unidirectional Transport
フルート--単方向の輸送の上のファイル配送
Status of this Memo
この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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.
このドキュメントはファイルの単方向の配送のためにインターネットの上でFLUTE、プロトコルを定義します。特に、インターネットはマルチキャストネットワークに合っています。 Asynchronous Layered Codingの上の仕様体格、膨大にスケーラブルなマルチキャスト分配のために設計されたベースプロトコル。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 適用性証明. . . . . . . . . . . . . . . . 3 1.1.1。 目標アプリケーションスペース. . . . . . . . . . 3 1.1.2。 目標スケール. . . . . . . . . . . . . . . . 4 1.1.3。 意図している環境. . . . . . . . . . . . . 4 1.1.4。 弱点. . . . . . . . . . . . . . . . . . . 4 2。 このDocumentで使用されるコンベンション。 . . . . . . . . . . . . . . 5 3. 配送. . . . . . . . . . . . . . . . . . . . . . . . 5 3.1をファイルしてください。 配送セッション. . . . . . . . . . . . . . . . . 6 3.2をファイルしてください。 配送テーブルをファイルしてください。 . . . . . . . . . . . . . . . . . . 8 3.3. FDT Instancesの力学は配送セッション. 9 3.4を中にファイルします。 FDT Instanceパケットの構造。 . . . . . . . . . . . 11
Paila, et al. Experimental [Page 1] RFC 3926 FLUTE October 2004
Paila、他 実験的な[1ページ]RFC3926は2004年10月にフルートを吹かせます。
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. FDTインスタンスヘッダー. . . . . . . . . 12 3.4.2の形式。 FDTインスタンス. . . . . . . . . . . . . 13 3.4.3の構文。 FDTインスタンス. . . . . . . . 16 3.5の満足しているコード化。 ファイル配送セッション. . 17 4以内のファイルのマルチプレクシング。 チャンネル、輻輳制御、およびタイミング. . . . . . . . . . . 18 5。 オブジェクトトランスミッション情報. . . . . . . . 19 5.1をFECに提供します。 EXT_FTIのFEC Object Transmission情報の配送の使用。 . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1. 一般EXT_FTI形式. . . . . . . . . . . . . 20 5.1.2。 EXT_FTI. . 21 5.2のためのFEC EncodingのIDの特定の形式。 FDTのFEC Object Transmission情報の配送の使用。 . . . . . . . . . . . . . . . . . . . . . . 25 6. ファイル配送セッションについて説明します。 . . . . . . . . . . . . . . 25 7. セキュリティ問題. . . . . . . . . . . . . . . . . . . 26 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 29 9。 FDT Instance(有益な)の承認. . . . . . . . . . . . . . . . . . . . . . . 29Normative References. . . . . . . . . . . . . . . . . . . . . 29Informative References. . . . . . . . . . . . . . . . . . . . 30A.Receiver操作(有益な).32B.Example。 . . . . . . . . . . . . 33人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 34の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 35
1. Introduction
1. 序論
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、プロトコルを定義します。 Asynchronous Layered Coding(ALC)、ベースプロトコルが膨大にスケーラブルなマルチキャスト分配のために設計したバージョン1[2]の仕様体格。 ALCは任意の2進のオブジェクトの輸送を定義します。 しかしながら、ファイル配送アプリケーションにおいて、オブジェクトの単なる輸送は十分ではありません。エンドシステムは、オブジェクトが実際に何を表すかを知る必要があります。 このドキュメントはFLUTEと呼ばれるテクニックを指定します--受信機が容認されたオブジェクトのためのそれらのパラメタを割り当てる方法でファイルの特性にALCの概念に合図して、写像するためのメカニズム。 その結果、このドキュメント中では、'ファイル'という用語はALCで議論するように'オブジェクト'に関連します。 この仕様は例として頻繁にマルチキャストアドレシングを利用しますが、使用には、テクニックはユニキャストアドレシングで同様に適切です。
This document defines a specific transport application of ALC, adding the following specifications:
以下の仕様を加えて、このドキュメントはALCの特定の輸送アプリケーションを定義します:
- Definition of a file delivery session built on top of ALC,
including transport details and timing constraints.
- ファイル配送セッションの定義は輸送の詳細とタイミング規制を含むALCの上に建てられました。
- In-band signalling of the transport parameters of the ALC session.
- バンドにおける、ALCセッションの輸送パラメタの合図。
Paila, et al. Experimental [Page 2] RFC 3926 FLUTE October 2004
Paila、他 実験的な[2ページ]RFC3926は2004年10月にフルートを吹かせます。
- 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は、ファイル配送セッションの概念を定義することによって、始まります。 この仕様のコア部分を形成するFile Delivery Tableを導入するのに続きます。 さらに、それは、ファイル配送セッション以内に輸送オブジェクトの問題を多重送信するのを議論します。 セクション4はFLUTEの輻輳制御とチャンネルの使用について説明します。 セクション5はファイル配送セッション以内に提供されるForward Error Correction(FEC)オブジェクトTransmission情報がことである方法を定義します。 セクション6は一般的な場合でファイル配送セッションについて説明するための必要なパラメタを定義します。 セクション7はFLUTEとのファイル配送に関するセキュリティ問題について概説します。 最後に、2個の有益な付録があります。 最初の付録はファイル配送セッションの受信機のための思い描かれた受信機操作について説明します。 2番目の付録はFile Delivery Tableに関する例を出します。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with
RFC2357. As per RFC2357, the use of any reliable multicast
protocol in the Internet requires an adequate congestion control
scheme.
このメモはRFC2357によると、Reliable Multicast Transportプロトコルを完全に指定するのに必要な定義の一部を含んでいます。 RFC2357に従って、インターネットでのどんな信頼できるマルチキャストプロトコルの使用も適切な輻輳制御体系を必要とします。
While waiting for such a scheme to be available, or for an
existing scheme to be proven adequate, the Reliable Multicast
Transport working group (RMT) publishes this Request for Comments
in the "Experimental" category.
そのような体系が利用可能であるか、または既存の体系が適切であると立証されるのを待っている間、Reliable Multicast Transportワーキンググループ(RMT)はCommentsのために「実験的な」カテゴリでこのRequestを発行します。
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
それは上記の状態の次第IETF Proposed Standardが会われるときRMTがこの仕様を再提出する意図です。
1.1. Applicability Statement
1.1. 適用性証明
1.1.1. The Target Application Space
1.1.1. 目標アプリケーションスペース
FLUTE is applicable to the delivery of large and small files to many hosts, using delivery sessions of several seconds or more. For instance, FLUTE could be used for the delivery of large software updates to many hosts simultaneously. It could also be used for continuous, but segmented, data such as time-lined text for subtitling - potentially leveraging its layering inheritance from ALC and LCT to scale the richness of the session to the congestion status
多くのホストにとって、FLUTEは大きくて小さいファイルの配送に適切です、数秒か以上の配送セッションを使用して。 例えば、同時に、大きいソフトウェアアップデートの配送に多くのホストにFLUTEを使用できました。 また、混雑状態にセッションの豊かについて合わせて調整するためにALCとLCTからレイヤリング継承を潜在的に利用して、字幕をつける時間で裏打ちされたテキストなどの連続しましたが、区分されたデータにそれを使用できました。
Paila, et al. Experimental [Page 3] RFC 3926 FLUTE October 2004
Paila、他 実験的な[3ページ]RFC3926は2004年10月にフルートを吹かせます。
of the network. It is also suitable for the basic transport of metadata, for example SDP [12] files which enable user applications to access multimedia sessions.
ネットワークについて。 また、それもメタデータ(例えば、ユーザアプリケーションがマルチメディアセッションにアクセスするのを可能にするSDP[12]ファイル)の基本的な輸送に適しています。
1.1.2. The Target Scale
1.1.2. 目標スケール
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は、IPマルチキャストの固有のスケーラビリティのいずれも犠牲にしないでALCとIPマルチキャストを使用することでこのすべてを提供します。
1.1.3. Intended Environments
1.1.3. 意図している環境
All of the environmental requirements and considerations that apply to the ALC building block [2] and to any additional building blocks that FLUTE uses also apply to FLUTE.
また、ALCブロック[2]と、そして、FLUTEが使用するどんな追加ブロックにも適用される環境要求事項と問題のすべてがFLUTEに適用されます。
FLUTE can be used with both multicast and unicast delivery, but it's primary application is for unidirectional multicast file delivery. FLUTE requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. FLUTE inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks.
マルチキャストとユニキャスト配送の両方と共にFLUTEを使用できますが、プライマリ利用が単方向のマルチキャストファイル配送のためのものであるということです。 FLUTEは送付者と受信機の間で接続性を必要としますが、受信機から送付者まで接続性は必要としません。 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].
FLUTEによるいいえとしてのIPv4かIPv6が分けるパケットの両方と互換性があるのが、IPバージョン詳細であるということです。 FLUTEは両方のマルチキャストモデルと共に働いています: いくらか、-、ソース、マルチキャスト(ASM)[13]とソース特有のマルチキャスト(SSM)[15]。
FLUTE is applicable for both Internet use, with a suitable congestion control building block, and provisioned/controlled systems, such as delivery over wireless broadcast radio systems.
適当な混雑制御建家によるインターネットの利用と食糧を供給されたか制御されたシステムの両方に、FLUTEは適切です、ワイヤレスの放送ラジオシステムの上の配送などのように。
1.1.4. Weaknesses
1.1.4. 弱点
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と共に使用できたいくつかの混雑制御プロトコルに従順でないものもあります。 衛星かワイヤレス・ネットワークのために、セッションまで割り当てられた固定通信速度があるかもしれないので事実上、受信機がそれらのレセプション率を低下させるメカニズムは全く特にないかもしれません。
Paila, et al. Experimental [Page 4] RFC 3926 FLUTE October 2004
Paila、他 実験的な[4ページ]RFC3926は2004年10月にフルートを吹かせます。
FLUTE provides reliability using the FEC building block. This will reduce the error rate as seen by applications. However, FLUTE does not provide a method for senders to verify the reception success of receivers, and the specification of such a method is outside the scope of this document.
FLUTEは、FECブロックを使用することで信頼性を提供します。 これはアプリケーションで見られるように誤り率を減少させるでしょう。 しかしながら、FLUTEは送付者が受信機のレセプション成功について確かめるメソッドを提供しません、そして、このドキュメントの範囲の外にそのようなメソッドの仕様があります。
2. Conventions used in this Document
2. このDocumentで使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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]との定義と一致しています。 用語「ファイル」と「ソースオブジェクト」は「オブジェクト」のための匿名です。
3. File delivery
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.
非同期なLayered Coding[2]は任意の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.
例と、" 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メディアがタイプされるように(また、通常、ファイル名の拡大からこれを結論づけることができます)言い表されたタイプをファイルしてください。 上記の例で: 「テキスト/明瞭です」。 MIMEの種類のための明白な値が別々にファイル拡張子から提供されて、ファイル拡張子のMIMEの種類に合っていないなら、MIMEの種類として明らかに提供された値を使用しなければなりません。
Paila, et al. Experimental [Page 5] RFC 3926 FLUTE October 2004
Paila、他 実験的な[5ページ]RFC3926は2004年10月にフルートを吹かせます。
* 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.
* ファイルのデジタル署名、メッセージダイジェストなどのセキュリティの特性 例えば、1つはファイルのためにこの認証ラッパーでタイプをコード化する内容としてS/MIME[18]を使用するかもしれません、そして、1つはFDT Instanceにデジタルに署名するのにXML-DSIG[19]を使用するかもしれません。
3.1. File delivery session
3.1. ファイル配送セッション
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つはTransport Session Identifier(TSI)です。 TSIはソースIPアドレスによって見られます、そして、(ソースIPアドレス、TSI)組は唯一セッションを特定します、そして、すなわち、受信機はパケットがどのセッションから受け取られたかを唯一特定するために各パケットで運ばれたこの組を使用します。 複数のオブジェクトがセッション以内に運ばれるといけないので、ALC/LCTヘッダーの中のTransport Object Identifier(TOI)分野は、パケットのデータがどのオブジェクトから生成されたかを特定します。 それぞれのオブジェクトがセッションの範囲の中のユニークなTOIに関連していることに注意してください。
If the sender is not assigned a permanent IP address accessible to receivers, but instead, packets that can be received by receivers containing a temporary IP address for packets sent by the sender, then the TSI is scoped by this temporary IP address of the sender for the duration of the session. As an example, the sender may be behind a Network Address Translation (NAT) device that temporarily assigns
受信機に理解できる永久的なIPアドレスが割り当てられるのではなく、送付者は代わりに送付者によって送られたパケットのための一時的なIPアドレスを含む受信機で受け取ることができるパケットを割り当てられるなら、TSIがセッションの持続時間のためのこの一時的なIP送信者のアドレスによって見られます。 例として、送付者はそれが一時割り当てるNetwork Address Translation(NAT)デバイスの後ろにいるかもしれません。
Paila, et al. Experimental [Page 6] RFC 3926 FLUTE October 2004
Paila、他 実験的な[6ページ]RFC3926は2004年10月にフルートを吹かせます。
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.
受信機にアクセスしやすい送付者、およびこの場合TSIのためのIPアドレスはそうです。NATによって割り当てられた一時的なIPアドレスによって見られて、それは受信機によって受け取られたパケットに現れるでしょう。ネットワークのいくつかの一部ができるIPv6でないかもしれません、そして、別の例として、送付者はIPv6を使用することでオリジナルのパケットを送るかもしれませんが、パケットのIPアドレスを異なったIPv4アドレスに変えるIPv4翻訳者へのIPv6があるかもしれません。 この場合、ネットワークのIPv4部分の受信機はIPv4アドレスを含むパケットを受けるでしょう、そして、その結果、それらのためのTSIはIPv4アドレスによって見られます。 範囲に使用されて、受信機によるセッションは受信機に提供されます、それが永久的なIPアドレスであるか否かに関係なくことである送信者のアドレスか一時的なIPが演説するどのようにIPがこのドキュメントの範囲の外のそうであるか。
When FLUTE is used for file delivery over ALC the following rules apply:
FLUTEがALCの上のファイル配送に使用されるとき、以下の規則は適用されます:
* The ALC/LCT session is called file delivery session.
* ALC/LCTセッションは呼ばれたファイル配送セッションです。
* The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
Delivery Table Instance' (section 3.2)
* 'オブジェクト'のALC/LCT概念は'ファイル'か'ファイルDelivery Table Instance'のどちらかを指示します。(セクション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分野を含まなければならなくて、Close Session(A)旗のセットとのFLUTEセッションのときに1に送られたALCパケット(セッションの終わりに合図する)とそれが含む例外で、どんなペイロード(どんなファイルやFDTのための情報も全く運ばない)SHALL NOTもTOIを運びません。 Close Session旗のLCT定義のためのRFC3451[3]のセクション5.1を見てください、そして、ALCパケットの中で使用に関する例のためのRFC3450[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'はFile Delivery Table Instancesの配送のために予約されます。 各File Delivery Table InstanceはFDT Instance IDによって唯一特定されます。
* Each file in a file delivery session MUST be associated with a TOI
(>0) in the scope of that session.
* ファイル配送セッションにおけるそれぞれのファイルはそのセッションの範囲のTOI(>0)に関連しているに違いありません。
* Information carried in the headers and the payload of a packet is
scoped by the source IP address and the TSI. Information
particular to the object carried in the headers and the payload of
a packet is further scoped by the TOI for file objects, and is
further scoped by both the TOI and the FDT Instance ID for FDT
Instance objects.
* パケットのヘッダーとペイロードで運ばれた情報はソースIPアドレスとTSIによって見られます。 パケットのヘッダーとペイロードで運ばれたオブジェクトに特定の情報は、ファイルオブジェクトのためにTOIによってさらに見られて、FDT InstanceオブジェクトのためにTOIとFDT Instance IDの両方によってさらに見られます。
Paila, et al. Experimental [Page 7] RFC 3926 FLUTE October 2004
Paila、他 実験的な[7ページ]RFC3926は2004年10月にフルートを吹かせます。
3.2. File Delivery Table
3.2. ファイル配送テーブル
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.
File Delivery Table(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 Encoding IDと関連しているときのFEC Instance 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)
- ファイルの名前、Identification、およびLocation(URIで、指定されます)
- MIME media type of file
- MIMEメディアファイル形式
- Size of file
- ファイルのサイズ
- Encoding of file
- ファイルのコード化
- Message digest of file
- ファイルのメッセージダイジェスト
Some of these attributes MUST be included in the file description entry for a file, others are optional, as defined in section 3.4.2.
ファイルのためのファイル記述項にこれらの属性のいくつかを含まなければならなくて、他のものは任意です、セクション3.4.2で定義されるように。
Logically, the FDT is a set of file description entries for files to be delivered in the session. Each file description entry MUST include the TOI for the file that it describes and the URI identifying the file. The TOI is included in each ALC/LCT data packet during the delivery of the file, and thus the TOI carried in the file description entry is how the receiver determines which ALC/LCT data packets contain information about which file. Each file description entry may also contain one or more descriptors that map the above-mentioned attributes to the file.
FDTは論理的に、ファイルがセッションのときに提供される1セットのファイル記述エントリーです。 各ファイル記述項はそれが説明するファイルとファイルを特定するURIのためのTOIを含まなければなりません。 TOIはファイルの配送の間、それぞれのALC/LCTデータ・パケットに含まれています、そして、その結果、ファイル記述項で運ばれたTOIは受信機が、どのALC/LCTデータ・パケットが情報を含むかをどのように決定するかというどのファイルに関することであるか。 また、各ファイル記述項は上記の属性をファイルに写像する1つ以上の記述子を含むかもしれません。
Each file delivery session MUST have an FDT that is local to the given session. The FDT MUST provide a file description entry mapped to a TOI for each file appearing within the session. An object that is delivered within the ALC session, but not described in the FDT, is
それぞれのファイル配送セッションには、与えられたセッションに地方であることのFDTがなければなりません。 FDT MUSTはセッション中に現れる各ファイルのためにTOIに写像されたファイル記述項を提供します。 ALCセッション中に提供されますが、FDTで説明されないオブジェクトがあります。
Paila, et al. Experimental [Page 8] RFC 3926 FLUTE October 2004
Paila、他 実験的な[8ページ]RFC3926は2004年10月にフルートを吹かせます。
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.
ファイル配送セッションに属しながら、'ファイル'であることは考えられません。 この仕様の範囲の外にこれらのunmapped TOIs(FDTによって決議されていないTOIs)の取り扱いがあります。
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 Instancesとして提供されます。 FDT InstanceはFDTの1つ以上のファイル記述エントリーを含んでいます。 どんなFDT Instanceも等しい場合がある、部分集合、スーパーセット、または、補数いかなる他のFDT Instance。 あるFDT Instanceはセッションの間、何度か繰り返されるかもしれません、その後のFDT Instances(より大きいFDT Instance ID番号がある)が伝えられた後にさえ。 各FDT Instanceは少なくとも一列で記述エントリーと高々ファイル配送セッションの完全な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 Instancesのレセプションでデータベースを維持します。 このようにして、そして、その時々で、FDTデータベースの内容は受信機のファイル配送セッションのFDTの現在の視点を表します。 想定されてください。以来各受信機が他の受信機の如何にかかわらず振る舞って、それがSHOULD NOTである、与えられたファイル配送セッションのすべての受信機に、FDTデータベースのコンテンツは同じです。
Since FDT database is an abstract concept, the structure and the maintaining of the FDT database are left to individual implementations and are thus out of scope of this specification.
FDTデータベースが抽象概念であるので、その結果、FDTデータベースの構造と維持は、個々の実装に残されて、この仕様の範囲の外にあります。
3.3. Dynamics of FDT Instances within file delivery session
3.3. ファイル配送セッション中のFDT Instancesの力学
The following rules define the dynamics of the FDT Instances within a file delivery session:
以下の規則はファイル配送セッション以内にFDT Instancesの力学を定義します:
* 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.
* ファイル配送セッション以内に提供されたあらゆるファイルのために、セッション中に送られた少なくとも1FDT Instanceに含まれていたファイル記述項があるに違いありません。 ファイル記述項は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 Instanceはファイル配送セッションのどんな部分にも現れるかもしれません、そして、FDT Instanceのためのパケットはセッション以内に他のファイルか他のFDT Instancesのためにパケットではさみ込まれるかもしれません。
* 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.
* FDT Instancesの配送のために'0'のTOI値を予約しなければなりません。 この仕様の範囲の外に他のTOI値のFDT Instancesの使用があります。
Paila, et al. Experimental [Page 9] RFC 3926 FLUTE October 2004
Paila、他 実験的な[9ページ]RFC3926は2004年10月にフルートを吹かせます。
* 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 Instanceは新しい固定長LCT Header Extension EXT_FDT(後でこのセクションで定義される)の使用で特定されます。 各FDT Instanceはファイル配送セッション中にFDT Instance IDによって唯一特定されます。 FDT Instance(戸井=0で、示される)を運ぶどんなALC/LCTパケットもEXT_FDTを含まなければなりません。
* It is RECOMMENDED that FDT Instance that contains the file
description entry for a file is sent prior to the sending of the
described file within a file delivery session.
* ファイル配送セッション以内に説明されたファイルの発信の前にファイルのためのファイル記述項を含むFDT Instanceを送るのは、RECOMMENDEDです。
* Within a file delivery session, any TOI > 0 MAY be described more
than once. An example: previous FDT Instance 0 describes TOI of
value '3'. Now, subsequent FDT Instances can either keep TOI '3'
unmodified on the table, not include it, or complement the
description. However, subsequent FDT Instances MUST NOT change
the parameters already described for a specific TOI.
* ファイル配送セッション以内に、どんなTOI>0も一度より説明されるかもしれません。 例: 前のFDT Instance0は価値'3'のTOIについて説明します。 今、その後のFDT Instancesはそれを含んでいるのではなく、TOI'3'をテーブルで変更されているように保たないか、または記述の補足となることができます。 しかしながら、その後のFDT Instancesは特定のTOIのために既に説明されたパラメタを変えてはいけません。
* An FDT Instance is valid until its expiration time. The
expiration time is expressed within the FDT Instance payload as a
32 bit data field. The value of the data field represents the 32
most significant bits of a 64 bit Network Time Protocol (NTP) [5]
time value. These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900. Handling of wraparound of the 32 bit time is outside the
scope of NTP and FLUTE.
* FDT Instanceは満了時間まで有効です。 満了時間は32ビットのデータ・フィールドとしてFDT Instanceペイロードの中に表されます。 データ・フィールドの値は64ビットのNetwork Timeプロトコル(NTP)[5]時間的価値の32の最上位ビットを表します。 これらの32ビットは秒に0時間の1900年1月1日に比例して時間を表す符号のない整数を提供します。 NTPとFLUTEの範囲の外に32ビットの倍の巻きつけて着るドレスの取り扱いがあります。
* The receiver SHOULD NOT use a received FDT Instance to interpret
packets received beyond the expiration time of the FDT Instance.
* 受信機SHOULD NOTは、FDT Instanceの満了時間を超えたところまで受け取られたパケットを解釈するのに容認されたFDT Instanceを使用します。
* A sender MUST use an expiry time in the future upon creation of an
FDT Instance relative to its Sender Current Time (SCT).
* 送付者は将来、FDT Instanceの作成でSender Current Time(SCT)に比例して満期時間を費やさなければなりません。
* Any FEC Encoding ID MAY be used for the sending of FDT Instances.
The default is to use FEC Encoding ID 0 for the sending of FDT
Instances. (Note that since FEC Encoding ID 0 is the default for
FLUTE, this implies that Source Block Number and Encoding Symbol
ID lengths both default to 16 bits each.)
* どんなFEC Encoding IDもFDT Instancesの発信に使用されるかもしれません。 デフォルトはFDT Instancesの発信にFEC Encoding ID0を使用することです。 (これが、Source Block NumberとEncoding Symbol IDの長さがともにそれぞれ16ビットをデフォルトとするのをFEC Encoding ID0がFLUTEのためのデフォルトであることで含意することに注意してください。)
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
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
Paila, et al. Experimental [Page 10] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 10] RFC 3926 FLUTE October 2004
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.
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.
3.4. Structure of FDT Instance packets
3.4. Structure of FDT Instance packets
FDT Instances are carried in ALC packets with TOI = 0 and with an 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 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.
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.
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.
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.
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.
Paila, et al. Experimental [Page 11] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 11] RFC 3926 FLUTE October 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default LCT header (with TOI = 0) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCT header extensions (EXT_FDT, EXT_FTI, etc.) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol(s) for FDT Instance | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default LCT header (with TOI = 0) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCT header extensions (EXT_FDT, EXT_FTI, etc.) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol(s) for FDT Instance | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall FDT Packet
Figure 1 - Overall FDT Packet
3.4.1. Format of FDT Instance Header
3.4.1. Format of FDT Instance Header
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) 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:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 192 | V | FDT Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET = 192 | V | FDT Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version of FLUTE (V), 4 bits:
Version of FLUTE (V), 4 bits:
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'.
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'.
FDT Instance ID, 20 bits:
FDT Instance ID, 20 bits:
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
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
Paila, et al. Experimental [Page 12] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 12] RFC 3926 FLUTE October 2004
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.
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.
3.4.2. Syntax of FDT Instance
3.4.2. Syntax of FDT Instance
The FDT Instance contains file description entries that provide the mapping functionality described in 3.2 above.
The FDT Instance contains file description entries that provide the mapping functionality described in 3.2 above.
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").
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").
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.
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.
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.
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.
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].
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].
Paila, et al. Experimental [Page 13] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 13] RFC 3926 FLUTE October 2004
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.
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.
* Where the MIME type is described, the attribute "Content-Type"
MUST be used for the purpose as defined in [6].
* Where the MIME type is described, the attribute "Content-Type" MUST be used for the purpose as defined in [6].
* Where the length is described, the attribute "Content-Length" MUST
be used for the purpose as defined in [6]. The transfer length is
defined to be the length of the object transported in bytes. It
is often important to convey the transfer length to receivers,
because the source block structure needs to be known for the FEC
decoder to be applied to recover source blocks of the file, and
the transfer length is often needed to properly determine the
source block structure of the file. There generally will be a
difference between the length of the original file and the
transfer length if content encoding is applied to the file before
transport, and thus the "Content-Encoding" attribute is used. If
the file is not content encoded before transport (and thus the
"Content-Encoding" attribute is not used) then the transfer length
is the length of the original file, and in this case the
"Content-Length" is also the transfer length. However, if the
file is content encoded before transport (and thus the "Content-
Encoding" attribute is used), e.g., if compression is applied
before transport to reduce the number of bytes that need to be
transferred, then the transfer length is generally different than
the length of the original file, and in this case the attribute
"Transfer-Length" MAY be used to carry the transfer length.
* 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.
* Where the content encoding scheme is described, the attribute
"Content-Encoding" MUST be used for the purpose as defined in [6].
* Where the content encoding scheme is described, the attribute "Content-Encoding" MUST be used for the purpose as defined in [6].
* Where the MD5 message digest is described, the attribute
"Content-MD5" MUST be used for the purpose as defined in [6].
* Where the MD5 message digest is described, the attribute "Content-MD5" MUST be used for the purpose as defined in [6].
* The FEC Object Transmission Information attributes as described in
section 5.2.
* The FEC Object Transmission Information attributes as described in section 5.2.
The following specifies the XML Schema [8][9] for FDT Instance:
The following specifies the XML Schema [8][9] for FDT Instance:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fl="http://www.example.com/flute"
elementFormDefault:xs="qualified"
targetNamespace:xs="http://www.example.com/flute">
<xs:element name="FDT-Instance">
<xs:complexType>
<xs:sequence>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fl="http://www.example.com/flute" elementFormDefault:xs="qualified" targetNamespace:xs="http://www.example.com/flute"> <xs:element name="FDT-Instance"> <xs:complexType> <xs:sequence>
Paila, et al. Experimental [Page 14] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 14] RFC 3926 FLUTE October 2004
<xs:element name="File" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="Content-Location"
type="xs:anyURI"
use="required"/>
<xs:attribute name="TOI"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="Content-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Transfer-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-MD5"
type="xs:base64Binary"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:element name="File" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="Content-Location" type="xs:anyURI" use="required"/> <xs:attribute name="TOI" type="xs:positiveInteger" use="required"/> <xs:attribute name="Content-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="Transfer-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="Content-Type" type="xs:string" use="optional"/> <xs:attribute name="Content-Encoding" type="xs:string" use="optional"/> <xs:attribute name="Content-MD5" type="xs:base64Binary" use="optional"/> <xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong" use="optional"/> <xs:anyAttribute processContents="skip"/> </xs:complexType> </xs:element> </xs:sequence>
<xs:attribute name="Expires"
type="xs:string"
use="required"/>
<xs:attribute name="Complete"
type="xs:boolean"
<xs:attribute name="Expires" type="xs:string" use="required"/> <xs:attribute name="Complete" type="xs:boolean"
Paila, et al. Experimental [Page 15] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 15] RFC 3926 FLUTE October 2004
use="optional"/>
<xs:attribute name="Content-Type"
type="xs:string"
use="optional"/>
<xs:attribute name="Content-Encoding"
type="xs:string"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Encoding-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-FEC-Instance-ID"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Encoding-Symbol-Length"
type="xs:unsignedLong"
use="optional"/>
<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols"
type="xs:unsignedLong"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
use="optional"/> <xs:attribute name="Content-Type" type="xs:string" use="optional"/> <xs:attribute name="Content-Encoding" type="xs:string" use="optional"/> <xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/> <xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong" use="optional"/> <xs:anyAttribute processContents="skip"/> </xs:complexType> </xs:element> </xs:schema>
Any valid FDT Instance must use the above XML Schema. This way FDT provides extensibility to support private attributes within the file description entries. Those could be, for example, the attributes related to the delivery of the file (timing, packet transmission rate, etc.).
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.).
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.
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.
3.4.3. Content Encoding of FDT Instance
3.4.3. Content Encoding of FDT Instance
The FDT Instance itself MAY be content encoded, for example 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
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
Paila, et al. Experimental [Page 16] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 16] RFC 3926 FLUTE October 2004
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:
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:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 193 | CENC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET = 193 | CENC | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Content Encoding Algorithm (CENC), 8 bits:
Content Encoding Algorithm (CENC), 8 bits:
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].
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].
Reserved, 16 bits:
Reserved, 16 bits:
This field MUST be set to all '0'.
This field MUST be set to all '0'.
3.5. Multiplexing of files within a file delivery session
3.5. Multiplexing of files within a file delivery session
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.
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.
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.
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.
Paila, et al. Experimental [Page 17] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 17] RFC 3926 FLUTE October 2004
4. Channels, congestion control and timing
4. Channels, congestion control and timing
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
ALC/LCT has a concept of channels and congestion control. There are four scenarios FLUTE is envisioned to be applied.
(a) Use a single channel and a single-rate congestion control
protocol.
(a) Use a single channel and a single-rate congestion control protocol.
(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) Use multiple channels and a multiple-rate congestion control protocol. In this case the FDT Instances MAY be delivered on more than one channel.
(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) 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.
(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) 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.
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.
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.
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.
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.
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:
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:
1. The layers to which packets for FDT Instances are sent SHOULD NOT
be biased towards those layers to which lower rate receivers are
not joined. For example, it is ok to put all the packets for an
FDT Instance into the lowest layer (if this layer carries enough
1. 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
Paila, et al. Experimental [Page 18] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 18] RFC 3926 FLUTE October 2004
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.
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.
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. 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.
5. Delivering FEC Object Transmission Information
5. Delivering FEC Object Transmission Information
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 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.
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.
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.
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.
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.
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).
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).
1. FEC Object Transmission Information that is available in EXT_FTI.
1. FEC Object Transmission Information that is available in EXT_FTI.
2. FEC Object Transmission Information that is available in the FDT.
2. FEC Object Transmission Information that is available in the FDT.
Paila, et al. Experimental [Page 19] RFC 3926 FLUTE October 2004
Paila, et al. Experimental [Page 19] RFC 3926 FLUTE October 2004
5.1. Use of EXT_FTI for delivery of FEC Object Transmission Information
5.1. Use of EXT_FTI for delivery of FEC Object Transmission Information
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.
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.
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.
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.
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header.
In FLUTE, the FEC Encoding ID (8 bits) is carried in the Codepoint field of the ALC/LCT header.
5.1.1. General EXT_FTI format
5.1.1. General EXT_FTI format
The general EXT_FTI format specifies the structure and those attributes of FEC Object Transmission Information that are applicable to any FEC Encoding ID.
The general EXT_FTI format specifies the structure and those attributes of FEC Object Transmission Information that are applicable to any 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Instance ID | FEC Enc. ID Specific Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 興奮の=64| ヘル| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 転送の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Instance ID| FEC Enc。 IDの特定の形式| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Type (HET), 8 bits:
8ビットのヘッダーExtension Type(HET):
64 as defined in [2].
64 [2]で定義されるように。
Header Extension Length (HEL), 8 bits:
8ビットのヘッダーExtension Length(HEL):
Paila, et al. Experimental [Page 20] RFC 3926 FLUTE October 2004
Paila、他 実験的な[20ページ]RFC3926は2004年10月にフルートを吹かせます。
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This length includes the FEC Encoding ID specific format part.
32ビットの単語の倍数で言い表された全体のHeader Extension分野の長さ。 この長さはFEC EncodingのIDの特定の形式部分を含んでいます。
Transfer Length, 48 bits:
Length、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:
16ビットの任意のFEC Instance ID:
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:
IDの特定の形式をコード化するFEC:
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 No.0、128、129、および130にこの分野の構造を指定します。
5.1.2. FEC Encoding ID specific formats for EXT_FTI
5.1.2. EXT_FTIのためのFEC EncodingのIDの特定の形式
5.1.2.1. FEC Encoding IDs 0, 128, and 130
5.1.2.1. ID0、128、および130をコード化するFEC
FEC Encoding ID 0 is 'Compact No-Code FEC' (Fully-Specified) [7]. FEC Encoding ID 128 is 'Small Block, Large Block and Expandable FEC' (Under-Specified) [4]. FEC Encoding ID 130 is 'Compact FEC' (Under- Specified) [7]. For these FEC Encoding IDs, the FEC Encoding ID specific format of EXT_FTI is defined as follows.
FEC Encoding ID0は'コンパクトなコードがないFEC'(完全に指定する)[7]です。 FEC Encoding ID128は'小さいBlock、Large Block、およびExpandable FEC'(下で指定する)[4]です。 FEC Encoding ID130は'コンパクトなFEC'(下は指定した)[7]です。 これらのFEC Encoding IDにおいて、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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+++++++++++++++++一般EXT_FTI形式| シンボルの長さをコード化します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のソースブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
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
輸送オブジェクトのすべてのEncoding Symbolsがこの長さと等しいに違いありません、最後のソースブロックの最後のソースシンボルの任意の例外で(したがって、その余分な詰め物はこれで義務的ではありません。
Paila, et al. Experimental [Page 21] RFC 3926 FLUTE October 2004
Paila、他 実験的な[21ページ]RFC3926は2004年10月にフルートを吹かせます。
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がこのソースシンボルに基づいて送付者と受信機でこのEncoding Symbol価値の同じ解釈を確実にするために計算されるとき、ゼロでこの最後のソースシンボルを論理的に広げなければなりません。しかしながら、実際に最後のソースシンボルに関するデータと共にこの詰め物によって送られる必要はありません。
Maximum Source Block Length, 32 bits:
最大のSource Block Length、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 Instanceの中で)によって特定されたファイルを運ぶ輸送オブジェクトのすべてのソースブロックのサイズを決定するための送付者と受信機の両方に知られているのを必要とします。 アルゴリズムSHOULD、すべてのファイルにおいて、セッション以内に同じFEC Encoding IDを使用するのにおいて同じであってください。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use.
セクション5.1 .2 .3 この使用のためにRECOMMENDEDであるアルゴリズムを説明します。
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に関しては、ID0、128、および130であり、このアルゴリズムは受信機がそれぞれのソースブロックの長さを測定できる唯一のよく知られている方法です。 したがって、アルゴリズムは2つのことをします: (a) そのソースブロックにパケットを受けているとき、それはそれぞれの特定のソースブロックの長さの受信機を言います--これはこれらのFEC体系のすべてに不可欠です。 (b) そして、それは、受信機が、どこで節約するかはデータ・パケットのレセプションの始めにファイルのためにソースブロックを回収しました--これがいくつかの実装に、不可欠の最適化であることを決定できるように、ソースブロック構造をすぐ受信機に供給します。
5.1.2.2. FEC Encoding ID 129
5.1.2.2. ID129をコード化するFEC
Small Block Systematic FEC (Under-Specified). The FEC Encoding ID specific format of EXT_FTI is defined as follows.
小さいブロック系統的な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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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+++++++++++++++++一般EXT_FTI形式| シンボルの長さをコード化します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のソースブロック長| マックス。 ヌムシンボルをコード化するのについて| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding Symbol Length, 16 bits:
Symbol Lengthをコード化する16ビット:
Length of Encoding Symbol in bytes.
バイトで表現されるEncoding Symbolの長さ。
Paila, et al. Experimental [Page 22] RFC 3926 FLUTE October 2004
Paila、他 実験的な[22ページ]RFC3926は2004年10月にフルートを吹かせます。
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 Symbolsがこの長さと等しいに違いありません、最後のソースブロックの最後のソースシンボルの任意の例外で(余分な詰め物がこの最後のシンボルで義務的でないように)。 別のEncoding Symbolがこのソースシンボルに基づいて送付者と受信機でこのEncoding Symbol価値の同じ解釈を確実にするために計算されるとき、ゼロでこの最後のソースシンボルを論理的に広げなければなりません。しかしながら、実際に最後のソースシンボルに関するデータと共にこの詰め物を送る必要はありません。
Maximum Source Block Length, 16 bits:
最大のSource Block Length、16ビット:
The maximum number of source symbols per source block.
ソースブロックあたりのソースシンボルの最大数。
Maximum Number of Encoding Symbols, 16 bits:
Encoding Symbols、最大16ビットのNumber:
Maximum number of Encoding Symbols that can be generated for a source block.
ソースブロックに生成することができるEncoding Symbolsの最大数。
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 Instanceの中で)によって特定されたファイルを運ぶ輸送オブジェクトのすべてのソースブロックのサイズを決定するための送付者と受信機の両方に知られているのを必要とします。 アルゴリズムSHOULD、すべてのファイルにおいて、セッション以内に同じFEC Encoding IDを使用するのにおいて同じであってください。
Section 5.1.2.3 describes an algorithm that is RECOMMENDED for this use. For FEC Encoding ID 129 the FEC Payload ID in each data packet already contains the source block length for the source block corresponding to the Encoding Symbol carried in the data packet. Thus, the algorithm for computing source blocks for FEC Encoding ID 129 could be to just use the source block lengths carried in data packets within the FEC Payload ID. However, the algorithm described in Section 5.1.2.3 is useful for the receiver to compute the source block structure at the beginning of the reception of data packets for the file. If the algorithm described in Section 5.1.2.3 is used then it MUST be the case that the source block lengths that appear in data packets agree with the source block lengths calculated by the algorithm.
セクション5.1 .2 .3 この使用のためにRECOMMENDEDであるアルゴリズムを説明します。 FEC Encoding ID129のために、各データ・パケットのFEC Payload IDは既にデータ・パケットで運ばれたEncoding Symbolに対応するソースブロックでソースブロック長を含んでいます。 したがって、FEC Encoding ID129のためのソースブロックを計算するためのアルゴリズムはただFEC Payload IDの中でデータ・パケットで運ばれたソースブロック長を使用することであることができました。 しかしながら、受信機がデータ・パケットのレセプションの始めにファイルのためにソースブロック構造を計算するように、アルゴリズム説明されたコネセクション5.1.2.3は役に立ちます。 アルゴリズムであるなら、セクション5.1.2で説明されて、.3は使用されています、そして、データ・パケットに現れるソースブロック長がアルゴリズムによって計算されたソースブロック長に同意するのが、事実であるに違いありません。
5.1.2.3. Algorithm for Computing Source Block Structure
5.1.2.3. ソースブロック構造を計算するためのアルゴリズム
This algorithm computes a source block structure so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are sent of the same smaller length. The total number of source blocks (N), the first number of
このアルゴリズムがソースブロック構造を計算するので、すべてのソースブロックができるだけ等しい長さであることの近くにあります。 最初の数のソースブロックは同じより大きい長さのものです、そして、同じよりわずかな長さについて2番目の残っている数のソースブロックを送ります。 ソースの数が(N)、最初の数を妨げる合計
Paila, et al. Experimental [Page 23] RFC 3926 FLUTE October 2004
Paila、他 実験的な[23ページ]RFC3926は2004年10月にフルートを吹かせます。
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)、2番目の数のソースブロック(N-I)、より大きい長さ(_多)、および、よりわずかな長さの出典を明示してください、(_小さい)、このようにして計算されます。
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
以下を入力してください。 バイトでSymbol Lengthをコード化して、B(すなわち、最大のSource Block Length、ソースブロックLあたりのソースシンボルの最大数)はバイトEでLengthを移します。
Output:
N -- The number of source blocks into which the transport
object is partitioned.
出力: N--輸送オブジェクトが仕切られるソースブロックの数。
The number and lengths of source symbols in each of the N
source blocks.
それぞれのNソースブロックのソースシンボルの数と長さ。
Algorithm:
(a) The number of source symbols in the transport object is
computed as T = L/E rounded up to the nearest integer.
(b) The transport object is partitioned into N source blocks,
where N = T/B rounded up to the nearest integer
(c) The average length of a source block, A = T/N
(this may be non-integer)
(d) A_large = A rounded up to the nearest integer
(it will always be the case that the value of A_large is at
most B)
(e) A_small = A rounded down to the nearest integer
(if A is an integer A_small = A_large,
and otherwise A_small = A_large - 1)
(f) The fractional part of A, A_fraction = A - A_small
(g) I = A_fraction * N
(I is an integer between 0 and N-1)
(h) Each of the first I source blocks consists of A_large source
symbols, each source symbol is E bytes in length. Each of the
remaining N-I source blocks consist of A_small source symbols,
each source symbol is E bytes in length except that the last
source symbol of the last source block is L-(((L-1)/E) rounded
down to the nearest integer)*E bytes in length.
アルゴリズム: (a) 輸送オブジェクトのソースシンボルの数は最も近い整数まで一周したT=L/Eとして計算されます。 (b) 輸送オブジェクトはNソースブロックに仕切られます; Nが最も近い整数に丸いT/N(これは非整数であるかもしれない)(d)のA_の大きいソースブロック、平均した長さのA==Aが_小さく最も近い整数(A_多大の値が高々Bであることはいつも事実になる)(e)Aまで一周した中で最も近い整数(c)=下であるまで一周したT/Bと等しいところでは、(Aであるなら、整数A_小さい=A_多く、およびそうでなければ、A_の小さい=A_が大きいです--1)という断片的が分けるAの(f); _断片はAと等しいです--(h) それぞれIソースが妨げる1つの番目ものの_の小さい(g)I=_断片*N(Iは0とN-1の間の整数です)はA_の大きいソースシンボルから成って、それぞれのソースシンボルは長さがEバイトです。 それぞれの残っているN-IソースブロックはA_の小さいソースシンボルから成って、それぞれのソースシンボルは長さが最後のソースブロックの最後のソースシンボルがL(最も近い整数まで一周した(L-1)/E))*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.
注意、このアルゴリズムは浮動小数点演算で実装を含意しません、そして、整数演算は、潜在的浮動小数点丸め誤差を避けるのに使用されるかもしれません。
Paila, et al. Experimental [Page 24] RFC 3926 FLUTE October 2004
Paila、他 実験的な[24ページ]RFC3926は2004年10月にフルートを吹かせます。
5.2. Use of FDT for delivery of FEC Object Transmission Information
5.2. FDTのFEC Object Transmission情報の配送の使用
The FDT delivers FEC Object Transmission Information for each file using an appropriate attribute within the "FDT-Instance" or the "File" element of the FDT structure. For future FEC Encoding IDs, if the attributes listed below do not fulfill the needs of describing the FEC Object Transmission Information then additional new attributes MAY be used.
FDTは、「FDT-インスタンス」かFDT構造の「ファイル」要素の中で適切な属性を使用することで各ファイルのための情報をFEC Object Transmissionに提供します。 将来のFEC Encoding IDのために、以下に記載された属性がFEC Object Transmission情報について説明する必要性を実現させないなら、追加新しい属性は使用されるかもしれません。
* "Transfer-Length" is semantically equivalent with the field
"Transfer Length" of EXT_FTI.
* 「転送長さ」はEXT_FTIの分野「転送の長さ」ゆえ意味的に同等です。
* "FEC-OTI-FEC-Encoding-ID" is semantically equivalent with the
field "FEC Encoding ID" as carried in the Codepoint field of the
ALC/LCT header.
* 「IDをコード化するFEC-OTI-FEC」は分野「IDをコード化するFEC」ゆえALC/LCTヘッダーのCodepoint分野で運ばれるように意味的に同等です。
* "FEC-OTI-FEC-Instance-ID" is semantically equivalent with the
field "FEC Instance ID" of EXT_FTI.
* 「FEC-OTI-FEC Instance ID」はEXT_FTIの分野「FECインスタンスID」ゆえ意味的に同等です。
* "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
with the field "Maximum Source Block Length" of EXT_FTI for FEC
Encoding IDs 0, 128 and 130, and semantically equivalent with the
field "Maximum Source Block Length" of EXT_FTI for FEC Encoding ID
129.
* 「FEC-OTIの最大のソースブロックの長さ」は、分野EXT_FTIの「最大のソースブロック長」ゆえFEC Encoding ID0、128、および130に意味的に同等であって、FEC Encoding ID129に、分野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」はFEC Encoding ID0、128、129、および130のためにEXT_FTIについて「シンボルの長さをコード化する」分野で意味的に同等です。
* "FEC-OTI-Max-Number-of-Encoding-Symbols" is semantically
equivalent with the field "Maximum Number of Encoding Symbols" of
EXT_FTI for FEC Encoding ID 129.
* 分野「最大数のコード化シンボル」によって、FEC Encoding ID129に、「コード化シンボルのFEC-OTIマックスNumber」はEXT_FTIで意味的に同等です。
6. Describing file delivery sessions
6. ファイル配送セッションについて説明します。
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;
* セッションにおける、チャンネルの数。
Paila, et al. Experimental [Page 25] RFC 3926 FLUTE October 2004
Paila、他 実験的な[25ページ]RFC3926は2004年10月にフルートを吹かせます。
* The destination IP address and port number for each channel in the
session;
* セッションにおける各チャンネルのための送付先IPアドレスとポートナンバー。
* The Transport Session Identifier (TSI) of the session;
* セッションのTransport Session Identifier(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をどんな使用で暗黙です、そして、これはセッションが1個以上のオブジェクトのためにパケットを運ぶかどうか(すべてのFLUTEセッションが1個以上のオブジェクトのためにパケットを運びます)しるしのALC要件を実現させます。
Optionally, the following parameters MAY be associated with the
session (Note, the list is not exhaustive):
任意に、以下のパラメタはセッションに関連しているかもしれません(注意、リストは徹底的ではありません):
* The start time and end time of the session;
* セッションの開始時刻と終わりの時間。
* FEC Encoding ID and FEC Instance ID when the default FEC Encoding
ID 0 is not used for the delivery of FDT;
* デフォルトFEC Encoding ID0がFDTの配送に使用されないFEC Encoding IDとFEC Instance ID。
* Content Encoding format if optional content encoding of FDT
Instance is used, e.g., compression;
* FDT Instanceの任意の満足しているコード化が使用されているならEncodingがフォーマットする内容、例えば、圧縮。
* 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などの)に従って説明されて、何らかのトランスポート・プロトコル(Session Announcementプロトコル[11]、メール、HTTP[6]、SIP[22]、手動のプレ構成などの)によってFLUTEセッションの前に受信機によって入手されるファイルに保持され始めるでしょう。 しかしながら、このドキュメントの範囲の外に受信機が上記のパラメタを発見する方法があります、それがLCTとALCのためのものであるときに。 この仕様は、どんなメカニズムも特に、強制もしませんし、除きもしません。
7. Security Considerations
7. セキュリティ問題
The security considerations that apply to, and are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE. In addition, any security considerations that apply to any congestion control building block used in conjunction with FLUTE also apply to FLUTE.
また、それが申し込んで、説明されるセキュリティ問題、ALC[2]、LCT[3]、およびFEC[4]はFLUTEに当てはまります。 また、さらに、FLUTEに関連して使用されるどんな混雑制御建家にも適用されるどんなセキュリティ問題もFLUTEに適用されます。
Because of the use of FEC, FLUTE is especially vulnerable to denial- of-service attacks by attackers that try to send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the FDT or file by receivers. Like ALC, FLUTE is particularly affected by such an
FECの使用のために、FLUTEは受信機でうまくいっている再建か原因を防ぐ偽造セッションまでのパケットにFDTかファイルの大半の不正確な再構成を送ろうとする攻撃者によるサービスの否定攻撃に特に被害を受け易いです。 ALCのように、FLUTEはそのようなもので特に影響を受けます。
Paila, et al. Experimental [Page 26] RFC 3926 FLUTE October 2004
Paila、他 実験的な[26ページ]RFC3926は2004年10月にフルートを吹かせます。
attack because many receivers may receive the same forged packet. A malicious attacker may spoof file packets and cause incorrect recovery of a file.
多くの受信機が同じ偽造パケットを受けるかもしれないので、攻撃してください。 悪意がある攻撃者は、ファイルパケットを偽造して、ファイルの不正確な回復を引き起こすかもしれません。
Even more damaging, a malicious forger may spoof FDT Instance packets, for example sending packets with erroneous FDT-Instance fields. Many attacks can follow this approach. For instance a malicious attacker may alter the Content-Location field of TOI 'n', to make it point to a system file or a user configuration file. Then, TOI 'n' can carry a Trojan Horse or some other type of virus. It is thus STRONGLY RECOMMENDED that the FLUTE delivery service at the receiver does not have write access to the system files or directories, or any other critical areas. As described for MIME [20][21], special consideration should be paid to the security implications of any MIME types that can cause the remote execution of any actions in the recipient's environment. Note, RFC 1521 [21] describes important security issues for this environment, even though its protocol is obsoleted by RFC 2048 [20].
さらにダメージが大きくて、例えば、誤ったFDT-インスタンス分野があるパケットを送って、悪意がある捏造者はFDT Instanceにパケットを偽造するかもしれません。 多くの攻撃がこのアプローチに続くことができます。 ''例えば、悪意がある攻撃者はTOIのContent-位置の分野を変更するかもしれません、そして、それを作るのはシステムファイルかユーザ構成ファイルを示します。 'そして、'TOIと缶はトロイの木馬かある他のタイプのウイルスを運びます。 その結果、受信機のデリバリ・サービスにはないFLUTEがシステムファイルかディレクトリへのアクセス、またはいかなる他の重要な領域も書くのは、STRONGLY RECOMMENDEDです。 MIME[20][21]のために説明されるように、受取人の環境における、どんな動作のリモート実行も引き起こす場合があるどんなMIMEの種類のセキュリティ含意にも特別の配慮を支払うべきです。 注意、RFC1521[21]はこの環境のために重要な安全保障問題について説明します、プロトコルがRFC2048[20]によって時代遅れにされますが。
Another example is generating a bad Content-MD5 sum, leading receivers to reject the associated file that will be declared corrupted. The Content-Encoding can also be modified, which also prevents the receivers to correctly handle the associated file. These examples show that the FDT information is critical to the FLUTE delivery service.
受信機が崩壊していると申告される関連ファイルを拒絶するように導いて、別の例は悪いContent-MD5合計を生成しています。 また、Content-コード化(また、正しく関連ファイルを扱うために受信機を防ぐ)を変更できます。 これらの例は、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.
アプリケーションレベルでは、それが送られたオブジェクトと同じであることを保証するためにいったんオブジェクトを再建すると全体の容認されたオブジェクトの保全チェックをするのは、RECOMMENDEDです、特にFDT Instancesであるオブジェクトのために。 そのうえ、受信機SHOULDが証明可能な強い暗号の保全保護aデジタル署名を得て、使用されて、このアプリケーションレベル保全チェックを提供してください。 しかしながら、1つの崩壊したか偽造しているパケットさえオブジェクトを再建するのに使用されると、容認されたオブジェクトは不当に再建されそうでしょう。 捨てられて、これは適切に失敗する保全チェックとこの場合不正確に再建されたオブジェクトSHOULDを引き起こすでしょう。 したがって、単一の偽造パケットの承認はオブジェクトを分配するためのサービス攻撃の有効な否定であるかもしれませんが、オブジェクト保全チェックは不正確に再建されたオブジェクトの不注意な使用を少なくとも防ぎます。 このドキュメントの範囲の外に容認されたオブジェクトのアプリケーションレベル保全チェックの仕様があります。
At the packet level, it is RECOMMENDED that a packet level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing FEC data for the object arriving from the specified sender. Packet level authentication has the advantage that corrupt or forged packets can be discarded
パケット・レベルでは、パケット・レベル認証がそれぞれの容認されたパケットが指定された送付者から届くオブジェクトのためのFECデータを含む正統の、そして、腐敗していないパケットであることを保証するのに使用されるのは、RECOMMENDEDです。 パケット・レベル認証で利点がそんなに不正になるか、または偽造パケットは捨てることができます。
Paila, et al. Experimental [Page 27] RFC 3926 FLUTE October 2004
Paila、他 実験的な[27ページ]RFC3926は2004年10月にフルートを吹かせます。
individually and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial of service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work.
そして、個別である、正確にオブジェクトを再建するのに容認された認証されたパケットを使用できます。 したがって、偽造パケットを注入するサービス不能攻撃の効果はオブジェクトサイズではなく、偽造パケットの数だけに比例しています。 現在、マルチキャストパケット・レベル認証をする方法を指定するIETF規格が全くありませんが、テスラ[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.
また、不正確なオブジェクトの再建に対する保護を提供することに加えて、パケット・レベル認証は複数のレート輻輳制御のときにサービス不能攻撃に対する何らかの保護を提供できます。 攻撃者はマルチキャストストリームへの不正確な混雑制御情報を偽造パケットに注射しようとすることができます、その結果、潜在的に、攻撃のネットワーク要素と受信機川下にまして、かなり悪影響を与えます。ネットワークと他の受信機の残り。 したがって、また、パケット・レベル認証がそのような攻撃から守るのに使用されるのは、RECOMMENDEDです。 また、そのような攻撃でもたらされた損害を制限するのにテスラ[14]をある程度使用できます。 しかしながら、テスラと共に、受信機は、それが受け取られていた数秒後にパケットが正統であるかどうか決定できるだけです、そして、その結果、受信機がセッションレセプション率を減速させるために反応できる前に混雑制御プロトコルに対する攻撃は数秒間、有効である場合があります。
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
逆のPath Forwardingチェック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.
複数のレート混雑制御建家の不正確であるか崩壊した実装がある受信機は、送付者と受信機の間の経路のネットワークの健康に影響して、また、セッションに接合された他の受信機のレセプション率に影響するかもしれません。 したがって、彼らが記述がセッションに参加する必要があったSessionを受ける前に受信機が、自分たちが正統であると認識しなければならないのは、RECOMMENDEDです。 このドキュメントの範囲の外に受信機が、自分たちが正統であるとどう認識するかがあります。
Another vulnerability of FLUTE is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure
FLUTEの別の脆弱性はセッションのために不正確なSession記述を得る受信機の可能性です。 この結果は間違ったSession記述がある正統の受信機が正しくセッション内容を受け取ろうとすることができないか、または受信機がそれらができるよりはるかに高いレートでうっかり受信しようとするということであるかもしれません、その結果、ネットワークの一部でトラフィックを混乱させます。 対策が受信機が不正確なSession記述を受け入れるのを防ぐために実施されるのは、これらの問題を避けるためには、RECOMMENDEDです、例えば、確実にするソース認証を使用することによって
Paila, et al. Experimental [Page 28] RFC 3926 FLUTE October 2004
Paila、他 実験的な[28ページ]RFC3926は2004年10月にフルートを吹かせます。
that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
受信機は認可された送付者から正統のSession記述を受け入れるだけです。 このドキュメントの範囲の外にこれがどう完了しているかがあります。
8. IANA Considerations
8. IANA問題
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登録を必要とします。
9. Acknowledgements
9. 承認
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.
以下の人々はこの仕様に貢献しました: ブライアン・アダムソン、ハンドレー、Esa Jalonen、ロジャー・カーモード、ユハ-ペッカLuoma、ヤニPeltotalo、サミPeltotalo、Topi Pohjolainen、およびロレンツォVicisanoをマークしてください。 作者は彼らの貴重な仕事についてこの仕様に関するフィードバックを見直して、提供する際にすべての貢献者に感謝したがっています。
Normative References
引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[2] Luby、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、「非同期な層にされたコード化(ALC)は具体化について議定書の中で述べます」、RFC3450、2002年12月。
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,
and J. Crowcroft, "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002.
[3] Luby(M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「コード化輸送(LCT)ブロックを層にしました」、RFC3451、2002年12月。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002.
[4]Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(2002年12月)。
[5] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[5] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月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] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[7] Luby, M. and L. Vicisano, "Compact Forward Error Correction
(FEC) Schemes", RFC 3695, February 2004.
[7]LubyとM.とL.Vicisano、「コンパクトな前進型誤信号訂正(FEC)体系」、RFC3695、2004年2月。
Paila, et al. Experimental [Page 29] RFC 3926 FLUTE October 2004
Paila、他 実験的な[29ページ]RFC3926は2004年10月にフルートを吹かせます。
[8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C Recommendation, May 2001.
[8] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造」(W3C推薦)は2001がそうするかもしれません。
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
Recommendation, May 2001.
[9] ビロン、P.、およびA.Malhotra、「XML図式第2部:」 「データ型式」(W3C推薦)は2001がそうするかもしれません。
Informative References
有益な参照
[10] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[10] ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[11] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[12] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[12] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[13] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[13] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[14] Perrig, A., Canetti, R., Song, D., and J. Tygar, "Efficient and
Secure Source Authentication for Multicast, Network and
Distributed System Security Symposium, NDSS 2001, pp. 35-46.",
February 2001.
[14]Perrig、A.、カネッティ、R.、Song、D.、そして、J.Tygar、「効率的である、MulticastとNetworkとDistributed System Security Symposium、NDSS2001年のSecure Source Authentication、ページ、」 「35-46」 2001年2月。
[15] Holbrook, H., "A Channel Model for Multicast, Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California", August 2001.
H.、「マルチキャストのためのチャンネルモデル、博士号Dissertation、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア」2001年8月の[15]ホルブルック。
[16] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[16] ドイツ語、P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[17] Deutsch, P., "GZIP file format specification version 4.3", RFC
1952, May 1996.
[17] ドイツ語、P.、「GZIPは1996年5月に書式仕様バージョン4.3インチ、RFC1952をファイルします」。
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[18]、RFC3851、2004年7月。
[19] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[19] イーストレーク、D.、Reagle、J.、およびD.は独奏されて、「(拡張マークアップ言語)XML-署名構文と処理」(RFC3275)は2002を行進させます。
[20] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC
2048, November 1996.
解放された[20]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
Paila, et al. Experimental [Page 30] RFC 3926 FLUTE October 2004
Paila、他 実験的な[30ページ]RFC3926は2004年10月にフルートを吹かせます。
[21] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 1521,
November 1996.
[21] ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC1521、1996年11月。
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
session initiation protocol", RFC 3261, June 2002.
[22] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Paila, et al. Experimental [Page 31] RFC 3926 FLUTE October 2004
Paila、他 実験的な[31ページ]RFC3926は2004年10月にフルートを吹かせます。
Appendix A. Receiver operation (informative)
付録A.Receiver操作(有益)です。
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 Symbolsを含む適切なセットのパケットを受け取ったとき、オブジェクトを回収できます。 適切なセットのパケットはFEC Encoding IDとFEC Instance IDの所有地と、そして、FEC Object Transmission情報に含まれた他の情報に依存しています。
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があるFDT Instanceであり、受信機がインスタンスのペイロードを分析する、'、FDT、それに従って、FDTデータベースをアップデートします。 受信機はファイル配送セッション以内にEXT_FDTヘッダー拡張子でFDT Instancesを特定します。 EXT_FDTヘッダー拡張子を使用することで提供されるどんなオブジェクトもFDT Instance IDによって唯一特定されたFDT Instanceです。 TOI'0'がFDT配送のために排他的に予約されることに注意してください。
7. If the object recovered is not an FDT Instance but a file, the
receiver looks up its FDT database to get the properties described
in the database, and assigns file with the given properties. The
receiver also checks that received content length matches with the
7. 回収されたオブジェクトがFDT Instanceではなく、ファイルであるなら、受信機はデータベースで特性について説明させるためにFDTデータベースを調べます、そして、案配は与えられた特性でファイルされます。 また、受信機は長さが合わせるその受信された内容をチェックします。
Paila, et al. Experimental [Page 32] RFC 3926 FLUTE October 2004
Paila、他 実験的な[32ページ]RFC3926は2004年10月にフルートを吹かせます。
description in the database. Optionally, if MD5 checksum has been
used, the receiver checks that calculated MD5 matches with the
description in the FDT database.
データベースにおける記述。 任意に、MD5チェックサムが使用されたなら、受信機は、計算されたMD5がFDTデータベースにおける記述に合わせるのをチェックします。
8. The actions the receiver takes with imperfectly received files
(missing data, mismatching digestive, etc.) is outside the scope
of this specification. When a file is recovered before the
associated file description entry is available, a possible
behavior is to wait until an FDT Instance is received that
includes the missing properties.
8. この仕様の範囲の外に受信機が不完全に受信されたファイル(欠測値、消化していた状態でミスマッチしますなど)で取る行動があります。 関連ファイル記述項が利用可能になる前にファイルが回収されるとき、なくなった特性を含んでいるFDT Instanceが受け取られているまでの待ちには可能な振舞いがあります。
9. If the file delivery session end time has not been reached go back
to 3. Otherwise end.
9. ファイル配送終わりの時間セッションに達していないなら、3に戻ってください。 さもなければ、終わってください。
Appendix B. Example of FDT Instance (informative)
FDTインスタンスに関する付録B.の例(有益)です。
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl="http://www.example.com/flute"
xsi:schemaLocation="http://www.example.com/flute-fdt.xsd"
Expires="2890842807">
<File
Content-Location="http://www.example.com/menu/tracklist.html"
TOI="1"
Content-Type="text/html"/>
<File
Content-Location="http://www.example.com/tracks/track1.mp3"
TOI="2"
Content-Length="6100"
Content-Type="audio/mp3"
Content-Encoding="gzip"
Content-MD5="+VP5IrWploFkZWc11iLDdA=="
Some-Private-Extension-Tag="abc123"/>
</FDT-Instance>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><FDT-インスタンスxmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xmlnsと等しいです: flは" http://www.example.com/flute "xsiと等しいです:; 「" http://www.example.com/flute-fdt.xsd "が吐き出すschemaLocation=が」 「2890842807><ファイル内容「><ファイル内容位置=" http://www.example.com/menu/tracklist.html "TOI=「1インチのコンテントタイプ=」テキスト/html」/位置=" http://www.example.com/tracks/track1.mp3 "TOI=「2インチのコンテンツの長さ=」6100」コンテントタイプ=「オーディオの、または、mp3"内容をコード化する="gzip"内容MD5=」+VP5IrWploFkZWc11iLDdA=いくつかと等しい、-個人的な拡大タグは></FDT"abc123"/インスタンス>と等しいです。
Paila, et al. Experimental [Page 33] RFC 3926 FLUTE October 2004
Paila、他 実験的な[33ページ]RFC3926は2004年10月にフルートを吹かせます。
Authors' Addresses
作者のアドレス
Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland
トニーPailaノキアItamerenkatu11-13ヘルシンキフィン-00180フィンランド
EMail: toni.paila@nokia.com
メール: toni.paila@nokia.com
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA 94538 USA
Suite300フレモント、マイケルLubyのデジタル噴水39141Civic Centerカリフォルニア94538米国博士
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
Rami Lehtonen TeliaSonera Hatanpaan valtatie 18 Tampere FIN-33100 Finland
枝レヒトネンTeliaSonera Hatanpaan valtatie18タンペレFIN-33100フィンランド
EMail: rami.lehtonen@teliasonera.com
メール: rami.lehtonen@teliasonera.com
Vincent Roca INRIA Rhone-Alpes 655, av. de l'Europe Montbonnot St Ismier cedex 38334 France
ヴィンセント・ロカ・INRIA av. de l'Europe Montbonnot通りIsmier cedex38334ローヌアルプ655(フランス)
EMail: vincent.roca@inrialpes.fr
メール: vincent.roca@inrialpes.fr
Rod Walsh Nokia Visiokatu 1 Tampere FIN-33720 Finland
ロッドウォルシュノキアVisiokatu1タンペレFIN-33720フィンランド
EMail: rod.walsh@nokia.com
メール: rod.walsh@nokia.com
Paila, et al. Experimental [Page 34] RFC 3926 FLUTE October 2004
Paila、他 実験的な[34ページ]RFC3926は2004年10月にフルートを吹かせます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Paila, et al. Experimental [Page 35]
Paila、他 実験的[35ページ]
一覧
スポンサーリンク
