[要約] RFC 6363は、転送エラー訂正（FEC）フレームワークに関する標準化ドキュメントであり、FECの目的は、ネットワーク上でのデータ転送中のエラーを検出および修正することです。
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
フォワードエラー補正（FEC）フレームワーク
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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保護データを運ぶフロー、およびの不透明なコンテナを指定します。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ヘッダーとともに、1つ以上の修理シンボルを含むトランスポートプロトコルに（それぞれ受信）に提出されたペイロード。
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ソースパケット：送信者（それぞれ、レシーバーで）では、ADUを含む輸送プロトコルとオプションの明示的なソースFECペイロードIDに提出されたペイロード（それぞれ受信）。
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保護が適用されるパケットフロー。ソースフローはAdusで構成されています。
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およびDatagram混雑制御プロトコル（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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が修復フローに使用される場合、RTPを使用して単一のUDPフローに合わせてソースと修復データを多重化することができ、その結果、受信機では反射する必要があります。この多重化を行うには、さまざまな方法があります（たとえば、[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スキームにADUSを渡します。FECスキームは、関連する修理FECペイロードIDと、場合によってはFECスキームに応じてSource 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フローの仕様、およびこれらのソースと修復フローの間の関係が含まれます。（つまり、どのソースフローが修復フローによって保護されているか）。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ヘッダーはADUに含まれています。
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の使用とは独立しているためです。2つのRTPインスタンスの外観は、多くのFECコードで、修理ペイロードにはソースパケットのRTPヘッダー全体で計算された修理データが含まれていると考えると、より自然です。したがって、RTPを搭載した修理パケットは、ソースRTPヘッダーを保護するバイトを含む修理データ（およびソースRTPペイロードの修理データ）を含む修理データが続く独自の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をサポートされている輸送プロトコルに掲載することを除いて、一緒に保護できるADUに制限を課しません（セクション7を参照）。データは、共同で保護されている複数のソースフローからのものです。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.
o 1つ以上のFEC修理パケットペイロード。
o FEC Payload IDs for each of the repair packet payloads (encoded according to a FEC-Scheme-Specific format).
o 各修理パケットペイロードのFECペイロードID（FECスキーム固有の形式に従ってエンコード）。
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つの操作を実行します。まず、Source FECペイロードIDを提供する場合は、それぞれのADUに追加し、「FECソースパケット」として知られる結果のパケットを受信機に送信します。第二に、提供されたFEC修理パケットペイロードと対応する修理FECペイロードIDを適切に配置して、FEC修理パケットを構築し、レシーバーに送信します。
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は、存在する場合、Source FECペイロードIDを削除するだけで受信したFECソースパケットから直接FECフレームワークによって回収されます。また、受信者は、受信したADUの内容に加えて、FECペイロードIDをFECスキームに渡し、デコードの可能性を渡します。
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:
送信者がセッション用に元のデータパケットを構築または受信したと想定されています。これらは、あらゆる種類のデータを運ぶ可能性があります。UDP修復フローの場合については図2に示す次の操作と、RTP修復フローの場合の図3に、準拠したソースと修復フローを生成する可能性のある方法を説明します。
1. ADUs are provided by the application.
1. ADUはアプリケーションによって提供されます。
2. A source block is constructed as specified in Section 5.2.
2. セクション5.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エンコードを実行し、ソースブロックから修理パケットペイロードを生成し、各修理ペイロードの修理FECペイロードIDフィールドを生成します。
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.3に従ってFECソースパケットを構築し、セクション5.4に従って修理パケットを構築します。
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の場合、UDPソースと宛先アドレスとIPの宛先アドレスとポートがソースパケットを運ぶデータグラムは、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:
以下は、FECソースまたは修理パケットを受け取った場合、それぞれUDPおよびRTP修復フローの場合について、図4および5に示す可能性のある受信機アルゴリズムについて説明します。
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
RTPが修理パケットに使用され、ソースと修理パケットが同じUDPフローに多重化されるという特別なケースでは、RTP Demultiplexingがソースを否定するために必要です。
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).
修理フロー。ただし、RTP処理は、この段階の修理パケットにのみ適用されます。ソースパケットは、UDPペイロード（つまり、RTPヘッダーを含む）として引き続き処理されます。
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を使用して派生した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スキームは、ADUSをFECフレームワークに戻し、受信およびデコードされたADUを含むソースブロックの形式で、欠落してデコードできなかったADUの適応症を示します。
6. The FEC Framework passes the received and recovered ADUs to the application.
6. FECフレームワークは、受信および回復したADUSをアプリケーションに渡します。
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.
1. Adusからのソースブロックの構築。FECコードがこのソースブロックに適用され、修理ペイロードが生成されます。
2. A format for packets containing source data.
2. ソースデータを含むパケットの形式。
3. A format for packets containing repair data.
3. 修理データを含むパケットの形式。
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フレームワーク構成情報に準拠しています。このフレームワークを使用する完全なプロトコル仕様は、送信者と受信機の間でこの情報を決定および通信する手段を指定する必要があります。
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.
o ADUが関連付けられているソースフローの説明。
o The ADU itself.
o ADU自体。
o The length of the ADU.
o ADUの長さ。
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.
IPパケットフラグメンテーションの回避が目標であるアプリケーションでは、FECフレームワークを使用して配信されるADUのサイズを決定する際に、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）内にあるプロトコルは、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スキームとソースブロックの構築とは無関係です。ただし、このシーケンス番号を使用すると、ソースブロック構造に制約があります。特定のソースブロック内のソースパケットには、連続したシーケンス番号が必要です（連続して、2オクテット（65535）から0で表すことができる最大値からラップアラウンドが含まれています）。シーケンス番号のすべての値が使用されるまで、シーケンス番号を再利用しないでください。
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修理パケットのパケット形式を図7に示します。トランスポートペイロードは、FECエンコードプロセスで生成された修理データとそれに続く修理データが続きます。
+------------------------------------+
| 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.
修理パケットにRTPの使用を指定するFECスキームの場合、修理パケットのパケット形式には、図8に示すように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フローに適用するために必要な情報です。ここで指定されたフレームワークを使用する完全な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フレームワークの単一インスタンスは、修理パケットで構成される1つ以上のパケットフローを使用して、指定されたソースフローのセットのパケットをFEC保護します。FECフレームワークの構成情報には、FECフレームワークの各インスタンスに含まれます。
1. Identification of the repair flows.
1. 修理フローの識別。
2. For each source flow protected by the repair flow(s):
2. 修復フローによって保護されている各ソースフローについて：
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つ増加することを割り当てることができます。ただし、ランダムな（ただしユニークな）割り当ても可能です。ソースパケットはパケットヘッダーのおかげでフローに直接関連付けられるため、ソースフロー識別子をソースパケットに携帯する必要はありません。
3. The FEC Encoding ID, identifying the FEC scheme.
3. FECエンコードID、FECスキームを識別します。
4. The length of the Explicit Source FEC Payload ID (in octets).
4. 明示的なソースFECペイロードID（オクテット）の長さ。
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-Scheme固有の情報（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フレームワークの単一インスタンスの修理パケットを提供します。他のパケットをこのフロー内で送信してはなりません。つまり、FEC修復フロー内のすべてのパケットは、セクション5.4で定義されている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の残りの部分からの送信者のみが必要とするFSSIを分離する動機（送信者側FEC-Scheme固有の情報（SS-FSSI）コンテナで運ばれる）は、受信者またはサードパーティのエンティティを提供することです。送信者でのFEC操作を制御する手段。送信者のみが必要とするfssi以外の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エンコードID値は、FECスキームを一意に識別します。この値は、セクション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-Scheme固有の情報要素のルールをエンコードする名前、タイプ、セマンティクス、およびテキスト値。
4. A full specification of the FEC code.
4. 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).
この仕様では、有効なFEC-Scheme固有の情報値、有効なFECペイロードID値、および有効なパケットペイロードサイズ（パケットペイロードは、エンコードシンボルを運ぶ専用のパケット内のスペースを指します）を正確に定義する必要があります。
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-Scheme固有の情報の有効な値、有効な修理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-Scheme固有の情報の有効な値、有効な修理FECペイロードを与えられたエンコードアルゴリズムの正確な仕様を提供することです。ID値、および入力としての有効なパケットペイロードサイズは、出力としてエンコードシンボルの正確な値を生成します。
5. A description of practical encoding and decoding algorithms.
5. 実用的なエンコードおよびデコードアルゴリズムの説明。
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. Formats and Codes
2. フォーマットとコード
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.1. ソースFECペイロードID（S）<明示的なソースFECペイロードIDのタイプと形式を定義するか、ソースFECペイロードID情報がソースパケットから派生する方法を定義します>
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-Scheme固有の情報要素の名前、タイプ、およびテキスト値エンコード形式>
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スキームに固有の手順、特にFECペイロードIDおよび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スキームは、他のすべてのFECスキームとは独立して指定する必要があります。たとえば、個別の仕様またはより大きな仕様の完全に独立したセクション（もちろん、1つのFECスキームの仕様には、参照ごとに別の部分を含めることができます）。特定のFECスキームの修理データに対してRTPペイロード形式が定義されている場合、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のパフォーマンスを報告するためにフィードバックメカニズムを強化する必要がある場合があります。
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）プロジェクト、第3世代パートナーシッププロジェクト（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の使用が混雑によって誘発されるパケット損失と戦うために正当化されるアプリケーションがあります - 特に軽く負荷のあるネットワークでは、混雑は瞬時のトラフィック負荷の比較的まれなランダムピークの結果であり、それによって意図的にうっ血管理原則に違反します。。このようなアプリケーションの可能な例の1つは、緊急信号として生成されたトラフィックのブルートフォース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 3番目のアプローチは、少なくとも、特定の環境で特定のアプリケーションでこのフレームワークを使用することで、アプリケーションだけが引き起こさない混雑の問題を引き起こさないことを要求することです。つまり、このフレームワークを使用することは、事態を悪化させてはなりません。
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強度選択メカニズムによって選択できます。いくつかのエキゾチックなアプリケーション、たとえば、宇宙ベースの送信者からのIPトラフィック、または特定の強化された軍事装置の送信者が、より高いFEC強度を保証する可能性があることを認めます。ただし、この仕様では、平均的なアプリケーションの全体的な安定性とネットワークの親しみやすさを優先します。
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 彼らは、Receiverの動作を妥協しようとすることができます（たとえば、オブジェクトのデコードを計算高価にすることにより）、これは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ソースおよび/または修理パケットを送信することにより）または帯域内のいずれかのFECパラメーター（例：修理FECペイロードIDまたは明示的なソース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フレームワークはエンドツーエンドを使用できます。つまり、上部アプリケーションが実行される最終エンドデバイスに含めることができます。たとえば、Middlebox、などのFECフレームワークを使用して、交換されたいくつかのソースフローをグローバルに保護できます。2つ以上の遠方のサイトの間。
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.
2番目の次元は脅威モデルです。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.
3番目の次元は、目的のセキュリティサービスで構成されています。その中で、コンテンツの整合性と送信者認証サービスがおそらく最も重要な機能です。また、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.
送信されるソースフローへのアクセス制御は、通常、暗号化によって提供されます。この暗号化は、コンテンツプロバイダー自体、またはアプリケーション内（たとえば、SRTP [RFC3711]を使用して）内で、またはIPSEC/ESP [RFC4303]を使用する場合のパケットごとにネットワークレイヤーで実行できます。機密性が懸念される場合、これらのソリューションの1つを使用することをお勧めします。ここでこれらの攻撃に言及したとしても、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.
暗号化を適用する場所（より一般的には暗号化を超えてセキュリティサービスを適用する場所）を選択するときに、以下の考慮事項が適用されます。復号化が行われると、ソースデータはプレーンテキストになります。解読モジュールの出力と最終目的地（たとえば、ビデオの場合のテレビディスプレイ）の間の完全なパスは、ソースデータへの不正アクセスを防ぐために保護する必要があります。
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
FECフレームワークのエンドポイントが最終システム（つまり、上部アプリケーションが実行される場所）である場合、脅威モデルに攻撃者がこの最終システムにアクセスできる可能性が含まれている場合、最終システムアーキテクチャは非常に重要です。より正確には、攻撃者がプレーンテキストを手に入れるのを防ぐために、すべての処理が解読が行われると、保護された環境で発生する必要があります。FEC保護後に暗号化が適用される場合
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保護の前に暗号化を適用することが推奨されます。
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メッセージのソースを認証するためのいくつかのソリューションを提供します。たとえば、タイミングの効率的なストリーム損失耐性認証（TESLA）[RFC4383]に関連付けられている場合、SRTPは損失に対して堅牢で、真の認証/整合性サービスを提供し、処理負荷または伝送が禁止されていない魅力的なソリューションです。オーバーヘッド。しかし、テスラでは、パケットをチェックするには、受信後にわずかな遅延（2秒以上）が必要です。クライアントでの起動遅延とエンドツーエンドの遅延の両方の観点から、この余分な遅延が適切であるかどうかは、ターゲットユースケースに依存します。状況によっては、これによりユーザーエクスペリエンスが低下する場合があります。他の状況では、これは問題ではありません。他のビルディングブロックを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パラメーターに対する攻撃は、関連するオブジェクトのデコードを防ぐことができます。たとえば、Reed-Solomon 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ペイロードIDに含まれるいくつかのFECパラメーターに対しても可能です。たとえば、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で説明するパケットレベルのソース認証/コンテンツの整合性手法の1つを使用できます。
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フレームワークが動作する状況である状況もあります。その場合、この状況は、ソースフローのサブセットのみが厳密なセキュリティ要件を持っている場合でも、IPSEC/ESPを使用してネットワークレイヤーで対処できます（セクション9.5を参照）。
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.
このセクションでは、IPSECプロトコルの適用に基づいたセキュアFECフレームワーク操作のベースラインモードについて説明します。これは、FECフレームワークの使用によって導入されたセキュリティの脅威を解決または軽減するための1つのソリューションです。
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.
2つの関連ドキュメントが興味深いものです。まず、[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にも基づいています。ただし、[RFC5775]に関する違いは、IPSECセキュリティ協会（SAS）および対応するセキュリティポリシーデータベース（SPD）エントリの管理に依存しています。これは、NORMにはSASおよびSPDエントリの2番目のセットを定義する必要があるため、ユニカストフィードバックを保護するために定義する必要があります。受信機。
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スキームの操作と管理の問題は、実用的に重要です。このセクションの目標は、特定の展開とソリューションに関連する側面と推奨事項を議論することです。
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つまたは複数の上層層アプリケーション（1つまたは複数のADUフローを生成する）と基礎となるプロトコルスタックを含むより大きなソリューション内の1つのコンポーネントです。重要な設計の原則は、Asperide frec Frameworkが、仮定が行われている特別なケースがある場合でも、上層層アプリケーションまたは基礎となるプロトコルスタックのいずれかに関して仮定することなく動作できるはずです。
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. フィードバックを1対1で1対1でフィードバックを使用して、フィードバックを使用せずに1対多で、フィードバックシナリオを使用しないでください。FECフレームワークは、互いに完全に異なるユースケースで使用できます。一部のユースケースは、一方向（ブロードキャストネットワークなど）であり、1対1、1対多、または多くの伝送モデルを備えており、受信者はフィードバックを送信できません。送信者。他のユースケースは、双方向の1対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.
5. 混雑制御の考慮事項：輻輳制御が必要かどうか、およびFECフレームワークとの関係についての議論については、セクション8を参照してください。
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).
6. エンドシステム内vs.ミドルボックス内：FECフレームワークは、エンドシステム内で、上層層アプリケーションに非常に近い、または専用のミドルボックス内で使用できます（たとえば、交差中に1つまたは複数のフローを保護することが望ましい場合は、2つ以上のリモートサイト間の損失のあるチャネル）。
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フレームワークと互換性のあるCDPSおよびFECスキームが、すべてのすべての場合に適した共通の操作と管理方法またはプロトコルが適切に機能するように、その機能、アプリケーション、および展開シナリオが大きく異なることは明らかです。それらは複雑すぎて定義できません。したがって、設計の選択として、FECフレームワークは、FECデータの輸送、ホストの管理、構成情報のシグナル、または構成情報のエンコードのための特定のテクノロジーまたはプロトコルの使用を決定しません。これは柔軟性を提供し、FECフレームワークの主な目標の1つです。ただし、このセクションでは、推奨されるガイドラインをいくつか示しています。
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. より大きな（そしてしばしばレガシー）ソリューション内の単一の小さな汎用コンポーネント：FECフレームワークは、1つまたは複数のRTPストリームを保護するためにしばしば使用されることが予想されます。したがって、実装は、RTCPを介してフィードバック情報をアクセスできるようにする必要があります。ユーザーは、RTCPを使用して（または使用する）ツールを利用して、関連するFECスキームとともにFECフレームワークインスタンスを操作および管理できるようにする必要があります。
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.
2. フィードバックを1対1で1対1でフィードバックとフィードバックなしの1対多数のシナリオ：一方向のユースケースでは、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].
実装者は、インバンドまたはバンド外の非同期報告メカニズムのいずれかを使用してフィードバックを利用できるようにする必要があります。帯域外ソリューションが優先される場合、Syslog [RFC5424]や単純なネットワーク管理プロトコル（SNMP）通知[RFC3411]などの標準化されたレポートメカニズムが推奨されます。必要に応じて、[RFC5675]および[RFC5676]に記載されているように、SYSLOGとSNMP報告メカニズムの間のマッピングメカニズムを使用できます。
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.
4. エンドシステム内vs.ミドルボックス内：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.
同様に、FECフレームワークがミドルボックス内で使用される場合、FECデコードを実行するミドルボックスと受信アプリケーションが動作する最終システムの間で、パスを可能な限り信頼できるパスにすることをお勧めします。
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.
5. 通信問題の管理FecFrameインスタンスの送信に到達する前：FECフレームワークがミドルボックス内で使用される状況を考えてみましょう。送信側では、送信アプリケーションとミドルボックスの間のパスに対する一般的な信頼性の推奨事項が重要ですが、何らかの理由で損失、並べ替え、または長い配送遅延が発生しないことを保証するものではありません。このようなまれなイベントが発生した場合、このイベントは、送信側または受信側のいずれかで、FecFrameインスタンスの動作を妥協するべきではありません。これは、後方互換性の目的でADUを変更しないFECスキームで特に重要です（つまり、明示的なソースFECペイロードIDを使用しない）、たとえばRTPシーケンス番号フィールドに依存して、FECソースパケットを識別します。ソースブロック。この場合、パケットの損失またはパケットの並べ替えは、FecFrameインスタンスで見られるRTPシーケンス番号スペースのギャップにつながります。同様に、このパス上のパケットの配信の遅延が変化すると、重大なタイミングの問題につながる可能性があります。修理FECペイロードIDに示すFECスキームを使用すると、各ソースブロックについて、このソースブロックに属するベースRTPシーケンス数と連続したRTPパケットの数、欠落しているADUまたはADUが順番に配信される可能性があります。新しいソースブロックに切り替えます。ただし、一部のFECスキームおよび/または受信機は、必ずしもさまざまなソースブロックサイズを処理しない場合があります。この場合、ADUフローの性質に応じて、損失前に受け取った最後のADUの複製、またはゼロドADU（S）を複製することを検討できます。実装者は、ユースケースに基づいて、このような代替アプローチの結果を考慮する必要があります。
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
6. 単一のフローといくつかのフローをグローバルに保護します。一般的な場合、グローバルに保護されているさまざまなADUフローには、異なる機能、特にリアルタイムの要件が異なる場合があります（リアルタイムフローの場合）。これらのフローをグローバルに保護するプロセスは、個々のフローの要件を考慮に入れる必要があります。特に、修理トラフィックをリアルタイムフローに追加することは逆効果です
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.
受信機での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フローと修復フローが受信機によってのみ受信されることを確認する必要があります。そのバンドルのすべての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.
さらに、複数のADUフローがグローバルに保護されている場合、FecFrameの損失保護から利益を得たいレシーバーは、バンドルのすべてのADUフローを受け取る必要があります。それ以外の場合、欠落しているFECソースパケットは失われたと見なされ、FECスキームの効率を大幅に低下させる可能性があります。
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]に一部基づいているため、そのドキュメントの追加著者であるMike Luby、Magnus Westerlund、およびStephan Wengerに感謝します。そのドキュメントは、[MBMSTS]の3GPPによって定義されたFECストリーミングプロトコルに基づいて順番に基づいていたため、3GPP SAワーキンググループ4の参加者にも感謝します。コメントとレビュー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Harrington、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] Watson、M.、Luby、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.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslog Protocol」、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] Watson、M.、Luby、M.、Westerlund、M。、およびS. Wenger、「Forward Error Correction（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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（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.、Frederick、R。、およびV. Jacobson、「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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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. Carrara、「安全なリアルタイム輸送プロトコル（SRTP）でのタイミングの効率的なストリーム損失耐性認証（TESLA）の使用」、RFC 4383、2006年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rey、J.、Leon、D.、Miyazaki、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] Marinov、V。およびJ. Schoenwaelder、「Syslogメッセージへの単純なネットワーク管理プロトコル（SNMP）通知のマッピング」、RFC 5675、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、「Syslogメッセージを単純なネットワーク管理プロトコル（SNMP）通知にマッピングするための管理オブジェクトの定義」、RFC 5676、2009年10月。
[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.、Hsu、D。、およびM. Lague、「RTPコントロールプロトコル（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] Adamson、B.、Bormann、C.、Handley、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] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 5775、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
Mark Watson Netflix、Inc。100 Winchester Circle Los Gatos、CA 95032 USA
EMail: watsonm@netflix.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Street Toronto、M5J 2T3カナダ
EMail: abegen@cisco.com
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca Inria 655、av。de l'uepore inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/