RFC5052 日本語訳
5052 Forward Error Correction (FEC) Building Block. M. Watson, M.Luby, L. Vicisano. August 2007. (Format: TXT=57754 bytes) (Obsoletes RFC3452) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Watson
Request for Comments: 5052 M. Luby
Obsoletes: 3452 L. Vicisano
Category: Standards Track Digital Fountain
August 2007
コメントを求めるワーキンググループM.ワトソン要求をネットワークでつないでください: 5052M.Lubyは以下を時代遅れにします。 3452年のL.Vicisanoカテゴリ: デジタル標準化過程噴水2007年8月
Forward Error Correction (FEC) Building Block
前進型誤信号訂正(FEC)ブロック
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.
このドキュメントはバルク・データ転送のためにIPマルチキャストの上で信頼性を効率的に提供する、そして/または、増大させるのにForward Error Correction(FEC)コードを使用する方法を説明します。 このドキュメントはバルク・データ転送にコード化されたデータ自体に加えてFECコードを使用するのにコミュニケートする必要がある情報の定義とその情報に関するコミュニケーションのための形式とコードの定義のためにフレームワークを定義します。 コード化されたデータ自体と伝えられた情報と'バンドの外'でコミュニケートする必要がある情報の両方が考えられます。 新しいFECコードを指定するための手順、また、それらのコードに関連している情報コミュニケーション要件を定義して、それらを登録するのはインターネットAssigned民数記Authority(IANA)に説明されます。 また、このフレームワークの中で定義されたFECコードを使用したがっているContent Deliveryプロトコルに関する要件は定義されます。 「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」と題をつけられた仲間ドキュメントは、内容を提供するためにFECコードのいくつかの応用について説明します。 このドキュメントはRFC3452を時代遅れにします。
Watson, et al. Standards Track [Page 1] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................4
3. Requirements Notation ...........................................4
4. Rationale .......................................................5
5. Applicability Statement .........................................6
6. Functionality ...................................................6
6.1. FEC Schemes ................................................8
6.2. FEC Object Transmission Information .......................10
6.2.1. Transport of FEC Object Transmission Information ...11
6.2.2. Opacity of FEC Object Transmission Information .....12
6.2.3. Mandatory FEC Object Transmission
Information Elements ...............................12
6.2.4. Common FEC Object Transmission Information
Elements ...........................................12
6.2.5. Scheme-Specific FEC Object Transmission
Information Element ................................13
6.3. FEC Payload ID ............................................13
7. FEC Scheme Specifications ......................................14
8. CDP Specifications .............................................17
9. Common Algorithms ..............................................18
9.1. Block Partitioning Algorithm ..............................18
9.1.1. First Step .........................................18
9.1.2. Second step ........................................19
10. Requirements from Other Building Blocks .......................20
11. Security Considerations .......................................20
12. IANA Considerations ...........................................21
12.1. Explicit IANA Assignment Guidelines ......................21
13. Changes from RFC 3452 .........................................22
14. Acknowledgments ...............................................23
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
1. 序論…3 2. 定義と略語…4 3. 要件記法…4 4. 原理…5 5. 適用性声明…6 6. 機能性…6 6.1. FECは計画します…8 6.2. FECオブジェクトトランスミッション情報…10 6.2.1. FECオブジェクトトランスミッション情報の輸送…11 6.2.2. FECオブジェクトトランスミッション情報の不透明…12 6.2.3. 義務的なFECオブジェクトトランスミッションInformation Elements…12 6.2.4. 一般的なFECオブジェクトトランスミッションInformation Elements…12 6.2.5. 体系特有のFECオブジェクトトランスミッション情報要素…13 6.3. FEC Payload ID…13 7. FECは仕様を計画します…14 8. CDP仕様…17 9. 一般的なアルゴリズム…18 9.1. 仕切りのアルゴリズムを妨げてください…18 9.1.1. 第一歩…18 9.1.2. 2番目に、踏んでください…19 10. 他のブロックからの要件…20 11. セキュリティ問題…20 12. IANA問題…21 12.1. 明白なIANA課題ガイドライン…21 13. RFC3452からの変化…22 14. 承認…23 15. 参照…23 15.1. 標準の参照…23 15.2. 有益な参照…23
Watson, et al. Standards Track [Page 2] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[2ページ]。
1. Introduction
1. 序論
This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content within the context of a Content Delivery Protocol (CDP). This document describes a building block as defined in [10], specifically Section 4.2 of that document, and follows the general guidelines provided in [5].
このドキュメントはContent Deliveryプロトコル(CDP)の文脈の中で内容の信頼できる配信のサポートを提供するのにForward Error Correction(FEC)コードを使用する方法を説明します。 このドキュメントは、[10]で定義されるブロック、明確にそのドキュメントのセクション4.2について説明して、[5]に提供された一般的ガイドラインに従います。
The purpose of this building block is to define a framework for forward error correction such that:
ブロックがフレームワークを定義することになっているこの目的は以下のことのようなものをエラー修正に送ります。
1. CDPs can be designed to operate with a range of different FEC
codes/schemes, without needing to know details of the specific
FEC code/scheme that may be used.
1. CDPsはさまざまな異なったFECコード/体系で作動するように設計される場合があります、使用されるかもしれない特定のFECコード/体系の詳細を知る必要はなくて。
2. FEC schemes can be designed to operate with a range of different
CDPs, without needing to know details of the specific CDPs.
2. FEC体系はさまざまな異なったCDPsと共に作動するように設計される場合があります、特定のCDPsの細部を知る必要はなくて。
Note that a 'CDP' in the context of this document may consist of several distinct protocol mechanisms and may support any kind of application requiring reliable transport -- for example, object delivery and streaming applications.
このドキュメントの文脈の'CDP'は、数個の異なったプロトコルメカニズムから成って、信頼できる輸送を必要とするどんな種類のアプリケーションもサポートするかもしれません--例えば、オブジェクト配送とストリーミング・アプリケーションに注意してください。
This document also provides detailed guidelines on how to write an RFC for an FEC scheme corresponding to a new FEC Encoding ID (for both Fully-Specified and Under-Specified FEC Schemes -- see Section 4).
また、このドキュメントは新しいFEC Encoding IDに対応するFEC体系のためにどうRFCに書くかに関する詳細なガイドラインを提供します(Fullyによって指定されてUnderによって指定の両方にされたFEC Schemesのために--セクション4を見てください)。
RFC 3452 [3], which is obsoleted by this document, contained a previous version, which was published in the "Experimental" category. RFC 3452 was published as an Experimental RFC in part due to the lack at that time of specified congestion control strategies suitable for use with Reliable Multicast protocols.
RFC3452[3](このドキュメントによって時代遅れにされる)は旧バージョンを含みました。(それは、「実験的な」カテゴリで発行されました)。 RFC3452はその時、不足のため一部Experimental RFCとしてReliable Multicastプロトコルによって使用に適した指定されたふくそう制御方式について発行されました。
This Proposed Standard specification is thus based on RFC 3452 [3] updated according to accumulated experience and growing protocol maturity since the publication of RFC 3452 [3]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
このProposed Standard仕様はその結果、RFC3452に基づいて蓄積した経験と増加しているプロトコルによると、RFC3452[3]の公表以来[3]が円熟のときにアップデートしたということです。 前述の経験はこの仕様自体と、そして、この仕様の使用に関連するふくそう制御方式に適用されます。
The differences between RFC 3452 [3] and this document are listed in Section 13.
RFC3452[3]とこのドキュメントの違いはセクション13に記載されています。
Watson, et al. Standards Track [Page 3] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[3ページ]。
2. Definitions and Abbreviations
2. 定義と略語
Object: An ordered sequence of octets to be transferred by the
transport protocol. For example, a file or stream.
オブジェクト: トランスポート・プロトコルによって移されるべき八重奏の規則正しい系列。 例えば、ファイルかストリーム。
Symbol: A unit of data processed by the Forward Error Correction
code. A symbol is always considered as a unit, i.e., it is either
completely received or completely lost.
シンボル: データのユニットはForward Error Correctionコードによって処理されました。 シンボルがユニットであるといつもみなされて、すなわち、それを完全に受け取るか、または完全に失います。
Source symbol: A symbol containing information from the original
object.
ソースシンボル: オリジナルのオブジェクトからの情報を含むシンボル。
Repair symbol: A symbol containing information generated by the FEC
code which can be used to recover lost source symbols.
シンボルを修理してください: 回復するのに使用できるFECコードによって生成された情報を含むシンボルはソースシンボルを失いました。
Encoding symbol: A source symbol or a repair symbol.
シンボルをコード化します: ソースシンボルか修理シンボル。
Encoder: The FEC scheme specific functions required to transform a
object into FEC encoded data. That is, the functions that produce
repair symbols using source symbols.
エンコーダ: 具体的な機能がオブジェクトをFECに変えるのを必要としたFEC体系はデータを暗号化しました。 すなわち、作り出される機能は、ソースシンボルを使用することでシンボルを修理します。
Decoder: The FEC scheme-specific functions required to transform
received FEC-encoded data into a copy of the original object.
デコーダ: 体系特有の機能が変形するのを必要としたFECはFECによってコード化されたデータを謄本オブジェクトに受け取りました。
Receiver: A system supporting the receiving functions of a CDP and
FEC scheme according to this specification.
受信機: この仕様通りにCDPとFEC体系の受信機能をサポートするシステム。
Sender: A system supporting the sending functions of a CDP and FEC
scheme according to this specification.
送付者: この仕様通りにCDPとFEC体系の送付機能をサポートするシステム。
Source Block: A part of the object formed from a subset of the
object's source symbols.
ソースブロック: オブジェクトの一部がオブジェクトのソースシンボルの部分集合から形成されました。
CDP: Content Delivery Protocol
CDP: 内容物配送プロトコル
FEC: Forward Error Correction
FEC: 前進型誤信号訂正
3. Requirements Notation
3. 要件記法
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
Watson, et al. Standards Track [Page 4] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[4ページ]。
4. Rationale
4. 原理
An FEC code, in the general sense, is a valuable basic component of any CDP that is to provide reliable delivery of an object. Using FEC codes is effective in the context of IP multicast and reliable delivery because FEC encoding symbols can be useful to all receivers for reconstructing an object even when the receivers have received different encoding symbols. Furthermore, FEC codes can ameliorate or even eliminate the need for feedback from receivers to senders to request retransmission of lost packets.
一般的な意味で、FECコードはオブジェクトの信頼できる配信を提供することになっているどんなCDPの貴重な基本的な部品です。 シンボルをコード化するFECが受信機が異なったコード化シンボルを受け取ったときさえオブジェクトを再建するのにおいてすべての受信機の役に立つ場合があるので、FECコードを使用するのはIPマルチキャストと信頼できる配信の文脈で有効です。 その上、FECコードは、好転するか、または受信機から送付者までのフィードバックが無くなっているパケットの「再-トランスミッション」を要求する必要性を排除さえできます。
Central to this document is the concept of an 'FEC Scheme', which we distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An FEC scheme defines the ancillary information and procedures which, combined with an FEC code or algorithm specification, fully define how the FEC code can be used with CDPs. An FEC scheme may be associated with a single standardized FEC code (A 'Fully-Specified' FEC scheme) or may be applicable to many FEC codes (An 'Under- Specified' FEC scheme).
このドキュメントに主要であるのは、'FEC Scheme'の概念です。(私たちは'FECコード'か'FECアルゴリズム'の概念とそれを区別します)。 FEC体系はFECコードかアルゴリズム仕様に結合されていた状態でCDPsと共にFECコードをどう使用できるかを完全に定義する補助的情報と手順を定義します。 FEC体系は、ただ一つの標準化されたFECコード('完全に指定された'FEC体系)に関連しているかもしれないか、または多くのFECコード('下は指定した'FEC体系)に適切であるかもしれません。
This document describes a framework for the definition of FEC schemes. Definition of actual FEC schemes is outside the scope of this document. This document also defines requirements for reliable CDPs that make use of FEC schemes. Any CDP that is compliant to the requirements specified in this document can make use of any FEC scheme that is defined within the framework described here. Note that FEC schemes may place restrictions on the types of CDP they are intended to be used with. For example, some FEC schemes may be specific to particular types of application, such as file delivery or streaming.
このドキュメントはFEC体系の定義のためにフレームワークについて説明します。 このドキュメントの範囲の外に実際のFEC体系の定義があります。 また、このドキュメントはFEC体系を利用する信頼できるCDPsのための要件を定義します。 本書では指定された要件に言いなりになっているどんなCDPもここで説明されたフレームワークの中で定義されるどんなFEC体系も利用できます。 FEC体系が使用される彼らが意図するCDPのタイプに関して制限を課すかもしれないことに注意してください。 例えば、いくつかのFEC体系が、特定のタイプのファイル配送などの適用に特定であるか、またはストリーミングであるかもしれません。
The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable CDPs and to all FEC schemes, and to leave out any additional functionality that is specific to particular CDPs or particular FEC schemes. The primary functionality described in this document that is common to all such CDPs that use FEC codes is the definition and transport of three kinds of information from sender to receiver(s):
FECブロックの目標は、直接FECコードにすべての信頼できるCDPsと、そして、すべてのFEC体系に共通の状態で関連する機能性について説明して、特定のCDPsか特定のFEC体系に特定のどんな追加機能性も省くことです。 送付者から受信機まで、本書では説明されたFECコードを使用するそのようなすべてのCDPsに共通のプライマリ機能性は、3種類の情報の定義と輸送です:
1) encoding symbols themselves,
2) ancillary information associated with encoding symbols (or
groups of such symbols, such as the group of symbols in a
single packet, or the group of symbols related to a single
source block), and
3) ancillary information associated with the whole object being
transferred.
シンボル自体をコード化する1)、2) シンボル(単一のパケットのシンボルのグループ、またはシンボルのグループなどのそのようなシンボルのグループは1つのソースブロックに関連した)、および3をコード化すると関連している補助的情報) 移す全体のオブジェクトに関連している補助的情報。
Watson, et al. Standards Track [Page 5] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[5ページ]。
It is important to note that this information is only required by the receiver if one or more of the encoding symbols to which it relates are received.
それが関係するコード化シンボルの1つか以上が受け取られている場合にだけこの情報が受信機によって必要とされることに注意するのは重要です。
This document does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are CDPs where requests for transmission are of use, there are also CDPs that do not require such requests.
このドキュメントは受信機がどうオブジェクトの特定のコード化シンボルの送信を要求するかもしれないかを説明しません。 これはCDPsがトランスミッションを求める要求が役に立つところにありますが、そのような要求を必要としないCDPsもあるからです。
The companion document [4] should be consulted for a full explanation of the benefits of using FEC codes for reliable content delivery using IP multicast. FEC codes are also useful in the context of unicast, and thus the scope and applicability of this document is not limited to IP multicast.
仲間ドキュメント[4]は、信頼できる内容物配送にFECコードを使用する利益に関する詳報のためにIPマルチキャストを使用することで参照されるべきです。 また、FECコードもユニキャストの文脈で役に立ちます、そして、その結果、このドキュメントの範囲と適用性はIPマルチキャストに限られていません。
5. Applicability Statement
5. 適用性証明
The FEC building block does not provide any support for congestion control. Any complete multicast CDP MUST provide congestion control that conforms to [6], in particular, Section 3.2 of that document. Thus, congestion control MUST be provided by another building block when the FEC building block is used in a CDP.
FECブロックは輻輳制御の少しのサポートも提供しません。 どんな完全なマルチキャストCDP MUSTもそのドキュメントのセクション3.2を[6]に特に従う輻輳制御に提供します。 FECブロックがCDPで使用されるとき、したがって、別のブロックは輻輳制御を提供しなければなりません。
A more complete description of the applicability of FEC codes can be found in the companion document [4].
仲間ドキュメント[4]でFECコードの適用性の、より完全な記述を見つけることができます。
6. Functionality
6. 機能性
This section describes FEC information that is to be sent either in packets also containing FEC encoding symbols or 'out-of-band'. The FEC information is associated with transmission of encoding symbols related to a particular object. There are three classes of packets that may contain FEC information: data packets, session-control packets, and feedback packets. They generally contain different kinds of FEC information. Note that some CDPs may not use session- control or feedback packets.
このセクションはまた、シンボルをコード化するFECを含むパケットか'バンドの外'のどちらかに送られることになっているFEC情報について説明します。 FEC情報はシンボルが特定のオブジェクトに関係づけたコード化のトランスミッションに関連しています。 FEC情報を含むかもしれない3つのクラスのパケットがあります: データ・パケット、セッション制御パケット、およびフィードバックパケット。 一般に、それらは異種のFEC情報を含んでいます。 いくつかのCDPsがセッションコントロールかフィードバックパケットを使用しないかもしれないことに注意してください。
Data packets may sometimes serve as session-control packets as well; both data and session-control packets generally travel downstream from the sender towards receivers and are sent to a multicast channel or to a specific receiver using unicast. Session-control packets may additionally travel upstream from receivers to senders.
データ・パケットはまた、セッション制御パケットとして時々機能するかもしれません。 データとセッション制御パケットの両方から一般に、川下を受信機に向かって送付者から旅して、ユニキャストを使用することでマルチキャストチャンネル、または、特定の受信機に送ります。 セッション制御パケットは受信機から送付者まで上流へさらに、移動するかもしれません。
As a general rule, feedback packets travel upstream from receivers to the sender. Sometimes, however, they might be sent to a multicast channel or to another receiver or to some intermediate node or neighboring router that provides recovery services.
概して、フィードバックパケットは受信機から送付者まで上流へ移動します。 しかしながら、時々、マルチキャストチャンネル、または、別の受信機、または、リカバリーサービスを備える何らかの中間的ノードか隣接しているルータにそれらを送るかもしれません。
Watson, et al. Standards Track [Page 6] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[6ページ]。
This document specifies both the FEC information that must be carried in data packets and the FEC information that must be communicated from sender to receiver(s) either out-of-band or in data packets. Specification of protocol mechanisms for transporting this information, for example, field and packet formats, is out of scope of this document. Instead, this document specifies at a higher level the information that must be communicated and provides detailed requirements for FEC Scheme and Content Delivery Protocol specifications, which are where the detailed field and packet formats should be defined.
このドキュメントはバンドの外かデータ・パケットのデータ・パケットで運ばなければならないFEC情報と送付者から受信機まで伝えなければならないFEC情報の両方を指定します。 このドキュメントの範囲の外にこの情報を輸送するためのプロトコルメカニズムの仕様(例えば、分野とパケット・フォーマット)は、あります。 代わりに、このドキュメントは、より高いレベルで伝えなければならない情報を指定して、FEC Schemeのための詳細な要件とContent Deliveryプロトコル仕様を提供します。(仕様は詳細な分野とパケット・フォーマットが定義されるべきであるところです)。
FEC information is classified as follows:
FEC情報は以下の通り分類されます:
1. FEC information associated with an object
1. オブジェクトに関連しているFEC情報
This is information that is essential for the FEC decoder to
decode a specific object. An example of this information is the
identity of the FEC scheme that is being used to encode the
object, in the form of the FEC Encoding ID. The FEC Encoding ID
is described further below. This information may also include
FEC scheme-specific parameters for the FEC decoder.
これはFECデコーダが特定のオブジェクトを解読するのに不可欠の情報です。 この情報に関する例はオブジェクトをコード化するのに使用されているFEC体系のアイデンティティです、FEC Encoding IDの形で。 FEC Encoding IDは以下でさらに説明されます。 また、この情報はFECデコーダのためのFECの体系特有のパラメタを含むかもしれません。
2. FEC information associated with specific encoding symbols for an
object
2. オブジェクトの特定のコード化シンボルに関連しているFEC情報
This is information that is associated with one or more encoding
symbols and is thus needed by the decoder whenever one or more of
those encoding symbols have been received. Depending on the FEC
scheme, information may be associated with individual symbols
and/or with groups of symbols. One common such grouping is the
group of symbols included within a single packet. Many FEC
schemes also segment the object being encoded into multiple
'source blocks', each of which is processed independently for FEC
purposes. Information about each source block is another type of
information associated with a group of encoding symbols -- in
this case, the group of symbols which are related to a given
source block.
これはシンボルをコード化するものの1つか以上を受け取ったときはいつも、シンボルをコード化する1つ以上に関連していて、デコーダによってこのようにして必要とされる情報です。 FEC体系によって、情報は個々のシンボルシンボルのグループに関連しているかもしれません。 ある一般的なそのような組分けが単一のパケットの中にシンボルを含むグループです。 また、多くのFECがそれぞれ複数の'ソースブロック'にコード化されるそれのオブジェクトがFEC目的のために独自に処理されるセグメントを計画します。 この場合それぞれのソースブロックに関する情報はコード化シンボルのグループに関連している別の情報の種類です、与えられたソースブロックに関連するシンボルのグループ。
Two 'containers' are provided for communicating the FEC information described above, but there is not necessarily a one-to-one correspondence between the class of FEC information and the mechanism used. The two mechanisms are:
上で情報が説明したFECを伝えますが、情報とメカニズムが使用したFECのクラスの間には、必ず1〜1つの通信がないのに2'コンテナ'を提供します。 2つのメカニズムは以下の通りです。
a. FEC Object Transmission Information
a。 FECオブジェクトトランスミッション情報
CDPs must provide a reliable mechanism for communicating certain
FEC information from sender to receiver(s). This information is
known as 'FEC Object Transmission Information' and its contents
CDPsは送付者から受信機まであるFEC情報を伝えるのに信頼できるメカニズムを提供しなければなりません。 この情報は'FEC Object Transmission情報'とそのコンテンツとして知られています。
Watson, et al. Standards Track [Page 7] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[7ページ]。
depend on the particular FEC scheme. It includes all information
of the first class above and may include information of the
second class. The FEC Object Transmission Information can be
sent to a receiver within the data packet headers, within session
control packets, or by some other means.
特定のFEC体系を当てにしてください。 それは、上の一流のすべての情報を含んでいて、二等の情報を含むかもしれません。 セッション制御パケット、またはある他の手段によるデータパケットのヘッダーの中でFEC Object Transmission情報を受信機に送ることができます。
b. FEC Payload ID
b。 FEC Payload ID
CDPs must provide a mechanism for communicating information which
identifies (for FEC purposes) the encoding symbols carried by a
packet. This information is known as the FEC Payload ID, and its
contents depend on the FEC scheme. It includes only information
of the second class above. A data packet that carries encoding
symbols MUST include an FEC Payload ID.
CDPsはパケットによって運ばれたコード化シンボルを特定する(FEC目的のために)情報を伝えるのにメカニズムを提供しなければなりません。 この情報はFEC Payload IDとして知られています、そして、内容はFEC体系によります。 それは上の二等の情報だけを含んでいます。 シンボルをコード化しながら運ばれるデータ・パケットはFEC Payload IDを含まなければなりません。
6.1. FEC Schemes
6.1. FEC体系
Two types of FEC scheme are defined by this document: 'Fully- Specified' FEC schemes and 'Under-Specified' FEC schemes. An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is formally and Fully-Specified, in a way that independent implementors can implement both encoder and decoder from a specification that is an IETF RFC.
FEC体系の2つのタイプがこのドキュメントによって定義されます: FEC体系を'完全に指定し'て、FEC体系を'下で指定しました'。 コード化体系が正式に体系であるなら、FEC体系はFullyによって指定されたFEC体系です、そして、Fullyによって指定されて、ある意味でそんなに独立している作成者はIETF RFCである仕様からエンコーダとデコーダの両方を実装することができます。
It is possible that an FEC scheme may not be a Fully-Specified FEC scheme, because either a specification is simply not available or a party exists that owns the encoding scheme and is not willing to disclose the algorithm or specification. We refer to such an FEC encoding scheme as an Under-Specified FEC scheme.
FEC体系がFullyによって指定されたFEC体系でないかもしれない可能、コード化体系を所有している、アルゴリズムか仕様を明らかにすることを望んでいないパーティーが仕様が絶対に利用可能でないか、または存在するので。 私たちはUnderによって指定されたFEC体系のような体系をコード化するFECについて言及します。
FEC schemes are identified by an FEC Encoding ID, which is an integer identifier assigned by IANA. The FEC Encoding ID allows receivers to select the appropriate FEC decoder. The value of the FEC Encoding ID MUST be the same for all transmission of encoding symbols related to a particular object, but MAY vary across different transmissions of encoding symbols about different objects, even if transmitted to the same set of multicast channels and/or using a single upper-layer session.
FEC体系はFEC Encoding IDによって特定されます。(それは、IANAによって割り当てられた整数識別子です)。 FEC Encoding IDは受信機に適切なFECデコーダを選択させます。 同じセットのマルチキャストチャンネルに伝えられてもコード化の異なったトランスミッションの向こう側に異なったオブジェクトに関するシンボルを変えるかもしれないのを除いて、特定のオブジェクトに関連するシンボルをコード化する、そして/または、ただ一つの上側の層のセッションを使用するすべてのトランスミッションに、FEC Encoding IDの値は同じであるに違いありません。
The FEC Instance ID is an integer value that identifies a specific instance of an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. The FEC Instance ID is scoped by the FEC Encoding ID, and FEC Instance ID values are subject to IANA registration.
FEC Instance IDはUnderによって指定されたFEC体系の特定のインスタンスを特定する整数値です。 この値はFullyによって指定されたFEC体系に使用されません。 FEC Instance IDはFEC Encoding IDによって見られます、そして、FEC Instance ID値はIANA登録を受けることがあります。
Watson, et al. Standards Track [Page 8] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[8ページ]。
The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are essential for the decoder to decode an object. Thus, they are part of the FEC Object Transmission Information.
デコーダがオブジェクトを解読するのにUnderによって指定されたFEC Schemesのための両方のFullyによって指定されたFEC SchemesのためのFEC Encoding ID、FEC Encoding ID、およびFEC Instance IDは不可欠です。 したがって、それらはFEC Object Transmission情報の一部です。
The following requirements apply to all FEC schemes, whether Fully- Specified or Under-Specified:
Fullyが指定したか、またはUnder指定したことにかかわらず以下の要件はすべてのFEC体系に適用されます:
o The type, semantics, and an encoding format for the FEC Payload ID
and the FEC Object Transmission Information MUST be defined.
o タイプ、意味論、およびFEC Payload IDとFEC Object Transmission情報のためのコード化形式を定義しなければなりません。
o A value for the FEC Encoding ID MUST be reserved and associated
with the types, semantics, and encoding format of the FEC Payload
ID and the FEC Object Transmission Information.
o FEC Payload IDとFEC Object Transmission情報のタイプ、意味論、およびコード化形式にFEC Encoding IDへの値を予約されて、関連づけなければなりません。
The specification for an Under-Specified FEC Scheme MAY allocate a sub-field within the Scheme-specific FEC Object Transmission Information element which is for instance-specific information. Each specific instance of the Under-Specified FEC Scheme may then use this field in an instance-specific way. The FEC scheme should define the scheme-specific FEC Object Transmission Information element in such a way that receivers that do not support the received FEC Instance ID can still parse and interpret the scheme-specific FEC Object Transmission Information element with the exception of the instance- specific field.
Underによって指定されたFEC Schemeのための仕様は例えば特殊情報であるScheme特有のFEC Object Transmission情報要素の中にサブ野原を割り当てるかもしれません。 そして、Underによって指定されたFEC Schemeのそれぞれの特定のインスタンスはインスタンス特有の方法でこの分野を使用するかもしれません。 FEC体系はインスタンスの特定の分野を除いて、容認されたFEC Instance IDをサポートしない受信機がまだ体系特有のFEC Object Transmission情報要素を分析して、解釈できるような方法で体系特有のFEC Object Transmission情報要素を定義するべきです。
An already defined Under-Specified FEC Scheme (i.e., FEC Encoding ID value) MUST be reused if the associated FEC Payload ID and FEC Object Transmission Information have the required fields and encoding formats for a new Under-Specified FEC scheme instance.
関連FEC Payload IDとFEC Object Transmission情報に新しいUnderによって指定されたFEC体系インスタンスのための必須項目とコード化形式があるなら、既に定義されたUnderによって指定されたFEC Scheme(すなわち、FEC Encoding ID価値)を再利用しなければなりません。
An instance of an Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme instance that has at least one implementation. The party that owns this tuple MUST be able to provide information on how to obtain the Under-Specified FEC scheme instance identified by the tuple, e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product.
Underによって指定されたFEC体系のインスタンスはtuple(FEC Encoding FEC Instance ID(ID))によって完全に特定されます。 tupleは少なくとも1つの実装を持っているただ一つの体系インスタンスを特定しなければなりません。 このtupleを所有しているパーティーはどうtupleと例えば、公的に利用可能な参照実装への指針か名前と別々にそれを販売する会社の接触によって特定されるか、または別の製品に埋め込まれたUnderによって指定されたFEC体系インスタンスを得るかの情報を提供できなければなりません。
This specification reserves the range 0-127 for the values of FEC Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for the values of Under-Specified FEC schemes.
この仕様はFullyによって指定されたFEC体系のためのFEC Encoding IDの値とUnderによって指定されたFEC体系の値のための範囲128-255への範囲0-127を予約します。
Watson, et al. Standards Track [Page 9] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[9ページ]。
6.2. FEC Object Transmission Information
6.2. FECオブジェクトトランスミッション情報
The FEC Object Transmission Information contains information which is essential to the decoder in order to decode the encoded object. It may also contain information which is required to decode certain groups of encoding symbols, for example, individual Source Blocks within the object. This information is communicated reliably by the CDP to the receiver(s) as described in Section 8.
FEC Object Transmission情報はコード化されたオブジェクトを解読するのにデコーダに不可欠の情報を含んでいます。 また、それはオブジェクトの中にシンボルの例えば、個々のSource Blocksをコード化するあるグループを解読するのに必要である情報を含むかもしれません。 この情報はセクション8で説明されるように受信機へのCDPによって確かに伝えられます。
The FEC Object Transmission Information may consist of several elements and each element may be one of three types, as follows:
FEC Object Transmission情報は数個の要素から成るかもしれません、そして、各要素は3つのタイプのひとりであるかもしれません、以下の通りです:
Mandatory: These elements are defined in this specification and are
each mandatory for at least one of the two types of FEC Scheme.
Each FEC scheme specifies how the values of the Mandatory FEC
Object Transmission Information elements are determined and each
CDP specifies how this information is encoded and reliably
communicated to the receiver(s). The Mandatory FEC Object
Transmission Information includes the identification of the FEC
Scheme, which is needed by the receiver to determine whether it
supports the FEC Scheme.
義務的: これらの要素は、この仕様に基づき定義されて、それぞれ少なくともFEC Schemeの2つのタイプのひとりに義務的です。 それぞれのFEC体系はMandatory FEC Object Transmission情報要素の値が決定していて、各CDPがどうこの情報がどうコード化されて、受信機に確かに伝えられるかを指定するかを指定します。 Mandatory FEC Object Transmission情報はFEC Schemeの識別を含んでいます。(FEC Schemeは受信機によってそれがFEC Schemeをサポートするかどうか決定する必要があります)。
Common: These elements are defined in this specification and are
optional to be used by an FEC scheme. Each FEC scheme specifies
which of the Common FEC Object Transmission Information elements
it uses and how the values of these elements are determined.
一般的: これらの要素は、この仕様に基づき定義されて、使用されているためにFEC体系で任意です。 それぞれのFEC体系はCommon FEC Object Transmission情報要素のどれを使用するか、そして、これらの要素の値がどのように決定しているかを指定します。
Scheme-specific: An FEC scheme may specify a single Scheme-specific
FEC Object Transmission Information element. The FEC scheme
specifies the type, semantics, and encoding format of the Scheme-
specific FEC Object Transmission Information element. The
resulting octet string is known as the "encoded Scheme-specific
FEC Object Transmission Information". Each CDP specifies how the
encoded Scheme-specific FEC Object Transmission is communicated
reliably to the receiver(s), i.e., exactly where it shall be
carried within packets of the CDP. Note that although from the
point of view of this specification and of CDPs, there is only a
single Scheme-specific FEC Object Transmission Information
element, the FEC scheme may specify this element to contain
multiple distinct pieces of information.
体系特有: FEC体系はただ一つのScheme特有のFEC Object Transmission情報要素を指定するかもしれません。 FEC体系はSchemeの特定のFEC Object Transmission情報要素のタイプ、意味論、およびコード化形式を指定します。 結果として起こる八重奏ストリングは「コード化されたScheme特有のFEC Object Transmission情報」として知られています。 すなわち、各CDPはちょうどそれがCDPのパケットの中で運ばれるものとするところでコード化されたScheme特有のFEC Object Transmissionがどう受信機に確かに伝えられるかを指定します。 ただ一つのScheme特有のFEC Object Transmission情報要素だけがこの仕様とCDPsの観点から来ていますが、FEC体系が複数の異なった情報を含むようにこの要素を指定するかもしれないことに注意してください。
Each FEC scheme specifies an encoding format for the Common and Scheme-specific FEC Object Transmission Information. Each CDP must specify at least one of the following:
それぞれのFEC体系はCommonとScheme特有のFEC Object Transmission情報にコード化形式を指定します。 各CDPは少なくとも以下の1つを指定しなければなりません:
1. A means to reliably communicate the Common FEC Object
Transmission Information elements to the receiver(s) using the
encoding format defined by the FEC scheme.
1. Common FEC Object Transmission情報要素を受信機にFEC体系によって定義されたコード化形式を使用することで確かに伝える手段。
Watson, et al. Standards Track [Page 10] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[10ページ]。
2. An alternative, CDP-specific, encoding format for each of the
Common FEC Object Transmission Information elements.
2. それぞれのCommon FEC Object Transmission情報要素のための代替の、そして、CDP特有のコード化形式。
The Mandatory and Common FEC Object Transmission Information elements are defined in the sections below.
MandatoryとCommon FEC Object Transmission情報要素は下のセクションで定義されます。
6.2.1. Transport of FEC Object Transmission Information
6.2.1. FECオブジェクトトランスミッション情報の輸送
It is the responsibility of the CDP to reliably transport the FEC Object Transmission Information to the receiver(s).
FEC Object Transmission情報を受信機に確かに輸送するのは、CDPの責任です。
It is important to note that the encoding format of the Mandatory FEC Object Transmission Information elements (the FEC Encoding ID) is defined by the CDP. This is so that the receiver can identify the FEC Scheme to be used for interpreting the remaining FEC Object Transmission Information elements. All CDPs must define encoding formats for the Mandatory FEC Object Transmission Information element.
Mandatory FEC Object Transmission情報要素(FEC Encoding ID)のコード化形式がCDPによって定義されることに注意するのは重要です。 これは、受信機が残っているFEC Object Transmission情報要素を解釈するのに使用されるためにFEC Schemeを特定できるためのそうです。 すべてのCDPsがMandatory FEC Object Transmission情報要素のためにコード化形式を定義しなければなりません。
Common FEC Object Transmission Information elements can be transported in two different ways: (a) the FEC Scheme defines an encoding format for the Common FEC Object Transmission Information elements that it uses, and the CDP transports this encoded data block, or (b) the CDP defines an encoding format for each Common FEC Object Transmission Information element and transports the information in this format.
2つの異なった方法で一般的なFEC Object Transmission情報要素を輸送できます: (a) (b) FEC Schemeがそれが使用するCommon FEC Object Transmission情報要素のためにコード化形式を定義して、CDPがこのコード化されたデータ・ブロックを輸送するか、CDPはそれぞれのCommon FEC Object Transmission情報要素のためにコード化形式を定義して、この形式で情報を輸送します。
An FEC Scheme MUST define an encoding format for the Common FEC Object Transmission Information elements that it uses. The resulting octet string is known as the "encoded Common FEC Object Transmission Information". A CDP MAY define individual encoding formats for each of the Common FEC Object Transmission Information elements. The choice of which way the Common FEC Object Transmission Information elements shall be transported, (a) or (b), is made by the Content Delivery Protocol, and a particular method SHOULD be defined in the Content Delivery Protocol specification. Note that a CDP may provide support for one or both options.
FEC Schemeはそれが使用するCommon FEC Object Transmission情報要素のためにコード化形式を定義しなければなりません。 結果として起こる八重奏ストリングは「コード化されたCommon FEC Object Transmission情報」として知られています。 CDP MAYはそれぞれのCommon FEC Object Transmission情報要素のための個々のコード化形式を定義します。 Common FEC Object Transmission情報要素が輸送されるものとする方法((a)か(b))は、定義されたコネがContent Deliveryプロトコル仕様であったならContent Deliveryプロトコル、およびa特定のメソッドSHOULDによってそれの選択にされます。 CDPが1のサポートかオプションの両方を提供するかもしれないことに注意してください。
In the case that the CDP uses the encoding format specified by the FEC scheme, it may simply concatenate the encoded Common FEC Object Transmission Information and the encoded Scheme-specific FEC Object Transmission Information, or it may carry each in a separate field or wrapper within the CDP. In the former case, the concatenated octet string is known as the encoded FEC Object Transmission Information. The FEC scheme must define the encoding format for the Common FEC Object Transmission Information elements that it uses in such a way that the length of each element is either fixed or can be determined from the encoded data itself.
CDPがFEC体系によって指定されたコード化形式を使用して、単にコード化されたCommon FEC Object Transmission情報とコード化されたScheme特有のFEC Object Transmission情報を連結するかもしれませんか、またはそれはCDPの中で別々の分野かラッパーでそれぞれを運ぶかもしれません。 前の場合では、連結された八重奏ストリングはコード化されたFEC Object Transmission情報として知られています。 FEC体系はそれがそれぞれの要素の長さを固定しているか、またはコード化されたデータ自体から測定できるような方法で使用するCommon FEC Object Transmission情報要素のためにコード化形式を定義しなければなりません。
Watson, et al. Standards Track [Page 11] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[11ページ]。
The encoding format of the Scheme-specific FEC Object Transmission Information element is defined by the FEC scheme. CDPs specify only how the resulting octet sequence is communicated. As with the encoding format for the Common FEC Object Transmission Information elements, the length of the Scheme-specific FEC Object Transmission Information must either be fixed or be possible to determine from the encoded data itself.
Scheme特有のFEC Object Transmission情報要素のコード化形式はFEC体系によって定義されます。 CDPsは結果として起こる八重奏系列がどう伝えられるだけであるかを指定します。 Common FEC Object Transmission情報要素のためのコード化形式なら、Scheme特有のFEC Object Transmission情報の長さは、固定されているか、またはコード化されたデータ自体から決定するのにおいて可能であるに違いありません。
6.2.2. Opacity of FEC Object Transmission Information
6.2.2. FECオブジェクトトランスミッション情報の不透明
The Scheme-specific FEC Object Transmission Information element is opaque to the CDP in the sense that inspecting the contents of this element can only be done if FEC scheme-specific logic is included in the CDP.
Scheme特有のFEC Object Transmission情報要素はFECの体系特有の論理がCDPに含まれている場合にだけこの要素のコンテンツを点検できるという意味におけるCDPに不明瞭です。
Any encoding formats defined by the FEC scheme for the Common FEC Object Transmission Information elements are also opaque to the CDP in the same sense.
また、Common FEC Object Transmission情報要素のFEC体系によって定義されたどんなコード化形式も同じ意味におけるCDPに不透明です。
Any encoding formats defined by the CDP for the Common FEC Object Transmission Information elements are not opaque in this sense, although it must be considered that different FEC Schemes may use different combinations of the Common FEC Object Transmission Information elements.
この意味で、Common FEC Object Transmission情報要素のためにCDPによって定義されたどんなコード化形式も不透明ではありません、異なったFEC SchemesがCommon FEC Object Transmission情報要素の異なった組み合わせを使用するかもしれないと考えなければなりませんが。
6.2.3. Mandatory FEC Object Transmission Information Elements
6.2.3. 義務的なFECオブジェクトトランスミッションInformation Elements
The Mandatory FEC Object Transmission Information element is:
Mandatory FEC Object Transmission情報要素は以下の通りです。
FEC Encoding ID: an integer between 0 and 255 inclusive identifying
a specific FEC scheme (Fully-Specified or Under-Specified.)
IDをコード化するFEC: 特定のFEC体系を特定する0と255の間で包括的な整数(完全に指定するか、または下で指定します。)
6.2.4. Common FEC Object Transmission Information Elements
6.2.4. 一般的なFECオブジェクトトランスミッションInformation Elements
The Common FEC Object Transmission Information elements are described below. Note that with the exception of the FEC Instance ID, this specification does not provide complete definitions of these fields. Instead, only aspects of the abstract type are defined. The precise type and semantics are defined for each FEC scheme in the FEC scheme specification.
Common FEC Object Transmission情報要素は以下で説明されます。 FEC Instance ID以外に、この仕様がこれらの分野の完全な定義を提供しないことに注意してください。 抽象型の局面だけが定義されます。 正確なタイプと意味論はFEC体系仕様によるそれぞれのFEC体系のために定義されます。
FEC Instance ID: an integer between 0 and 65535 inclusive
identifying an instance of an Under-Specified FEC scheme
FEC Instance ID: Underによって指定されたFEC体系のインスタンスを特定する0と65535の間で包括的な整数
Transfer-Length: a non-negative integer indicating the length of the
object in octets
転送長さ: 八重奏における、オブジェクトの長さを示す非負の整数
Watson, et al. Standards Track [Page 12] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[12ページ]。
Encoding-Symbol-Length: a non-negative integer indicating the length
of each encoding symbol in octets
シンボルの長さをコード化しています: 八重奏におけるシンボルをコード化しながらそれぞれの長さを示す非負の整数
Maximum-Source-Block-Length: a non-negative integer indicating the
maximum number of source symbols in a source block
最大のソースブロック長: ソースブロックのソースシンボルの最大数を示す非負の整数
Max-Number-of-Encoding-Symbols: a non-negative integer indicating
the maximum number of encoding symbols (i.e., source plus repair
symbols in the case of a systematic code)
コード化シンボルのマックスNumber: コード化シンボルの最大数を示す非負の整数(すなわち、システマティック・コードの場合におけるソースプラス修理シンボル)
The FEC Instance ID MUST be used by all Under-Specified FEC schemes and MUST NOT be used by Fully-Specified FEC Schemes.
FEC Instance IDは、すべてのUnderによって指定されたFEC体系で使用しなければならなくて、Fullyによって指定されたFEC Schemesによって使用されてはいけません。
FEC Schemes define the precise type of those of the above elements that they use and in particular may restrict the value range of each element. FEC Schemes also define an encoding format for the subset of the above elements that they use. CDPs may also provide an encoding format for each element; in which case, this encoding format MUST be capable of representing values up to (2^^16)-1 in the case of the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length, and up to (2^^32)-1 for the other elements. CDPs may additionally or alternatively provide a mechanism to transport the encoded Common FEC Object Transmission information defined by the FEC scheme. For example, FLUTE [8] specifies an XML-based encoding format for these elements, but can also transport FEC scheme-specific encoding formats within the EXT-FTI LCT header extension.
FEC Schemesはそれらが使用する正確なタイプの上の要素のものを定義して、それぞれの要素の値の範囲を特に制限するかもしれません。 また、FEC Schemesはそれらが使用する上の要素の部分集合のためにコード化形式を定義します。 また、CDPsは各要素にコード化形式を供給するかもしれません。 その場合、このコード化形式はFEC Instance IDに関するケース、Transfer-長さに関するケース、および他の要素のための(2^^32)-1までの(2^^48)-1が(2^^16)-1まで代表値ができなければなりません。 CDPsは、さらに、提供するかもしれないか、またはあるいはまた、FEC体系によって定義されたコード化されたCommon FEC Object Transmission情報を輸送するためにメカニズムを提供します。 例えば、FLUTE[8]はXMLベースのコード化形式をこれらの要素に指定しますが、また、EXT-FTI LCTヘッダー拡張子の中でFECの体系特有のコード化形式を輸送できます。
6.2.5. Scheme-Specific FEC Object Transmission Information Element
6.2.5. 体系特有のFECオブジェクトトランスミッション情報要素
The Scheme-specific FEC Object Transmission Information element may be used by an FEC Scheme to communicate information that is essential to the decoder and that cannot adequately be represented within the Mandatory or Common FEC Object Transmission Information elements.
Scheme特有のFEC Object Transmission情報要素は、デコーダに不可欠であり、Mandatoryの中に適切に表すことができない情報かCommon FEC Object Transmission情報要素を伝えるのにFEC Schemeによって使用されるかもしれません。
From the point of view of a CDP, the Scheme-specific FEC Object Transmission Information element is an opaque, variable length, octet string. The FEC Scheme defines the structure of this octet string, which may contain multiple distinct elements.
CDPの観点から、Scheme特有のFEC Object Transmission情報要素は不透明で、可変な長さです、八重奏ストリング。 FEC Schemeはこの八重奏ストリングの構造を定義します。(ストリングは複数の異なった要素を含むかもしれません)。
6.3. FEC Payload ID
6.3. FEC Payload ID
The FEC Payload ID contains information that indicates to the FEC decoder the relationships between the encoding symbols carried by a particular packet and the FEC encoding transformation. For example, if the packet carries source symbols, then the FEC Payload ID indicates which source symbols of the object are carried by the packet. If the packet carries repair symbols, then the FEC Payload
FEC Payload IDはコード化シンボルの間の関係が特定のパケットと変換をコード化するFECによって運ばれたのをFECデコーダに示す情報を含んでいます。 例えば、パケットがソースシンボルを運ぶなら、FEC Payload IDは、オブジェクトのどのソースシンボルがパケットによって運ばれるかを示します。 パケットが修理シンボル、次にFEC有効搭載量を運ぶなら
Watson, et al. Standards Track [Page 13] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[13ページ]。
ID indicates how those repair symbols were constructed from the object.
IDはそれらの修理シンボルがオブジェクトからどう構成されたかを示します。
The FEC Payload ID may also contain information about larger groups of encoding symbols of which those contained in the packet are part. For example, the FEC Payload ID may contain information about the source block the symbols are related to.
また、FEC Payload IDはパケットに含まれたものが部分であるコード化シンボルの、より大きいグループの情報を含むかもしれません。 例えば、FEC Payload IDはシンボルが関連するソースブロックの情報を含むかもしれません。
The FEC Payload ID for a given packet is essential to the decoder if and only if the packet itself is received. Thus, it must be possible to obtain the FEC Payload ID from the received packet. Usually, the FEC Payload ID is simply carried explicitly as a separate field within each packet. In this case, the size of the FEC Payload ID field SHOULD be a small fraction of the packet size. Some FEC schemes may specify means for deriving the relationship between the carried encoding symbols and the object implicitly from other information within the packet, such as protocol headers already present. Such FEC schemes could obviously only be used with CDPs which provided the appropriate information from which the FEC Payload ID could be derived.
そして、与えられたパケットのためのFEC Payload IDがデコーダに不可欠である、パケット自体が受け取られている場合にだけ。 したがって、容認されたパケットからFEC Payload IDを得るのは可能であるに違いありません。 通常、FEC Payload IDは別々の分野として各パケットの中で単に明らかに運ばれます。 この場合、FEC Payload IDの大きさはパケットのわずかな部分がサイズであったならSHOULDをさばきます。 いくつかのFEC体系がパケットの中の他の情報から運ばれたコード化シンボルとオブジェクトとの関係をそれとなく引き出すための手段を指定するかもしれません、ヘッダーが既に提示するプロトコルなどのように。 FEC Payload IDを引き出すことができた適切な情報を提供したCDPsと共にそのようなFEC体系を明らかに使用できただけです。
The encoding format of the FEC Payload ID, including its size, is defined by the FEC Scheme. CDPs specify how the FEC Payload ID is carried within data packets, i.e., the position of the FEC Payload ID within the CDP packet format and the how it is associated with encoding symbols.
サイズを含むFEC Payload IDのコード化形式はFEC Schemeによって定義されます。 そして、CDPsはFEC Payload IDがデータ・パケットの中でどう運ばれるかを指定します、すなわち、CDPパケット・フォーマットの中のFEC Payload IDの位置、それがどうシンボルをコード化すると関連しているか。
FEC schemes for systematic FEC codes (that is, those codes in which the original source data is included within the encoded data) MAY specify two FEC Payload ID formats, one for packets carrying only source symbols and another for packets carrying at least one repair symbol. CDPs must include an indication of which of the two FEC Payload ID formats is included in each packet if they wish to support such FEC Schemes.
系統的なFECコード(すなわち、一次資料データがコード化されたデータの中に含まれているそれらのコード)のFEC体系は2つのFEC有効搭載量ID形式(パケットのために少なくとも1つの修理シンボルを運びながらソースシンボルと別のものだけを運ぶパケットのためのもの)を指定するかもしれません。 CDPsは彼らがそのようなFEC SchemesをサポートしたいならPayload IDがフォーマットする2FECのどれが各パケットに含まれているかしるしを含まなければなりません。
7. FEC Scheme Specifications
7. FEC体系仕様
A specification for a new FEC scheme MUST include the following things:
新しいFEC体系のための仕様は以下のものを含まなければなりません:
1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA as described in
Section 12.
1. 唯一FEC体系を特定するFEC Encoding ID価値。 セクション12で説明されるIANAにこの値を示さなければなりません。
2. The type, semantics, and encoding format of one or two FEC
Payload IDs. Where two FEC Payload ID formats are specified,
then the FEC scheme MUST be a systematic FEC code and one FEC
Payload ID format MUST be designated for use with packets
2. 1か2つのFEC有効搭載量IDのタイプ、意味論、およびコード化形式。 2つのFEC有効搭載量ID形式が指定されて、次に、FEC体系が系統的なFECコードであるに違いなく、使用のためにパケットで1つのFEC有効搭載量ID形式を指定しなければならないところ
Watson, et al. Standards Track [Page 14] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[14ページ]。
carrying only source symbols, and the other FEC Payload ID format
MUST be designated for use with packets carrying at least one
repair symbol.
ソースだけを運ぶのは象徴されます、そして、パケットが少なくとも1つの修理シンボルを運んでいて、使用のためにもう片方のFEC有効搭載量ID形式を指定しなければなりません。
3. The type and semantics of the FEC Object Transmission
Information. The FEC Scheme MAY define additional restrictions
on the type (including value range) of the Common FEC Object
Transmission Information elements.
3. FEC Object Transmission情報のタイプと意味論。 FEC SchemeはCommon FEC Object Transmission情報要素のタイプ(値の範囲を含んでいる)の上で追加制限を定義するかもしれません。
4. An encoding format for the Common FEC Object Transmission
Information elements used by the FEC Scheme.
4. FEC Schemeによって使用されたCommon FEC Object Transmission情報要素のためのコード化形式。
Fully-Specified FEC schemes MUST further specify:
完全に指定されたFEC体系はさらに指定しなければなりません:
1. A full specification of the FEC code.
1. FECコードの完全な仕様。
This specification MUST precisely define the valid FEC Object
Transmission Information values, the valid FEC Payload ID values,
and the valid packet payload sizes for any given object (where
packet payload refers to the space -- not necessarily contiguous
-- within a packet dedicated to carrying encoding symbol octets).
この仕様はどんな与えられたオブジェクト(パケットペイロードがシンボル八重奏をコード化しながら運ぶのに捧げられたパケットの中の必ず隣接であるというわけではないスペースを呼ぶところ)のためにも正確に有効なFEC Object Transmission情報値、有効なFEC有効搭載量ID値、および有効なパケットペイロードサイズを定義しなければなりません。
Furthermore, given an object, valid values for each of the FEC
Object Transmission Information elements used by the FEC Scheme,
a valid FEC Payload ID value, and a valid packet payload size,
the specification MUST uniquely define the values of the encoding
symbol octets to be included in the packet payload of a packet
with the given FEC Payload ID value.
その上、オブジェクト、FEC Scheme、有効なFEC Payload ID値によって使用されるそれぞれのFEC Object Transmission情報要素のための有効値、および有効なパケットペイロードサイズを考えて、仕様は、パケットのパケットペイロードに与えられたFEC有効搭載量ID価値で含まれるように唯一コード化しているシンボル八重奏の値を定義しなければなりません。
A common and simple way to specify the FEC code to the required
level of detail is to provide a precise specification of an
encoding algorithm which, given an object, valid values for each
of the FEC Object Transmission Information elements used by the
FEC Scheme for the object, a valid FEC Payload ID, and packet
payload length as input produces the exact value of the encoding
symbol octets as output.
必要なレベルの詳細にFECコードを指定する一般的で簡単な方法がコード化アルゴリズムの正確な仕様を提供することである、どれ、入力が出力されるようにコード化しているシンボル八重奏の正確な値を生産するので、それぞれのFEC Object Transmission情報要素のための有効値はオブジェクトを考えて、オブジェクト、有効なFEC Payload ID、およびパケットペイロード長にFEC Schemeを使用したか。
2. A description of practical encoding and decoding algorithms.
2. 実用的なコード化と解読アルゴリズムの記述。
This description need not be to the same level of detail as for
(1) above; however, it must be sufficient to demonstrate that
encoding and decoding of the code is both possible and practical.
この記述は上で同じレベルの詳細に(1)に似る必要はありません。 しかしながら、コードがコード化して、解読するのが、可能であって、かつ実用的であることを示すのは十分であるに違いありません。
FEC scheme specifications MAY additionally define the following:
FEC体系仕様はさらに、以下を定義するかもしれません:
1. Type, semantics, and encoding format of a Scheme-specific FEC
Object Transmission Information element.
1. Scheme特有のFEC Object Transmission情報要素のタイプ、意味論、およびコード化形式。
Watson, et al. Standards Track [Page 15] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[15ページ]。
Note that if an FEC scheme does not define a Scheme-specific FEC Object Transmission Information element, then such an element MUST NOT be introduced in future versions of the FEC Scheme. This requirement is included to ensure backwards-compatibility of CDPs designed to support only FEC Schemes that do not use the Scheme- specific FEC Object Transmission Information element.
FEC体系がScheme特有のFEC Object Transmission情報要素を定義しないならFEC Schemeの将来のバージョンでそのような要素を紹介してはいけないことに注意してください。 この要件は、Schemeの特定のFEC Object Transmission情報要素を使用しないFEC Schemesだけをサポートするように設計されたCDPsの遅れている互換性を確実にするために含まれています。
Whenever an FEC scheme specification defines an 'encoding format' for an element, this must be defined in terms of a sequence of octets that can be embedded within a protocol. The length of the encoding format MUST either be fixed, or it must be possible to derive the length from examining the encoded octets themselves. For example, the initial octets may include some kind of length indication.
FEC体系仕様が要素のために'コード化形式'を定義するときはいつも、プロトコルの中で埋め込むことができる八重奏の系列でこれを定義しなければなりません。 コード化形式の長さを固定しなければならない、さもなければ、コード化された八重奏自体を調べるのから長さを得るのは可能であるに違いありません。 例えば、初期の八重奏はある種の長さの指示を含むかもしれません。
FEC schemes SHOULD make use of the Common FEC Object Transmission Information elements in preference to including information in a Scheme-specific FEC Object Transmission Information element.
SHOULDがScheme特有のFEC Object Transmission情報要素に情報を含んでいることに優先してCommon FEC Object Transmission情報要素の使用をするFEC体系。
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
用語が本書では定義したFEC体系仕様SHOULD使用とSHOULDは以下の形式に続きます:
1. Introduction <define whether the scheme is Fully-Specified or
Under-Specified>
1. 序論<は、体系がFullyによって指定されたかUnderによって指定された>であるかどうかを定義します。
<describe the use-cases addressed by this FEC scheme>
<は、ケースを使用するとこのFEC体系>によって扱われた説明します。
2. Formats and Codes
2. 形式とコード
2.1 FEC Payload ID(s) <define the type and format of one or two
FEC Payload IDs>
2.1 FEC Payload ID<は1か2FEC有効搭載量ID>のタイプと書式を定義します。
2.2 FEC Object Transmission Information
2.2 FECオブジェクトトランスミッション情報
2.2.1 Mandatory <define the value of the FEC Encoding ID for
this FEC scheme>
2.2.1 義務的な<はこのFEC体系>のためにFEC Encoding IDの値を定義します。
2.2.2 Common <describe which Common FEC Object Transmission
Information elements are used by this FEC scheme, define
their value ranges, and define an encoding format for
them>
2.2.2 コモン<がそれらのためにどのCommon FEC Object Transmission情報要素がこのFEC体系によって使用されるかを説明して、それらの値の範囲を定義して、コード化形式を定義する、>。
2.2.3 Scheme-Specific <define the Scheme-specific FEC Object
Transmission Information, including an encoding format, if
required>
2.2.3 体系特有の<はコード化形式、必要なら>を含むScheme特有のFEC Object Transmission情報を定義します。
3. Procedures <describe any procedures that are specific to this FEC
scheme, in particular derivation and interpretation of the fields
in the FEC Payload ID and FEC Object Transmission Information.>
3. 手順<はこのFEC体系に特定のどんな手順についても説明します、IDとFEC Object Transmission情報FEC有効搭載量>における、分野の特定の派生と解釈で
Watson, et al. Standards Track [Page 16] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[16ページ]。
4. FEC code specification (for Fully-Specified FEC schemes only)
<provide a complete specification of the FEC Code>
4. FECコード仕様(Fullyによって指定されたFEC体系だけのための)<はFEC Code>の完全な仕様を提供します。
Specifications MAY include additional sections such as those containing examples.
仕様は例を含むものなどの追加セクションを含むかもしれません。
Each FEC scheme MUST be specified independently of all other FEC schemes; for example, in a separate specification or a completely independent section of a larger specification.
他のすべてのFEC体系の如何にかかわらずそれぞれのFEC体系を指定しなければなりません。 例えばより大きい仕様の別々の仕様か完全に独立しているセクションで。
8. CDP Specifications
8. CDP仕様
A specification for a CDP that uses this building block MUST include the following things:
このブロックを使用するCDPのための仕様は以下のものを含まなければなりません:
1. Definitions of an encoding format for the Mandatory FEC Object
Transmission Information element.
1. Mandatory FEC Object Transmission情報要素のためのコード化形式の定義。
2. A means to reliably communicate the Mandatory FEC Object
Transmission Information element from sender to receiver(s) using
the encoding format defined in (1).
2. (1)で定義されたコード化形式を使用することでMandatory FEC Object Transmission情報要素を確かに送付者から受信機まで伝える手段。
3. Means to reliably communicate the Common FEC Object Transmission
Information element from sender to receiver(s) using either or
both of (a) the encoding format defined by the FEC Scheme or (b)
encoding formats defined by the CDP
3. (a) FEC Schemeによって定義されたコード化形式か(b) CDPによって定義されたコード化形式のどちらかか両方を使用することでCommon FEC Object Transmission情報要素を確かに送付者から受信機まで伝えることを意味します。
4. A means to reliably communicate the Scheme-specific FEC Object
Transmission Information element from sender to receiver(s) using
the encoding format of the Scheme-specific FEC Object
Transmission Information element defined by the FEC scheme.
4. FEC体系によって定義されたScheme特有のFEC Object Transmission情報要素のコード化形式を使用することでScheme特有のFEC Object Transmission情報要素を確かに送付者から受信機まで伝える手段。
5. A means to communicate the FEC Payload ID in association with a
data packet. Note that the encoding format of the FEC Payload ID
is defined by the FEC Scheme.
5. データ・パケットと関連してFEC Payload IDを伝える手段。 FEC Payload IDのコード化形式がFEC Schemeによって定義されることに注意してください。
If option (b) of (3) above is used, then the CDP MUST specify an encoding format for the Common FEC Object Transmission Information elements.
上の(3)のオプション(b)が使用されているなら、CDP MUSTはCommon FEC Object Transmission情報要素にコード化形式を指定します。
CDPs MAY additionally specify the following things:
CDPsはさらに、以下のものを指定するかもしれません:
1. A means to indicate whether the FEC Payload ID within a packet is
encoded according to the format for packets including only source
symbols or according to the format for packets including at least
one repair symbol.
1. 少なくとも1つを含むパケットのためにソースシンボルだけを含むパケットのための形式か形式に従ってパケットの中のFEC Payload IDがコード化されるかどうかを示す手段はシンボルを修理します。
Watson, et al. Standards Track [Page 17] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[17ページ]。
9. Common Algorithms
9. 一般的なアルゴリズム
This section describes certain algorithms that are expected to be commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs SHOULD use these algorithms in preference to scheme- or protocol- specific algorithms, where appropriate.
このセクションはFEC体系かCDPsが一般的に必要であると予想されるあるアルゴリズムを説明します。 FEC SchemesとCDPs SHOULDは体系かプロトコルの特定のアルゴリズムに優先して適切であるところでこれらのアルゴリズムを使用します。
9.1. Block Partitioning Algorithm
9.1. ブロック仕切りのアルゴリズム
This algorithm computes a partitioning of an object into source blocks 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 of the same smaller length.
このアルゴリズムがソースブロックにオブジェクトの仕切りを計算するので、すべてのソースブロックができるだけ等しい長さであることの近くにあります。 最初の数のソースブロックは同じより大きい長さのものです、そして、2番目の残っている数のソースブロックは同じよりわずかな長さのものです。
This algorithm is described in two steps, the second of which may be useful in itself as an independent algorithm in some cases. In the first step, the number of source symbols (T) and the number of source blocks (N) are derived from the Object transfer length (L), Maximum Source Block Length (B), and Symbol Length (E).
このアルゴリズムは2ステップで説明されます。いくつかの場合、その2番目は本来独立しているアルゴリズムとして役に立つかもしれません。 第一歩では、Object転送の長さ(L)、Maximum Source Block Length(B)、およびSymbol Length(E)からソースシンボル(T)の数とソースブロック(N)の数を得ます。
In the second step, the partitioning of the object is derived from the number of source symbols (T) and the number of source blocks (N). The partitioning is defined in terms of a first number of source blocks (I), a second number of source blocks (N-I), the length of each of the first source blocks (A_large), and the length of each of the second source blocks (A_small).
第2ステップでは、ソースシンボル(T)の数からオブジェクトの仕切りを得ます、そして、ソースの数は(N)を妨げます。 仕切りが(I)、2番目の数のソースブロック(N-I)、それぞれの最初のソースブロック(_多)の長さ、およびそれぞれのセカンドソースの長さが妨げるソースブロックの最初の数で定義される、(_小さい)
The following notation is used in the description below:
以下の記法は以下での記述に使用されます:
ceil[x] denotes x rounded up to the nearest integer.
ceil[x]は最も近い整数まで一周したxを指示します。
floor[x] denotes x rounded down to the nearest integer.
床[x]は最も近い整数まで一周したxを指示します。
9.1.1. First Step
9.1.1. 第一歩
Input:
以下を入力してください。
B -- Maximum Source Block Length, i.e., the maximum number of source
symbols per source block
B--すなわち、最大のSource Block Length、ソースブロックあたりのソースシンボルの最大数
L -- Transfer Length in octets
L--八重奏でLengthを移してください。
E -- Encoding Symbol Length in octets
E--八重奏でSymbol Lengthをコード化すること。
Watson, et al. Standards Track [Page 18] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[18ページ]。
Output:
出力:
T -- the number of source symbols in the object.
T--オブジェクトのソースシンボルの数。
N -- the number of source blocks into which the object shall be
partitioned.
N--オブジェクトが仕切られるものとするソースブロックの数。
Algorithm:
アルゴリズム:
1. The number of source symbols in the transport object is computed
as T = ceil[L/E].
1. Tがceil[L/E]と等しいときに、輸送オブジェクトのソースシンボルの数は計算されます。
2. The transport object shall be partitioned into N = ceil[T/B]
source blocks.
2. 輸送オブジェクトはN=ceil[T/B]ソースブロックに仕切られるものとします。
9.1.2. Second step
9.1.2. 第2ステップ
Input:
以下を入力してください。
T -- the number of source symbols in the object.
T--オブジェクトのソースシンボルの数。
N -- the number of source blocks into which the object is
partitioned.
N--オブジェクトが仕切られるソースブロックの数。
Output:
出力:
I -- the number of larger source blocks.
私--より大きいソースブロックの数。
A_large -- the length of each of the larger source blocks in
symbols.
_多--それぞれの、より大きい源の長さはシンボルの輪郭を描きます。
A_small -- the length of each of the smaller source blocks in
symbols.
_小さく、それぞれの、より小さい源の長さはシンボルの輪郭を描きます。
Algorithm:
アルゴリズム:
1. A_large = ceil[T/N]
1. _大きい=ceil[T/N]
2. A_small = floor[T/N]
2. _小さい=床[T/N]
3. I = T - A_small * N
3. 私はTと等しいです--_の小さい*N
Each of the first I source blocks then consists of A_large source symbols; each source symbol is E octets in length. Each of the remaining N-I source blocks consist of A_small source symbols; each source symbol is E octets 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 octets in length.
次に、それぞれの最初IのソースブロックはA_の大きいソースシンボルから成ります。 それぞれのソースシンボルは長さがE八重奏です。 それぞれの残っているN-IソースブロックはA_の小さいソースシンボルから成ります。 それぞれのソースシンボルは長さがE八重奏です、最後のソースブロックの最後のソースシンボルが長さがL(最も近い整数まで一周した(L-1)/E))*E八重奏であるのを除いて。
Watson, et al. Standards Track [Page 19] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[19ページ]。
10. Requirements from Other Building Blocks
10. 他のブロックからの要件
The FEC building block does not provide any support for congestion control. Any complete CDP MUST provide congestion control that conforms to [6], and thus this MUST be provided by another building block when the FEC building block is used in a CDP.
FECブロックは輻輳制御の少しのサポートも提供しません。 どんな完全なCDP MUSTも[6]に従う輻輳制御を提供します、そして、FECブロックがCDPで使用されるとき、その結果、別のブロックはこれを提供しなければなりません。
There are no other specific requirements from other building blocks for the use of this FEC building block. However, any CDP that uses the FEC building block may use other building blocks, for example, to provide support for sending higher level session information within data packets containing FEC encoding symbols.
このFECブロックの使用のための他のブロックからの他の決められた一定の要求が全くありません。 しかしながら、例えば、FECブロックを使用するどんなCDPも、シンボルをコード化するFECを含んでいて、データ・パケットの中で、より高い平らなセッション情報を送るサポートを提供するのに他のブロックを使用するかもしれません。
11. Security Considerations
11. セキュリティ問題
Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. This is particularly a concern for multicast delivery because a corrupted packet may be injected into the session close to the root of the multicast tree, in which case, the corrupted packet will arrive at many receivers. This is particularly a concern for the FEC building block because the use of even one corrupted packet containing encoding data may result in the decoding of an object that is completely corrupted and unusable. It is thus RECOMMENDED that source authentication and integrity checking are applied to decoded objects before delivering objects to an application. For example, a SHA-1 hash [7] of an object may be appended before transmission, and the SHA-1 hash is computed and checked after the object is decoded, but before it is delivered to an application. Source authentication SHOULD be provided, for example, by including a digital signature verifiable by the receiver and computed on top of the hash value. It is also RECOMMENDED that a packet authentication protocol such as Timed Efficient Stream Loss- Tolerant Authentication (TESLA) [9] be used to detect and discard corrupted packets upon arrival. Furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path.
データ配送は攻撃者による受信機で正統であるとして認められる崩壊したパケットを送るサービス不能攻撃を受けることがある場合があります。 これが崩壊したパケットがマルチキャスト木の根の近くでのセッションに注がれるかもしれないので特にマルチキャスト配送に関する心配である、その場合、崩壊したパケットは多くの受信機に到着するでしょう。 これは、データを暗号化を含む1つの崩壊したパケットさえの使用が完全に崩壊して使用不可能なオブジェクトの解読をもたらすかもしれないので、特にFECブロックに関する心配です。 その結果、オブジェクトをアプリケーションに提供する前にソース認証と保全の照合が解読されたオブジェクトに適用されるのは、RECOMMENDEDです。 例えば、トランスミッションの前にオブジェクトのSHA-1ハッシュ[7]を追加するかもしれなくて、オブジェクトが解読された後にもかかわらず、それがアプリケーションに提供される前を除いて、SHA-1ハッシュは、計算されて、チェックされます。 ソース認証SHOULDは例えば、受信機で証明可能なデジタル署名を含んでいることによって提供されて、ハッシュ値の上で計算しました。 また、Timed Efficient Stream Lossの許容性があるAuthentication(テスラ)[9]などのパケット認証プロトコルが到着のときに崩壊したパケットを検出して、捨てるのに使用されるのは、RECOMMENDEDです。 その上、Reverse Path ForwardingがチェックするRECOMMENDEDが首尾よく悪いエージェントの可能性を制限するためにマルチキャスト木のデータ経路に崩壊したパケットを注ぎながらすべてのネットワークルータで可能にされて、経路に沿って送付者から受信機に切り替わるということです。
Another security concern is that some FEC information may be obtained by receivers out-of-band in a session description, and if the session description is forged or corrupted, then the receivers will not use the correct protocol for decoding content from received packets. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders.
別のセキュリティ関心はバンドの外で受信機でセッション記述で何らかのFEC情報を得るかもしれないということであり、セッション記述が鍛造されるか、または崩壊すると、受信機は、容認されたパケットから内容を解読するのに正しいプロトコルを使用しないでしょう。 対策が受信機が不正確なセッション記述を受け入れるのを防ぐために実施されるのは、これらの問題を避けるためには、RECOMMENDEDです、例えば、受信機が認可された送付者から正統のセッション記述を受け入れるだけであるのを保証するのにソース認証を使用することによって。
Watson, et al. Standards Track [Page 20] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[20ページ]。
12. IANA Considerations
12. IANA問題
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
registration. They are in the registry named "Reliable Multicast
Transport (RMT) FEC Encoding IDs and FEC Instance IDs" located at
time of publication at:
http://www.iana.org/assignments/rmt-fec-parameters
FEC Encoding IDとFEC Instance IDの値はIANA登録を受けることがあります。 彼らは公表の時に見つけられた「IDをコード化する信頼できるマルチキャスト輸送(RMT)FECとFECインスタンスID」という登録に以下にいます。 http://www.iana.org/assignments/rmt-fec-parameters
FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding IDs that correspond to Under-Specified FEC schemes scope a corresponding set of FEC Instance IDs.
FEC Encoding IDとFEC Instance IDは階層的です: FEC Instance IDのFEC Encoding ID範囲の独立者範囲。 Underによって指定されたFECに対応するFEC Encoding IDだけが対応が設定するFEC Instance IDの範囲を計画します。
The FEC Encoding ID and FEC Instance IDs are non-negative integers. In this document, the range of values for FEC Encoding IDs is 0 to 255. Values from 0 to 127 are reserved for Fully-Specified FEC schemes, and Values from 128 to 255 are reserved for Under-Specified FEC schemes, as described in more detail in Section 6.1.
FEC Encoding IDとFEC Instance IDは非負の整数です。 本書では、FEC Encoding IDのための値の範囲は、0〜255です。 0〜127までの値はFullyによって指定されたFEC体系のために予約されます、そして、128〜255までのValuesはUnderによって指定されたFEC体系のために予約されます、さらに詳細にセクション6.1で説明されるように。
12.1. Explicit IANA Assignment Guidelines
12.1. 明白なIANA課題ガイドライン
This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding
このドキュメントは指定されたFEC Encoding IDのために名前空間を定義します: ietf:rmt:fec: コード化
The values that can be assigned within the "ietf:rmt:fec:encoding" name-space are numeric indexes in the range [0, 255], boundaries included. Assignment requests are granted on a "IETF Consensus" basis as defined in [2]. Section 7 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
それを割り当てることができる値、「ietf:rmt:fec: 」 名前空間をコード化するのは、境界を含んでいる範囲[0、255]の数値インデックスです。 課題要求は[2]で定義されるように「IETFコンセンサス」ベースで承諾されます。 セクション7は新しいFEC Encoding IDを定義するドキュメントに満たされるはずであるという明白な要件を定義します。
This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance
また、このドキュメントは指定されたFEC Instance IDのために名前空間を定義します: ietf:rmt:fec:コード化:インスタンス
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. Each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
「ietf:rmt:fec:コード化:例」名前スペースが交際したサブ名のスペースである、「ietf:rmt:fec: コード化」は名前で区切ります。 範囲[128、255]で割り当てられた「ietf:rmt:fec: コード化」の各値には、それが見る別々の「ietf:rmt:fec:コード化:例」サブ名のスペースがあります。 範囲[0、127]の「ietf:rmt:fec: コード化」の値は「ietf:rmt:fec:コード化:例」サブ名のスペースをどんな範囲にもしません。
The values that can be assigned within each "ietf:rmt:fec:encoding: instance" sub-name-space are non-negative integers less than 65536. Assignment requests are granted on a "First Come First Served" basis as defined in [2]. The same value of "ietf:rmt:fec:encoding: instance" can be assigned within multiple distinct sub-name-spaces, i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used for multiple values of "ietf:rmt:fec:encoding".
各「ietf:rmt:fec: 以下をコード化する」中で割り当てることができる値 「例」サブ名のスペースは65536未満の非負の整数です。 課題要求は[2]で定義されるように「先着順」ベースで承諾されます。 同じ値、「ietf:rmt:fec: 以下をコード化すること」。 複数の異なったサブ名の空間の中で「例」を割り当てることができます、すなわち、「ietf:rmt:fec: コード化」の複数の値に「ietf:rmt:fec:コード化:例」の同じ値を使用できます。
Watson, et al. Standards Track [Page 21] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[21ページ]。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
「ietf:rmt:fec:コード化:例」課題の要請者は以下の情報を提供しなければなりません:
o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt:
fec:encoding:instance" sub-name-space. This must be in the range
[128, 255].
o 見られる「ietf:rmt:fec: コード化」の値、「ietf: rmt:、」 「fec:コード化:例」サブ名のスペース。 これは範囲[128、255]にあるに違いありません。
o Point of contact information
o 連絡先情報
o A pointer to publicly accessible documentation describing the
Under-Specified FEC scheme, associated with the value of "ietf:
rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g.,
a pointer to a publicly available reference-implementation or the
name and contacts of a company that sells it, either separately or
embedded in a product).
o 公的にアクセスしやすいドキュメンテーション説明へのUnderによって指定されたFECが計画して、値と交際したポインタは「以下をietfします」。 割り当てられた「rmt:fec:コード化: 例」、およびそれを得る方法(例えば、別々にそれを販売したか、または製品を中に埋め込んだ会社の公的に利用可能な参照実現か名前と接触へのポインタ)。
It is the responsibility of the requestor to keep all the above information up to date.
すべての上記の情報が時代について行かせるのは、要請者の責任です。
13. Changes from RFC 3452
13. RFC3452からの変化
This section lists the changes between the Experimental version of this specification, [3], and this version:
このセクションはこの仕様のExperimentalバージョンと、[3]と、このバージョンの間の変化を記載します:
o The requirements for definition of a new FEC Scheme and the
requirements for specification of new Content Delivery Protocols
that use FEC Schemes are made more explicit to permit independent
definition of FEC Schemes and Content Delivery Protocols.
o 新しいFEC Schemeの定義のための要件とFEC Schemesを使用する新しいContent Deliveryプロトコルの仕様のための要件をFEC SchemesとContent Deliveryプロトコルの独立している定義を可能にするために、より明白にします。
o The definitions of basic FEC Schemes have been removed with the
intention of publishing these separately.
o 別々にこれらを発行するという意志で基本的なFEC Schemesの定義を取り除きました。
o The FEC Object Transmission Information (OTI) is more explicitly
defined, and in particular, three classes of FEC OTI (Mandatory,
Common, and Scheme-specific) are introduced to permit reusable
definition of explicit fields in Content Delivery Protocols to
carry these elements.
o より明らかに、FEC Object Transmission情報(OTI)を定義します、そして、特に、Content Deliveryプロトコルとの明白な分野の再利用できる定義がこれらの要素を運ぶことを許可するためにFEC OTI(義務的で、Commonの、そして、Scheme特有の)の3つのクラスを導入します。
o FEC Schemes are required to specify a complete encoding for the
FEC Object Transmission, which can be carried transparently by
Content Delivery protocols (instead of defining explicit
elements).
o FEC SchemesはFEC Object Transmissionのための完全なコード化を指定しなければなりません。(Content Deliveryプロトコル(明白な要素を定義することの代わりに)で透明にFEC Object Transmissionを運ぶことができます)。
o The possibility for FEC Schemes to define two FEC Payload ID
formats for use with source and repair packets, respectively, in
the case of systematic FEC codes is introduced.
o FEC Schemesが使用のためにソースと修理パケットで系統的なFECコードの場合でそれぞれ2つのFEC有効搭載量ID書式を定義する可能性を導入します。
Watson, et al. Standards Track [Page 22] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[22ページ]。
o The file blocking algorithm from FLUTE is included here as a
common algorithm that is recommended to be reused by FEC Schemes
when appropriate.
o FLUTEからのファイルブロッキングアルゴリズムは適切であるときに、FEC Schemesによって再利用されることが勧められる一般的なアルゴリズムとしてここに含まれています。
14. Acknowledgments
14. 承認
This document is largely based on RFC 3452 [3], and thus thanks are due to the additional authors of that document: J. Gemmell, L. Rizzo, M. Handley, and J. Crowcroft.
このドキュメントはRFC3452[3]に主に基づいています、そして、その結果、感謝はそのドキュメントの追加作者のためです: J。 Gemmell、L.リゾー、M.ハンドレー、およびJ.クロウクロフト。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[2]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
15.2. Informative References
15.2. 有益な参照
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "Forward Error Correction (FEC) Building
Block", RFC 3452, December 2002.
[3]Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(2002年12月)。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
and J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002.
[4]Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453(2002年12月)。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002.
[5] カーモード、R.、およびL.Vicisanoは「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、2002年4月。
[6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[6] マンキン、A.、ロマーノフ、A.、ブラドナー、S.、およびV.パクソン、「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)。
[7] Federal Information Processing Standards Publication (FIPS PUB)
180-1, Secure Hash Standard, 17 April 1995.
[7] 連邦政府の情報処理規格公表(FIPSパブ)180-1、安全な細切れ肉料理規格、1995年4月17日。
[8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", RFC
3926, October 2004.
[8] Paila、T.、Luby、M.、レヒトネン、R.、ロカ、V.、およびR.ウォルシュ、「フルート--単方向の輸送の上の配送をファイルしてください」、RFC3926、2004年10月。
Watson, et al. Standards Track [Page 23] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[23ページ]。
[9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe,
"Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction", RFC
4082, June 2005.
[9] Perrig、A.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、「効率的な状態で調節されて、損失許容性がある認証(テスラ)を流してください」 「マルチキャストソース認証変換序論」、RFC4082、2005年6月。
[10] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[10]Whetten、B.、Vicisano、L.、カーモード、R.、ハンドレー、M.、フロイド、S.、およびM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048(2001年1月)。
Authors' Addresses
作者のアドレス
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
フレモント、マークワトソンデジタル噴水39141シビック・センタードライブスイート300カリフォルニア94538米国
EMail: mark@digitalfountain.com
メール: mark@digitalfountain.com
Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
フレモント、マイケルLubyのデジタル噴水39141シビック・センタードライブスイート300カリフォルニア94538米国
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
Lorenzo Vicisano Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
フレモント、ロレンツォVicisanoのデジタル噴水39141シビック・センタードライブスイート300カリフォルニア94538米国
EMail: lorenzo@digitalfountain.com
メール: lorenzo@digitalfountain.com
Watson, et al. Standards Track [Page 24] RFC 5052 FEC Building Block August 2007
ワトソン、他 規格はFECブロック2007年8月にRFC5052を追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Watson, et al. Standards Track [Page 25]
ワトソン、他 標準化過程[25ページ]
一覧
スポンサーリンク
