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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Singletonパターンを使ってクラスのインスタンスを1つにする(共有クラスのリソースを削減する方法)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る