[要約] RFC 8406は、効率的なネットワーク通信のためのコーディング技術の分類に関するものです。このRFCの目的は、異なるコーディング技術を分類し、ネットワーク通信の効率を向上させるためのガイドラインを提供することです。
Internet Research Task Force (IRTF) B. Adamson
Request for Comments: 8406 NRL
Category: Informational C. Adjih
ISSN: 2070-1721 INRIA
J. Bilbao
Ikerlan
V. Firoiu
BAE Systems
F. Fitzek
TU Dresden
S. Ghanem
Independent
E. Lochin
ISAE - Supaero
A. Masucci
Orange
M-J. Montpetit
Independent
M. Pedersen
Aalborg University
G. Peralta
Ikerlan
V. Roca, Ed.
INRIA
P. Saxena
AnsuR Technologies
S. Sivakumar
Cisco
June 2018
Taxonomy of Coding Techniques for Efficient Network Communications
効率的なネットワーク通信のためのコーディング技術の分類
Abstract
概要
This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.
このドキュメントでは、ネットワークコーディングの概念と構成に推奨される用語をまとめています。ネットワークコーディングに関する将来のIRTFおよびIETFドキュメントのあいまいさを回避するために、包括的な用語セットを提供します。このドキュメントは、コーディングフォーエフィシェントネットワークコミュニケーションリサーチグループ（NWCRG）の製品であり、信頼性の高いマルチキャストトランスポート（RMT）およびFECフレームワーク（FECFRAME）IETFワーキンググループによって作成されたRFCで使用される用語と一致しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Coding for Efficient Network Communications Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、Internet Research Task Force（IRTF）のCoding for Efficient Network Communications Research Groupのコンセンサスを表しています。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8406.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8406で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Definitions and Concepts . . . . . . . . . . . . . . 4
3. Taxonomy of Code Uses . . . . . . . . . . . . . . . . . . . . 7
4. Coding Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Coding Types . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Coding Basics . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Coding in Practice . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. In 2017, the document was discussed during three audio conferences, each of them gathering 6 to 8 key experts; it was co-edited and subjected to an RG Last Call. The general feeling was that the document was ready. Additional information about Network Coding may be found on these NWCRG pages: <https://irtf.org/nwcrg> and <https://datatracker.ietf.org/rg/nwcrg/about/>.
このドキュメントは、コーディングと効率的なネットワーク通信研究グループ（NWCRG）の共同作業とコンセンサスの成果物であり、それらを代表しています。 IETF製品ではなく、標準ではありません。 2017年、この文書は3つの音声会議で議論され、それぞれ6〜8人の主要な専門家が集まりました。それは共同編集され、RG Last Callの対象となりました。一般的な感触は、ドキュメントが準備できたということでした。ネットワークコーディングに関する追加情報は、これらのNWCRGページ<https://irtf.org/nwcrg>および<https://datatracker.ietf.org/rg/nwcrg/about/>にあります。
The literature on Network Coding research and system design, including IETF documentation, led to a rich set of concepts and constructs. This document collects terminology used in the domain, both outside and inside IETF, provides concise definitions, and introduces a high-level taxonomy. Its primary goal is to be useful to IETF and IRTF activities. It is also in line with the terminology already used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups, in particular [RFC5052], [RFC5740], [RFC5775], [RFC6363], and [RFC6726]. This document is also related to IETF work being done in the PAYLOAD and TSVWG WGs (in particular, the extension of FECFRAME to support Sliding Window Codes and the Random Linear Coding (RLC) sliding window FEC scheme) and past work in the AVTCORE and MMUSIC WGs. Note that in the definitions, the "(IETF)" tag indicates that the associated term is already used in IETF documents (Internet-Drafts and RFCs).
IETFのドキュメントを含む、ネットワークコーディングの研究とシステム設計に関する文献は、豊富な概念と構成のセットにつながりました。このドキュメントでは、IETFの外部と内部の両方でドメインで使用されている用語を収集し、簡潔な定義を提供し、高レベルの分類法を紹介します。その主な目標は、IETFとIRTFの活動に役立つことです。また、Reliable Multicast Transport（RMT）およびFEC Framework（FECFRAME）IETFワーキンググループ、特に[RFC5052]、[RFC5740]、[RFC5775]、[RFC6363]によって作成されたRFCですでに使用されている用語と一致しています。および[RFC6726]。このドキュメントは、PAYLOADおよびTSVWG WGで行われているIETF作業（特に、スライディングウィンドウコードとランダム線形コーディング（RLC）スライディングウィンドウFECスキームをサポートするためのFECFRAMEの拡張）と、AVTCOREおよびMMUSICでの過去の作業にも関連しています。 WGs。定義の「（IETF）」タグは、関連する用語がIETF文書（インターネットドラフトおよびRFC）ですでに使用されていることを示していることに注意してください。
This document focuses on packet transmissions and losses. These losses will typically be triggered by various types of networking issues and/or impairments (e.g., congested routers or intermittent wireless connectivity). The notion of "packet" itself is multiform, depending on the target use case and the notion of network (e.g., in which layer of the protocol stack does the coding middleware operate?). For instance, a "packet" may be a data unit to be carried as a UDP payload because the coding middleware is located between the application and UDP. In another configuration, coding may be applied within an overlay network and the notion of "packet" will be totally different. In any case, the goals of Network Coding can be to improve the network throughput, efficiency, latency, and scalability, as well as to provide resilience to partition, attacks, and eavesdropping (NWCRG charter). Both End-to-End Coding and systems that also perform recoding within intermediate forwarding nodes are considered in this document.
このドキュメントでは、パケットの送信と損失に焦点を当てています。これらの損失は通常、さまざまなタイプのネットワークの問題や障害（たとえば、ルーターの混雑や断続的なワイヤレス接続）によって引き起こされます。 「パケット」自体の概念は、ターゲットのユースケースとネットワークの概念（たとえば、コーディングミドルウェアがプロトコルスタックのどの層で動作するか）に応じて、マルチフォームです。たとえば、「パケット」は、コーディングミドルウェアがアプリケーションとUDPの間に配置されているため、UDPペイロードとして伝送されるデータユニットの場合があります。別の構成では、コーディングはオーバーレイネットワーク内で適用され、「パケット」の概念はまったく異なります。いずれの場合でも、ネットワークコーディングの目標は、ネットワークのスループット、効率、待ち時間、およびスケーラビリティを改善すること、およびパーティション、攻撃、盗聴に対する回復力を提供することです（NWCRG憲章）。このドキュメントでは、エンドツーエンドコーディングと、中間転送ノード内で再コーディングも実行するシステムの両方について検討します。
This document does not consider physical-layer transmission issues, physical-layer codes, or error detection: if low-layer error codes detect but fail to correct bit errors, or if an upper-layer checksum (e.g., within IP or UDP) identifies a corrupted packet, then the packet is supposed to be dropped.
このドキュメントでは、物理層伝送の問題、物理層コード、またはエラー検出については考慮していません。低層エラーコードがビットエラーを検出しても訂正できない場合、または上位層のチェックサム（IPまたはUDP内など）で識別される場合破損したパケットの場合、そのパケットはドロップされるはずです。
This section provides general definitions and concepts that are used throughout this document.
このセクションでは、このドキュメント全体で使用される一般的な定義と概念について説明します。
Packet Erasure Channel: A communication path where packets are either dropped or received without any error. This type of packet drop is referred to as an "erasure" or "loss". The term "channel" must be understood as a generic term for any type of communication technology (e.g., an Ethernet link, a WiFi network, or a full path between two nodes over the Internet). As opposed to the "Erasure" channels, "Error" channels are where one or multiple bit errors may happen during a packet transmission. These "Error" channels are out of scope.
パケット消去チャネル：エラーなしでパケットがドロップまたは受信される通信パス。このタイプのパケットドロップは、「消失」または「損失」と呼ばれます。 「チャネル」という用語は、あらゆるタイプの通信技術（イーサネットリンク、WiFiネットワーク、インターネット上の2つのノード間のフルパスなど）の総称として理解する必要があります。 「消去」チャネルとは対照的に、「エラー」チャネルは、パケット伝送中に1つまたは複数のビットエラーが発生する可能性がある場所です。これらの「エラー」チャネルは範囲外です。
Erasure Correcting Code (ECC) or (IETF) Forward Erasure Correction (FEC): A code for the Packet Erasure Channel (only). These codes are also called "Application-Level FECs" to highlight that they have been designed for use within the higher layers of the protocol stack to protect against packet losses. As opposed to ECCs/FECs, "Error" correction codes are capable of identifying the presence of bit errors and perhaps correcting them. The "Error" correction codes are out of scope.
消失訂正コード（ECC）または（IETF）前方消失訂正（FEC）：パケット消失チャネル（のみ）のコード。これらのコードは、「アプリケーションレベルのFEC」とも呼ばれ、パケット損失から保護するためにプロトコルスタックの上位層内で使用するように設計されていることを強調しています。 ECC / FECとは対照的に、「エラー」訂正コードは、ビットエラーの存在を識別し、おそらくそれらを訂正することができます。 「エラー」修正コードは範囲外です。
End-to-End Coding: A system where coding is performed at the source or (coding) middlebox, and decoding is performed at the destination(s) or (decoding) middlebox. There is no recoding operation at intermediate nodes. This is the approach followed in the FLUTE/ALC [RFC6726] [RFC5775], NORM [RFC5740], and FECFRAME [RFC6363] protocols.
エンドツーエンドコーディング：ソースまたは（コーディング）ミドルボックスでコーディングが実行され、デスティネーションまたは（デコーディング）ミドルボックスでデコードが実行されるシステム。中間ノードでの再コーディング操作はありません。これは、FLUTE / ALC [RFC6726] [RFC5775]、NORM [RFC5740]、およびFECFRAME [RFC6363]プロトコルで採用されているアプローチです。
Network Coding: A system where coding can be performed at the source as well as at intermediate forwarding nodes (all or a subset of them). End-to-End Coding is regarded as a special case of Network Coding. Depending on the use case, additional assumptions can be made: for instance, the destination knowing the Coding Nodes' topology and coding operations can help during decoding operations.
ネットワークコーディング：ソースと中間転送ノード（それらのすべてまたは一部）でコーディングを実行できるシステム。エンドツーエンドコーディングは、ネットワークコーディングの特殊なケースと見なされます。ユースケースに応じて、追加の仮定を行うことができます。たとえば、宛先は、コーディングノードのトポロジとコーディング操作を知っているため、デコード操作中に役立ちます。
Packet versus Symbol: Generally speaking, a Packet is the unit of data that is sent in the Packet Erasure Channel, while a Symbol is the unit of data that is manipulated during the encoding and decoding operations.
パケットとシンボル：一般的に言えば、パケットはパケット消去チャネルで送信されるデータの単位であり、シンボルはエンコードおよびデコード操作中に操作されるデータの単位です。
Original Payload, Uncoded Payload, Systematic Symbol, or (IETF) Source Symbol: A unit of data originating from the source that is used as input to encoding operations.
オリジナルのペイロード、コード化されていないペイロード、システマティックシンボル、または（IETF）ソースシンボル：エンコード操作への入力として使用されるソースからのデータの単位。
Coded Payload, Coded Symbol, or (IETF) Repair Symbol: A unit of data that is the result of a coding operation, applied either to Source Symbols or (in case of recoding) Source and/or Repair Symbols. When there is a single Repair Symbol per Repair Packet, a Repair Symbol corresponds to a Repair Packet.
コード化されたペイロード、コード化されたシンボル、または（IETF）修復シンボル：コード化操作の結果であるデータの単位。ソースシンボルまたは（再コーディングの場合）ソースおよび/または修復シンボルに適用されます。修復パケットごとに単一の修復シンボルがある場合、修復シンボルは修復パケットに対応します。
Input Symbol and Output Symbol: A unit of data that is used as input to an encoding operation or that is generated as output of an encoding operation. At a recoding node, Repair Symbols are also part of the Input Symbols. With Systematic Coding, Source Symbols are also part of the Output Symbols.
入力シンボルと出力シンボル：エンコード操作への入力として使用される、またはエンコード操作の出力として生成されるデータの単位。記録ノードでは、修復記号も入力記号の一部です。系統的コーディングでは、ソースシンボルも出力シンボルの一部です。
(IETF) Encoding Symbol: A Source or a Repair Symbol.
（IETF）エンコーディングシンボル：ソースまたは修復シンボル。
(En)coding versus Recoding versus Decoding: (En)coding is an operation that takes Source Symbols as input and produces Encoding Symbols as output. Recoding is an operation that takes Encoding Symbols as input and produces Encoding Symbols as output. Decoding is an operation takes Encoding Symbols as input and produces Source Symbols as output.
（エンコード）対再コーディング対デコード：（エンコード）は、ソースシンボルを入力として受け取り、エンコードシンボルを出力として生成する操作です。再コーディングは、エンコーディングシンボルを入力として受け取り、エンコーディングシンボルを出力として生成する操作です。デコードは、エンコードシンボルを入力として受け取り、ソースシンボルを出力として生成する操作です。
(IETF) Source Packet: A packet originating from the source that contributes to one or more Source Symbols. For instance, an RTP packet as a whole can constitute a Source Symbol. In other situations (e.g., to address variable size packets), a single RTP packet may contribute to various Source Symbols.
（IETF）ソースパケット：1つ以上のソースシンボルに寄与するソースから発信されたパケット。たとえば、RTPパケットは全体としてソースシンボルを構成できます。他の状況では（たとえば、可変サイズのパケットをアドレス指定するため）、単一のRTPパケットがさまざまなソースシンボルに寄与する場合があります。
(IETF) Repair Packet: A packet containing one or more Repair Symbols.
（IETF）修復パケット：1つ以上の修復シンボルを含むパケット。
Figure 1 illustrates the relationships between packets (what is sent in the Packet Erasure Channel) and symbols (what is manipulated during encoding and decoding operations) in case of a Systematic Coding at a Coding Node that performs Encoding (rather than Recoding). FEC decoding procedures are similarly performed in the reverse order.
図1は、（再コード化ではなく）エンコードを実行するコーディングノードでの体系的コーディングの場合のパケット（パケット消去チャネルで送信されるもの）とシンボル（エンコードおよびデコード操作中に操作されるもの）の関係を示しています。 FECデコード手順は、逆の順序で同様に実行されます。
Source Packet
|
| Source Packet to Source Symbols transform
| (one or more symbols per packet)
v
Source Symbols
|
v Input Symbols
+----------------------+
| FEC encoding |
+----------------------+
| Output Symbols |
v v
Source Symbols Repair Symbols
| |
| | symbol-to-packet transform
| | (one or more symbols per packet)
v v
Source Packet Repair Packet
Figure 1: Packet and Symbol Relationships at a Coding Node That Performs Encoding (Rather Than Recoding)
図1：エンコードではなく（エンコードではなく）コーディングノードでのパケットとシンボルの関係
Source Node: A node that generates one or more Source Flows.
ソースノード：1つ以上のソースフローを生成するノード。
Coding Node: A node that performs FEC Encoding or Recoding operations. It may be an end host or a middlebox (Encoding case), or a forwarding node (Recoding case).
コーディングノード：FECエンコーディングまたはレコーディング操作を実行するノード。エンドホストまたはミドルボックス（エンコードの場合）、または転送ノード（エンコードの場合）の場合があります。
(IETF) Flow: A stream of packets logically grouped.
（IETF）フロー：論理的にグループ化されたパケットのストリーム。
(IETF) Source Flow: A flow of Source Packets coming from an application on a given host and to which FEC encoding is to be applied, potentially along with other Source Flows. Depending on the use case, Source Flows may come from the same application, from different applications on the same host, or from different applications on different hosts.
（IETF）ソースフロー：特定のホスト上のアプリケーションから送信され、FECエンコーディングが適用されるソースパケットのフロー。他のソースフローと一緒になる可能性があります。ユースケースに応じて、ソースフローは、同じアプリケーション、同じホストの異なるアプリケーション、または異なるホストの異なるアプリケーションに由来する場合があります。
(IETF) Repair Flow: A flow containing Repair Packets after FEC encoding.
（IETF）修復フロー：FECエンコード後の修復パケットを含むフロー。
This section discusses the various ways of using coding, without going into coding details.
このセクションでは、コーディングの詳細に触れずに、コーディングのさまざまな使用方法について説明します。
Source Coding versus Channel Coding: (see Figure 2) When both terms are used, "Source Coding" usually refers to compression techniques (e.g., audio and video compression) within the upper application that generates the Source Flow. "Channel Coding" refers to FEC encoding in order to improve transmission robustness, for instance, within the lower physical layer (out of scope of this document) or as part of Network Coding. These terms should not be confused with "FEC coding within the Source Node" and "FEC recoding within an intermediate Coding Node", respectively.
ソースコーディングとチャネルコーディング：（図2を参照）両方の用語を使用する場合、「ソースコーディング」は通常、ソースフローを生成する上位アプリケーション内の圧縮技術（オーディオやビデオの圧縮など）を指します。 「チャネルコーディング」とは、送信の堅牢性を向上させるためのFECエンコーディングを指します。たとえば、下位の物理層内（このドキュメントの範囲外）、またはネットワークコーディングの一部として。これらの用語を、それぞれ「ソースノード内のFECコーディング」および「中間コーディングノード内のFEC再コーディング」と混同しないでください。
raw data flow from camera ^ video flow display
| | ^
v | upper |
+------------------------+ | +-------------------------+
| source coding | | applica- | source (de)coding |
|(e.g., mpeg compression)| | tion |(e.g., mpg decompression)|
+------------------------+ v +-------------------------+
| ^
v |
+------------------------+ ^ +-------------------------+
| network/AL-FEC coding | | middle- | network/AL-FEC coding |
| (e.g., RLC encoding) | | ware | (e.g., RLC decoding) |
+------------------------+ v +-------------------------+
| ^
v |
+------------------------+ ^ +-------------------------+
| packetization | | | depacketization |
| (e.g., UDP/IP) | | communi- | (e.g., UDP/IP) |
+------------------------+ | cation +-------------------------+
| | ^
v | layers |
+-----------------------+ | +-------------------------+
| PHY layer | | | PHY layer |
| (channel coding) | | | (channel decoding) |
+-----------------------+ v +-------------------------+
| ^
| source + repair traffic |
+-----------------------------------------+
Figure 2: Example of End-to-End Flow Manipulation with Network Coding
図2：ネットワークコーディングによるエンドツーエンドフロー操作の例
Figure 2 shows Network Coding between the application and UDP layers (as with RMT or FECFRAME architectures). Other architectures are possible, for instance, with Network Coding below the transport layer to allow recoding within the network.
図2は、アプリケーション層とUDP層の間のネットワークコーディングを示しています（RMTまたはFECFRAMEアーキテクチャーと同様）。たとえば、トランスポート層の下にネットワークコーディングを使用して、ネットワーク内での再コーディングを可能にする他のアーキテクチャも可能です。
Intra-Flow Coding or Single-Source Network Coding: Process where incoming packets to the Coding Node belong to the same flow.
フロー内コーディングまたは単一ソースネットワークコーディング：コーディングノードへの着信パケットが同じフローに属するプロセス。
Inter-Flow Coding or Multi-Source Network Coding: Process where incoming packets to the Coding Node belong to different flows.
フロー間コーディングまたはマルチソースネットワークコーディング：コーディングノードへの着信パケットが異なるフローに属するプロセス。
Single-Path Coding: Network Coding over a route that has a single path from the source to each destination(s). In case of multicast or broadcast traffic, this route is a tree. Coding may be done end to end and/or at intermediate forwarding nodes.
単一パスコーディング：送信元から各宛先への単一パスを持つルート上のネットワークコーディング。マルチキャストまたはブロードキャストトラフィックの場合、このルートはツリーです。コーディングはエンドツーエンドで、および/または中間転送ノードで行うことができます。
Multi-Path Coding: Network Coding over a route that has multiple (at least partially) disjoint paths from the source to each given destination. Coding may be done end to end and/or at intermediate forwarding nodes.
マルチパスコーディング：送信元から特定の各宛先への複数の（少なくとも部分的に）ばらばらのパスを持つルート上のネットワークコーディング。コーディングはエンドツーエンドで、および/または中間転送ノードで行うことができます。
This section provides a high-level taxonomy of coding techniques. Technical details are discussed in subsequent sections.
このセクションでは、コーディング技法の高レベルの分類法について説明します。技術的な詳細については、後続のセクションで説明します。
Linear Coding: Linear combination of a set of Input Symbols (i.e., Source and/or Repair Symbols) using a given set of coefficients and resulting in a Repair Symbol. Many linear codes exist that differ from the way coding coefficients are drawn from a Finite Field of a given size.
線形コーディング：与えられた係数のセットを使用して入力シンボルのセット（つまり、ソースおよび/または修復シンボル）を線形結合し、修復シンボルを生成します。与えられたサイズの有限体からコード化係数が引き出される方法とは異なる多くの線形コードが存在します。
Random Linear Coding (RLC): Particular case of Linear Coding using a set of random coding coefficients.
ランダムリニアコーディング（RLC）：一連のランダムコーディング係数を使用したリニアコーディングの特定のケース。
Adaptive Linear Coding: Linear Coding that utilizes cross-layer adaptation. For instance, an adaptive coding scheme may adapt the generation and transmission of Repair Packets according to the channel variations over time, accounting for the predictive loss of degrees of freedom due to erasures.
適応線形コーディング：クロスレイヤー適応を利用する線形コーディング。例えば、適応コーディングスキームは、時間の経過に伴うチャネル変動に従って修復パケットの生成および送信を適合させ、消去による自由度の予測的損失を考慮に入れてもよい。
Block Coding: Coding technique where the input Flow(s) must first be segmented into a sequence of blocks; FEC encoding and decoding are performed independently on a per-block basis. The term "Chunk Coding" is sometimes used, where a "Chunk" denotes a block.
ブロックコーディング：入力フローを最初に一連のブロックにセグメント化する必要があるコーディング手法。 FECエンコードとデコードは、ブロックごとに独立して実行されます。 「チャンクコーディング」という用語が時々使用されます。「チャンク」はブロックを示します。
Sliding Window Coding or Convolutional Coding: General class of coding techniques that rely on a sliding encoding window. This is an alternative solution to Block Coding.
スライディングウィンドウコーディングまたは畳み込みコーディング：スライディングエンコーディングウィンドウに依存するコーディングテクニックの一般的なクラス。これは、ブロックコーディングの代替ソリューションです。
Fixed or Elastic Sliding Window Coding: Coding technique that generates Repair Symbol(s) on the fly, from the set of Source Symbols present in the sliding encoding window at that time, usually by using Linear Coding. The sliding window may be either of fixed size or of variable size over the time (also known as "Elastic Sliding Window"). For instance, the size may depend on acknowledgments sent by the receiver(s) for a particular Source Symbol or Source Packet (received, decoded, or decodable).
固定または弾性スライディングウィンドウコーディング：通常は線形コーディングを使用して、その時点でスライディングエンコーディングウィンドウに存在するソースシンボルのセットから修復シンボルをその場で生成するコーディング手法。スライディングウィンドウは、固定サイズまたは時間の経過とともに可変サイズになります（「弾性スライディングウィンドウ」とも呼ばれます）。たとえば、サイズは、特定のソースシンボルまたはソースパケット（受信、デコード、またはデコード可能）について受信者が送信した確認応答に依存する場合があります。
Systematic Coding: A coding technique where Source Symbols are part of the output Flow generated by a Coding Node.
体系的コーディング：ソースシンボルがコーディングノードによって生成される出力フローの一部であるコーディング手法。
Rateless and Non-rateless Coding: Rateless Coding can generate an unlimited number of Repair Symbols (in practice, this number can be limited by practical considerations or because of use-case requirements) from a given set of Source Symbols, meaning that the code rate is null. RLC codes are an example of Rateless Codes. Alternately, Non-rateless Coding usually has a predefined maximum number of Repair Symbols that can be generated from a given set of Source Symbols.
レートレスおよび非レートレスコーディング：レートレスコーディングは、特定のソースシンボルのセットから無制限の数の修復シンボルを生成できます（実際には、この数は実際の考慮事項によって、またはユースケース要件のために制限される場合があります）。つまり、コードレート無効です。 RLCコードは、レートレスコードの例です。あるいは、非レートレスコーディングには通常、所定のソースシンボルのセットから生成できる事前定義された最大数の修復シンボルがあります。
This section discusses and defines low-level coding aspects.
このセクションでは、低レベルのコーディングの側面について説明し、定義します。
Code Rate: In case of a Block Code, the Code Rate is the k/n ratio between the number of Source Symbols, k, and the number of Source plus Repair Symbols, n. With a Sliding Window Code, the Code Rate is defined similarly over a certain time interval, since the Code Rate may change dynamically. 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 and vice versa.
コードレート：ブロックコードの場合、コードレートはソースシンボルの数kとソースと修復シンボルの数nの間のk / n比です。スライディングウィンドウコードでは、コードレートが動的に変化する可能性があるため、コードレートは一定の時間間隔で同様に定義されます。定義により、コードレートは次のようになります。0 <コードレート<=1。1に近いコードレートは、エンコードプロセス中に少数の修復シンボルが生成されたことを示し、その逆も同様です。
(En)coding Window: A set of Source (and Repair in the case of recoding) Symbols used as input to the coding operations. The set of symbols will typically change over time, as the Coding Window slides over the input Flow(s).
（En）コーディングウィンドウ：コーディング操作への入力として使用される一連のソース（および再コーディングの場合は修復）シンボル。コーディングウィンドウは入力フロー上をスライドするため、通常、一連のシンボルは時間とともに変化します。
(En)coding Window Size: The number of Source (and Repair in case of recoding) Symbols in the current Encoding Window. This size may change over the time.
（En）コーディングウィンドウサイズ：現在のエンコーディングウィンドウ内のソース（および再コーディングの場合は修復）シンボルの数。このサイズは時間とともに変化する可能性があります。
Payload Set: The set of Source and Repair Symbols available (i.e., received or previously decoded) at the receiver and used during FEC decoding operations.
ペイロードセット：受信側で利用可能（つまり、受信済みまたは以前にデコード済み）で、FECデコード操作中に使用されるソースおよび修復シンボルのセット。
Decoding Window: The set of Source Symbols (only) that are considered in the current linear system of a receiver, independently of the fact these Source Symbols have been received, decoded, or lost. The Decoding Window will typically change over time, as transmissions and decoding progress, and may be different for different receivers of a session where content is multicast or broadcast.
Decoding Window：これらのソースシンボルが受信、デコード、または失われたという事実とは関係なく、レシーバーの現在の線形システムで考慮されるソースシンボルのセット（のみ）。デコードウィンドウは、通常、送信とデコードが進むにつれて時間とともに変化し、コンテンツがマルチキャストまたはブロードキャストされるセッションの受信者によって異なる場合があります。
Decoding Window Size: The number of Source Symbols (only) in the current Decoding Window. This size may change over time.
デコードウィンドウサイズ：現在のデコードウィンドウ内のソースシンボル（のみ）の数。このサイズは時間とともに変化する可能性があります。
Rank of a Payload Set or Rank of the Linear System: At a receiver, number of linearly independent members of a Payload Set, or equivalently the number of linearly independent equations of the linear system. It is also known as "Degrees of Freedom". The system may be of "full rank" where decoding is possible or "partial rank" where only partial decoding is possible.
ペイロードセットのランクまたは線形システムのランク：受信側で、ペイロードセットの線形独立メンバーの数、または同等に線形システムの線形独立方程式の数。 「自由度」としても知られています。システムは、復号化が可能な「フルランク」、または部分的な復号化のみが可能な「パーシャルランク」のシステムであってもよい。
Seen Payload or Seen Symbol: A Source Symbol is Seen when the receiver can compute a linear combination with this symbol and Source Symbols that are strictly more recent (i.e., with logically higher Encoding Symbol Identifiers). Otherwise, the Source Symbol is considered as "Unseen".
Seen PayloadまたはSeen Symbol：ソースシンボルは、レシーバーがこのシンボルと厳密に新しい（つまり、論理的に高いエンコーディングシンボルIDを持つ）ソースシンボルとの線形結合を計算できるときに見られます。それ以外の場合、ソースシンボルは「見えない」と見なされます。
Generation or (IETF) Block: With Block Codes, the set of Source Symbols of the input Flow(s) that are logically grouped into a Block, before doing encoding.
生成または（IETF）ブロック：エンコードを実行する前に、ブロックコードを使用して、論理的にブロックにグループ化される入力フローのソースシンボルのセット。
Generation Size, Code Dimension, or (IETF) Block Size: With Block Codes, the number of Source Symbols, k, belonging to a Block.
生成サイズ、コード次元、または（IETF）ブロックサイズ：ブロックコードでは、ブロックに属するソースシンボルの数k。
Coding Matrix or Generator Matrix: A matrix G that transforms the set of Input Symbols X into a set of Repair Symbols: Y = X * G. Defining a Generator Matrix is typical with Block Codes. The set of Input Symbols X can consist only of Source Symbols (e.g., with End-to-End Coding) or can consist of Source and Repair Symbols (e.g., with recoding in an intermediate node).
コーディングマトリックスまたはジェネレーターマトリックス：入力シンボルXのセットを修復シンボルのセットに変換するマトリックスG：Y = X *G。ジェネレーターマトリックスの定義は、ブロックコードでは一般的です。入力シンボルXのセットは、ソースシンボルのみ（例：エンドツーエンドコーディング）またはソースシンボルと修復シンボル（例：中間ノードでの再コーディング）で構成できます。
Coding Coefficient: With Linear Coding, this is a coefficient in a certain Finite Field. This coefficient may be chosen in different ways: for instance, randomly, in a predefined table, or using a predefined algorithm plus a seed.
コーディング係数：線形コーディングでは、これは特定の有限体の係数です。この係数は、さまざまな方法で選択できます。たとえば、ランダムに、定義済みのテーブルで、または定義済みのアルゴリズムとシードを使用して選択できます。
Coding Vector: A set of Coding Coefficients used to generate a certain Repair Symbol through Linear Coding. The number of nonzero coefficients in the Coding Vector defines its density.
コーディングベクトル：線形コーディングを通じて特定の修復シンボルを生成するために使用されるコーディング係数のセット。コーディングベクトルの非ゼロ係数の数は、その密度を定義します。
Finite Field, Galois Field, or Coding Field: Finite Fields, used in Linear Codes, have the desired property of having all elements (except zero) invertible for the + and * operators, and all operations over any elements do not result in an overflow or underflow. Examples of Finite Fields are prime fields {0..p^m-1}, where p is prime. The most used fields use p=2 and are called binary extension fields {0..2^m-1}, where m often equals 1, 4, or 8 for practical reasons.
有限体、ガロア体、または符号化体：線形符号で使用される有限体には、+および*演算子に対してすべての要素（ゼロを除く）を反転可能にするという望ましい特性があり、要素に対するすべての演算でオーバーフローは発生しませんまたはアンダーフロー。有限体の例は、素数体{0..p ^ m-1}です。ここで、pは素数です。最も使用されるフィールドはp = 2を使用し、バイナリ拡張フィールド{0..2 ^ m-1}と呼ばれます。mは実際上の理由で1、4、または8に等しいことがよくあります。
Finite Field size or Coding Field size: The number of elements in a Finite Field. For example, the binary extension field {0..2^m-1} has size q=2^m.
有限フィールドサイズまたはコーディングフィールドサイズ：有限フィールドの要素数。たとえば、バイナリ拡張フィールド{0..2 ^ m-1}のサイズはq = 2 ^ mです。
Feedback: Feedback information sent by a decoding node to a Coding Node (or from a receiver to a source in case of End-to-End Coding). The nature of information contained in a feedback packet varies, depending on the use case. It can provide reception and/or FEC decoding statistics, the list of available Source Packets received or decoded (acknowledgement), the list of lost Source Packets that should be retransmitted (negative acknowledgement), or a number of additional Repair Symbols needed to have a Full Rank Linear System.
フィードバック：デコードノードによってコーディングノードに送信されたフィードバック情報（エンドツーエンドコーディングの場合はレシーバーからソースに送信されます）。フィードバックパケットに含まれる情報の性質は、ユースケースによって異なります。受信および/またはFECデコード統計、受信またはデコードされた使用可能なソースパケットのリスト（確認）、再送信する必要のある失われたソースパケットのリスト（否定確認）、またはフルランク線形システム。
This section discusses practical aspects. Indeed, a practical solution must specify the exact manner in which encoding and decoding are performed but also detail all the peripheral aspects, for instance, how an encoder informs a decoder about the parameters used to generate a certain Repair Packet (signaling).
このセクションでは、実用的な側面について説明します。実際、実用的なソリューションでは、エンコードとデコードを実行する正確な方法を指定するだけでなく、周辺機器のすべての側面、たとえばエンコーダーがデコーダーに特定の修復パケット（シグナリング）を生成するために使用されるパラメーターについて通知する方法を指定する必要があります。
(IETF) FEC Scheme: A specification that defines a particular FEC code as well as the additional protocol aspects required to use this FEC code. In particular, the FEC Scheme defines in-band (e.g., information contained in Source and Repair Packet header or trailers) and out-of-band (e.g., information contained in an SDP description) signaling needed to synchronize encoders and decoders.
（IETF）FECスキーム：特定のFECコードと、このFECコードを使用するために必要な追加のプロトコルの側面を定義する仕様。特に、FECスキームは、エンコーダーとデコーダーを同期するために必要なインバンド（たとえば、ソースおよび修復パケットのヘッダーまたはトレーラーに含まれる情報）とアウトオブバンド（たとえば、SDP記述に含まれる情報）のシグナリングを定義します。
Payload Index or (IETF) Encoding Symbol Identifier (ESI): An identifier of a Source or Repair Symbol. With Block Coding, each symbol of a given block is identified by a unique ESI value. With Sliding Window Coding, a continuous Source Flow and a limited field size to hold the ESI, wrapping to zero is unavoidable and the same integer value will be reused several times.
ペイロードインデックスまたは（IETF）エンコーディングシンボル識別子（ESI）：ソースまたは修復シンボルの識別子。ブロックコーディングでは、特定のブロックの各シンボルが一意のESI値によって識別されます。スライディングウィンドウコーディング、連続的なソースフロー、およびESIを保持するための制限されたフィールドサイズでは、ゼロへのラップは避けられず、同じ整数値が何度か再利用されます。
(IETF) FEC Payload ID: Information that identifies the contents of a packet with respect to the FEC Scheme. The FEC Payload ID of a packet containing Source Symbol(s) is usually different from that of a packet containing Repair Symbol(s). The FEC Payload ID typically contains at least an ESI.
（IETF）FECペイロードID：FECスキームに関してパケットの内容を識別する情報。ソースシンボルを含むパケットのFECペイロードIDは、通常、修復シンボルを含むパケットのFECペイロードIDとは異なります。 FECペイロードIDには通常、少なくともESIが含まれています。
Coding Vector and Encoding Window Signaling: With Sliding Window Codes, the FEC Payload ID of a Repair Packet contains information needed and sufficient to identify the Coding Vector and Coding Window. Concerning the Coding Vector, this may consist of a full list of Coding Coefficients (that may or may not be compressed), or a piece of information (e.g., a seed) that can be used to generate the list of Coding Coefficients thanks to a predefined algorithm known by encoders and decoders (e.g., a Pseudorandom Number Generator, or PRNG) or an ESI that points to a given entry in a Generator Matrix in case of a Block Code. Concerning the Coding Window, this may consist of the full list of ESI of symbols in the Coding Window (that may or may not be compressed) or the ESI of the first Source Symbol along with their number (assuming there is no gap).
コーディングベクトルとエンコーディングウィンドウシグナリング：スライディングウィンドウコードでは、修復パケットのFECペイロードIDに、コーディングベクトルとコーディングウィンドウを識別するために必要かつ十分な情報が含まれています。コーディングベクトルに関して、これは、コーディング係数の完全なリスト（圧縮されている場合とされていない場合があります）、またはのおかげでコーディング係数のリストを生成するために使用できる情報（シードなど）で構成される場合があります。エンコーダーとデコーダー（例：疑似乱数ジェネレーター、PRNG）またはブロックコードの場合はジェネレーターマトリックスの特定のエントリを指すESIによって既知の定義済みアルゴリズム。コーディングウィンドウに関しては、これは、コーディングウィンドウ内のシンボルのESIの完全なリスト（圧縮されている場合とされていない場合があります）、または最初のソースシンボルのESIとその番号（ギャップがない場合）で構成されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document introduces a recommended terminology for Network Coding and therefore does not contain any security considerations. This does not mean that Network Coding systems do not have any security implication.
このドキュメントでは、ネットワークコーディングの推奨用語を紹介しているため、セキュリティに関する考慮事項は含まれていません。これは、ネットワークコーディングシステムがセキュリティに影響を与えないという意味ではありません。
[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>。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, <https://www.rfc-editor.org/info/rfc5740>.
[RFC5740] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「NACK-Oriented Reliable Multicast（NORM）Transport Protocol」、RFC 5740、DOI 10.17487 / RFC5740、2009年11月、<https： //www.rfc-editor.org/info/rfc5740>。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, <https://www.rfc-editor.org/info/rfc5775>.
[RFC5775] Luby、M.、Watson、M。、およびL. Vicisano、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 5775、DOI 10.17487 / RFC5775、2010年4月、<https：//www.rfc-editor .org / info / rfc5775>。
[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>。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/info/rfc6726>.
[RFC6726] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「FLUTE-単一方向トランスポートを介したファイル配信」、RFC 6726、DOI 10.17487 / RFC6726、2012年11月、< https://www.rfc-editor.org/info/rfc6726>。
Authors' Addresses
著者のアドレス
Brian Adamson NRL United States of America
ブライアンアダムソンNRLアメリカ合衆国
Email: brian.adamson@nrl.navy.mil
Cedric Adjih INRIA France
セドリックアディINRIAフランス
Email: cedric.adjih@inria.fr
Josu Bilbao Ikerlan Spain
ジョスビルバオイケルランスペイン
Email: jbilbao@ikerlan.es
Victor Firoiu BAE Systems United States of America
Victor Firoiu BAE Systemsアメリカ合衆国
Email: victor.firoiu@baesystems.com
Frank Fitzek TU Dresden Germany
フランクフィツェクTUドレスデンドイツ
Email: frank.fitzek@tu-dresden.de
Samah A. M. Ghanem Independent
サマーA. M.ガネム独立
Email: samah.ghanem@gmail.com
Emmanuel Lochin ISAE - Supaero France
Emmanuel Lochin ISAE-Supaero France
Email: emmanuel.lochin@isae-supaero.fr Antonia Masucci Orange France
メール：emmanuel.lochin@isae-supaero.fr Antonia Masucci Orange France
Email: antoniamaria.masucci@orange.com
Marie-Jose Montpetit Independent United States of America
マリーホセモンプティインディペンデントアメリカ合衆国
Email: marie@mjmontpetit.com
Morten V. Pedersen Aalborg University Denmark
Morten V. Pedersenオールボー大学デンマーク
Email: mvp@es.aau.dk
Goiuri Peralta Ikerlan Spain
Goiuriペラルタイケルランスペイン
Email: gperalta@ikerlan.es
Vincent Roca (editor) INRIA France
ヴィンセントロカ（編集者）INRIAフランス
Email: vincent.roca@inria.fr
Paresh Saxena AnsuR Technologies Norway
Paresh Saxena AnsuR Technologiesノルウェー
Email: paresh.saxena@ansur.es
Senthil Sivakumar Cisco United States of America
Senthil Sivakumar Ciscoアメリカ合衆国
Email: ssenthil@cisco.com