[要約] RFC 8680は、スライディングウィンドウコードに対する転送エラー訂正（FEC）フレームワークの拡張に関するものです。このRFCの目的は、スライディングウィンドウコードの性能向上と、FECフレームワークの拡張による柔軟性の向上です。
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 8680 INRIA
Updates: 6363 A. Begen
Category: Standards Track Networked Media
ISSN: 2070-1721 January 2020
Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
スライディングウィンドウコードの前方誤り訂正（FEC）フレームワーク拡張
Abstract
概要
RFC 6363 describes a framework for using Forward Error Correction (FEC) codes 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. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.
RFC 6363は、Forward Error Correction（FEC）コードを使用してパケット損失から保護するためのフレームワークについて説明しています。このフレームワークは、信頼性の低いトランスポートを介した任意のパケットフローへのFECの適用をサポートし、主にリアルタイムまたはストリーミングメディアを対象としています。ただし、RFC 6363によるFECFRAMEはFECコードのブロックに制限されています。このドキュメントでは、ブロックFECコードに加えて、スライディングエンコーディングウィンドウに基づくFECコードを下位互換性のある方法でサポートするようにRFC 6363を更新します。マルチキャスト/ブロードキャストのリアルタイムコンテンツ配信中に、スライディングウィンドウコードを使用することで、過酷な環境での堅牢性が大幅に向上し、修復トラフィックが少なくなり、FEC関連の追加遅延が少なくなります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8680.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8680で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Definitions and Abbreviations
2.2. Requirements Language
3. Summary of Architecture Overview
4. Procedural Overview
4.1. General
4.2. Sender Operation with Sliding Window FEC Codes
4.3. Receiver Operation with Sliding Window FEC Codes
5. Protocol Specification
5.1. General
5.2. FEC Framework Configuration Information
5.3. FEC Scheme Requirements
6. Feedback
7. Transport Protocols
8. Congestion Control
9. Security Considerations
10. Operations and Management Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. About Sliding Encoding Window Management
(Informational)
Acknowledgments
Authors' Addresses
Many applications need 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. In particular, packets may be lost, which is strictly the focus of this document: we assume that transmitted packets are either lost (e.g., because of a congested router, a poor signal-to-noise ratio in a wireless network, or because the number of bit errors exceeds the correction capabilities of the physical-layer error-correcting code) or were received by the transport protocol without any corruption (i.e., the bit errors, if any, have been fixed by the physical-layer error-correcting code and therefore are hidden to the upper layers).
多くのアプリケーションでは、パケット化されたデータの連続ストリームを、保証されたパケット配信を提供しないネットワークを介して、ソース（送信者）から1つ以上の宛先（受信者）に転送する必要があります。特に、パケットが失われる可能性があります。これは、このドキュメントの焦点です。送信されたパケットが失われたと想定します（たとえば、ルーターの輻輳、ワイヤレスネットワークの信号対雑音比の低下、またはビットエラーの数が物理層のエラー修正コードの修正能力を超えるか、トランスポートプロトコルによって破損なしに受信された（ビットエラーがある場合は、物理層のエラー修正コードによって修正された）したがって、上位層には表示されません）。
For these use cases, Forward Error Correction (FEC) applied within the transport or application layer is an efficient technique to improve packet transmission robustness in the presence of packet losses (or "erasures") without going through packet retransmissions that create a delay often incompatible with real-time constraints. The FEC Building Block defined in [RFC5052] provides a framework for the definition of Content Delivery Protocols (CDPs) 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スキームで簡単に使用できます。
Then, FECFRAME [RFC6363] provides a framework to define Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary packet flows over an unreliable datagram service transport, such as UDP. It is primarily intended for real-time or streaming media applications that are using broadcast, multicast, or on-demand delivery. A subset of FECFRAME is currently part of the 3GPP Evolved Multimedia Broadcast/Multicast Service (eMBMS) standard [MBMSTS].
次に、FECFRAME [RFC6363]は、UDPなどの信頼性の低いデータグラムサービストランスポート上の任意のパケットフローにFEC保護を提供するコンテンツ配信プロトコル（CDP）を定義するフレームワークを提供します。主に、ブロードキャスト、マルチキャスト、またはオンデマンド配信を使用するリアルタイムまたはストリーミングメディアアプリケーションを対象としています。 FECFRAMEのサブセットは、現在3GPP Evolved Multimedia Broadcast / Multicast Service（eMBMS）標準[MBMSTS]の一部です。
However, [RFC6363] only considers block FEC schemes defined in accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], [RFC6816], or [RFC6865]). These codes require the input flow(s) to be segmented into a sequence of blocks. Then, FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver or a decoding middlebox) are both performed on a per-block basis. For instance, if the current block encompasses the 100's to 119's source symbols (i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) will be performed on this block independently of other blocks. This approach has major impacts on FEC encoding and decoding delays. The data packets of continuous media flow(s) may be passed to the transport layer immediately, without delay. But the block creation time, which depends on the number of source symbols in this block, impacts both the FEC encoding delay (since encoding requires that all source symbols be known) and, mechanically, the packet loss recovery delay at a receiver (since no repair symbol for the current block can be generated and therefore received before that time). Therefore, a good value for the block size is necessarily a balance between the maximum FEC decoding latency at the receivers (which must be in line with the most stringent real-time requirement of the protected flow(s), hence an incentive to reduce the block size) and the desired robustness against long loss bursts (which increases with the block size, hence an incentive to increase this size).
ただし、[RFC6363]は、FECビルディングブロック[RFC5052]（[RFC6681]、[RFC6816]、または[RFC6865]など）に従って定義されたブロックFECスキームのみを考慮します。これらのコードでは、入力フローをブロックのシーケンスにセグメント化する必要があります。次に、FECエンコード（送信側またはエンコードミドルボックス）およびデコード（受信側またはデコードミドルボックス）の両方がブロックごとに実行されます。たとえば、現在のブロックが入力フローの100から119のソースシンボル（つまり、サイズ20シンボルのブロック）を含む場合、他のブロックとは無関係に、このブロックに対してエンコード（およびデコード）が実行されます。このアプローチは、FECエンコードとデコードの遅延に大きな影響を与えます。連続メディアフローのデータパケットは、遅延することなく、トランスポート層にすぐに渡されます。ただし、このブロック内のソースシンボルの数に依存するブロック作成時間は、FECエンコーディング遅延（エンコーディングではすべてのソースシンボルが既知である必要があるため）と、機械的にはレシーバーでのパケット損失回復遅延（現在のブロックの修復シンボルを生成できるため、その前に受信できます）。したがって、ブロックサイズの適切な値は、レシーバーでの最大FECデコードレイテンシ間のバランスです（これは、保護されたフローの最も厳しいリアルタイム要件に一致している必要があるため、ブロックサイズ）および長い損失バーストに対する望ましい堅牢性（これはブロックサイズとともに増加するため、このサイズを増加させるインセンティブ）。
This document updates [RFC6363] in order to also support FEC codes based on a sliding encoding window (a.k.a., convolutional codes) [RFC8406]. This encoding window, either fixed or variable size, slides over the set of source symbols. FEC encoding is launched whenever needed from the set of source symbols present in the sliding encoding window at that time. This approach significantly reduces FEC-related latency, since repair symbols can be generated and passed to the transport layer on the fly at any time and can be regularly received by receivers to quickly recover packet losses. Using sliding window FEC codes is therefore highly beneficial to real-time flows, one of the primary targets of FECFRAME. [RFC8681] provides an example of such a FEC scheme for FECFRAME, which is built upon the simple sliding window Random Linear Code (RLC).
このドキュメントは、スライディングエンコーディングウィンドウに基づくFECコード（別名、畳み込みコード）[RFC8406]もサポートするために[RFC6363]を更新します。このエンコードウィンドウは、固定サイズでも可変サイズでも、ソースシンボルのセットの上をスライドします。 FECエンコーディングは、その時点でスライディングエンコーディングウィンドウに存在するソースシンボルのセットから必要に応じて起動されます。このアプローチは、FEC関連のレイテンシを大幅に削減します。これは、修復シンボルを随時生成してトランスポート層に渡し、受信機が定期的に受信してパケット損失を迅速に回復できるためです。したがって、スライディングウィンドウFECコードの使用は、FECFRAMEの主要なターゲットの1つであるリアルタイムフローにとって非常に有益です。 [RFC8681]は、FECFRAMEのそのようなFECスキームの例を提供します。これは、単純なスライディングウィンドウランダム線形コード（RLC）に基づいて構築されています。
This document is fully backward compatible with [RFC6363]. Indeed:
このドキュメントは、[RFC6363]と完全に下位互換性があります。確かに：
* This FECFRAME update does not prevent or compromise in any way the support of block FEC codes. Both types of codes can nicely coexist, just like different block FEC schemes can coexist.
* このFECFRAMEの更新は、ブロックFECコードのサポートを妨げたり妥協したりするものではありません。異なるタイプのブロックFECスキームが共存できるように、両方のタイプのコードがうまく共存できます。
* Each sliding window FEC scheme is associated with a specific FEC Encoding ID subject to IANA registration, just like block FEC schemes.
* 各スライディングウィンドウFECスキームは、ブロックFECスキームと同様に、IANA登録の対象となる特定のFECエンコーディングIDに関連付けられています。
* Any receiver -- for instance, a legacy receiver that only supports block FEC schemes -- can easily identify the FEC scheme used in a FECFRAME session. Indeed, the FEC Encoding ID that identifies the FEC scheme is carried in FEC Framework Configuration Information (see Section 5.5 of [RFC6363]). For instance, when the Session Description Protocol (SDP) is used to carry the FEC Framework Configuration Information, the FEC Encoding ID can be communicated in the "encoding-id=" parameter of a "fec-repair-flow" attribute [RFC6364]. This mechanism is the basic approach for a FECFRAME receiver to determine whether or not it supports the FEC scheme used in a given FECFRAME session.
* たとえば、ブロックFECスキームのみをサポートするレガシーレシーバーなどのレシーバーは、FECFRAMEセッションで使用されるFECスキームを簡単に識別できます。実際、FECスキームを識別するFECエンコーディングIDはFECフレームワーク構成情報で伝達されます（[RFC6363]のセクション5.5を参照）。たとえば、セッション記述プロトコル（SDP）を使用してFECフレームワーク構成情報を伝達する場合、FECエンコーディングIDは、「fec-repair-flow」属性の「encoding-id =」パラメーターで通信できます[RFC6364] 。このメカニズムは、FECFRAMEレシーバーが特定のFECFRAMEセッションで使用されるFECスキームをサポートするかどうかを判断するための基本的なアプローチです。
This document leverages on [RFC6363] and reuses its structure. It proposes new sections specific to sliding window FEC codes whenever required. The only exception is Section 3, which provides a quick summary of FECFRAME in order to facilitate the understanding of this document to readers not familiar with the concepts and terminology.
このドキュメントは[RFC6363]を活用し、その構造を再利用します。必要に応じて、スライディングウィンドウFECコードに固有の新しいセクションを提案します。唯一の例外はセクション3です。このセクションでは、概念と用語に精通していない読者がこのドキュメントを理解しやすくするために、FECFRAMEの概要を簡単に説明しています。
The following list of definitions and abbreviations is copied from [RFC6363], adding only the Block FEC Code, Sliding Window FEC Code, and Encoding/Decoding Window definitions (tagged with "ADDED"):
以下の定義と略語のリストは、[RFC6363]からコピーされ、ブロックFECコード、スライディングウィンドウFECコード、およびエンコード/デコードウィンドウ定義（「ADDED」のタグが付けられている）のみが追加されています。
Application Data Unit (ADU): The unit of source data provided as a payload to the transport layer. For instance, it can be a payload containing the result of the RTP packetization of a compressed video frame.
アプリケーションデータユニット（ADU）：トランスポート層へのペイロードとして提供されるソースデータの単位。たとえば、圧縮されたビデオフレームのRTPパケット化の結果を含むペイロードにすることができます。
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コードは、データフローを破損から回復するためにも使用できますが、このドキュメントでは考慮していません。
Block FEC Code: (ADDED) A FEC code that operates on blocks, i.e., for which the input flow MUST be segmented into a sequence of blocks, with FEC encoding and decoding being performed independently on a per-block basis.
ブロックFECコード：（追加）ブロックで動作するFECコード、つまり、入力フローをブロックのシーケンスにセグメント化する必要があり、FECエンコードとデコードはブロックごとに独立して実行されます。
Sliding Window FEC Code: (ADDED) A FEC code that can generate repair symbols on the fly, at any time, from the set of source symbols present in the sliding encoding window at that time. These codes are also known as convolutional codes.
スライディングウィンドウ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 and provides positional information 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修復パケット：送信側（それぞれ、受信側）で、1つ以上の修復シンボルと、修復FECペイロードID、および場合によってはRTPヘッダーを含むトランスポートプロトコルに送信された（それぞれから受信された）ペイロード。
FEC Scheme: A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework.
FECスキーム：FECフレームワークで特定のFECコードを使用するために必要な追加のプロトコルの側面を定義する仕様。
FEC Source Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID.
FECソースパケット：送信側（受信側）で、ADUとオプションの明示的ソースFECペイロードIDを含むトランスポートプロトコルに送信された（それぞれ受信された）ペイロード。
Repair Flow: The packet flow carrying FEC data.
修復フロー：FECデータを運ぶパケットフロー。
Repair FEC Payload ID: A FEC Payload ID specifically for use with repair packets.
修理FECペイロードID：特に修理パケットで使用するためのFECペイロードID。
Source Flow: The packet flow to which FEC protection is to be applied. A source flow consists of ADUs.
ソースフロー：FEC保護が適用されるパケットフロー。ソースフローはADUで構成されます。
Source FEC Payload ID: A FEC Payload ID specifically for use with source packets.
ソースFECペイロードID：ソースパケットで使用するためのFECペイロードID。
Source Protocol: A protocol used for the source flow being protected, e.g., RTP.
ソースプロトコル：保護されているソースフローに使用されるプロトコル（RTPなど）。
Transport Protocol: The protocol used for the transport of the source and repair flows. This protocol needs to provide an unreliable datagram service, as UDP does ([RFC6363], Section 7).
転送プロトコル：ソースと修復フローの転送に使用されるプロトコル。このプロトコルは、UDPとは異なり、信頼性の低いデータグラムサービスを提供する必要があります（[RFC6363]、セクション7）。
Encoding Window: (ADDED) Set of source symbols available at the sender/coding node that are used (with a Sliding Window FEC code) to generate a repair symbol.
エンコーディングウィンドウ：（追加）修復シンボルを生成するために（スライディングウィンドウFECコードと共に）使用される、送信側/コーディングノードで使用可能なソースシンボルのセット。
Decoding Window: (ADDED) Set of received or decoded source and repair symbols available at a receiver that are used (with a Sliding Window FEC code) to decode lost source symbols.
復号化ウィンドウ：（追加）失われたソースシンボルを復号化するために（スライディングウィンドウFECコードと共に）使用される、受信機で利用可能な受信または復号化されたソースおよび修復シンボルのセット。
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 lost (e.g., in our case, by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer code) or received. When a packet is received, it is assumed that this packet is not corrupted (i.e., in our case, the bit errors, if any, are fixed by the physical-layer code and are therefore hidden to the upper layers).
パケット消去チャネル：パケットが失われた（この例では、輻輳したルーターによって、または送信エラーの数が物理層コードの訂正能力を超えたために）または受信された通信パス。パケットが受信されると、このパケットは破損していないと想定されます（つまり、この場合、ビットエラーは、もしあれば、物理層コードによって修正されるため、上位層には表示されません）。
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. This notion is restricted to Block FEC codes.
ソースブロック：FEC保護される単一ブロックとしてADUのグループ。この概念は、ブロックFECコードに限定されています。
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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The architecture of Section 3 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here. However, this section includes a quick summary to facilitate the understanding of this document to readers not familiar with the concepts and terminology.
[RFC6363]のセクション3のアーキテクチャは、このFECFRAME拡張に同様に適用され、ここでは繰り返されません。ただし、このセクションには、概念と用語に精通していない読者がこのドキュメントを理解しやすくするための簡単な要約が含まれています。
+----------------------+
| Application |
+----------------------+
|
| (1) Application Data Units (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 Protocol |
+----------------------+
Figure 1: FECFRAME Architecture at a Sender
図1：送信側のFECFRAMEアーキテクチャ
The FECFRAME architecture is illustrated in Figure 1 for a block FEC scheme from the sender's point of view. It shows an application generating an ADU flow (other flows from other applications may coexist). These ADUs of variable size must be somehow mapped to source symbols of a fixed size (this fixed size is a requirement of all FEC schemes, which comes from the way mathematical operations are applied to the symbols' content). This is the goal of an ADU-to-symbols mapping process that is FEC scheme specific (see below). Once the source block is built, taking into account both the FEC scheme constraints (e.g., in terms of maximum source block size) and the application's flow constraints (e.g., in terms of real-time constraints), the associated source symbols are handed to the FEC scheme in order to produce an appropriate number of repair symbols. FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or more repair symbols each) are then generated and sent using an appropriate transport protocol (more precisely, Section 7 of [RFC6363] requires a transport protocol providing an unreliable datagram service, such as UDP). In practice, FEC Source Packets may be passed to the transport layer as soon as available without having to wait for FEC encoding to take place. In that case, a copy of the associated source symbols needs to be kept within FECFRAME for future FEC encoding purposes.
FECFRAMEアーキテクチャは、送信者の観点からのブロックFECスキームについて図1に示されています。これは、ADUフローを生成するアプリケーションを示しています（他のアプリケーションからの他のフローが共存する場合があります）。可変サイズのこれらのADUは、何らかの方法で固定サイズのソースシンボルにマッピングする必要があります（この固定サイズは、すべてのFECスキームの要件であり、数学的な演算がシンボルのコンテンツに適用される方法から生じます）。これは、FECスキーム固有のADUからシンボルへのマッピングプロセスの目標です（以下を参照）。ソースブロックが構築されると、FECスキームの制約（たとえば、最大ソースブロックサイズに関する）とアプリケーションのフロー制約（たとえば、リアルタイム制約に関する）の両方を考慮して、関連するソースシンボルが適切な数の修復シンボルを生成するためのFECスキーム。 FECソースパケット（ADUを含む）およびFEC修復パケット（それぞれに1つ以上の修復シンボルを含む）が生成され、適切なトランスポートプロトコルを使用して送信されます（より正確には、[RFC6363]のセクション7では、信頼性の低いデータグラムサービスを提供するトランスポートプロトコルが必要です。 UDPなど）。実際には、FECソースパケットは、FECエンコーディングが行われるのを待つ必要なく、利用可能になり次第トランスポート層に渡されます。その場合、関連するソースシンボルのコピーは、将来のFECエンコードのためにFECFRAME内に保持する必要があります。
At a receiver (not shown), FECFRAME processing operates in a similar way, taking as input the incoming FEC Source and Repair Packets received. In case of FEC Source Packet losses, the FEC decoding of the associated block may recover all (in case of successful decoding) or a subset that is potentially empty (if decoding fails) of the missing source symbols. After source-symbol-to-ADU mapping, when lost ADUs are recovered, they are then assigned to their respective flow (see below). ADUs are returned to the application(s), either in their initial transmission order (in which case all ADUs received after a lost ADU will be delayed until FEC decoding has taken place) or not (in which case each ADU is returned as soon as it is received or recovered), depending on the application requirements.
受信機（図示せず）では、FECFRAME処理が同様の方法で動作し、受信した受信FECソースと修復パケットを入力として受け取ります。 FECソースパケット損失の場合、関連するブロックのFECデコードは、欠落したソースシンボルのすべて（デコードが成功した場合）または潜在的に空である（デコードが失敗した場合）サブセットを回復します。ソースシンボルからADUへのマッピング後、失われたADUが復元されると、それぞれのフローに割り当てられます（以下を参照）。 ADUは、最初の送信順序（この場合、失われたADUの後に受信されたすべてのADUは、FECデコードが行われるまで遅延されます）またはそうではない（この場合、各ADUはすぐに返されます）アプリケーションの要件に応じて、受信または回復されます）。
FECFRAME features two subtle mechanisms whose details are FEC scheme dependent:
FECFRAMEは、詳細がFECスキームに依存する2つの微妙なメカニズムを備えています。
* ADUs-to-source-symbols mapping: in order to manage variable size ADUs, FECFRAME and FEC schemes can use small, fixed-size symbols and create a mapping between ADUs and symbols. The mapping details are FEC scheme dependent and must be defined in the associated document. For instance, with certain FEC schemes, to each ADU, this mechanism prepends a length field (plus a flow identifier; see below) and pads the result to a multiple of the symbol size. A small ADU may be mapped to a single source symbol, while a large one may be mapped to multiple symbols.
* ADUからソースシンボルへのマッピング：可変サイズのADUを管理するために、FECFRAMEおよびFECスキームでは、小さい固定サイズのシンボルを使用して、ADUとシンボル間のマッピングを作成できます。マッピングの詳細はFECスキームに依存し、関連ドキュメントで定義する必要があります。たとえば、特定のFECスキームでは、このメカニズムは各ADUに対して、長さフィールド（およびフロー識別子、以下を参照）を付加し、結果をシンボルサイズの倍数にパディングします。小さなADUは単一のソースシンボルにマッピングされ、大きなADUは複数のシンボルにマッピングされます。
* Assignment of decoded ADUs to flows in multi-flow configurations: when multiple flows are multiplexed over the same FECFRAME instance, a problem is to assign a decoded ADU to the right flow (UDP port numbers and IP addresses traditionally used to map incoming ADUs to flows are not recovered during FEC decoding). The mapping details are FEC scheme dependent and must be defined in the associated document. For instance, with certain FEC schemes, to make it possible, at the FECFRAME sending instance, each ADU is prepended with a flow identifier (1 byte) during the ADU-to-source-symbols mapping (see above). The flow identifiers are also shared between all FECFRAME instances as part of the FEC Framework Configuration Information. The ADU Information (ADUI), which includes the flow identifier, length, application payload, and padding, is then FEC protected. Therefore, a decoded ADUI contains enough information to assign the ADU to the right flow. Note that a FEC scheme may also be restricted to the particular case of a single flow over a FECFRAME instance; that would make the above mechanism pointless.
* マルチフロー構成でのデコードされたADUのフローへの割り当て：複数のフローが同じFECFRAMEインスタンスで多重化される場合、問題は、デコードされたADUを正しいフローに割り当てることです（UDPポート番号と、着信ADUをフローにマッピングするために従来使用されているIPアドレス） FECデコード中に回復されません）。マッピングの詳細はFECスキームに依存し、関連ドキュメントで定義する必要があります。たとえば、特定のFECスキームでは、これを可能にするために、FECFRAME送信インスタンスで、ADUからソースシンボルへのマッピング中に、各ADUにフロー識別子（1バイト）が付加されます（上記を参照）。フロー識別子は、FECフレームワーク構成情報の一部として、すべてのFECFRAMEインスタンス間でも共有されます。フロー識別子、長さ、アプリケーションペイロード、パディングを含むADU情報（ADUI）は、FEC保護されます。したがって、デコードされたADUIには、ADUを正しいフローに割り当てるのに十分な情報が含まれています。 FECスキームは、FECFRAMEインスタンスを介した単一フローの特定のケースに制限される場合もあります。上記のメカニズムは無意味になります。
A few aspects are not covered by FECFRAME, namely:
FECFRAMEでカバーされないいくつかの側面、すなわち：
* Section 8 of [RFC6363] does not detail any congestion control mechanisms and only provides high-level normative requirements.
* [RFC6363]のセクション8には、輻輳制御メカニズムの詳細は記載されておらず、高水準の規範的要件のみを提供しています。
* The possibility of having feedback from receiver(s) is considered out of scope, although such a mechanism may exist within the application (e.g., through RTP Control Protocol (RTCP) messages).
* このようなメカニズムはアプリケーション内に存在する場合がありますが（例：RTP制御プロトコル（RTCP）メッセージを介して）、レシーバーからのフィードバックの可能性は範囲外と見なされます。
* Flow adaptation at a FECFRAME sender (e.g., how to set the FEC code rate based on transmission conditions) is not detailed, but it needs to comply with the congestion control normative requirements (see above).
* FECFRAME送信側でのフローの適応（たとえば、送信条件に基づいてFECコードレートを設定する方法）は詳細ではありませんが、輻輳制御の規範的な要件に準拠する必要があります（上記を参照）。
The general considerations of Section 4.1 of [RFC6363] that are specific to block FEC codes are not repeated here.
[RFC6363]のセクション4.1のブロックFECコードに固有の一般的な考慮事項は、ここでは繰り返されません。
With a Sliding Window FEC code, the FEC Source Packet MUST contain information to identify the position occupied by the ADU within the source flow in terms specific to the FEC scheme. This information is known as the Source FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.
スライディングウィンドウFECコードを使用する場合、FECソースパケットには、FECスキームに固有の用語でソースフロー内のADUが占める位置を識別するための情報が含まれている必要があります。この情報はソースFECペイロードIDとして知られており、FECスキームはそれを定義して解釈する責任があります。
With a Sliding Window FEC code, the FEC Repair Packets MUST contain information that identifies the relationship between the contained repair payloads and the original source symbols used during encoding. This information is known as the Repair FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.
スライディングウィンドウFECコードの場合、FEC修復パケットには、含まれている修復ペイロードとエンコード中に使用された元のソースシンボルとの関係を識別する情報が含まれている必要があります。この情報は、Repair FEC Payload IDと呼ばれ、FECスキームはそれを定義および解釈する責任があります。
The sender operation ([RFC6363], Section 4.2) and receiver operation ([RFC6363], Section 4.3) are both specific to block FEC codes and are therefore omitted below. The following two sections detail similar operations for Sliding Window FEC codes.
送信者の操作（[RFC6363]、セクション4.2）と受信者の操作（[RFC6363]、セクション4.3）はどちらもブロックFECコードに固有であるため、以下では省略します。次の2つのセクションでは、スライディングウィンドウFECコードの同様の操作について詳しく説明します。
With a Sliding Window FEC scheme, the following operations, illustrated in Figure 2 for the generic case (non-RTP repair flows) and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:
スライディングウィンドウFECスキームでは、一般的なケース（RTP以外の修復フロー）の図2とRTP修復フローの場合の図3に示されている次の操作は、準拠するソースと修復フローを生成する可能な方法を示しています。
1. A new ADU is provided by the application.
1. 新しいADUがアプリケーションによって提供されます。
2. The FEC Framework communicates this ADU to the FEC scheme.
2. FECフレームワークは、このADUをFECスキームに伝達します。
3. The sliding encoding window is updated by the FEC scheme. The ADU-to-source-symbol mapping as well as the encoding window management details are both the responsibility of the FEC scheme and MUST be detailed there. Appendix A provides non-normative hints about what FEC scheme designers need to consider.
3. スライディングエンコーディングウィンドウは、FECスキームによって更新されます。 ADUからソースシンボルへのマッピングと、エンコーディングウィンドウ管理の詳細は、FECスキームの責任であり、そこで詳述する必要があります。付録Aは、FECスキームの設計者が考慮する必要があることに関する非規範的なヒントを提供します。
4. The Source FEC Payload ID information of the 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 and returned to the FEC Framework.
4. ソースパケットのソースFECペイロードID情報は、FECスキームによって決定されます。 FECスキームで必要な場合、ソースFECペイロードIDは、明示的なソースFECペイロードIDフィールドにエンコードされ、FECフレームワークに返されます。
5. The FEC Framework constructs the FEC Source Packet according to Figure 6 in [RFC6363], using the Explicit Source FEC Payload ID provided by the FEC scheme if applicable.
5. FECフレームワークは、[RFC6363]の図6に従ってFECソースパケットを構築し、該当する場合、FECスキームによって提供される明示的なソースFECペイロードIDを使用します。
6. The FEC Source Packet is sent using normal transport-layer procedures. This packet is sent using the same ADU flow identification information as would have been used for the original source packet if the FEC Framework were not present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied).
6. FECソースパケットは、通常のトランスポート層手順を使用して送信されます。このパケットは、FECフレームワークが存在しない場合に元のソースパケットに使用されたのと同じADUフロー識別情報を使用して送信されます（たとえば、ソースパケットを運ぶIPデータグラムのソースアドレスと宛先アドレス、およびUDPポート番号はFECフレームワークが適用されているかどうかにかかわらず同じです）。
7. When the FEC Framework needs to send one or several FEC Repair Packets (e.g., according to the target code rate), it asks the FEC scheme to create one or several repair packet payloads from the current sliding encoding window along with their Repair FEC Payload ID.
7. FECフレームワークが1つまたは複数のFEC修復パケットを送信する必要がある場合（たとえば、ターゲットコードレートに従って）、現在のスライディングエンコーディングウィンドウから1つまたは複数の修復パケットペイロードを、修復FECペイロードIDとともに作成するようにFECスキームに要求します。
8. The Repair FEC Payload IDs and repair packet payloads are provided back by the FEC scheme to the FEC Framework.
8. 修復FECペイロードIDと修復パケットペイロードは、FECスキームによってFECフレームワークに返されます。
9. The FEC Framework constructs FEC Repair Packets according to Figure 7 in [RFC6363], using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.
9. FECフレームワークは、[RFC6363]の図7に従って、FECペイロードIDとFECスキームによって提供される修復パケットペイロードを使用して、FEC修復パケットを構築します。
10. The FEC 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.
10. FEC修復パケットは、通常のトランスポート層手順を使用して送信されます。 FEC修復パケットに使用されるポートとマルチキャストグループは、FECフレームワーク構成情報で定義されています。
+----------------------+
| Application |
+----------------------+
|
| (1) New Application Data Unit (ADU)
v
+---------------------+ +----------------+
| FEC Framework | | FEC Scheme |
| |-------------------------->| |
| | (2) New ADU |(3) Update of |
| | | encoding |
| |<--------------------------| window |
|(5) Construct FEC | (4) Explicit Source | |
| Source Packet | FEC Payload ID(s) |(7) FEC |
| |<--------------------------| encoding |
|(9) Construct FEC | (8) Repair FEC Payload ID | |
| Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+
|
| (6) FEC Source Packet
| (10) FEC Repair Packets
v
+----------------------+
| Transport Protocol |
+----------------------+
Figure 2: Sender Operation with Sliding Window FEC Codes
図2：スライディングウィンドウFECコードを使用した送信者操作
+----------------------+
| Application |
+----------------------+
|
| (1) New Application Data Unit (ADU)
v
+---------------------+ +----------------+
| FEC Framework | | FEC Scheme |
| |-------------------------->| |
| | (2) New ADU |(3) Update of |
| | | encoding |
| |<--------------------------| window |
|(5) Construct FEC | (4) Explicit Source | |
| Source Packet | FEC Payload ID(s) |(7) FEC |
| |<--------------------------| encoding |
|(9) Construct FEC | (8) Repair FEC Payload ID | |
| Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+
| |
|(6) Source |(10) Repair payloads
| packets |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Protocol |
+----------------------+
Figure 3: Sender Operation with Sliding Window FEC Codes and RTP Repair Flows
図3：スライディングウィンドウFECコードとRTP修復フローを使用した送信者操作
With a Sliding Window FEC scheme, the following operations are illustrated in Figure 4 for the generic case (non-RTP repair flows) and in Figure 5 for the case of RTP repair flows. The only differences with respect to block FEC codes lie in steps (4) and (5). Therefore, this section does not repeat the other steps of Section 4.3 of [RFC6363] ("Receiver Operation"). The new steps (4) and (5) are:
スライディングウィンドウFECスキームの場合、一般的なケース（RTP以外の修復フロー）の場合は図4に、RTP修復フローの場合は図5に次の操作を示します。ブロックFECコードに関する唯一の違いは、ステップ（4）と（5）にあります。したがって、このセクションでは、[RFC6363]のセクション4.3（「受信者の操作」）の他の手順を繰り返しません。新しいステップ（4）と（5）は次のとおりです。
4. The FEC scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs when the Explicit Source FEC Payload ID field is not used) to insert source and repair packets into the decoding window in the right way. If at least one source packet is missing and at least one repair packet has been received, then FEC decoding is attempted to recover the missing source payloads. The FEC scheme determines whether source packets have been lost and whether enough repair packets have been received to decode any or all of the missing source payloads.
4. FECスキームは、受信したFECペイロードID（および明示的なソースFECペイロードIDフィールドが使用されていない場合は派生したFECソースペイロードID）を使用して、ソースパケットと修復パケットを正しい方法でデコードウィンドウに挿入します。少なくとも1つのソースパケットが欠落していて、少なくとも1つの修復パケットが受信されている場合、欠落しているソースペイロードを回復するためにFECデコードが試行されます。 FECスキームは、ソースパケットが失われたかどうか、および失われたソースペイロードの一部またはすべてをデコードするのに十分な修復パケットが受信されたかどうかを決定します。
5. The FEC scheme returns the received and decoded ADUs to the FEC Framework, along with indications of any ADUs that were missing and could not be decoded.
5. FECスキームは、欠落していてデコードできなかったADUの表示とともに、受信およびデコードされたADUをFECフレームワークに返します。
+----------------------+
| Application |
+----------------------+
^
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | FEC Scheme |
| |<--------------------------| |
|(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding|
| IDs and pass IDs & |-------------------------->| |
| payloads to FEC |(3) Explicit Source FEC +----------------+
| scheme | Payload IDs
+----------------------+ Repair FEC Payload IDs
^ Source payloads
| Repair payloads
|(1) FEC Source
| and Repair Packets
+----------------------+
| Transport Protocol |
+----------------------+
Figure 4: Receiver Operation with Sliding Window FEC Codes
図4：スライディングウィンドウFECコードを使用したレシーバーの動作
+----------------------+
| Application |
+----------------------+
^
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | FEC Scheme |
| |<--------------------------| |
|(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding|
| IDs and pass IDs & |-------------------------->| |
| payloads to FEC |(3) Explicit Source FEC +----------------+
| scheme | Payload IDs
+----------------------+ Repair FEC Payload IDs
^ ^ Source payloads
| | Repair payloads
|Source pkts |Repair payloads
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC Source and Repair Packets
|
+----------------------+
| Transport Protocol |
+----------------------+
Figure 5: Receiver Operation with Sliding Window FEC Codes and RTP Repair Flows
図5：スライディングウィンドウFECコードとRTP修復フローを使用したレシーバーの動作
This section discusses the protocol elements for the FEC Framework specific to Sliding Window FEC schemes. The global formats of source data packets (i.e., [RFC6363], Figure 6) and repair data packets (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding Window FEC codes. They are not repeated here.
このセクションでは、スライディングウィンドウFECスキームに固有のFECフレームワークのプロトコル要素について説明します。ソースデータパケット（つまり、[RFC6363]、図6）と修復データパケット（つまり、[RFC6363]、図7および8）のグローバルフォーマットは、スライディングウィンドウFECコードと同じままです。ここでは繰り返されません。
The FEC Framework Configuration Information considerations of Section 5.5 of [RFC6363] equally apply to this FECFRAME extension and are not repeated here.
[RFC6363]のセクション5.5のFECフレームワーク構成情報の考慮事項は、このFECFRAME拡張機能にも同様に適用され、ここでは繰り返されません。
The FEC scheme requirements of Section 5.6 of [RFC6363] mostly apply to this FECFRAME extension and are not repeated here. An exception, though, is the "full specification of the FEC code", item (4), which is specific to block FEC codes. In case of a Sliding Window FEC scheme, then the following item (4-bis) applies:
[RFC6363]のセクション5.6のFECスキーム要件は、主にこのFECFRAME拡張に適用され、ここでは繰り返されません。ただし、例外は「FECコードの完全な仕様」の項目（4）で、これはブロックFECコードに固有のものです。スライディングウィンドウFECスキームの場合、次の項目（4-bis）が適用されます。
4-bis. A full specification of the Sliding Window FEC code.
4-bis。スライディングウィンドウ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スキーマ固有の情報値、有効なFECペイロードID値、および有効なパケットペイロードサイズを正確に定義する必要があります（「パケットペイロード」とは、エンコードシンボルの伝送専用のパケット内のスペースを指します）。
Furthermore, given valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, a valid packet payload size, and a valid encoding window (i.e., a set of source symbols), the specification MUST uniquely define the values of the encoding symbol (or symbols) to be included in the repair packet payload with the given Repair FEC Payload ID value.
さらに、FECスキーマ固有情報の有効な値、有効な修復FECペイロードID値、有効なパケットペイロードサイズ、および有効なエンコーディングウィンドウ（つまり、ソースシンボルのセット）が指定されている場合、仕様は値を一意に定義する必要があります。指定された修復FECペイロードID値を使用して、修復パケットペイロードに含まれる1つまたは複数のエンコーディングシンボルの。
Additionally, the FEC scheme associated with a Sliding Window FEC code:
さらに、スライディングウィンドウFECコードに関連付けられたFECスキーム：
* MUST define the relationships between ADUs and the associated source symbols (mapping).
* ADUと関連するソースシンボル（マッピング）の関係を定義する必要があります。
* MUST define the management of the encoding window that slides over the set of ADUs. Appendix A provides non-normative hints about what FEC scheme designers need to consider.
* ADUのセットの上をスライドするエンコーディングウィンドウの管理を定義する必要があります。付録Aは、FECスキームの設計者が考慮する必要があることに関する非規範的なヒントを提供します。
* MUST define the management of the decoding window. This usually consists of managing a system of linear equations (for a linear FEC code).
* デコードウィンドウの管理を定義する必要があります。これは通常、線形方程式のシステムの管理で構成されます（線形FECコードの場合）。
The discussion in Section 6 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.
[RFC6363]のセクション6での議論は、このFECFRAME拡張にも同様に適用され、ここでは繰り返されません。
The discussion in Section 7 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.
[RFC6363]のセクション7の説明は、このFECFRAME拡張にも同様に適用され、ここでは繰り返されません。
The discussion in Section 8 of [RFC6363] equally applies to this FECFRAME extension and is not repeated here.
[RFC6363]のセクション8での議論は、このFECFRAME拡張にも同様に適用され、ここでは繰り返されません。
This FECFRAME extension does not add any new security considerations. All the considerations of Section 9 of [RFC6363] apply to this document as well. However, for the sake of completeness, the following goal can be added to the list provided in Section 9.1 of [RFC6363] ("Problem Statement"):
このFECFRAME拡張機能は、セキュリティに関する新しい考慮事項を追加しません。 [RFC6363]のセクション9のすべての考慮事項は、このドキュメントにも適用されます。ただし、完全を期すために、[RFC6363]のセクション9.1に記載されているリストに次の目標を追加できます（「問題の説明」）。
* Attacks can try to corrupt source flows in order to modify the receiver application's behavior (as opposed to just denying service).
* 攻撃は、（単にサービスを拒否するのではなく）受信側アプリケーションの動作を変更するために、ソースフローを破壊しようとする可能性があります。
This FECFRAME extension does not add any new Operations and Management Considerations. All the considerations of Section 10 of [RFC6363] apply to this document as well.
このFECFRAME拡張機能は、新しい運用と管理の考慮事項を追加しません。 [RFC6363]のセクション10のすべての考慮事項は、このドキュメントにも適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
A FEC scheme for use with this FEC Framework is identified via its FEC Encoding ID. It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of Section 11 of [RFC6363] apply and are not repeated here.
このFECフレームワークで使用するFECスキームは、そのFECエンコーディングIDによって識別されます。 「FECフレームワーク（FECFRAME）FECエンコーディングID」レジストリでのIANA登録の対象です。 [RFC6363]のセクション11のすべてのルールが適用され、ここでは繰り返されません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、DOI 10.17487 / RFC6363、2011年10月、<https：//www.rfc-editor。 org / info / rfc6363>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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、「Multimedia Broadcast / Multicast Service（MBMS）; Protocols and codecs」、3GPP TS 26.346、2009年3月、<http://ftp.3gpp.org/specs/html-info/26346.htm>。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, <https://www.rfc-editor.org/info/rfc5052>.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「Forward Error Correction（FEC）Building Block」、RFC 5052、DOI 10.17487 / RFC5052、2007年8月、<https：//www.rfc-editor .org / info / rfc5052>。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, <https://www.rfc-editor.org/info/rfc6364>.
[RFC6364] Begen、A。、「前方誤り訂正（FEC）フレームワークのセッション記述プロトコル要素」、RFC 6364、DOI 10.17487 / RFC6364、2011年10月、<https://www.rfc-editor.org/info/ rfc6364>。
[RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, DOI 10.17487/RFC6681, August 2012, <https://www.rfc-editor.org/info/rfc6681>.
[RFC6681]ワトソン、M。、ストックハンマー、T。、およびM.ルビー、「FECFRAMEのラプター転送エラー訂正（FEC）スキーム」、RFC 6681、DOI 10.17487 / RFC6681、2012年8月、<https：//www.rfc -editor.org/info/rfc6681>。
[RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/RFC6816, December 2012, <https://www.rfc-editor.org/info/rfc6816>.
[RFC6816] Roca、V.、Cunche、M。、およびJ. Lacan、「FECFRAMEのためのシンプルな低密度パリティチェック（LDPC）階段前方誤り訂正（FEC）スキーム」、RFC 6816、DOI 10.17487 / RFC6816、2012年12月、<https://www.rfc-editor.org/info/rfc6816>。
[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Matsuzono, "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/RFC6865, February 2013, <https://www.rfc-editor.org/info/rfc6865>.
[RFC6865] Roca、V.、Cunche、M.、Lacan、J.、Bouabdallah、A。、およびK. Matsuzono、「FECFRAMEのための単純なリードソロモン前方誤り訂正（FEC）スキーム」、RFC 6865、DOI 10.17487 / RFC6865、2013年2月、<https://www.rfc-editor.org/info/rfc6865>。
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RFC8406] Adamson、B.、Adjih、C.、Bilbao、J.、Firoiu、V.、Fitzek、F.、Ghanem、S.、Lochin、E.、Masucci、A.、Montpetit、MJ。、Pedersen、 M.、ペラルタ、G。、ロカ、V。、編、サクセナ、P.、S。シバクマール、「効率的なネットワーク通信のためのコーディング手法の分類法」、RFC 8406、DOI 10.17487 / RFC8406、2018年6月、<https ：//www.rfc-editor.org/info/rfc8406>。
[RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, <https://www.rfc-editor.org/info/rfc8681>.
[RFC8681] Roca、V。およびB. Teibi、「FECFRAMEのスライディングウィンドウランダムリニアコード（RLC）前方消失訂正（FEC）スキーム」、RFC 8681、DOI 10.17487 / RFC8681、2020年1月、<https：// www。 rfc-editor.org/info/rfc8681>。
Appendix A. About Sliding Encoding Window Management (Informational)
付録A.スライディングエンコーディングウィンドウの管理について（参考）
The FEC Framework does not specify the management of the sliding encoding window, which is the responsibility of the FEC scheme. This annex only provides a few informational hints.
FECフレームワークは、FECスキームの責任であるスライディングエンコーディングウィンドウの管理を指定しません。この附属書は、いくつかの情報提供のヒントを提供しています。
Source symbols are added to the sliding encoding window each time a new ADU is available at the sender after the ADU-to-source-symbol mapping specific to the FEC scheme has been done.
ソースシンボルは、FECスキームに固有のADUからソースシンボルへのマッピングが行われた後、新しいADUが送信側で利用可能になるたびに、スライディングエンコーディングウィンドウに追加されます。
Source symbols are removed from the sliding encoding window. For instance:
ソースシンボルは、スライディングエンコーディングウィンドウから削除されます。例えば：
* After a certain delay, when an "old" ADU of a real-time flow times out. The source symbol retention delay in the sliding encoding window should therefore be initialized according to the real-time features of incoming flow(s) when applicable.
* 一定の遅延の後、リアルタイムフローの「古い」ADUがタイムアウトした場合。したがって、スライディングエンコーディングウィンドウでのソースシンボルの保持遅延は、必要に応じて、着信フローのリアルタイム機能に従って初期化する必要があります。
* Once the sliding encoding window has reached its maximum size (there is usually an upper limit to the sliding encoding window size). In that case, the oldest symbol is removed each time a new source symbol is added.
* スライディングエンコーディングウィンドウが最大サイズに達すると（通常、スライディングエンコーディングウィンドウサイズには上限があります）。その場合、新しいソースシンボルが追加されるたびに、最も古いシンボルが削除されます。
Several considerations can impact the management of this sliding encoding window:
いくつかの考慮事項が、このスライディングエンコーディングウィンドウの管理に影響を与える可能性があります。
* At the source flows level: real-time constraints can limit the total time during which source symbols can remain in the encoding window.
* ソースフローレベル：リアルタイム制約により、ソースシンボルがエンコーディングウィンドウに留まることができる合計時間を制限できます。
* At the FEC code level: theoretical or practical limitations (e.g., because of computational complexity) can limit the number of source symbols in the encoding window.
* FECコードレベル：理論的または実際的な制限（たとえば、計算の複雑さ）により、エンコードウィンドウ内のソースシンボルの数が制限される可能性があります。
* At the FEC scheme level: signaling and window management are intrinsically related. For instance, an encoding window composed of a nonsequential set of source symbols requires appropriate signaling to inform a receiver of the composition of the encoding window, and the associated transmission overhead can limit the maximum encoding window size. On the contrary, an encoding window always composed of a sequential set of source symbols simplifies signaling: providing the identity of the first source symbol plus its number is sufficient, which creates a fixed and relatively small transmission overhead.
* FECスキームレベル：シグナリングとウィンドウ管理は本質的に関連しています。たとえば、非順次のソースシンボルのセットで構成されるエンコードウィンドウは、受信者にエンコードウィンドウの構成を通知するための適切なシグナリングを必要とし、関連する送信オーバーヘッドによって最大エンコードウィンドウサイズが制限される可能性があります。逆に、常に一連のソースシンボルで構成されるエンコードウィンドウはシグナリングを簡素化します。最初のソースシンボルとその番号のIDを提供するだけで十分であり、固定された比較的小さな送信オーバーヘッドが発生します。
Acknowledgments
謝辞
The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on this document. This document being an extension of [RFC6363], the authors would also like to thank Mark Watson as the main author of that RFC.
このドキュメントに関する貴重なフィードバックを提供してくれたChrister Holmberg、David Black、Gorry Fairhurst、Emmanuel Lochin、Spencer Dawkins、Ben Campbell、Benjamin Kaduk、Eric Rescorla、Adam Roach、Greg Skinnerに感謝します。この文書は[RFC6363]の拡張版であり、著者はそのRFCの主要著者であるMark Watsonにも感謝します。
Authors' Addresses
著者のアドレス
Vincent Roca INRIA Univ. Grenoble Alpes France
ヴィンセントロカINRIA大学グルノーブルアルプスフランス
Email: vincent.roca@inria.fr
Ali Begen Networked Media Konya/ Turkey
Ali Begen Network Media Daughter /トルコ
Email: ali.begen@networked.media