Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6363 Netflix, Inc.
Category: Standards Track A. Begen
ISSN: 2070-1721 Cisco
V. Roca
INRIA
October 2011
Forward Error Correction (FEC) Framework
Abstract
抽象
This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.
この文書では、パケット損失に対する保護を提供するために、パブリックおよびプライベートIPネットワークにおけるアプリケーションと前方誤り訂正（FEC）コードを使用するためのフレームワークについて説明します。フレームワークは、任意のパケットにFECを適用すると、信頼性の低いトランスポート上で流れ、主にリアルタイム、またはストリーミング、メディアを対象としてサポートしています。このフレームワークは、メディア配信や他のパケットフローをストリーミングするためにFECを提供し、コンテンツ配信プロトコルを定義するために使用することができます。このフレームワークを使用して定義されたコンテンツ配信プロトコルは、この文書で定義された様々な要件に準拠している任意のFECスキーム（及び関連するFECコード）をサポートすることができます。このように、コンテンツ配信プロトコルは、特定のFECスキームに固有のものではありませんように定義することができ、FECスキームは、特定のコンテンツ配信プロトコルに固有ではないように定義することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6363.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6363で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................5
3. Architecture Overview ...........................................7
4. Procedural Overview ............................................11
4.1. General ...................................................11
4.2. Sender Operation ..........................................13
4.3. Receiver Operation ........................................15
5. Protocol Specification .........................................19
5.1. General ...................................................19
5.2. Structure of the Source Block .............................19
5.3. Packet Format for FEC Source Packets ......................19
5.3.1. Generic Explicit Source FEC Payload ID .............21
5.4. Packet Format for FEC Repair Packets ......................21
5.4.1. Packet Format for FEC Repair Packets over RTP ......22
5.5. FEC Framework Configuration Information ...................22
5.6. FEC Scheme Requirements ...................................24
6. Feedback .......................................................26
7. Transport Protocols ............................................27
8. Congestion Control .............................................27
8.1. Motivation ................................................27
8.2. Normative Requirements ....................................29
9. Security Considerations ........................................29
9.1. Problem Statement .........................................29
9.2. Attacks against the Data Flows ............................31
9.2.1. Access to Confidential Content .....................31
9.2.2. Content Corruption .................................32
9.3. Attacks against the FEC Parameters ........................33
9.4. When Several Source Flows Are to Be Protected Together ....33
9.5. Baseline Secure FEC Framework Operation ...................34
10. Operations and Management Considerations ......................35
10.1. What Are the Key Aspects to Consider? ....................35
10.2. Operational and Management Recommendations ...............36
11. IANA Considerations ...........................................39
12. Acknowledgments ...............................................39
13. References ....................................................40
13.1. Normative References .....................................40
13.2. Informative References ...................................40
Many applications have a requirement to transport a continuous stream of packetized data from a source (sender) to one or more destinations (receivers) over networks that do not provide guaranteed packet delivery. Primary examples are real-time, or streaming, media applications such as broadcast, multicast, or on-demand forms of audio, video, or multimedia.
多くのアプリケーションは保証パケット配信を提供していないネットワーク上で1つの以上の宛先（受信機）にソース（送信者）からのパケット化されたデータの連続ストリームを輸送する必要があります。主な例としては、ブロードキャスト、マルチキャスト、またはオンデマンドオーディオの形式、ビデオ、またはマルチメディアなどのリアルタイム、またはストリーミングメディアアプリケーションです。
Forward Error Correction (FEC) is a well-known technique for improving the reliability of packet transmission over networks that do not provide guaranteed packet delivery, especially in multicast and broadcast applications. The FEC Building Block, defined in [RFC5052], provides a framework for the definition of Content Delivery Protocols (CDPs) for object delivery (including, primarily, file delivery) that make use of separately defined FEC schemes. Any CDP defined according to the requirements of the FEC Building Block can then easily be used with any FEC scheme that is also defined according to the requirements of the FEC Building Block.
前方誤り訂正（FEC）は、特に、マルチキャスト及びブロードキャストアプリケーションにおいて、保証パケット配信を提供しないネットワークを介してパケット伝送の信頼性を向上させるための周知の技術です。 [RFC5052]で定義されたFECビルディングブロックは、別々に定義されたFECスキームを利用する（ファイル配信、主を含む）オブジェクト送達のためのコンテンツ配信プロトコル（のCDP）の定義のためのフレームワークを提供します。 FECビルディングブロックの要件に応じて定義された任意のCDPは、簡単に、またFECビルディングブロックの要件に従って定義される任意のFECのスキームで使用することができます。
Note that the term "Forward Erasure Correction" is sometimes used, erasures being a type of error in which data is lost and this loss can be detected, rather than being received in corrupted form. The focus of this document is strictly on erasures, and the term "Forward Error Correction" is more widely used.
用語「前方消失訂正」は時々消失は、データが失われたエラーの種類であると、この損失はかなり破損形式で受信されるよりも、検出することができ、使用されることに留意されたいです。このドキュメントの焦点は、消去に厳密であり、用語「前方誤り訂正は、」より広く使用されています。
This document defines a framework for the definition of CDPs that provide for FEC protection for arbitrary packet flows over unreliable transports such as UDP. As such, this document complements the FEC Building Block of [RFC5052], by providing for the case of arbitrary packet flows over unreliable transport, the same kind of framework as that document provides for object delivery. This document does not define a complete CDP; rather, it defines only those aspects that are expected to be common to all CDPs based on this framework.
この文書では、UDPなどの信頼性の低いトランスポート上を流れる任意のパケットのためのFEC保護を提供するのCDPの定義のためのフレームワークを定義します。そのようなものとして、この文書は[RFC5052]のFECビルディングブロックを補完そのドキュメントオブジェクト配信を提供するように、任意のパケットの場合のために提供することにより、信頼性の低いトランスポートを介してフレームワークの同じ種類を流れます。この文書では、完全なCDPを定義していません。むしろ、それはこのフレームワークに基づいて、すべてのCDPに共通であることが予想される態様のみを定義します。
This framework does not define how the flows to be protected are determined, nor does it define how the details of the protected flows and the FEC streams that protect them are communicated from sender to receiver. It is expected that any complete CDP specification that makes use of this framework will address these signaling requirements. However, this document does specify the information that is required by the FEC Framework at the sender and receiver, e.g., details of the flows to be FEC protected, the flow(s) that will carry the FEC protection data, and an opaque container for FEC-Scheme-Specific Information.
このフレームワークは、保護されるべきフローがどのように決定されるかを定義していません。また、保護されたフローの詳細と、それらを保護するFECストリームが送信側から受信側へ伝達される方法を定義しません。このフレームワークを使用する任意の完全なCDPの仕様は、これらの信号要件に対処することが期待されます。しかし、この文書は、例えば、送信者と受信者、でFECフレームワークが必要とする情報を指定し、フローの詳細については、保護されたFECするように、FEC保護データを搬送する流れ（S）、および不透明な容器用FEC-スキーム固有の情報。
FEC schemes designed for use with this framework must fulfill a number of requirements defined in this document. These requirements are different from those defined in [RFC5052] for FEC schemes for object delivery. However, there is a great deal of commonality, and FEC schemes defined for object delivery may be easily adapted for use with the framework defined in this document.
このフレームワークで使用するために設計されたFECスキームは、この文書で定義された要件の数を満たす必要があります。これらの要件は、オブジェクト送達のためのFECスキームのために[RFC5052]で定義されたものとは異なります。しかし、共通の大量があり、オブジェクトの配信のために定義されたFECスキームは、簡単にこの文書で定義されたフレームワークでの使用に適合させることができます。
Since RTP [RFC3550] is (often) used over UDP, this framework can be applied to RTP flows as well. FEC repair packets may be sent directly over UDP or RTP. The latter approach has the advantage that RTP instrumentation, based on the RTP Control Protocol (RTCP), can be used for the repair flow. Additionally, the post-repair RTCP extended reports [RFC5725] may be used to obtain information about the loss rate after FEC recovery.
RTP [RFC3550]が（しばしば）UDP上で使用されているため、このフレームワークは、RTPに適用することができるだけでなく流れます。 FECリペアパケットはUDPまたはRTPを介して直接送信することができます。後者のアプローチは、RTP制御プロトコル（RTCP）に基づいて、リペアフローのために使用することができるRTP計装利点を有します。また、修理後RTCP拡張レポート[RFC5725]はFEC回復後損失率に関する情報を取得するために使用することができます。
The use of RTP for repair flows is defined for each FEC scheme by defining an RTP payload format for that particular FEC scheme (possibly in the same document).
リペアフローのためのRTPの使用は、（おそらく、同じドキュメント内の）その特定のFECスキームのためのRTPペイロードフォーマットを定義することによって、各FECスキームのために定義されています。
Application Data Unit (ADU): The unit of source data provided as payload to the transport layer.
アプリケーション・データ・ユニット（ADU）：トランスポート層にペイロードとして提供されたソースデータの単位。
ADU Flow: A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}).
ADUフロー：トランスポート・レイヤ・フロー識別子に関連付けられているのADUの配列（例えば、標準的な5タプル{送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、トランスポートプロトコル}）。
AL-FEC: Application-layer Forward Error Correction.
AL-FEC：アプリケーションレイヤ前方誤り訂正。
Application Protocol: Control protocol used to establish and control the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP).
アプリケーションプロトコル：制御プロトコルは、例えば、リアルタイムストリーミングプロトコル（RTSP）、保護されているソースの流れを確立し、制御するために使用されます。
Content Delivery Protocol (CDP): A complete application protocol specification that, through the use of the framework defined in this document, is able to make use of FEC schemes to provide FEC capabilities.
コンテンツ配信プロトコル（CDP）：この文書で定義されたフレームワークを使用して、FEC機能を提供するために、FECスキームの利用をすることができる、完全なアプリケーションプロトコル仕様。
FEC Code: An algorithm for encoding data such that the encoded data flow is resilient to data loss. Note that, in general, FEC codes may also be used to make a data flow resilient to corruption, but that is not considered in this document.
FECコード：符号化データフローは、データ損失に弾性であるように、符号化データのためのアルゴリズム。一般的に、FECコードも破損へのデータフローは、弾性作るために使用することができるが、それは本書では考慮されていないことに留意されたいです。
FEC Framework: A protocol framework for the definition of Content Delivery Protocols using FEC, such as the framework defined in this document.
FECフレームワーク：など、この文書で定義されたフレームワークとしてFECを使用したコンテンツ配信プロトコルの定義のためのプロトコルのフレームワーク。
FEC Framework Configuration Information: Information that controls the operation of the FEC Framework.
FECフレームワーク構成情報：FECフレームワークの動作を制御する情報。
FEC Payload ID: Information that identifies the contents of a packet with respect to the FEC scheme.
FECペイロードID：FECスキームに対するパケットの内容を特定する情報。
FEC Repair Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header.
FECリペアパケット（受信機でそれぞれ）送信側において、に提出されたペイロードは、リペアFECペイロードIDおよびおそらくRTPヘッダと共に、一つ以上のリペアシンボルを含むトランスポート・プロトコル（それぞれから受信しました）。
FEC Scheme: A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework.
FECスキーム：FECフレームワークを有する特定のFECコードを使用するために必要な追加のプロトコルの態様を定義する仕様。
FEC Source Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID.
FECソースパケット（受信機でそれぞれ）送信側において、に提出されたペイロードは任意明示ソースFECペイロードIDとともにADUを含むトランスポートプロトコル（それぞれから受信しました）。
Protection Amount: The relative increase in data sent due to the use of FEC.
保護量：FECの使用に起因して送信されたデータの相対的な増加。
Repair Flow: The packet flow carrying FEC data.
フローを修復：パケットがFECデータを搬送する流れ。
Repair FEC Payload ID: A FEC Payload ID specifically for use with repair packets.
特にリペアパケットで使用するためのFECペイロードID：FECペイロードIDを修復します。
Source Flow: The packet flow to which FEC protection is to be applied. A source flow consists of ADUs.
ソースフロー：FEC保護が適用されるパケットの流れ。ソース流はのADUから成ります。
Source FEC Payload ID: A FEC Payload ID specifically for use with source packets.
ソースFECペイロードID：特にソースパケットで使用するFECペイロードID。
Source Protocol: A protocol used for the source flow being protected, e.g., RTP.
ソースプロトコル：ソース・フローのために使用されるプロトコルは、RTP、例えば、保護されています。
Transport Protocol: The protocol used for the transport of the source and repair flows, e.g., UDP and the Datagram Congestion Control Protocol (DCCP).
トランスポートプロトコル：ソースおよびリペアフローの輸送に使用されるプロトコル、例えば、UDPデータグラム輻輳制御プロトコル（DCCP）。
The following definitions are aligned with [RFC5052]:
以下の定義は[RFC5052]と一致しています。
Code Rate: The ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.
コードレート：ソースシンボルの数と符号化シンボルの数との比。定義により、符号化率は0 <コードレート<= 1の1に近いコードレートは、リペアシンボルの数が少ない符号化プロセス中に生成されたことを示すものです。
Encoding Symbol: Unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols.
エンコードシンボル：符号化プロセスによって生成されたデータの単位。体系的なコードでは、ソースシンボルは、符号化シンボルの一部です。
Packet Erasure Channel: A communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
パケット消失チャンネル：パケットのいずれか（伝送エラーの数は、物理レイヤコードの訂正能力を超えて、例えば、輻輳ルータによって、またはので）ドロップまたは受信された通信経路。パケットが受信されると、このパケットが破損していないことが想定されます。
Repair Symbol: Encoding symbol that is not a source symbol.
修復シンボル：符号化シンボルソースシンボルではありません。
Source Block: Group of ADUs that are to be FEC protected as a single block.
ソースブロック：単一のブロックとしてFEC保護されるのADUのグループ。
Source Symbol: Unit of data used during the encoding process.
ソースシンボル：符号化プロセス中に使用されるデータの単位。
Systematic Code: FEC code in which the source symbols are part of the encoding symbols.
システマティックコード：ソースシンボルは、符号化シンボルの一部である、FECコード。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The FEC Framework is described in terms of an additional layer between the transport layer (e.g., UDP or DCCP) and protocols running over this transport layer. As such, the data path interface between the FEC Framework and both underlying and overlying layers can be thought of as being the same as the standard interface to the transport layer; i.e., the data exchanged consists of datagram payloads each associated with a single ADU flow identified by the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}. In the case that RTP is used for the repair flows, the source and repair data can be multiplexed using RTP onto a single UDP flow and needs to be consequently demultiplexed at the receiver. There are various ways in which this multiplexing can be done (for example, as described in [RFC4588]).
FECフレームワークは、トランスポート層（例えば、UDPまたはDCCP）と、このトランスポート層の上で動作するプロトコル間の追加の層に関して説明されています。このように、FECフレームワークとの両方の下にある及び上にある層との間のデータ・パス・インターフェースは、トランスポート層の標準的なインターフェイスと同じであると考えることができます。すなわち、データは、標準的な5タプル{送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、トランスポートプロトコル}によって識別される単一のADUフローに関連付けられたデータグラムのペイロードそれぞれから成る交換しました。 RTP修理・フローのために使用される場合には、ソースおよびリペアデータは、単一のUDPフローにRTPを使用して多重化し、その結果、受信機において逆多重化される必要があることができます。 （[RFC4588]に記載されているように、例えば、）は、この多重化を行うことが可能な様々な方法があります。
It is important to understand that the main purpose of the FEC Framework architecture is to allocate functional responsibilities to separately documented components in such a way that specific instances of the components can be combined in different ways to describe different protocols.
FECフレームワークアーキテクチャの主な目的は、別々の成分の特定のインスタンスは、異なるプロトコルを記述するために様々な方法で組み合わせることができるように構成要素を文書化するための機能の責任を割り当てることであることを理解することが重要です。
The FEC Framework makes use of a FEC scheme, in a similar sense to that defined in [RFC5052], and uses the terminology of that document. The FEC scheme defines the FEC encoding and decoding, and it defines the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme. The interface between the FEC
FECフレームワークは[RFC5052]で定義されたものと同様の意味で、FEC方式を利用し、その文書の用語を使用します。 FEC方式は、FEC符号化および復号化を定義し、それはFECスキームの文脈におけるパケットのペイロードデータを識別するために使用されるプロトコルフィールドおよび手順を定義します。 FECとの間のインターフェイス
Framework and a FEC scheme, which is described in this document, is a logical one that exists for specification purposes only. At an encoder, the FEC Framework passes ADUs to the FEC scheme for FEC encoding. The FEC scheme returns repair symbols with their associated Repair FEC Payload IDs and, in some cases, Source FEC Payload IDs, depending on the FEC scheme. At a decoder, the FEC Framework passes transport packet payloads (source and repair) to the FEC scheme, and the FEC scheme returns additional recovered source packet payloads.
フレームワークと、この文書に記載されているFEC方式、仕様目的でのみ存在する論理的なものです。エンコーダにおいて、FECフレームワークは、FEC符号化のためのFECスキームへのADUを渡します。 FECスキームは、FECスキームに応じて、それらに関連するリペアFECペイロードIDと、いくつかのケースでは、ソースFECペイロードIDとリペアシンボルを返します。デコーダで、FECフレームワークはFECスキームにトランスポートパケットペイロード（ソースおよびリペア）を通過し、FECスキームは、追加の回復されたソースパケットのペイロードを返します。
This document defines certain FEC Framework Configuration Information that MUST be available to both sender and receiver(s). For example, this information includes the specification of the ADU flows that are to be FEC protected, specification of the ADU flow(s) that will carry the FEC protection (repair) data, and the relationship(s) between these source and repair flows (i.e., which source flow(s) are protected by repair flow(s)). The FEC Framework Configuration Information also includes information fields that are specific to the FEC scheme. This information is analogous to the FEC Object Transmission Information defined in [RFC5052].
この文書では、送信者と受信者（単数または複数）の両方に利用可能でなければならない特定のFECフレームワーク構成情報を定義します。例えば、この情報は、FEC保護（修復）を運ぶADUフロー（単数または複数）のFEC保護され、仕様であることであるADUフローデータの仕様、及びこれらのソースおよびリペアフローの関係（複数可）を含みます（すなわち、そのソース・フロー（S）は、修理の流れ（S）によって保護されています）。 FECフレームワークの設定情報もFECスキームに固有の情報フィールドを含んでいます。この情報は、[RFC5052]で定義されたFECオブジェクト伝送情報に類似しています。
The FEC Framework does not define how the FEC Framework Configuration Information for the stream is communicated from sender to receiver. This has to be defined by any CDP specification, as described in the following sections.
FECフレームワークは、ストリームのFECフレームワークの構成情報が送信側から受信側に伝達する方法を定義していません。これは、次のセクションで説明したように、任意のCDP仕様で定義されなければなりません。
In this architecture, we assume that the interface to the transport layer supports the concepts of data units (referred to here as Application Data Units (ADUs)) to be transported and identification of ADU flows on which those data units are transported. Since this is an interface internal to the architecture, we do not specify this interface explicitly. We do require that ADU flows that are distinct from the transport layer point of view (for example, distinct UDP flows as identified by the UDP source/destination addresses/ports) are also distinct on the interface between the transport layer and the FEC Framework.
このアーキテクチャでは、我々は、トランスポート層へのインタフェースは、データユニットの概念をサポートすると仮定する（ここでアプリケーションデータユニット（のADU）と称する）を輸送し、ADUの同定は、これらのデータユニットが搬送される上を流れることができます。これは、アーキテクチャへの内部インターフェイスであるので、我々は明示的にこのインタフェースを指定しないでください。我々は、ビューのトランスポート層ポイントは異なるADUフローは（UDP送信元/宛先アドレス/ポートによって識別されるように、例えば、別個のUDPフロー）もまた、トランスポート層とFECフレームワークとの間のインターフェイス上で区別されることを必要とします。
As noted above, RTP flows are a specific example of ADU flows that might be protected by the FEC Framework. From the FEC Framework point of view, RTP source flows are ADU flows like any other, with the RTP header included within the ADU.
上述したように、RTPフローはFECフレームワークによって保護されるかもしれないADUフローの具体例です。ビューのFECフレームワークの観点から、RTPソース・フローは、ADUは、ADU内に含まれるRTPヘッダと、他のように流れるされています。
Depending on the FEC scheme, RTP can also be used as a transport for repair packet flows. In this case, a FEC scheme has to define an RTP payload format for the repair data.
FECスキームによっては、RTPも修理パケットフローのトランスポートとして使用することができます。この場合、FECスキームは、リペアデータのRTPペイロードフォーマットを定義しなければなりません。
The architecture outlined above is illustrated in Figure 1. In this architecture, two (optional) RTP instances are shown, for the source and repair data, respectively. This is because the use of RTP for the source data is separate from, and independent of, the use of RTP for the repair data. The appearance of two RTP instances is more natural when one considers that in many FEC codes, the repair payload contains repair data calculated across the RTP headers of the source packets. Thus, a repair packet carried over RTP starts with an RTP header of its own, which is followed (after the Repair Payload ID) by repair data containing bytes that protect the source RTP headers (as well as repair data for the source RTP payloads).
上記で概説したアーキテクチャは、このアーキテクチャでは、図1に示され、2つ（オプション）RTPインスタンスは、それぞれ、ソースおよびリペアデータのために、示されています。ソース・データのためのRTPの使用はから分離、および修復データのRTPの使用とは無関係であるからです。一つは、多くのFEC符号では、修復ペイロードはソースパケットのRTPヘッダにわたって計算修復データが含まれていることを考えるときに、2つのRTPインスタンスの外観がより自然です。したがって、RTPを介して搬送される修復パケットが（ソースRTPペイロードのための、ならびにリペアデータ）ソースRTPヘッダを保護バイトを含むリペアデータによって（修復ペイロードIDの後に）続いて、それ自身のRTPヘッダで始まり。
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
| Content Delivery Protocol | + - - - - - - - - - - - - - - - - - - - - - - - +
|コンテンツ配信プロトコル| + - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture
図1：FECフレームワークのアーキテクチャ
The content of the transport payload for repair packets is fully defined by the FEC scheme. For a specific FEC scheme, a means MAY be defined for repair data to be carried over RTP, in which case, the repair packet payload format starts with the RTP header. This corresponds to defining an RTP payload format for the specific FEC scheme.
リペアパケットのトランスポートペイロードの内容は完全にFECスキームによって定義されます。特定のFECスキームのために、手段がリペアデータが、その場合、リペアパケットのペイロードフォーマットは、RTPヘッダで始まり、RTP上に搬送されるために定義されてもよいです。これは、特定のFECスキームのためのRTPペイロードフォーマットを定義するに相当します。
The use of RTP for repair packets is independent of the protocols used for source packets: if RTP is used for source packets, repair packets may or may not use RTP and vice versa (although it is unlikely that there are useful scenarios where non-RTP source flows are protected by RTP repair flows). FEC schemes are expected to recover entire transport payloads for recovered source packets in all cases. For example, if RTP is used for source flows, the FEC scheme is expected to recover the entire UDP payload, including the RTP header.
修復パケットのRTPの使用は、ソースパケットのために使用されるプロトコルとは無関係である：RTPは、ソースパケットのために使用される場合、リペアパケットは、または使用してもしなくてもよいRTPおよびその逆（それはそうであるが、有用なシナリオはここで非RTPがあることソースフロー）はRTPの修理の流れによって保護されています。 FECスキームは、すべてのケースで回復ソースパケットのための全体のトランスポートペイロードを回復することが期待されています。 RTPソース・フローに使用される場合、例えば、FECスキームは、RTPヘッダを含む、全体のUDPペイロードを回復することが期待されます。
The mechanism defined in this document does not place any restrictions on the ADUs that can be protected together, except that the ADU be carried over a supported transport protocol (see Section 7). The data can be from multiple source flows that are protected jointly. The FEC Framework handles the source flows as a sequence of source blocks each consisting of a set of ADUs, possibly from multiple source flows that are to be protected together. For example, each source block can be constructed from those ADUs related to a particular segment in time of the flow.
この文書で定義されたメカニズムは、ADUがサポートされているトランスポートプロトコル（セクション7を参照）上で実施されることを除いて、一緒に保護することができますのADUに制限を課しません。データは共同で保護されている複数のソース・フローからのものであり得ます。 FECフレームワークは、ソースはおそらく一緒に保護される複数のソース・フローから、ソースブロックのシーケンスとしてのADUの組からなる各フロー処理します。例えば、各ソースブロックは、流量の時間に特定のセグメントに関連するもののADUから構成することができます。
At the sender, the FEC Framework passes the payloads for a given block to the FEC scheme for FEC encoding. The FEC scheme performs the FEC encoding operation and returns the following information:
送信側において、FECフレームワークは、FEC符号化のためのFECスキームに与えられたブロックのためのペイロードを渡します。 FEC方式は、FEC符号化動作を行い、次の情報を戻します。
o Optionally, FEC Payload IDs for each of the source payloads (encoded according to a FEC-Scheme-Specific format).
O必要に応じて、ソース・ペイロードの各々に対するFECペイロードIDは（FEC-スキーム固有のフォーマットに従って符号化されました）。
o One or more FEC repair packet payloads.
一の以上のFECリペアパケットペイロードO。
o FEC Payload IDs for each of the repair packet payloads (encoded according to a FEC-Scheme-Specific format).
リペアパケットペイロードの各々に対するFECペイロードIDは（FEC-スキーム固有のフォーマットに従って符号化された）O。
The FEC Framework then performs two operations. First, it appends the Source FEC Payload IDs, if provided, to each of the ADUs, and sends the resulting packets, known as "FEC source packets", to the receiver. Second, it places the provided FEC repair packet payloads and corresponding Repair FEC Payload IDs appropriately to construct FEC repair packets and send them to the receiver.
FECフレームワークは、2つの動作を行います。まず提供される場合、それはのADUのそれぞれに、ソースFECペイロードIDを付加し、受信機に、「FECソースパケット」として知られて得られたパケットを送信します。第二に、それはFEC修復パケットを構築し、受信機に送信するために適切に提供さFECリペアパケットのペイロードおよび対応するリペアFECペイロードIDを配置します。
This document does not define how the sender determines which ADUs are included in which source blocks or the sending order and timing of FEC source and repair packets. A specific CDP MAY define this mapping, or it MAY be left as implementation dependent at the sender. However, a CDP specification MUST define how a receiver determines a minimum length of time that it needs to wait to receive FEC repair packets for any given source block. FEC schemes MAY define limitations on this mapping, such as maximum size of source blocks, but they SHOULD NOT attempt to define specific mappings. The sequence of operations at the sender is described in more detail in Section 4.2.
この文書では、送信者がのADUがどのソースブロックまたはFECソースおよびリペアパケットの送信順序やタイミングに含まれているかを判断する方法を定義しません。特定のCDPは、このマッピングを定義する場合もあれば、送信側の実装に依存として残すことができます。しかし、CDP仕様は、受信機は、それが任意の所与のソースブロックに対するFECリペアパケットを受信するのを待つ必要がある時間の最小の長さを決定する方法を定義しなければなりません。 FECスキームは、このようなソースブロックの最大サイズとして、このマッピングに制限を定義するかもしれないが、彼らは、特定のマッピングを定義しないでください。送信側における動作のシーケンスは、4.2節でより詳細に記載されています。
At the receiver, original ADUs are recovered by the FEC Framework directly from any FEC source packets received simply by removing the Source FEC Payload ID, if present. The receiver also passes the contents of the received ADUs, plus their FEC Payload IDs, to the FEC scheme for possible decoding.
受信機において、オリジナルのADUは、パケットが存在する場合、ソースFECペイロードIDを除去することにより、単に受信したFECソースから直接FECフレームワークによって回収されます。受信機はまた、可能復号化のためのFECスキームに、受信のADUの内容に加え、それらのFECペイロードIDを渡します。
If any ADUs related to a given source block have been lost, then the FEC scheme can perform FEC decoding to recover the missing ADUs (assuming sufficient FEC source and repair packets related to that source block have been received).
所与のソースブロックに関連する任意のADUが失われた場合には、FECスキームは、（そのソースブロックに関連する十分なFECソースおよびリペアパケットが受信されたと仮定して）行方不明のADUを回復するためにFEC復号化を実行することができます。
Note that the receiver might need to buffer received source packets to allow time for the FEC repair packets to arrive and FEC decoding to be performed before some or all of the received or recovered packets are passed to the application. If such a buffer is not provided, then the application has to be able to deal with the severe re-ordering of packets that can occur. However, such buffering is CDP- and/or implementation-specific and is not specified here. The receiver operation is described in more detail in Section 4.3.
受信機は受信または回復されたパケットの一部又は全てのアプリケーションに渡される前に実行される到着するFECリペアパケットとFEC復号化のための時間を可能にするために、受信したソースパケットをバッファリングする必要があるかもしれないことに留意されたいです。そのようなバッファが提供されていない場合は、アプリケーションが発生する可能性があり、パケットの深刻な再順序付けに対処できるようにしています。しかし、そのようなバッファリングは、CDP-および/または実装固有であり、ここで指定されていません。受信機動作は、4.3節でより詳細に説明します。
The FEC source packets MUST contain information that identifies the source block and the position within the source block (in terms specific to the FEC scheme) occupied by the ADU. This information is known as the Source FEC Payload ID. The FEC scheme is responsible for defining and interpreting this information. This information MAY be encoded into a specific field within the FEC source packet format defined in this specification, called the Explicit Source FEC Payload ID field. The exact contents and format of the Explicit Source FEC Payload ID field are defined by the FEC schemes. Alternatively, the
FECソースパケットがソースブロックとADUによって占有（FECスキームに特有の用語で）ソースブロック内の位置を識別する情報を含まなければなりません。この情報はソースFECペイロードIDとして知られています。 FECスキームは、定義し、この情報を解釈する責任があります。この情報は、明示的なソースFECペイロードIDフィールドと呼ばれ、本明細書で定義されたFECソースパケットフォーマット内の特定のフィールドに符号化されてもよいです。明示的なソースFECペイロードIDフィールドの正確な内容およびフォーマットはFECスキームによって定義されます。また、
FEC scheme MAY define how the Source FEC Payload ID is derived from other fields within the source packets. This document defines the way that the Explicit Source FEC Payload ID field is appended to source packets to form FEC source packets.
FECスキームは、ソースFECペイロードIDは、ソースパケット内の他のフィールドに由来している方法を定義することができます。この文書は、明示的なソースFECペイロードIDフィールドは、FECソースパケットを形成するために、ソースパケットに付加された方法を定義します。
The FEC repair packets MUST contain information that identifies the source block and the relationship between the contained repair payloads and the original source block. This is known as the Repair FEC Payload ID. This information MUST be encoded into a specific field, the Repair FEC Payload ID field, the contents and format of which are defined by the FEC schemes.
FECリペアパケットは、ソースブロックと含ま修復ペイロードと元のソースブロックとの間の関係を識別する情報を含まなければなりません。これは、リペアFECペイロードIDとして知られています。この情報は、特定のフィールド、リペアFECペイロードIDフィールド、FECスキームによって定義される内容とフォーマットにエンコードされなければなりません。
The FEC scheme MAY use different FEC Payload ID field formats for source and repair packets.
FECスキームは、ソースおよび修理のパケットに対して異なるFECペイロードIDフィールドのフォーマットを使用することができます。
It is assumed that the sender has constructed or received original data packets for the session. These could be carrying any type of data. The following operations, illustrated in Figure 2 for the case of UDP repair flows and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:
送信者が構築またはセッションのために元のデータパケットを受信したことを想定しています。これらは、任意のタイプのデータを運ぶことができます。 RTP修復フローの場合については、図3 UDPリペアフローの場合についてとで、図2に示されている以下の操作は、流れる準拠ソース及び修理を生成することが可能な方法を説明します。
3. The source block is passed to the FEC scheme for FEC encoding. The Source FEC Payload ID information of each source packet is determined by the FEC scheme. If required by the FEC scheme, the Source FEC Payload ID is encoded into the Explicit Source FEC Payload ID field.
3.ソースブロックは、FEC符号化のためのFECスキームに渡されます。各ソースパケットのソースFECペイロードID情報は、FECスキームによって決定されます。 FECスキームによって必要な場合は、ソースFECペイロードIDは、明示的なソースFECペイロードIDフィールドに符号化されています。
4. The FEC scheme performs FEC encoding, generating repair packet payloads from a source block and a Repair FEC Payload ID field for each repair payload.
4. FECスキームは、各修復ペイロードのソースブロック及びリペアFECペイロードIDフィールドからリペアパケットペイロードを生成する、FEC符号化を実行します。
5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload IDs, and repair packet payloads are provided back from the FEC scheme to the FEC Framework.
5.明示的なソースFECペイロードIDは、（使用する場合）、FECペイロードIDを修復し、修復パケットペイロードはFECフレームワークにFECスキームから背面に設けられています。
6. The FEC Framework constructs FEC source packets according to Section 5.3, and FEC repair packets according to Section 5.4, using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.
6. FECフレームワークは、FECスキームによって提供されるFECペイロードIDとリペアパケットのペイロードを使用して、5.4節によれば、セクション5.3に従ってFECソースパケットおよびFECリペアパケットを構築します。
7. The FEC source and repair packets are sent using normal transport-layer procedures. The port(s) and multicast group(s) to be used for FEC repair packets are defined in the FEC Framework Configuration Information. The FEC source packets are sent using the same ADU flow identification information as would have been used for the original source packets if the FEC Framework were not present (for example, in the UDP case, the UDP source and destination addresses and ports on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied).
7. FECソースおよびリペアパケットは、通常、トランスポート・レイヤ・プロシージャを使用して送信されます。 FECリペアパケットのために使用するポート（複数可）とマルチキャストグループ（単数または複数）はFECフレームワーク設定情報に定義されています。元のソースパケットのために使用されたであろうようにFECフレームワークは（存在しない場合、FECソースパケットが同じADUフロー識別情報を使用して送信され、例えば、UDPの場合には、IP上のUDP送信元および宛先アドレスおよびポートソースパケットを運ぶデータグラム）はFECフレームワークが適用されるか否か同じになります。
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 2: Sender Operation
図2：送信側動作
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 3: Sender Operation with RTP Repair Flows
図3：RTP修理フローと送信側動作
The following describes a possible receiver algorithm, illustrated in Figures 4 and 5 for the case of UDP and RTP repair flows, respectively, when receiving a FEC source or repair packet:
以下は、UDP及びRTPリペアフローの場合について図4および図5に示す可能受信機アルゴリズムを記述する、それぞれ、FECソースまたはリペアパケットを受信した場合。
1. FEC source packets and FEC repair packets are received and passed to the FEC Framework. The type of packet (source or repair) and the source flow to which it belongs (in the case of source packets) are indicated by the ADU flow information, which identifies the flow at the transport layer.
1. FECソースパケットおよびFECリペアパケットが受信され、FECフレームワークに渡されます。パケットのタイプ（ソースまたはリペア）、それは（ソースパケットの場合）に属するソース・フローはトランスポート層でフローを識別するADUフロー情報によって示されます。
In the special case that RTP is used for repair packets, and
source and repair packets are multiplexed onto the same UDP flow,
then RTP demultiplexing is required to demultiplex source and repair flows. However, RTP processing is applied only to the
repair packets at this stage; source packets continue to be
handled as UDP payloads (i.e., including their RTP headers).
2. The FEC Framework extracts the Explicit Source FEC Payload ID field (if present) from the source packets and the Repair FEC Payload ID from the repair packets.
2. FECフレームワークは、リペアパケットからソースパケットとリペアFECペイロードIDからの明示的なソースFECペイロードIDフィールド（存在する場合）を抽出します。
3. The Explicit Source FEC Payload IDs (if present), Repair FEC Payload IDs, and FEC source and repair payloads are passed to the FEC scheme.
3.明示的なソースFECペイロードIDは、（存在する場合）、FECペイロードIDを修復し、FECソースおよびリペアペイロードはFECスキームに渡されます。
4. The FEC scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs in the case that the Explicit Source FEC Payload ID field is not used) to group source and repair packets into source blocks. If at least one source packet is missing from a source block, and at least one repair packet has been received for the same source block, then FEC decoding can be performed in order to recover missing source payloads. The FEC scheme determines whether source packets have been lost and whether enough data for decoding of any or all of the missing source payloads in the source block has been received.
4. FECスキームは、受信されたFECペイロードIDを使用して（と明示ソースFECペイロードIDフィールドは使用されない場合に、FECソースペイロードIDを派生）ソースブロックにグループ源及び修復パケットに。少なくとも1つのソースパケットがソースブロックから欠落していると、少なくとも1つのリペアパケットは、同じソースブロックのために受信された場合、FEC復号化が欠落ソースペイロードを回復するために行うことができます。 FEC方式は、ソースパケットが失われたかどうか、および任意またはソースブロック内のソース欠落ペイロードの全ての復号化のための十分なデータが受信されたか否かを判断します。
5. The FEC scheme returns the ADUs to the FEC Framework in the form of source blocks containing received and decoded ADUs and indications of any ADUs that were missing and could not be decoded.
5. FECスキームは、受信され復号のADUと欠落してデコードすることができなかった任意のADUの指示を含むソースブロックの形でFECフレームワークへのADUを返します。
6. The FEC Framework passes the received and recovered ADUs to the application.
6. FECフレームワークは、受信を通過し、アプリケーションへのADUを回復しました。
The description above defines functionality responsibilities but does not imply a specific set of timing relationships. Source packets that are correctly received and those that are reconstructed MAY be delivered to the application out of order and in a different order from the order of arrival at the receiver. Alternatively, buffering and packet re-ordering MAY be applied to re-order received and reconstructed source packets into the order they were placed into the source block, if that is necessary according to the application.
上記の説明は、機能の責任を定義するが、タイミング関係の特定のセットを意味するものではありません。ソースパケットが正しく受信され、再構成されているものが順不同と受信機の到着の順序とは異なる順序でアプリケーションに送達することができます。あるいは、バッファリング及びパケット並べ替えをするために適用することができる再注文が受信され、それはアプリケーションに応じて必要であればために再構成されたソースパケットは、それらが、ソースブロックに入れました。
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 4: Receiver Operation
図4：レシーバ動作
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 5: Receiver Operation with RTP Repair Flows
図5：RTPの修復フローとレシーバ動作
Note that the above procedure might result in a situation in which not all ADUs are recovered.
上記の手順ではなく、すべてのADUが回収される状況になるかもしれないことに注意してください。
This section specifies the protocol elements for the FEC Framework. Three components of the protocol are defined in this document and are described in the following sections:
このセクションでは、FECフレームワークのためのプロトコル要素を指定します。プロトコルの3つの成分は、この文書で定義され、以下のセクションに記載されています。
1. Construction of a source block from ADUs. The FEC code will be applied to this source block to produce the repair payloads.
ADUからソースブロックの1建設。 FECコードは、修復ペイロードを生成するために、このソースブロックに適用されます。
The operation of the FEC Framework is governed by certain FEC Framework Configuration Information, which is defined in this section. A complete protocol specification that uses this framework MUST specify the means to determine and communicate this information between sender and receiver.
FECフレームワークの動作は、このセクションで定義された特定のFEC Framework構成情報、によって支配されています。このフレームワークを使用する完全なプロトコル仕様は決定し、送信側と受信側の間でこの情報を通信するための手段を指定しなければなりません。
The FEC Framework and FEC scheme exchange ADUs in the form of source blocks. A source block is generated by the FEC Framework from an ordered sequence of ADUs. The allocation of ADUs to blocks is dependent on the application. Note that some ADUs may not be included in any block. Each source block provided to the FEC scheme consists of an ordered sequence of ADUs where the following information is provided for each ADU:
ソースブロックの形でFECフレームワークとFECスキーム交換のADU。ソースブロックのADUの順序付けられたシーケンスからFECフレームワークによって生成されます。ブロックへのADUの割り当てはアプリケーションに依存しています。いくつかのADUは、任意のブロックに含まれないことに注意してください。 FECスキームに設けられた各ソースブロックは、以下の情報は、各ADUのために提供されるのADUの規則正しい配列から成ります：
o A description of the source flow with which the ADU is associated.
ADUが関連付けられているソース・フローの記述O。
o The ADU itself.
ADU自体の。
o The length of the ADU.
ADUの長さは、O。
The packet format for FEC source packets MUST be used to transport the payload of an original source packet. As depicted in Figure 6, it consists of the original packet, optionally followed by the Explicit Source FEC Payload ID field. The FEC scheme determines whether the Explicit Source FEC Payload ID field is required. This determination is specific to each ADU flow.
FECソースパケットに関するパケットフォーマットは、元のソースパケットのペイロードを輸送するために使用されなければなりません。図6に示されるように、それは、必要に応じて明示的なソースFECペイロードIDフィールドに続く元のパケットからなります。 FECスキームは、明示的なソースFECペイロードIDフィールドが必要とされているかどうかを決定します。この決定は、各ADU流に特異的です。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+
Figure 6: Structure of the FEC Packet Format for FEC Source Packets
図6：FECソースパケットのためのFECパケットフォーマットの構造
The FEC source packets MUST be sent using the same ADU flow as would have been used for the original source packets if the FEC Framework were not present. The transport payload of the FEC source packet MUST consist of the ADU followed by the Explicit Source FEC Payload ID field, if required.
FECソースパケットはFECフレームワークが存在しない場合、元のソースパケットのために使用されたであろう同じADUフローを使用して送信されなければなりません。 FECソースパケットのトランスポート・ペイロードは、ADUで構成する必要があり、必要であれば、明示的なソースFECペイロードIDフィールドが続きます。
The Explicit Source FEC Payload ID field contains information required to associate the source packet with a source block and for the operation of the FEC algorithm, and is defined by the FEC scheme. The format of the Source FEC Payload ID field is defined by the FEC scheme. In the case that the FEC scheme or CDP defines a means to derive the Source FEC Payload ID from other information in the packet (for example, a sequence number used by the application protocol), then the Source FEC Payload ID field is not included in the packet. In this case, the original source packet and FEC source packet are identical.
明示的なソースFECペイロードIDフィールドは、ソースブロックとし、FECアルゴリズムの動作のためにソースパケットを関連付けるために必要な情報を含み、FECスキームによって定義されます。ソースFECペイロードIDフィールドのフォーマットは、FECスキームによって定義されます。 FECスキームまたはCDPは、（例えば、アプリケーションプロトコルによって使用されるシーケンス番号）は、パケット内の他の情報からソースFECペイロードIDを導出する手段を定義する場合には、ソースFECペイロードIDフィールドはに含まれていませんパケット。この場合、元のソースパケットおよびFECソースパケットは同一です。
In applications where avoidance of IP packet fragmentation is a goal, CDPs SHOULD consider the Explicit Source FEC Payload ID size when determining the size of ADUs that will be delivered using the FEC Framework. This is because the addition of the Explicit Source FEC Payload ID increases the packet length.
FECフレームワークを使用して配信されますのADUのサイズを決定する際にIPパケットの断片化の回避が目的であるアプリケーションでは、のCDPは、明示的なソースFECペイロードIDの大きさを考慮すべきです。明示的なソースFECペイロードIDの付加は、パケット長を増加させるためです。
The Explicit Source FEC Payload ID is placed at the end of the packet, so that in the case that Robust Header Compression (ROHC) [RFC3095] or other header compression mechanisms are used, and in the case that a ROHC profile is defined for the protocol carried within the transport payload (for example, RTP), then ROHC will still be applied for the FEC source packets. Applications that are used with this framework need to consider that FEC schemes can add this Explicit Source FEC Payload ID and thereby increase the packet size.
明示的なソースFECペイロードIDは、ロバストヘッダ圧縮（ROHC）[RFC3095]または他のヘッダ圧縮メカニズムが使用される場合となるように、およびROHCプロファイルが定義されている場合には、パケットの最後に配置されていますプロトコルは、トランスポート・ペイロード（例えば、RTP）内で実施し、ROHCは依然としてFECソースパケットに適用されるであろう。このフレームワークで使用されているアプリケーションは、FECスキームは、この明示的なソースFECペイロードIDを追加することにより、パケットサイズを増やすことを検討する必要があります。
In many applications, support for FEC is added to a pre-existing protocol, and in this case, use of the Explicit Source FEC Payload ID can break backward compatibility, since source packets are modified.
多くのアプリケーションでは、FECのサポートは、既存のプロトコルに追加され、ソースパケットが修正されるので、この場合には、明示的なソースFECペイロードIDの使用は、後方互換性を破ることができます。
In order to apply FEC protection using multiple FEC schemes to a single source flow, all schemes have to use the same Explicit Source FEC Payload ID format. In order to enable this, it is RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format described below.
単一のソースフローに複数のFEC方式を使用してFEC保護を適用するためには、すべてのスキームは同じ明示的なソースFECペイロードIDフォーマットを使用する必要があります。これを可能にするためには、FECスキームは、以下に説明汎用明示的なソースFECペイロードIDフォーマットをサポートすることが推奨されます。
The Generic Explicit Source FEC Payload ID has a length of two octets and consists of an unsigned packet sequence number in network-byte order. The allocation of sequence numbers to packets is independent of any FEC scheme and of the source block construction, except that the use of this sequence number places a constraint on source block construction. Source packets within a given source block MUST have consecutive sequence numbers (where consecutive includes wrap-around from the maximum value that can be represented in two octets (65535) to 0). Sequence numbers SHOULD NOT be reused until all values in the sequence number space have been used.
一般的な明示的なソースFECペイロードIDは、2つのオクテットの長さを有し、ネットワークバイト順で符号なしのパケットシーケンス番号で構成されています。パケットのシーケンス番号の割り当ては、このシーケンス番号を使用するが、ソースブロック構造に制約を課すことを除いて、任意のFECスキームのソースブロック構造とは無関係です。所与のソースブロック内のソースパケットは、連続したシーケンス番号を持たなければならない（連続は、ラップアラウンド0に2つのオクテット（65535）で表すことができる最大値から含む場合）。シーケンス番号空間内のすべての値が使用されるまで、シーケンス番号は再利用されるべきではありません。
Note that if the original packets of the source flow are already carrying a packet sequence number that is at least two bytes long, there is no need to add the generic Explicit Source FEC Payload ID and modify the packets.
ソースの流れの元のパケットがすでに少なくとも2バイトの長さのパケットシーケンス番号を運んでいる場合は、パケットを汎用の明示的なソースFECペイロードIDを追加および変更する必要がないことに注意してください。
The packet format for FEC repair packets is shown in Figure 7. The transport payload consists of a Repair FEC Payload ID field followed by repair data generated in the FEC encoding process.
FECリペアパケットに関するパケットフォーマットは、トランスポート・ペイロードがFEC符号化処理において生成リペアデータ続いリペアFECペイロードIDフィールドで構成され、図7に示されています。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 7: Packet Format for FEC Repair Packets
図7：FECリペアパケットのパケットフォーマット
The Repair FEC Payload ID field contains information required for the operation of the FEC algorithm at the receiver. This information is defined by the FEC scheme. The format of the Repair FEC Payload ID field is defined by the FEC scheme.
リペアFECペイロードIDフィールドは、受信機におけるFECアルゴリズムの動作に必要な情報を含んでいます。この情報は、FECスキームによって定義されます。リペアFECペイロードIDフィールドのフォーマットはFECスキームによって定義されます。
For FEC schemes that specify the use of RTP for repair packets, the packet format for repair packets includes an RTP header as shown in Figure 8.
図8に示すように、リペアパケットのRTPの使用を指定FECスキームのため、リペアパケットに関するパケットフォーマットは、RTPヘッダを含みます。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 8: Packet Format for FEC Repair Packets over RTP
図8：RTPオーバーFECリペアパケットのパケットフォーマット
The FEC Framework Configuration Information is information that the FEC Framework needs in order to apply FEC protection to the ADU flows. A complete CDP specification that uses the framework specified here MUST include details of how this information is derived and communicated between sender and receiver.
FECフレームワークの設定情報は、FECフレームワークは、ADUフローにFEC保護を適用するために必要な情報です。この情報が導出され、送信者と受信者との間で通信する方法の詳細を含まなければなりません、ここで指定されたフレームワークを使用して、完全なCDP仕様。
The FEC Framework Configuration Information includes identification of the set of source flows. For example, in the case of UDP, each source flow is uniquely identified by a tuple {source IP address, source UDP port, destination IP address, destination UDP port}. In some applications, some of these fields can contain wildcards, so that the flow is identified by a subset of the fields. In particular, in many applications the limited tuple {destination IP address, destination UDP port} is sufficient.
FECフレームワークの設定情報は、ソース・フローのセットの識別を含みます。例えば、UDPの場合、各ソース・フローを一意タプル{送信元IPアドレス、送信元UDPポート、宛先IPアドレス、宛先UDPポート}によって識別されます。流れはフィールドのサブセットで識別されるように、いくつかのアプリケーションでは、これらのフィールドのいくつかは、ワイルドカードを含めることができます。具体的には、多くの用途に限定タプル{宛先IPアドレス、宛先UDPポートは}で十分です。
A single instance of the FEC Framework provides FEC protection for packets of the specified set of source flows, by means of one or more packet flows consisting of repair packets. The FEC Framework Configuration Information includes, for each instance of the FEC Framework:
FECフレームワークの単一のインスタンスは、ソース・フローの指定されたセットのパケットのFEC保護を提供し、一つ以上のパケットによって修復パケットからなる流れます。 FECフレームワークの設定情報は、FECフレームワークのインスタンスごとに、含まれています。
A. Definition of the source flow.
ソースの流れのA.定義。
B. An integer identifier for this flow definition (i.e., tuple). This identifier MUST be unique among all source flows that are protected by the same FEC repair flow. Integer identifiers can be allocated starting from zero and increasing by one for each flow. However, any random (but still unique) allocation is also possible. A source flow identifier need not be carried in source packets, since source packets are directly associated with a flow by virtue of their packet headers.
B.このフロー定義（すなわち、タプル）に対する整数識別子。この識別子は、同じFECリペアフローによって保護されているすべてのソース・フローの中で一意でなければなりません。整数識別子は、ゼロから開始し、各フローに対して1つずつ増加割り当てることができます。しかし、任意のランダムな（しかしユニーク）の割り当ても可能です。ソースパケットを直接そのパケットヘッダによってフローに関連付けられているため、ソース・フロー識別子は、ソースパケットで運ばれる必要はありません。
5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each consisting of a name and a value where the valid element names and value ranges are defined by the FEC scheme.
5.ゼロまたはそれ以上のFEC-スキーム固有情報（FSSI）要素、名前、有効な要素名と値の範囲は、FECスキームによって定義される値からなる各。
Multiple instances of the FEC Framework, with separate and independent FEC Framework Configuration Information, can be present at a sender or receiver. A single instance of the FEC Framework protects packets of the source flows identified in (2) above; i.e., all packets sent on those flows MUST be FEC source packets as defined in Section 5.3. A single source flow can be protected by multiple instances of the FEC Framework.
別個の独立したFECフレームワークの設定情報とFECフレームワークの複数のインスタンスは、送信側または受信側に存在することができます。 FECフレームワークの単一のインスタンスは、ソースのパケットを保護（2）上記で同定されたフロー。セクション5.3で定義されるように、すなわち、これらのフロー上で送られるすべてのパケットは、FECソースパケットでなければなりません。単一のソース・フローは、FECフレームワークの複数のインスタンスによって保護することができます。
The integer flow identifier identified in (2B) above is a shorthand to identify source flows between the FEC Framework and the FEC scheme. The reason for defining this as an integer, and including it in the FEC Framework Configuration Information, is so that the FEC scheme at the sender and receiver can use it to identify the source flow with which a recovered packet is associated. The integer flow identifier can therefore take the place of the complete flow description (e.g., UDP 4-tuple).
（2B）で同定された整数フロー識別子は、上記のソースFECフレームワークとFECスキームとの間でフローを識別するための速記です。送信側と受信側でFECスキームが回復パケットが関連付けられているソース・フローを識別するためにそれを使用できるように整数としてこれを定義し、FECフレームワーク設定情報に含める理由は、です。整数フロー識別子は、したがって、完全なフロー記述（例えば、UDP 4タプル）を行うことができます。
Whether and how this flow identifier is used is defined by the FEC scheme. Since repair packets can provide protection for multiple source flows, repair packets either would not carry the identifier at all or can carry multiple identifiers. However, in any case, the flow identifier associated with a particular source packet can be recovered from the repair packets as part of a FEC decoding operation.
かどうか、そしてどのようにこのフロー識別子が使用されているFECスキームによって定義されます。リペアパケットは、複数のソース・フローに対する保護を提供することができるので、いずれかのリペアパケットは、すべての識別子を運ぶことはないだろうか、複数の識別子を運ぶことができます。しかし、いずれの場合においても、特定のソースパケットに関連付けられたフロー識別子は、FEC復号動作の一部として、リペアパケットから回収することができます。
A single FEC repair flow provides repair packets for a single instance of the FEC Framework. Other packets MUST NOT be sent within this flow; i.e., all packets in the FEC repair flow MUST be FEC repair packets as defined in Section 5.4 and MUST relate to the same FEC Framework instance.
単一のFECリペアフローはFECフレームワークの単一のインスタンスに対してリペアパケットを提供します。その他のパケットは、この流れの中に送ってはいけません。セクション5.4で定義されており、同一のFECフレームワーク・インスタンスに関連しなければならないように、すなわち、FECリペアフローの全てのパケットは、FECリペアパケットでなければなりません。
In the case that RTP is used for repair packets, the identification of the repair packet flow can also include the RTP payload type to be used for repair packets.
RTPは、修復パケットのために使用される場合には、リペアパケットフローの識別はまた、リペアパケットに使用されるRTPペイロードタイプを含むことができます。
FSSI includes the information that is specific to the FEC scheme used by the CDP. FSSI is used to communicate the information that cannot be adequately represented otherwise and is essential for proper FEC encoding and decoding operations. The motivation behind separating the FSSI required only by the sender (which is carried in a Sender-Side FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of the FSSI is to provide the receiver or the third-party entities a means of controlling the FEC operations at the sender. Any FSSI other than the one solely required by the sender MUST be communicated via the FSSI container.
FSSIはCDPで使用されるFECスキームに固有の情報を含みます。 FSSIは十分さもなければ表される、適切なFEC符号化および復号化動作のために必須であることができない情報を通信するために使用されます。 FSSIの残りの部分から（送信側FEC-スキーム固有の情報（SS-FSSI）コンテナで運ばれる）のみ送信者が必要なFSSIを分離するの背後にある動機は、受信機やサードパーティのエンティティを提供することです送信側でFEC動作を制御する手段。単に送信者によって必要とされるもの以外の任意FSSIはFSSI容器を介して通信されなければなりません。
The variable-length SS-FSSI and FSSI containers transmit the information in textual representation and contain zero or more distinct elements, whose descriptions are provided by the fully specified FEC schemes.
可変長SS-FSSIとFSSI容器は、テキスト表現で情報を送信し、その説明を完全に指定されたFECスキームによって提供されるゼロ個以上の別個の要素を含みます。
For the CDPs that choose the Session Description Protocol (SDP) [RFC4566] for their multimedia sessions, the ABNF [RFC5234] syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 of [RFC6364].
そのマルチメディアセッションのためのセッション記述プロトコル（SDP）[RFC4566]を選択したのCDPのために、SS-FSSIとFSSIコンテナのABNF [RFC5234]構文は、[RFC6364]のセクション4.5で提供されています。
In order to be used with this framework, a FEC scheme MUST be capable of processing data arranged into blocks of ADUs (source blocks).
このフレームワークで使用するためには、FECスキームは、（ソースブロック）のADUのブロックに配置されたデータを処理できなければなりません。
A specification for a new FEC scheme MUST include the following:
新しいFECスキームの仕様は以下を含める必要があります。
1. The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA, as described in Section 11.
1.一意FECスキームを識別するFEC符号化ID値。セクション11で説明したように、この値は、IANAに登録されなければなりません。
2. The type, semantics, and encoding format of the Repair FEC Payload ID.
2.タイプ、意味論、及びリペアFECペイロードIDのエンコード形式。
3. The name, type, semantics, and text value encoding rules for zero or more FEC-Scheme-Specific Information elements.
3.名前、タイプ、セマンティクス、およびゼロまたはそれ以上のFEC-スキーム固有の情報要素のテキスト値の符号化規則。
This specification MUST precisely define the valid FEC-Scheme-
Specific Information values, the valid FEC Payload ID values, and
the valid packet payload sizes (where packet payload refers to
the space within a packet dedicated to carrying encoding
symbols).
Furthermore, given a source block as defined in Section 5.2, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size, the specification MUST uniquely define the values of the encoding symbols to be included in the repair packet payload of a packet with the given Repair FEC Payload ID value.
また、セクション5.2で定義されるように、FECスキーム特有の情報の有効な値は、有効なリペアFECペイロードID値、および有効なパケットのペイロードサイズは、ソースブロックを所定の仕様を一意に符号化シンボルの値を定義する必要があります所与のリペア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 that -- given a source block, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size as input -- produces the exact value of the encoding symbols as output.
ソースブロック、FEC-スキーム特有の情報の有効な値は、有効なリペアFECペイロード所与 - 詳細の必要なレベルにFECコードを指定するための一般的かつ簡単な方法は、符号化アルゴリズムの正確な仕様を提供することですID値、入力として有効なパケットペイロードサイズは - 出力として符号化シンボルの正確な値を生成します。
This description need not be to the same level of detail as for
the encoding above; however, it has to be sufficient to
demonstrate that encoding and decoding of the code are both
possible and practical.
FEC scheme specifications MAY additionally define the following:
FECスキームの仕様は、さらに次のように定義することができます。
Type, semantics, and encoding format of an Explicit Source FEC Payload ID.
タイプ、意味論、および明示的なソースFECペイロードIDのエンコード形式。
Whenever a FEC scheme specification defines an 'encoding format' for an element, this has to be defined in terms of a sequence of bytes that can be embedded within a protocol. The length of the encoding format either MUST be fixed or it MUST be possible to derive the length from examining the encoded bytes themselves. For example, the initial bytes can include some kind of length indication.
FECスキーム仕様は要素のための「コード化フォーマット」を定義するたびに、このプロトコル内に埋め込むことができるバイトのシーケンスの観点から定義されなければなりません。符号化フォーマットの長さは、いずれかの修正が必要かは、符号化されたバイト自体を検査から長さを導出することができなければなりません。例えば、最初のバイトは、長さ指示のいくつかの種類を含むことができます。
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
FECスキームの仕様は、この文書で定義された用語を使用すべきであり、次の形式に従ってください：
1. Introduction <Describe the use cases addressed by this FEC scheme>
1.はじめに<このFECスキームによって対処ユースケースを説明>
2.1. Source FEC Payload ID(s) <Either define the type and
format of the Explicit Source FEC Payload ID or define how
Source FEC Payload ID information is derived from source
packets>
2.2. Repair FEC Payload ID <Define the type and format of the Repair FEC Payload ID>
2.2. FECペイロードIDを修復<リペアFECペイロードIDの種類と形式を定義>
2.3. FEC Framework Configuration Information <Define the names, types, and text value encoding formats of the FEC-Scheme-Specific Information elements>
2.3. FECフレームワークの構成情報<FEC-スキーム固有の情報要素の名前、種類、およびテキスト値のエンコード形式を定義します>
3. Procedures <Describe any procedures that are specific to this FEC scheme, in particular derivation and interpretation of the fields in the FEC Payload IDs and FEC-Scheme-Specific Information>
3.手順<特定の導出及びFECペイロードIDの内のフィールドの解釈とFEC-スキーム固有情報に、このFECスキームに固有の任意の手順を説明>
4. FEC Code Specification <Provide a complete specification of the FEC Code>
4. FECコード仕様<FECコードの完全な仕様を提供します>
Specifications can include additional sections including 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 (except, of course, a specification of one FEC scheme can include portions of another by reference). Where an RTP payload format is defined for repair data for a specific FEC scheme, the RTP payload format and the FEC scheme can be specified within the same document.
各FECスキームは、個別仕様以上仕様の完全に独立した部分（ただし、もちろん、1つのFECスキームの仕様は、参照によって別の部分を含むことができる）、例えば、独立して、全ての他のFECスキームの指定されなければなりません。 RTPペイロードフォーマットは、特定のFECスキームのリペアデータのために定義されている場合、RTPペイロードフォーマットとFECスキームは、同じドキュメント内で指定することができます。
Many applications require some kind of feedback on transport performance, e.g., how much data arrived at the receiver, at what rate, and when? When FEC is added to such applications, feedback mechanisms may also need to be enhanced to report on the performance of the FEC, e.g., how much lost data was recovered by the FEC?
多くのアプリケーションでは、どのような割合で、受信機に到着し、そしてとき例えば、どのくらいのデータ、輸送性能にフィードバックのいくつかの種類を必要としますか？ FECは、そのようなアプリケーションに追加されると、フィードバック機構はまた、FEC、例えば、どのくらいの失われたデータは、FECにより回収したのパフォーマンスを報告するように拡張する必要があるかもしれませんか？
When used to provide instrumentation for engineering purposes, it is important to remember that FEC is generally applied to relatively small blocks of data (in the sense that each block is transmitted over a relatively small period of time). Thus, feedback information that is averaged over longer periods of time will likely not provide sufficient information for engineering purposes. More detailed feedback over shorter time scales might be preferred. For example, for applications using RTP transport, see [RFC5725].
エンジニアリングの目的のためにインスツルメンテーションを提供するために使用される場合、FECは一般的に（各ブロックは時間の比較的小さな期間にわたって送信されるという意味で）データの比較的小さなブロックに適用されることを覚えておくことが重要です。このように、時間の長い期間にわたって平均化されたフィードバック情報は、可能性の高いエンジニアリングの目的のために十分な情報を提供することはありません。短い時間スケールをより詳細なフィードバックが好まれるかもしれません。例えば、RTPトランスポートを使用するアプリケーションのために、[RFC5725]を参照。
Applications that use feedback for congestion control purposes MUST calculate such feedback on the basis of packets received before FEC recovery is applied. If this requirement conflicts with other uses of the feedback information, then the application MUST be enhanced to support information calculated both pre- and post-FEC recovery. This is to ensure that congestion control mechanisms operate correctly based on congestion indications received from the network, rather than on post-FEC recovery information that would give an inaccurate picture of congestion conditions.
輻輳制御のためにフィードバックを使用するアプリケーションは、FEC回復が適用される前に受信したパケットに基づいて、このようなフィードバックを計算する必要があります。フィードバック情報の他の用途で、この要件が競合した場合、そのアプリケーションは、前後のFEC回復の両方を算出した情報をサポートするように拡張されなければなりません。これは、メカニズムはかなり混雑状況の不正確な絵を与えるポストFEC回復情報に比べて、ネットワークから受信した輻輳の指標に基づいて正しく動作する輻輳制御を確保することです。
New applications that require such feedback SHOULD use RTP/RTCP [RFC3550].
このようなフィードバックを必要とする新しいアプリケーションでは、RTP / RTCP [RFC3550]を使用すべきです。
This framework is intended to be used to define CDPs that operate over transport protocols providing an unreliable datagram service, including in particular the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP).
このフレームワークは、特に、ユーザデータグラムプロトコル（UDP）データグラム輻輳制御プロトコル（DCCP）を含む信頼性のないデータグラムサービスを提供するトランスポートプロトコル上で動作のCDPを定義するために使用されることを意図しています。
This section starts with some informative background on the motivation of the normative requirements for congestion control, which are spelled out in Section 8.2.
このセクションでは、8.2節で綴られている輻輳制御のための規範的要件のモチベーションに関するいくつかの有益な背景から始まります。
o The enforcement of congestion control principles has gained a lot of momentum in the IETF over recent years. While the need for congestion control over the open Internet is unquestioned, and the goal of TCP friendliness is generally agreed upon for most (but not all) applications, the problem of congestion detection and measurement in heterogeneous networks can hardly be considered solved. Most congestion control algorithms detect and measure congestion by taking (primarily or exclusively) the packet loss rate into account. This appears to be inappropriate in environments where a large percentage of the packet losses are the result of link-layer errors and independent of the network load.
O輻輳制御原則の施行は、近年IETFにおける運動量の多くを得ています。オープンインターネット上での輻輳制御の必要性は不問で、TCPフレンドリーの目標は、一般的に、ほとんどの（すべてではない）アプリケーションのために合意されている間、異種ネットワークにおける輻輳検出および測定の問題はほとんど解決しないとみなすことができます。ほとんどの輻輳制御アルゴリズムを検出し、アカウントに（主にまたは排他的に）パケットロス率を取ることによって輻輳を測定します。これは、パケット損失の大部分は、リンク層エラーの結果とネットワーク負荷から独立している環境では不適切であるように思われます。
o The authors of this document are primarily interested in applications where the application reliability requirements and end-to-end reliability of the network differ, such that it warrants higher-layer protection of the packet stream, e.g., due to the presence of unreliable links in the end-to-end path and where real-time, scalability, or other constraints prohibit the use of higher-layer (transport or application) feedback. A typical example for such applications is multicast and broadcast streaming or multimedia transmission over heterogeneous networks. In other cases, application reliability requirements can be so high that the required end-to-end reliability will be difficult to achieve. Furthermore, the end-to-end network reliability is not necessarily known in advance.
本書の著者は、信頼できないリンクが存在するために、アプリケーションの信頼性要件およびネットワークのエンド・ツー・エンドの信頼性が異なるアプリケーション、それはパケットストリームの上位層の保護を保証するような、例えばで主に興味を持っているoをエンドツーエンドパス、どこでリアルタイム、スケーラビリティ、または他の制約は、上位層（トランスポート又はアプリケーション）フィードバックの使用を禁止します。このような用途のための典型的な例は、異種ネットワーク上のマルチキャストおよびブロードキャストストリーミング又はマルチメディアの伝送です。他の例では、アプリケーションの信頼性の要件は、必要なエンドツーエンドの信頼性を達成することは困難になるほど高くなることがあります。また、エンドツーエンドのネットワークの信頼性は必ずしも事前に知られていません。
o This FEC Framework is not defined as, nor is it intended to be, a quality-of-service (QoS) enhancement tool to combat losses resulting from highly congested networks. It should not be used for such purposes.
OこのFECフレームワークは、次のように定義されていない、またそれは、非常に混雑したネットワークによる損失に対処するためのサービス品質（QoS）の拡張ツールであることが意図されています。それは、このような目的のために使用すべきではありません。
o In order to prevent such misuse, one approach is to leave standardization to bodies most concerned with the problem described above. However, the IETF defines base standards used by several bodies, including the Digital Video Broadcasting (DVB) Project, the Third Generation Partnership Project (3GPP), and 3GPP2, all of which appear to share the environment and the problem described.
Oこのような誤用を防止するために、1つのアプローチは、上述の問題に最も関係機関に標準化を残すことです。しかし、IETFは、環境と課題を共有して表示されるすべてのそれらのデジタルビデオ放送（DVB）プロジェクト、第三世代パートナーシッププロジェクト（3GPP）、および3GPP2、を含むいくつかの機関で使用されるベースの標準を定義します。
o Another approach is to write a clear applicability statement. For example, one could restrict the use of this framework to networks with certain loss characteristics (e.g., wireless links). However, there can be applications where the use of FEC is justified to combat congestion-induced packet losses -- particularly in lightly loaded networks, where congestion is the result of relatively rare random peaks in instantaneous traffic load -- thereby intentionally violating congestion control principles. One possible example for such an application could be a no-matter-what, brute-force FEC protection of traffic generated as an emergency signal.
O別のアプローチは、明確な適用性の文を書くことです。例えば、一方が一定の損失特性（例えば、無線リンク）を用いてネットワークへのこのフレームワークの使用を制限する可能性があります。これにより、意図的に輻輳制御の原則に違反する - 特に負荷の軽いネットワークでは、輻輳が瞬時トラフィック負荷は比較的まれなランダムピークの結果である - しかし、FECの使用は輻輳誘起パケット損失に対処するために正当化されるアプリケーションが存在し得ます。このようなアプリケーションのための一つの可能な例は無問題 - どのようなトラフィックのFEC保護は緊急信号として生成され、ブルートフォースである可能性があります。
o A third approach is to require, at a minimum, that the use of this framework with any given application, in any given environment, does not cause congestion issues that the application alone would not itself cause; i.e., the use of this framework must not make things worse.
O第三のアプローチは、任意のアプリケーションでこのフレームワークの使用は、任意の所与の環境において、単独で、アプリケーション自体が生じないこと、輻輳の問題を起こさないこと、最低限必要とすることです。すなわち、このフレームワークを使用すると、さらに悪いことではない必要があります。
o Taking the above considerations into account, Section 8.2 specifies a small set of constraints for FEC; these constraints are mandatory for all senders compliant with this FEC Framework. Further restrictions can be imposed by certain CDPs.
アカウントに上記の注意事項を取るO、8.2節には、FECのための制約の小さなセットを指定します。これらの制約は、このFECフレームワークに準拠したすべての送信者のために必須です。さらなる制限は、特定のCDPによって課すことができます。
o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of the original source data being protected (without the possible addition of an Explicit Source FEC Payload ID). This disallows the (static or dynamic) use of excessively strong FEC to combat high packet loss rates, which can otherwise be chosen by naively implemented dynamic FEC-strength selection mechanisms. We acknowledge that there are a few exotic applications, e.g., IP traffic from space-based senders, or senders in certain hardened military devices, that could warrant a higher FEC strength. However, in this specification, we give preference to the overall stability and network friendliness of average applications.
O FECリペアデータの帯域幅は、（明示的なソースFECペイロードIDの可能な添加せずに）保護される元のソースデータの帯域幅を超えてはなりません。これは、そうでなければ単純に実装動的FEC強度選択機構によって選択することができ、高いパケット損失率を、戦うために過度に強いFECの（静的または動的）の使用を禁止します。我々はいくつかのエキゾチックなアプリケーション、高FEC強度を保証することができ宇宙ベースの送信者、または特定の硬化軍用デバイスでの送信者から例えば、IPトラフィックがあることを認めます。しかし、この仕様では、我々は平均的なアプリケーションの全体的な安定性とネットワーク親しみやすさを優先します。
o Whenever the source data rate is adapted due to the operation of congestion control mechanisms, the FEC repair data rate MUST be similarly adapted.
ソースデータレートが輻輳制御機構の動作に適合されるたびに、O、FECリペアデータレートは、同様に適合させなければなりません。
First of all, it must be clear that the application of FEC protection to a stream does not provide any kind of security. On the contrary, the FEC Framework itself could be subject to attacks or could pose new security risks. The goals of this section are to state the problem, discuss the risks, and identify solutions when feasible. It also defines a mandatory-to-implement (but not mandatory-to-use) security scheme.
ストリームにFEC保護のアプリケーションはセキュリティのいずれかの種類を提供していないことをまず第一に、それが明確でなければなりません。それどころか、FECフレームワーク自体が攻撃を受ける可能性があり、または新しいセキュリティリスクをもたらす可能性があります。このセクションの目標は、問題を述べるリスクを議論し、可能な場合の解決策を識別するためです。また、に実装-必須（なく必須に使用）セキュリティ方式を定義します。
A content delivery system is potentially subject to many attacks. Attacks can target the content, the CDP, or the network itself, with completely different consequences, particularly in terms of the number of impacted nodes.
コンテンツ配信システムは、多くの攻撃に対して潜在的に対象となります。攻撃は、特に影響を受けたノードの数の点で、全く異なる結果を有するコンテンツ、CDP、またはネットワーク自体を標的とすることができます。
Attacks can have several goals:
攻撃は、いくつかの目標を持つことができます。
o They can try to give access to confidential content (e.g., in the case of non-free content).
O彼らは（例えば、非フリーのコンテンツの場合）機密コンテンツへのアクセス権を与えることを試みることができます。
o They can try to corrupt the source flows (e.g., to prevent a receiver from using them), which is a form of denial-of-service (DoS) attack.
Oそれらは（例えば、それらを使用してから受信することを防止するために）、サービス拒否（DoS）攻撃の形態である破損したソース・フローを試みることができます。
o They can try to compromise the receiver's behavior (e.g., by making the decoding of an object computationally expensive), which is another form of DoS attack.
O彼らは、DoS攻撃の別の形態である、（計算コストの高いオブジェクトのデコードを行うことによって、例えば）受信機の動作を侵害しようとすることができます。
o They can try to compromise the network's behavior (e.g., by causing congestion within the network), which potentially impacts a large number of nodes.
Oそれらは潜在的に影響を与える、多数のノードを（ネットワーク内の輻輳を引き起こすことによって、例えば）ネットワークの動作を侵害しようとすることができます。
These attacks can be launched either against the source and/or repair flows (e.g., by sending fake FEC source and/or repair packets) or against the FEC parameters that are sent either in-band (e.g., in the Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or out-of-band (e.g., in the FEC Framework Configuration Information).
これらの攻撃は、リペアFECペイロードIDで、いずれか（例えば、偽のFECソースおよび/または修復パケットを送信することにより）、ソースおよび/または修理の流れに対して、またはインバンドなど（いずれか送られ、FECパラメータに対して起動することができますか明示的なソースFECペイロードID）、またはアウトオブバンド（例えば、FECフレームワーク構成情報で）。
Several dimensions to the problem need to be considered. The first one is the way the FEC Framework is used. The FEC Framework can be used end-to-end, i.e., it can be included in the final end-device where the upper application runs, or the FEC Framework can be used in middleboxes, for instance, to globally protect several source flows exchanged between two or more distant sites.
問題のいくつかの寸法を考慮する必要があります。一つ目はFECフレームワークを使用する方法です。 FECフレームワークは、エンドツーエンドを使用することができる、すなわち、それが上位アプリケーションの実行、又はFECフレームワークは、中間装置で使用することができ、最終的なエンドデバイスに含めることができ、例えば、いくつかのソースを保護するグローバルすることが交換流れます。二つ以上の遠隔部位の間。
A second dimension is the threat model. When the FEC Framework operates in the end-device, this device (e.g., a personal computer) might be subject to attacks. Here, the attacker is either the end-user (who might want to access confidential content) or somebody else. In all cases, the attacker has access to the end-device but does not necessarily fully control this end-device (a secure domain can exist). Similarly, when the FEC Framework operates in a middlebox, this middlebox can be subject to attacks or the attacker can gain access to it. The threats can also concern the end-to-end transport (e.g., through the Internet). Here, examples of threats include the transmission of fake FEC source or repair packets; the replay of valid packets; the drop, delay, or misordering of packets; and, of course, traffic eavesdropping.
二次元は脅威モデルです。 FECフレームワークは、エンドデバイスで動作する場合、このデバイスは、（例えば、パーソナルコンピュータ）攻撃を受けるかもしれません。ここでは、攻撃者は、または他の誰か（機密コンテンツにアクセスする場合があります）、エンドユーザーのいずれかです。全ての場合において、攻撃者は、エンドデバイスへのアクセスを有するが、必ずしも完全に（セキュア・ドメインが存在し得る）、このエンドデバイスを制御しません。 FECフレームワークは、ミドルボックスで動作する場合同様に、このミドル攻撃を受けることができ、あるいは攻撃者がそれにアクセスすることができます。脅威は、エンド・ツー・エンドの輸送（例えば、インターネットを介した）を懸念することができます。ここでは、脅威の例は、偽のFECソースまたはリペアパケットの送信が含まれ;有効なパケットのリプレイ。パケットのドロップ、遅延、または誤った順序。そして、もちろん、交通盗聴。
The third dimension consists in the desired security services. Among them, the content integrity and sender authentication services are probably the most important features. We can also mention DoS mitigation, anti-replay protection, or content confidentiality.
三次元は、必要なセキュリティサービスで構成されています。その中でも、コンテンツの完全性と送信者認証サービスは、おそらく最も重要な特徴です。また、DoS攻撃の緩和、抗再生保護、またはコンテンツの機密性を挙げることができます。
Finally, the fourth dimension consists in the security tools available. This is the case of the various Digital Rights Management (DRM) systems, defined outside of the context of the IETF, that can be proprietary solutions. Otherwise, the Secure Real-Time Transport Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload (IPsec/ESP) [RFC4303] are two tools that can turn out to be useful in the context of the FEC Framework. Note that using SRTP requires that the application generate RTP source flows and, when applied below the
最後に、第4の次元は、利用可能なセキュリティツールで構成されています。これは、独自のソリューションをすることができIETFの文脈の外で定義された様々なデジタル著作権管理（DRM）システム、の場合です。それ以外の場合は、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]とIPsec /カプセル化セキュリティペイロード（IPsecの/ ESP）[RFC4303]はFECフレームワークの文脈において有用であることが判明することができる2つのツールです。 SRTPを使用して下に適用された場合、アプリケーションは、RTPソース・フローを生成していることを必要とすることに注意してください
FEC Framework, that both the FEC source and repair packets be regular RTP packets. Therefore, SRTP is not considered to be a universal solution applicable in all use cases.
FECフレームワーク、FECソースと修復の両方のパケットが通常のRTPパケットであること。したがって、SRTPは、すべてのユースケースで適用ユニバーサルソリューションであるとは考えられません。
In the following sections, we further discuss security aspects related to the use of the FEC Framework.
次のセクションでは、我々はさらにFECフレームワークの使用に関連するセキュリティの側面を議論します。
Access control to the source flow being transmitted is typically provided by means of encryption. This encryption can be done by the content provider itself, or within the application (for instance, by using SRTP [RFC3711]), or at the network layer on a per-packet basis when IPsec/ESP is used [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used. Even if we mention these attacks here, they are neither related to nor facilitated by the use of FEC.
ソース流へのアクセス制御は、典型的には、暗号化によって提供される送信されます。 IPsec / ESPは、[RFC4303]を使用する場合、この暗号化は、パケット単位でコンテンツプロバイダ自体によって、またはアプリケーション内（例えば、SRTP [RFC3711]を使用することによって）、またはネットワーク層で行うことができます。機密性が懸念される場合には、これらの解決策の一つが使用することをお勧めします。私たちはここに、これらの攻撃に言及している場合でも、彼らはどちらに関連することも、FECの使用によって促進されます。
Note that when encryption is applied, this encryption MUST be applied either on the source data before the FEC protection or, if done after the FEC protection, on both the FEC source packets and repair packets (and an encryption at least as cryptographically secure as the encryption applied on the FEC source packets MUST be used for the FEC repair packets). Otherwise, if encryption were to be performed only on the FEC source packets after FEC encoding, a non-authorized receiver could be able to recover the source data after decoding the FEC repair packets, provided that a sufficient number of such packets were available.
暗号化が適用されたときにFEC保護した後に行う場合には、この暗号のようにFECソースパケットおよびリペアパケット（および暗号化の両方に、少なくとも同じ暗号化された安全なFEC保護する前に、ソースデータのいずれかを適用したりしなければならないことに注意してくださいFECソースパケットに適用される暗号化は、FECリペアパケットを使用しなければなりません）。そうでない場合、暗号化は、FEC符号化後のFECソースパケットに対してのみ実施された場合、非認可受信機がFECリペアパケットを復号化した後、ソースデータを回復できる可能性があり、そのようなパケットの十分な数が利用可能であったことを条件とします。
The following considerations apply when choosing where to apply encryption (and more generally where to apply security services beyond encryption). Once decryption has taken place, the source data is in plaintext. The full path between the output of the deciphering module and the final destination (e.g., the TV display in the case of a video) MUST be secured, in order to prevent any unauthorized access to the source data.
ここで、（より一般的にどこ暗号を超えてセキュリティサービスを適用する）暗号化を適用することを選択する場合は、次の考慮事項が適用されます。復号化が行われた後は、元のデータが平文です。解読モジュールの出力と最終宛先（例えば、ビデオの場合にはTV表示）との間の完全なパスは、ソースデータへの不正アクセスを防止するために、確保しなければなりません。
When the FEC Framework endpoint is the end-system (i.e., where the upper application runs) and if the threat model includes the possibility that an attacker has access to this end-system, then the end-system architecture is very important. More precisely, in order to prevent an attacker from getting hold of the plaintext, all processing, once deciphering has taken place, MUST occur in a protected environment. If encryption is applied after FEC protection at the sending side (i.e., below the FEC Framework), it means that FEC decoding MUST take place in the protected environment. With certain use cases, this MAY be complicated or even impossible. In such cases, applying encryption before FEC protection is preferred.
FECフレームワークエンドポイントが、エンドシステムである場合（すなわち、上位のアプリケーションが実行されている）と脅威モデルは、攻撃者がこのエンドシステムへのアクセスを有する可能性を含む場合、次いでエンドシステムアーキテクチャは、非常に重要です。解読が行われた後、より正確には、平文のホールドを取得からの攻撃を防ぐために、すべての処理は、保護された環境で行われなければなりません。暗号化は、送信側（すなわち、FECフレームワーク以下）でFEC保護の後に適用されている場合は、FEC復号化が保護された環境で行わなければならないことを意味します。特定のユースケースでは、これは複雑または不可能でさえあるかもしれません。 FEC保護が優先される前に、そのような場合には、暗号化を適用します。
When the FEC Framework endpoint is a middlebox, the recovered source flow, after FEC decoding, SHOULD NOT be sent in plaintext to the final destination(s) if the threat model includes the possibility that an attacker eavesdrops on the traffic. In that case, it is preferable to apply encryption before FEC protection.
FECフレームワークエンドポイントはミドル、回収源流である場合、FEC復号後、脅威モデルは、攻撃者がトラフィックを盗聴する可能性を含む場合、最終的な宛先（複数可）に平文で送信されるべきではありません。その場合には、FEC保護の前に暗号化を適用することが好ましいです。
In some cases, encryption could be applied both before and after the FEC protection. The considerations described above still apply in such cases.
いくつかのケースでは、暗号化は、FEC保護の前と後の両方に適用することができます。上記の考察は、まだそのような場合に適用されます。
Protection against corruptions (e.g., against forged FEC source/ repair packets) is achieved by means of a content integrity verification/source authentication scheme. This service is usually provided at the packet level. In this case, after removing all the forged packets, the source flow might sometimes be recovered. Several techniques can provide this content integrity/source authentication service:
（偽造FECソース/リペアパケットに対して例えば、）破損に対する保護は、コンテンツの完全性検証/ソース認証方式によって達成されます。このサービスは通常、パケットレベルで提供されます。この場合、すべての偽造パケットを削除した後、ソースの流れは時々回復することがあります。いくつかの技術がこのコンテンツの完全性/ソース認証サービスを提供することができます。
o At the application layer, SRTP [RFC3711] provides several solutions to check the integrity and authenticate the source of RTP and RTCP messages, among other services. For instance, when associated with the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383], SRTP is an attractive solution that is robust to losses, provides a true authentication/integrity service, and does not create any prohibitive processing load or transmission overhead. Yet, with TESLA, checking a packet requires a small delay (a second or more) after its reception. Whether or not this extra delay, both in terms of startup delay at the client and end-to-end delay, is appropriate depends on the target use case. In some situations, this might degrade the user experience. In other situations, this will not be an issue. Other building blocks can be used within SRTP to provide content integrity/authentication services.
Oアプリケーション層では、SRTP [RFC3711]は整合性をチェックし、RTPとRTCPメッセージの送信元を認証し、他のサービスの中でするためにいくつかのソリューションを提供しています。時限効率ストリーム損失トレラント認証（テスラ）[RFC4383]に関連付けられている場合、例えば、SRTPは、損失に対してロバストである魅力的な解決策である真の認証/完全性サービスを提供し、任意の法外な処理負荷や送信を作成しませんオーバーヘッド。まだ、TESLAと、パケットをチェックすると、その受信後にわずかな遅延（秒以上）を必要とします。この余分な遅延は、両方のクライアントの起動遅延およびエンドツーエンド遅延の観点から、適切であるかどうかは、ターゲット・ユースケースに依存します。いくつかの状況では、これは、ユーザーエクスペリエンスが低下することがあります。他の状況では、これは問題になりません。他のビルディングブロックは、コンテンツの完全性/認証サービスを提供するために、SRTP内で使用することができます。
o At the network layer, IPsec/ESP [RFC4303] offers (among other services) an integrity verification mechanism that can be used to provide authentication/content integrity services.
ネットワーク層でO、（他のサービスの中）のIPsec / ESP [RFC4303]オファー認証/コンテンツ完全性サービスを提供するために使用することができる完全性検証メカニズム。
It is up to the developer and the person in charge of deployment, who know the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, it is RECOMMENDED that at least one of these techniques be used.
これは、最も適切なソリューションを定義するには、対象のアプリケーション領域のセキュリティ要件と機能を知っている人、開発と展開の担当者に任されています。それにもかかわらず、これらの技術のうちの少なくとも1つを使用することをお勧めします。
Note that when integrity protection is applied, it is RECOMMENDED that it take place on both FEC source and repair packets. The motivation is to keep corrupted packets from being considered during decoding, as such packets would often lead to a decoding failure or result in a corrupted decoded source flow.
完全性保護が適用されたとき、それはFECソースおよびリペアパケットの両方に場所を取ることが推奨されていることに注意してください。動機は、そのようなパケットは、多くの場合、復号失敗につながるまたは破損デコードソース流をもたらすように、復号化の際に考慮されているから破損したパケットを保持することです。
Attacks on these FEC parameters can prevent the decoding of the associated object. For instance, modifying the finite field size of a Reed-Solomon FEC scheme (when applicable) will lead a receiver to consider a different FEC code.
これらのFECパラメータの攻撃が関連付けられたオブジェクトの復号化を防止することができます。例えば、異なるFECコードを検討するために受信機をリードするリードソロモンFEC方式（該当する場合）の有限体サイズを変更します。
Therefore, it is RECOMMENDED that security measures be taken to guarantee the integrity of the FEC Framework Configuration Information. Since the FEC Framework does not define how the FEC Framework Configuration Information is communicated from sender to receiver, we cannot provide further recommendations on how to guarantee its integrity. However, any complete CDP specification MUST give recommendations on how to achieve it. When the FEC Framework Configuration Information is sent out-of-band, e.g., in a session description, it SHOULD be protected, for instance, by digitally signing it.
そのため、セキュリティ対策は、FECフレームワーク構成情報の整合性を保証するために取られることが推奨されます。 FECフレームワークは、FECフレームワークの設定情報が送信者から受信者に伝達する方法を定義していないので、我々はその完全性を保証する方法についてさらに勧告を提供することはできません。しかし、いずれの完全なCDPの仕様では、それを達成する方法についての勧告を与える必要があります。 FECフレームワーク構成情報は、帯域外送信されると、例えば、セッション記述には、例えば、デジタル的に署名することにより、保護されるべきです。
Attacks are also possible against some FEC parameters included in the Explicit Source FEC Payload ID and Repair FEC Payload ID. For instance, modifying the Source Block Number of a FEC source or repair packet will lead a receiver to assign this packet to a wrong block.
攻撃は、明示的なソースFECペイロードIDに含まれるいくつかのFECパラメータに対しても可能であり、FECペイロードIDを修復します。例えば、FECソースまたはリペアパケットのソースブロック番号を変更することは間違ったブロックに、このパケットを割り当てるために受信機をリードします。
Therefore, it is RECOMMENDED that security measures be taken to guarantee the integrity of the Explicit Source FEC Payload ID and Repair FEC Payload ID. To that purpose, one of the packet-level source authentication/content integrity techniques described in Section 9.2.2 can be used.
そのため、セキュリティ対策は、明示的なソースFECペイロードIDの整合性を保証し、FECペイロードIDを修復するために取られることが推奨されます。そのために、セクション9.2.2に記載のパケット・レベル・ソース認証/コンテンツ完全性技術の一つを使用することができます。
When several source flows, with different security requirements, need to be FEC protected jointly, within a single FEC Framework instance, then each flow MAY be processed appropriately, before the protection. For instance, source flows that require access control MAY be encrypted before they are FEC protected.
複数のソース・フローは、異なるセキュリティ要件と、単一のFECフレームワーク・インスタンス内で、共同保護FECする必要がある場合、各流れは保護の前に、適切に処理されてもよいです。彼らはFEC保護されています前に、例えば、アクセス制御を必要とするソース・フローは、暗号化されてもよいです。
There are also situations where the only insecure domain is the one over which the FEC Framework operates. In that case, this situation MAY be addressed at the network layer, using IPsec/ESP (see Section 9.5), even if only a subset of the source flows has strict security requirements.
唯一の安全でないドメインはFECフレームワークが動作する1である状況もあります。その場合、この状況は、ソース・フローのサブセットのみが厳密なセキュリティ要件を有する場合であっても、（セクション9.5を参照）のIPsec / ESPを使用して、ネットワーク層で対処することができます。
Since the use of the FEC Framework should not add any additional threat, it is RECOMMENDED that the FEC Framework aggregate flow be in line with the maximum security requirements of the individual source flows. For instance, if denial-of-service (DoS) protection is required, an integrity protection SHOULD be provided below the FEC Framework, using, for instance, IPsec/ESP.
FECフレームワークの使用は、任意の追加の脅威を追加してはならないので、FECフレームワーク集約フローは、個々のソース・フローの最大のセキュリティ要件に合わせてすることが推奨されます。サービス拒否（DoS）の保護が必要な場合、例えば、完全性保護は、例えば、IPsecの/ ESPを使用して、FECフレームワークの下に提供されるべきです。
Generally speaking, whenever feasible, it is RECOMMENDED that FEC protecting flows with totally different security requirements be avoided. Otherwise, significant processing overhead would be added to protect source flows that do not need it.
いつでも可能な一般的に言えば、FECが全く異なるセキュリティ要件と流れを保護を回避することが推奨されます。そうでなければ、かなりの処理オーバーヘッドがそれを必要としないソース・フローを保護するために追加されます。
The FEC Framework has been defined in such a way to be independent from the application that generates source flows. Some applications might use purely unidirectional flows, while other applications might also use unicast feedback from the receivers. For instance, this is the case when considering RTP/RTCP-based source flows.
FECフレームワークは、ソース・フローを生成するアプリケーションから独立しているように、このような方法で定義されています。他のアプリケーションでも受信機からのユニキャストのフィードバックを使用するかもしれないが、一部のアプリケーションは、純粋に単方向フローを使用する場合があります。例えば、これは、RTP / RTCPベースのソース・フローを考慮した場合です。
This section describes a baseline mode of secure FEC Framework operation based on the application of the IPsec protocol, which is one possible solution to solve or mitigate the security threats introduced by the use of the FEC Framework.
このセクションは、FECフレームワークの使用によって導入セキュリティ上の脅威を解決または軽減する一つの可能な解決策であるIPsecプロトコルのアプリケーションに基づいて、安全なFECフレームワーク操作のベースラインモードを記述する。
Two related documents are of interest. First, Section 5.1 of [RFC5775] defines a baseline secure Asynchronous Layered Coding (ALC) operation for sender-to-group transmissions, assuming the presence of a single sender and a source-specific multicast (SSM) or SSM-like operation. The proposed solution, based on IPsec/ESP, can be used to provide a baseline FEC Framework secure operation, for the downstream source flow.
二つの関連文書は興味深いものです。まず、[RFC5775]のセクション5.1は、単一の送信者の存在およびソース固有マルチキャスト（SSM）またはSSMのような動作を想定し、送信者のグループの送信のためのベースラインの安全な非同期階層符号化（ALC）の動作を規定します。 IPsec / ESPに基づいて提案された解決策は、下流源フローについて、ベースラインFECフレームワークの安全な動作を提供するために使用することができます。
Second, Section 7.1 of [RFC5740] defines a baseline secure NACK-Oriented Reliable Multicast (NORM) operation, for sender-to-group transmissions as well as unicast feedback from receivers. Here, it is also assumed there is a single sender. The proposed solution is also based on IPsec/ESP. However, the difference with respect to [RFC5775] relies on the management of IPsec Security Associations (SAs) and corresponding Security Policy Database (SPD) entries, since NORM requires a second set of SAs and SPD entries to be defined to protect unicast feedback from receivers.
第二に、[RFC5740]のセクション7.1は、ベースライン、送信者とグループの送信のためのNACK指向高信頼マルチキャスト（NORM）演算、ならびに受信機からのユニキャストフィードバックを確保を規定します。ここでは、また、単一の送信者があると想定されます。提案されたソリューションは、IPSec / ESPにも基づいています。 NORMからユニキャストフィードバックを保護するために定義されるSASおよびSPDエントリの第2のセットを必要とするので、[RFC5775]との差は、IPsecセキュリティアソシエーション（SA）を、対応するセキュリティポリシーデータベース（SPD）エントリの管理に依存しています受信機。
Note that the IPsec/ESP requirement profiles outlined in [RFC5775] and [RFC5740] are commonly available on many potential hosts. They can form the basis of a secure mode of operation. Configuration and operation of IPsec typically require privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to allow the needed system IPsec configuration.
[RFC5775]及び[RFC5740]に概説されたIPsec / ESP要件プロファイルは、多くの潜在的なホスト上で一般に利用可能であることに留意されたいです。彼らは、セキュアな動作モードの基礎を形成することができます。設定とIPsecの動作は、一般的に、特権ユーザー認証を必要とします。自動鍵管理の実装は、一般的に必要なシステムのIPsecの設定を可能にするために必要な権限を持つように構成されています。
The question of operating and managing the FEC Framework and the associated FEC scheme(s) is of high practical importance. The goals of this section are to discuss aspects and recommendations related to specific deployments and solutions.
営業およびFECフレームワークを管理し、関連するFECスキーム（S）の質問は高い実用的な重要性です。このセクションの目的は、特定の展開やソリューションに関連する側面および提言を議論することです。
In particular, this section discusses the questions of interoperability across vendors/use cases and whether defining mandatory-to-implement (but not mandatory-to-use) solutions is beneficial.
具体的には、このセクションでは、ベンダ/ユースケース間の相互運用性の問題について説明し、強制的に実装定義（ただし必須のに使用できる）のソリューションをするかどうかは有益です。
Several aspects need to be considered, since they will directly impact the way the FEC Framework and the associated FEC schemes can be operated and managed.
いくつかの態様は、彼らが直接FECフレームワークと関連するFECスキームを操作して管理することができる方法に影響を与えることから、検討する必要があります。
This section lists them as follows:
このセクションでは、次のようにそれらを示しています。
1. A Single Small Generic Component within a Larger (and Often Legacy) Solution: The FEC Framework is one component within a larger solution that includes one or several upper-layer applications (that generate one or several ADU flows) and an underlying protocol stack. A key design principle is that the FEC Framework should be able to work without making any assumption with respect to either the upper-layer application(s) or the underlying protocol stack, even if there are special cases where assumptions are made.
大きい（しばしばレガシー）内1.単一の小さな汎用コンポーネントソリューション：FECフレームワークは、1つまたは（いずれかを生成するか、いくつかのADUが流れる）は、いくつかの上位層アプリケーションを含むより大きな液及び下層のプロトコル・スタック内の一の成分であります。重要な設計原理は、FECフレームワークは仮定がなされる特別なケースがあっても、上位層アプリケーション（S）または基礎となるプロトコルスタックのいずれかに対する任意の仮定を行うことなく動作することができなければならないということです。
2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios: The FEC Framework can be used in use cases that completely differ from one another. Some use cases are one-way (e.g., in broadcast networks), with either a one-to-one, one-to-many, or many-to-many transmission model, and the receiver(s) cannot send any feedback to the sender(s). Other use cases follow a bidirectional one-to-one, one-to-many, or many-to-many scenario, and the receiver(s) can send feedback to the sender(s).
2.一対一のフィードバックシナリオ無し一対多対フィードバック付き一対多対フィードバック付き：FECフレームワークは、完全に互いに異なるユースケースで使用することができます。いくつかのユースケースは、1対1のいずれかで、（例えば、ブロードキャストネットワークにおける）一対多、または多対多の伝送モデル一方向であり、受信機（複数可）へのフィードバックを送信することはできません送信者（複数可）。他のユースケースは、以下の双方向一対一、一対多、または多対多のシナリオでは、送信者（複数可）にフィードバックを送ることができる受信機（複数可）。
3. Non-FEC Framework Capable Receivers: With the one-to-many and many-to-many use cases, the receiver population might have different capabilities with respect to the FEC Framework itself and the supported FEC schemes. Some receivers might not be capable of decoding the repair packets belonging to a particular FEC scheme, while some other receivers might not support the FEC Framework at all.
3.非FECフレームワークが可能なレシーバは：1対多および多対多のユースケースでは、受信機の人口は、FECフレームワーク自体とサポートされているFECスキームに関して異なる能力を持っているかもしれません。いくつかの他の受信機が全くFECフレームワークをサポートしていないかもしれないが、いくつかの受信機は、特定のFECスキームに属する修復パケットをデコードすることができない場合があります。
4. Internet vs. Non-Internet Networks: The FEC Framework can be useful in many use cases that use a transport network that is not the public Internet (e.g., with IPTV or Mobile TV). In such networks, the operational and management considerations can be achieved through an open or proprietary solution, which is specified outside of the IETF.
非インターネットネットワーク対4.インターネット：FECフレームワークは、（例えば、IPTVやモバイルTV付き）公共のインターネットではないトランスポートネットワークを使用する多くのユースケースに役立ちます。そのようなネットワークでは、運用及び管理の考慮事項は、IETFの外側に指定されているオープンまたは独自のソリューションを介して達成することができます。
5. Congestion Control Considerations: See Section 8 for a discussion on whether or not congestion control is needed, and its relationships with the FEC Framework.
必要とされているかどうかの輻輳制御に関する議論については、セクション8を参照してください、とFECフレームワークとの関係：5.輻輳制御に関する注意事項。
6. Within End-Systems vs. within Middleboxes: The FEC Framework can be used within end-systems, very close to the upper-layer application, or within dedicated middleboxes (for instance, when it is desired to protect one or several flows while they cross a lossy channel between two or more remote sites).
エンドシステム内で対のMiddleboxes以内6：ながら、1つのまたはいくつかのフローを保護することが望まれるときにFECフレームワークは、例えば、（上位層アプリケーションに非常に近いエンドシステムは、内部または専用中間装置内で使用することができます彼らは）二つ以上のリモートサイト間の非可逆チャネルを横断します。
7. Protecting a Single Flow vs. Several Flows Globally: The FEC Framework can be used to protect a single flow or several flows globally.
7.世界的に単一のフロー対複数のフローの保護：FECフレームワークは、単一の流れまたはグローバルいくつかのフローを保護するために使用することができます。
Overall, from the discussion in Section 10.1, it is clear that the CDPs and FEC schemes compatible with the FEC Framework differ widely in their capabilities, application, and deployment scenarios such that a common operation and management method or protocol that works well for all of them would be too complex to define. Thus, as a design choice, the FEC Framework does not dictate the use of any particular technology or protocol for transporting FEC data, managing the hosts, signaling the configuration information, or encoding the configuration information. This provides flexibility and is one of the main goals of the FEC Framework. However, this section gives some RECOMMENDED guidelines.
全体として、セクション10.1で説明から、FECフレームワークと互換性のCDPとFECスキームは、それらの機能、アプリケーション、および展開シナリオで大きく異なることは明らかであるように、すべてのに適しています一般的操作および管理方法またはプロトコルそれらを定義するには複雑すぎるだろう。このように、設計上の選択として、FECフレームワークは、FECデータを転送するホストを管理、設定情報を、シグナリング、またはコンフィギュレーション情報を符号化するための任意の特定の技術やプロトコルの使用を規定していません。これは、柔軟性を提供し、FECフレームワークの主な目標の一つです。ただし、このセクションでは、いくつかの推奨ガイドラインを示します。
1. A Single Small Generic Component within a Larger (and Often Legacy) Solution: It is anticipated that the FEC Framework will often be used to protect one or several RTP streams. Therefore, implementations SHOULD make feedback information accessible via RTCP to enable users to take advantage of the tools using (or used by) RTCP to operate and manage the FEC Framework instance along with the associated FEC schemes.
大きな（そして多くの場合、レガシー）ソリューション内の1 Aシングル小型汎用コンポーネント：FECフレームワークは、多くの場合、1つまたは複数のRTPストリームを保護するために使用されることが予想されます。したがって、実装は、関連するFECスキームと共にFECフレームワーク・インスタンスを操作および管理するRTCPを使用して（またはによって使用される）ツールを利用するためにユーザを可能にするために、RTCPを介してフィードバック情報にアクセスできるようにすべきです。
2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios: With use cases that are one-way, the FEC Framework sender does not have any way to gather feedback from receivers. With use cases that are bidirectional, the FEC Framework sender can collect detailed feedback (e.g., in the case of a one-to-one scenario) or at least occasional feedback (e.g., in the case of a multicast, one-to-many scenario). All these applications have naturally different operational and management aspects. They also have different requirements or features, if any, for collecting feedback, processing it, and acting on it. The data structures for carrying the feedback also vary.
フィードバックシナリオなしの一対多対フィードバックと1対多の対フィードバック付き2一対一：片道あるユースケースでは、FECフレームワークの送信者がフィードバックを収集するためにどのような方法を持っていません受信機から。双方向でのユースケースでは、FECフレームワークの送信者は、またはマルチキャストの場合は、少なくとも時折フィードバック（例えば、1対多（1対1のシナリオの場合には、例えば）詳細なフィードバックを収集することができますシナリオ）。すべてのこれらのアプリケーションは当然異なる運用と管理の側面を持っています。彼らはまた、フィードバックを収集し、それを処理し、それに作用するためのさまざまな要件や機能を、もしあれば、持っています。フィードバックを運ぶためのデータ構造も異なります。
Implementers SHOULD make feedback available using either an
in-band or out-of-band asynchronous reporting mechanism. When an
out-of-band solution is preferred, a standardized reporting
mechanism, such as Syslog [RFC5424] or Simple Network Management
Protocol (SNMP) notifications [RFC3411], is RECOMMENDED. When
required, a mapping mechanism between the Syslog and SNMP
reporting mechanisms could be used, as described in [RFC5675] and
[RFC5676].
3. Non-FEC Framework Capable Receivers: Section 5.3 gives recommendations on how to provide backward compatibility in the presence of receivers that cannot support the FEC scheme being used or the FEC Framework itself: basically, the use of Explicit Source FEC Payload ID is banned. Additionally, a non-FEC Framework capable receiver MUST also have a means not to receive the repair packets that it will not be able to decode in the first place or a means to identify and discard them appropriately upon receiving them. This SHOULD be achieved by sending repair packets on a different transport-layer flow. In the case of RTP transport, and if both source and repair packets will be sent on the same transport-layer flow, this SHOULD be achieved by using an RTP framing for FEC repair packets with a different payload type. It is the responsibility of the sender to select the appropriate mechanism when needed.
3.非FECフレームワークが可能なレシーバ：5.3節が使用されているFEC方式やFECフレームワーク自体をサポートすることはできません受信機の存在下での後方互換性を提供する方法に関する推奨事項を示します。基本的には、明示的なソースFECペイロードIDが禁止されているの使用を。また、非FECフレームワーク可能な受信機は、最初の場所又は特定し、それらを受信したときにそれらを適切に廃棄する手段でデコードすることができなくなり、修理パケットを受信しない手段を持たなければなりません。これは、異なるトランスポート層のフローに修復パケットを送信することにより達成されなければなりません。 RTP輸送の場合には、ソースおよびリペアの両方のパケットが同じトランスポート・レイヤ・フロー上で送信される場合、これは、異なるペイロードタイプとFECリペアパケットのRTPフレーミングを使用することによって達成されるべきです。必要なときに適切なメカニズムを選択するために、送信者の責任です。
4. Within End-Systems vs. within Middleboxes: When the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the hosts where the sending applications run and the middlebox that performs FEC encoding be as reliable as possible, i.e., not be prone to packet loss, packet reordering, or varying delays in delivering packets.
エンドシステム対のMiddleboxes以内内4.：FECフレームワークは、中間装置内で使用される場合には、送信アプリケーションを実行するホストとFEC符号化を実行するミドル間のパスは、可能な限り信頼性の高い、すなわち、ではないことが推奨されますパケットロス、パケットの並べ替え、またはパケットを提供する上で様々な遅延が発生しやすいこと。
Similarly, when the FEC Framework is used within middleboxes, it
is RECOMMENDED that the paths be as reliable as possible between
the middleboxes that perform FEC decoding and the end-systems
where the receiving applications operate.
5. Management of Communication Issues before Reaching the Sending FECFRAME Instance: Let us consider situations where the FEC Framework is used within middleboxes. At the sending side, the general reliability recommendation for the path between the sending applications and the middlebox is important, but it may not guarantee that a loss, reordering, or long delivery delay cannot happen, for whatever reason. If such a rare event happens, this event SHOULD NOT compromise the operation of the FECFRAME instances, at either the sending side or the receiving side. This is particularly important with FEC schemes that do not modify the ADU for backward-compatibility purposes (i.e., do not use any Explicit Source FEC Payload ID) and rely on, for instance, the RTP sequence number field to identify FEC source packets within their source block. In this case, packet loss or packet reordering leads to a gap in the RTP sequence number space seen by the FECFRAME instance. Similarly, varying delay in delivering packets over this path can lead to significant timing issues. With FEC schemes that indicate in the Repair FEC Payload ID, for each source block, the base RTP sequence number and number of consecutive RTP packets that belong to this source block, a missing ADU or an ADU delivered out of order could cause the FECFRAME sender to switch to a new source block. However, some FEC schemes and/or receivers may not necessarily handle such varying source block sizes. In this case, one could consider duplicating the last ADU received before the loss, or inserting zeroed ADU(s), depending on the nature of the ADU flow. Implementers SHOULD consider the consequences of such alternative approaches, based on their use cases.
送信FECFRAMEインスタンスに到達する前に、コミュニケーションの問題の5.管理：私たちは、FECフレームワークがミドルボックス内で使用される状況を考えてみましょう。送信側では、送信アプリケーションとミドルの間のパスのための一般的な信頼性の勧告は重要ですが、それは損失、並べ替え、または長い配達遅延が何らかの理由で、発生しないことを保証しない場合があります。そのような稀な事象が発生した場合、このイベントは、送信側または受信側のいずれかで、FECFRAMEインスタンスの操作性を損なうべきではありません。これは彼らの内のFECソースパケットを識別するために、例えば、RTPシーケンス番号フィールドを（すなわち、任意の明示的なソースFECペイロードIDを使用していない）と、頼りに下位互換性のためにADUを変更しないでくださいFECスキームと特に重要ですソースブロック。この場合、パケット損失やパケットの並べ替えはFECFRAMEインスタンスから見たRTPシーケンス番号空間の隙間をもたらします。同様に、このパスを介してパケットを配信の遅延を変化させることに有意なタイミングの問題につながる可能性があります。各ソースブロック、このソースブロックに属している連続したRTPパケットの基本RTPシーケンス番号と番号のため、不足しているADUまたはADUはFECFRAME送信者を引き起こす可能性が順不同で配信、リペアFECペイロードIDに示すFECスキームと新しいソースブロックに切り替えます。しかし、いくつかのFECスキーム及び/又は受信機は、必ずしもそのような変ソースブロックサイズを処理しなくてもよいです。この場合、一方が最後ADUが消失する前に受信した複製、またはゼロ化ADU（複数可）を挿入し、ADUの流れの性質に応じて検討することができました。実装者は、その使用例をもとに、そのような代替的アプローチの影響を考慮すべきです。
6. Protecting a Single Flow vs. Several Flows Globally: In the general case, the various ADU flows that are globally protected can have different features, and in particular different real-time requirements (in the case of real-time flows). The process of globally protecting these flows SHOULD take into account the requirements of each individual flow. In particular, it would be counterproductive to add repair traffic to a real-time flow for which the FEC decoding delay at a receiver makes decoded ADUs for this flow useless because they do not satisfy the associated real-time constraints. From a practical point of view, this means that the source block creation process at the sending FEC Framework instance SHOULD consider the most stringent real-time requirements of the ADU flows being globally protected.
6.世界的に単一のフロー対複数のフローの保護：一般的なケースでは、世界的に保護され、さまざまなADU・フローは、異なる特徴を持っており、特に、異なるリアルタイム要件（リアルタイム・フローの場合）にすることができます。世界的にこれらのフローを保護するプロセスを考慮に入れ、個々のフローの要件を取る必要があります。特に、受信機におけるFEC復号遅延は、彼らが関連したリアルタイム制約を満たしていないため、役に立たない。この流れのためのADUをデコードしますそのため、リアルタイムのフローに修理トラフィックを追加することが逆効果になります。実用的な観点からは、これは送信FECフレームワークインスタンスのソースブロックの作成プロセスは、ADUの最も厳しいリアルタイム要件を考慮すべきであることを意味し、グローバルに保護されて流れています。
7. ADU Flow Bundle Definition and Flow Delivery: By design, a repair flow might enable a receiver to recover the ADU flow(s) that it protects even if none of the associated FEC source packets are received. Therefore, when defining the bundle of ADU flows that are globally protected and when defining which receiver receives which flow, the sender SHOULD make sure that the ADU flow(s) and repair flow(s) of that bundle will only be received by receivers that are authorized to receive all the ADU flows of that bundle. See Section 9.4 for additional recommendations for situations where strict access control for ADU flows is needed.
7. ADUフローバンドルの定義とフロー配信：デザインすることで、修理の流れは、それが関連するFECソースパケットのいずれも受信されない場合でも、保護することをADUの流れ（複数可）を回復するために受信機を有効かもしれません。従ってADUフローのバンドルを定義する場合、グローバル保護されていると流れる受信する受信機定義するとき、送信者は、ADUの流れ（S）とその束のリペアフロー（単数または複数）だけで受信機によって受信されることを確認してくださいそのバンドルのすべてのADUのフローを受け取ることを許可されています。 ADUのための厳格なアクセス制御が必要とされているフローの状況のための追加の推奨事項については、セクション9.4を参照してください。
Additionally, when multiple ADU flows are globally protected, a
receiver that wants to benefit from FECFRAME loss protection
SHOULD receive all the ADU flows of the bundle. Otherwise, the
missing FEC source packets would be considered lost, which might
significantly reduce the efficiency of the FEC scheme.
FEC schemes for use with this framework are identified in protocols using FEC Encoding IDs. Values of FEC Encoding IDs are subject to IANA registration. For this purpose, this document creates a new registry called the "FEC Framework (FECFRAME) FEC Encoding IDs".
このフレームワークで使用するためのFECスキームは、FEC符号化IDを使用してプロトコルで識別されています。 FEC符号化IDの値は、IANA登録の対象となっています。このためには、この文書では、「FECフレームワーク（FECFRAME）FEC符号化のID」と呼ばれる新しいレジストリを作成します。
The values that can be assigned within the "FEC Framework (FECFRAME) FEC Encoding IDs" registry are numeric indexes in the range (0, 255). Values of 0 and 255 are reserved. Assignment requests are granted on an IETF Review basis as defined in [RFC5226]. Section 5.6 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
「FECフレームワーク（FECFRAME）FEC符号化IDが」レジストリ内で割り当て可能な値は、範囲（0、255）内の数値のインデックスです。 0と255の値が予約されています。 [RFC5226]で定義された割り当て要求はIETFレビューごとに付与されます。 5.6節では、新たなFECエンコーディングIDを定義する文書が満たさなければならない明示的な要件を定義します。
This document is based in part on [FEC-SF], and so thanks are due to the additional authors of that document: Mike Luby, Magnus Westerlund, and Stephan Wenger. That document was in turn based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and thus, thanks are also due to the participants in 3GPP SA Working Group 4. Further thanks are due to the members of the FECFRAME Working Group for their comments and reviews.
この文書は、[FEC-SF]に部分的に基づいて、そしてそのおかげで、その文書の追加の作者によるものであるさ：マイク・ルビー、マグヌスウェスター、そしてステファンウェンガー。その文書には、[MBMSTS]に3GPPで定義されたFECストリーミングプロトコルに基づいて順番にし、ひいては、感謝が原因4.さらにおかげで彼らのためにFECFRAMEワーキンググループのメンバーによるものである3GPP SAワーキンググループの参加者にもありますコメントやレビュー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、M.、およびL. Vicisano、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 5052、2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "Syslogのプロトコル"、RFC 5424、2009年3月。
[FEC-SF] Watson, M., Luby, M., Westerlund, M., and S. Wenger, "Forward Error Correction (FEC) Streaming Framework", Work in Progress, July 2005.
[FEC-SF]ワトソン、M.、ルビー、M.、ウェスター、M.、およびS.ウェンガー、 "前方誤り訂正（FEC）ストリーミングフレームワーク"、進歩、2005年7月での作業。
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, March 2009, <http://ftp.3gpp.org/specs/html-info/26346.htm>.
[MBMSTS] 3GPP、 "マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルとコーデック"、3GPP TS 26.346、2009年3月、<http://ftp.3gpp.org/specs/html-info/26346.htm>。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383] Baugher、M.とE.カララ、RFC 4383、2006年2月「時限効率的なストリーム損失トレラントセキュアリアルタイム転送プロトコル（SRTP）での認証（TESLA）の使用」。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]レイ、J.、レオン、D.、宮崎、A.、Varsa、V.、およびR. Hakenberg、 "RTP再送信ペイロードフォーマット"、RFC 4588、2006年7月。
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009.
[RFC5675]マリノフ、V.およびJ. Schoenwaelder、RFC 5675 "SYSLOGメッセージへのマッピング簡易ネットワーク管理プロトコル（SNMP）通知"、2009年10月。
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5676] Schoenwaelder、J.、Clemm、A.、およびA. Karmakar、RFC 5676、2009年10月 "簡易ネットワーク管理プロトコル（SNMP）通知へのマッピングSYSLOGメッセージのための管理オブジェクトの定義"。
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, February 2010.
[RFC5725] Begen、A.、スー、D.、およびM. Lague、 "RTP制御プロトコルのための修復後の損失RLEレポートブロックタイプ（RTCP）拡張レポート（XRS）"、RFC 5725、2010年2月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "NACK指向高信頼マルチキャスト（NORM）トランスポートプロトコル"、RFC 5740、2009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]ルビー、M.、ワトソン、M.、およびL. Vicisano、RFC 5775 "非同期階層は（ALC）プロトコルインスタンス化コーディング" 2010年4月。
[RFC6364] Begen, A., "Session Description Protocol Elements for FEC Framework", RFC 6364, October 2011.
[RFC6364] Begen、A.、 "FECフレームワークのためのセッション記述プロトコル要素"、RFC 6364、2011年10月。
Authors' Addresses
著者のアドレス
Mark Watson Netflix, Inc. 100 Winchester Circle Los Gatos, CA 95032 USA
マーク・ワトソンはNetflix、Inc.の100ウィンチェスターサークルロスガトス、CA 95032 USA
EMail: watsonm@netflix.com
メールアドレス：watsonm@netflix.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
M5J 2T3カナダONアリBegenのCisco 181ベイストリートトロント、
EMail: abegen@cisco.com
メールアドレス：abegen@cisco.com
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
INRIAヴィンセントロカ655、AV。ドゥヨーロッパInovallée。フランス38334 CEDEX MontbonnotセントIsmier
EMail: vincent.roca@inria.fr URI: http://planete.inrialpes.fr/people/roca/
電子メール：vincent.roca@inria.fr URI：http://planete.inrialpes.fr/people/roca/