[要約] RFC 4410は、セレクティブリリアブルマルチキャストプロトコル（SRMP）に関するものであり、信頼性のあるマルチキャスト通信を実現するためのプロトコルです。SRMPの目的は、ネットワーク上でのデータの効率的な配信と信頼性の向上です。
Network Working Group M. Pullen
Request for Comments: 4410 F. Zhao
Category: Experimental George Mason Univ
D. Cohen
Sun Microsystems
February 2006
Selectively Reliable Multicast Protocol (SRMP)
選択的に信頼性の高いマルチキャストプロトコル（SRMP）
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application.
選択的に信頼性の高いマルチキャストプロトコル（SRMP）は、信頼できるトラフィックよりも有効なトラフィックが大幅に多いマルチキャスト環境で信頼性の高いベストエフォートメッセージの組み合わせを提供することを目的としたトランスポートプロトコルです。したがって、損失検出のための信頼できるメッセージのシーケンス番号を運ぶことができます。SRMPは、分散シミュレーションアプリケーション環境で使用することを目的としています。特定のデータ識別子の信頼できる伝送の最新値のみが配信を必要とします。SRMPには2つのサブレイヤーがあります。メッセージの集計と輻輳制御のバンドリングサブレイヤーハンドリングコントロールと、選択的に信頼性の高い輸送（SRT）サブレイヤーです。信頼できるエフォルトメッセージとベストエフォルトメッセージの選択は、アプリケーションによって実行されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Protocol Description ............................................4
3. Message Formats .................................................6
3.1. Bundle Message Format: .....................................6
3.2. Bundle Header Format .......................................7
3.3. Feedback Message Format ....................................9
3.4. SRT Mode 0 Header Format ..................................10
3.5. SRT Mode 1 Header Format ..................................11
3.6. SRT Mode 2 Header Format ..................................11
3.7. SRT NACK Format ...........................................12
3.8. User-Configurable Parameters ..............................13
4. TFMCC Operation ................................................13
4.1. TCP Rate Prediction Equation for TFMCC ....................13
4.2. Bundling ..................................................13
4.3. Congestion Control ........................................14
4.4. Any-Source Multicast ......................................14
4.5. Multiple Sources ..........................................14
4.6. Bundle Size ...............................................15
4.7. Data Rate Control .........................................15
4.8. Mode 1 Loss Detection .....................................16
4.8.1. Sending a Negative Acknowledgement .................16
4.9. Unbundling ................................................17
4.10. Heartbeat Bundle .........................................17
5. SRT Operation ..................................................17
5.1. Mode 0 Operation ..........................................18
5.1.1. Sending Mode 0 Messages ............................18
5.1.2. Receiving Mode 0 Messages ..........................18
5.2. Mode 1 Operation ..........................................18
5.2.1. Sending Mode 1 Data Messages .......................19
5.2.2. Receiving Mode 1 Data Messages .....................19
5.2.3. Sending a Negative Acknowledgement .................20
5.2.4. Receiving a Negative Acknowledgement ...............21
5.3. Mode 2 Operation ..........................................21
5.3.1. Sending Mode 2 Data Messages .......................21
5.3.2. Receiving Mode 2 Data Messages .....................22
5.3.3. Sending a Positive Acknowledgement .................23
5.3.4. Receiving a Positive Acknowledgement ...............23
6. RFC 2357 Analysis ..............................................23
6.1. Scalability ...............................................23
6.2. Congestion ................................................24
7. Security Considerations ........................................25
8. List of Acronyms Used ..........................................26
9. Contributions ..................................................27
10. References ....................................................27
There is no viable generic approach to achieving reliable transport over multicast networks. Existing successful approaches require that the transport protocol take advantage of special properties of the traffic in a way originally proposed by Cohen [10]. The protocol described here is applicable to real-time traffic containing a mix of two categories of messages: a small fraction requiring reliable delivery, mixed with a predominating flow of best-effort messages. This sort of traffic is associated with distributed virtual simulation (RFC 2502 [4]) and also with some forms of distributed multimedia conferencing. These applications typically have some data that changes rarely, or not at all, so the best efficiency will be achieved by transmitting that data reliably (the external appearance of a simulated vehicle is an excellent example). They also require real-time transmission of a best-effort stream (for example, the position and orientation of the vehicle). There is no value to reliable transmission of this stream because typically new updates arrive faster than loss identification and retransmission could take place. By piggy-backing the sequence number (SN) of the latest reliable transmission on each bundle of traffic, the reliable and best-effort traffic can co-exist synergistically. This approach is implemented in the Selectively Reliable Multicast Protocol (SRMP).
マルチキャストネットワークを介して信頼できる輸送を達成するための実行可能な一般的なアプローチはありません。既存の成功したアプローチでは、輸送プロトコルがCohen [10]によって最初に提案された方法で、トラフィックの特別な特性を活用する必要があります。ここで説明するプロトコルは、2つのカテゴリのメッセージの組み合わせを含むリアルタイムトラフィックに適用できます。信頼できる配信を必要とする少数の割合で、最高のエフォルトメッセージの主な流れと混合されます。この種のトラフィックは、分散仮想シミュレーション（RFC 2502 [4]）と、分散マルチメディア会議のいくつかの形態に関連付けられています。これらのアプリケーションには通常、めったに変わらない、またはまったく変わらないデータがあるため、そのデータを確実に送信することで最良の効率が達成されます（シミュレートされた車両の外観は優れた例です）。また、ベストエフォルトストリームのリアルタイム送信（たとえば、車両の位置と向き）も必要です。通常、新しいアップデートが損失の識別と再送信が行われるよりも速く到着するため、このストリームの信頼できる送信に価値はありません。トラフィックの各バンドルでの最新の信頼性のあるトランスミッションのシーケンス番号（SN）を貯めることにより、信頼性と最高のエフォルトのトラフィックは相乗的に共存できます。このアプローチは、選択的に信頼性の高いマルチキャストプロトコル（SRMP）に実装されています。
The IETF has conducted a successful working group on Reliable Multicast Transport (RMT) that has produced RFCs 2357 [6], 2887 [11], and 3450 through 3453 [12 - 15], which define building block protocols for reliable multicast. Selectively reliable multicast is similar in spirit to these protocols and in fact uses one of them, TCP-Friendly Multicast Congestion Control (TFMCC). This document provides the basis for specifying SRMP with TFMCC for use on an experimental basis. Key requirements of the RMT process that is carried forward here are specified in RFC 2357 [6]. These generally relate to scalability and congestion control, and are addressed in section 6 of this document.
IETFは、信頼できるマルチキャストのビルディングブロックプロトコルを定義するRFCS 2357 [6]、2887 [11]、および3450から3453 [12-15]を生成した信頼性の高いマルチキャストトランスポート（RMT）に関する成功したワーキンググループを実施しました。選択的に信頼性の高いマルチキャストは、これらのプロトコルとスピリットが類似しており、実際にはTCPフレンドリーマルチキャスト輻輳制御（TFMCC）の1つを使用しています。このドキュメントは、実験ベースで使用するためにTFMCCでSRMPを指定するための基礎を提供します。ここで繰り越されるRMTプロセスの主要な要件は、RFC 2357 [6]で指定されています。これらは一般に、スケーラビリティと輻輳制御に関連しており、このドキュメントのセクション6で説明されています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
The Selectively Reliable Multicast Protocol (SRMP) has two major components: Selectively Reliable Transport (SRT) and a "bundling sublayer" that implements TCP-Friendly Multicast Congestion Control (TFMCC), as proposed by Widmer and Handley [2], in order to meet the requirements of RFC 2357 [6] for congestion avoidance.
選択的に信頼性の高いマルチキャストプロトコル（SRMP）には、2つの主要なコンポーネントがあります。選択的に信頼できる輸送（SRT）と、WidmerとHandley [2]が提案するTCPに優しいマルチキャスト輻輳制御（TFMCC）を実装する「バンドリングサブレイヤー」、混雑回避のためにRFC 2357 [6]の要件を満たします。
SRMP is capable of reliable message delivery over multicast networks, when the messages to be delivered reliably represent a fraction of a larger, associated best-effort flow and only the latest reliable message must be delivered. The basic strategy for SRMP is to trade as little network capacity as possible for reliability by buffering the most recently sent reliable message at each sender and piggy-backing its sequence number on associated best-effort messages. For this purpose, three modes of sending are defined:
SRMPは、配信されるメッセージがより大きく関連するベストエフォートフローの一部を確実に表し、最新の信頼できるメッセージのみを配信する必要がある場合、マルチキャストネットワークよりも信頼できるメッセージ配信が可能です。SRMPの基本的な戦略は、各送信者で最近送信された信頼できるメッセージをバッファリングし、関連するベストエフォートメッセージでシーケンス番号をピギーバッキングすることにより、信頼性のためにできるだけネットワーク容量を取引することです。この目的のために、送信の3つのモードが定義されています。
o Mode 0 messages. These will be delivered best-effort; if lost, no retransmission will be done.
o モード0メッセージ。これらはベストエフォルトが配信されます。紛失した場合、再送信は行われません。
o Mode 1 messages. When a Mode 1 message loss is detected, the receiver will send back a NACK to the sender, where SRMP will retransmit the latest reliable message from that sender. Senders define data identifiers (dataIDs), allowing multiple reliable message streams to be supported. Mode 1 messages may be up to 131,071 bytes long; SRMP provides for segmentation and reassembly, but only for the latest Mode 1 message for any given <sourceAddress, multicastAddress, dataID>.
o モード1メッセージ。モード1メッセージの損失が検出されると、受信者は送信者にNACKを送り返し、SRMPはその送信者からの最新の信頼できるメッセージを再送信します。送信者は、データ識別子（DataID）を定義し、複数の信頼できるメッセージストリームをサポートできるようにします。モード1メッセージの長さは最大131,071バイトです。SRMPは、セグメンテーションと再組み立てを提供しますが、特定の<sourceaddress、multicastAddress、dataId>の最新モード1メッセージのみを提供します。
o Mode 2 messages. Through Mode 2 messages, SRMP provides for a lightweight, reliable, connectionless peer-to-peer unicast transaction exchange between any two members of the multicast group. This is a unicast message requiring positive acknowledgement (ACK).
o モード2メッセージ。モード2メッセージを介して、SRMPは、マルチキャストグループの任意の2つのメンバー間で、軽量で信頼性が高く、コネクションレスピアツーピアユニキャストトランザクション交換を提供します。これは、肯定的な確認（ACK）を必要とするユニキャストメッセージです。
| Application |
----------------- ----------
| SRT |
----------------- -> SRMP
|Bundling(TFMCC)|
----------------- ----------
| UDP |
The bundling sublayer is transparent to the Selectively Reliable Transport (SRT) sublayer. It implements congestion control both by dropping Mode 0 messages at the source when needed and by bundling multiple short messages that are presented by applications within a short time window. It also performs NACK suppression.
バンドリングサブレイヤーは、選択的に信頼性の高い輸送（SRT）サブレイヤーに対して透明です。必要に応じてソースでモード0メッセージをドロップすることと、短い時間ウィンドウ内でアプリケーションによって提示される複数の短いメッセージをバンドすることにより、輻輳制御を実装します。また、NACK抑制も実行します。
A bundling sublayer data unit is called a bundle. A bundle is made up of a bundle header and one or more Mode 0 and Mode 1 SRMP messages. Retransmission of Mode 1 messages does not imply retransmission of the original bundle; the retransmitted message becomes part of a new bundle.
バンドリングサブレイヤーデータユニットはバンドルと呼ばれます。バンドルは、バンドルヘッダーと1つ以上のモード0とモード1 SRMPメッセージで構成されています。モード1メッセージの再送信は、元のバンドルの再送信を意味するものではありません。再送信されたメッセージは、新しいバンドルの一部になります。
The TFMCC layer's behavior follows the mechanism described by Widmer and Handley. This is an equation-based multicast congestion control mechanism: in a multicast group, each receiver determines its loss rate with regard to the sender, and calculates a desired source sending rate based on an equation that models the steady-state sending rate of TCP. A distributed feedback suppression mechanism restricts feedback to those receivers likely to report the lowest desired rates. Congestion control is achieved by dropping best-effort (Mode 0) messages at random. For example, in distributed simulation, Mode 0 messages are part of a stream of state updates for dynamic data such as geographic location; therefore, the application can continue to function (with lower fidelity) when they are dropped.
TFMCCレイヤーの動作は、WidmerとHandleyによって記述されたメカニズムに従います。これは方程式ベースのマルチキャスト輻輳制御メカニズムです。マルチキャストグループでは、各受信機が送信者に関する損失率を決定し、TCPの定常状態送信率をモデル化する方程式に基づいて目的のソース送信率を計算します。分散型フィードバック抑制メカニズムは、最低の希望するレートを報告する可能性のある受信機へのフィードバックを制限します。輻輳制御は、ランダムにBest-Effort（モード0）メッセージをドロップすることで実現されます。たとえば、分散シミュレーションでは、モード0メッセージは、地理的位置などの動的データの状態更新のストリームの一部です。したがって、アプリケーションは、ドロップされたときに（忠実度が低い）機能し続けることができます。
As described by its authors, TFMCC's congestion control mechanism works as follows:
著者によって説明されているように、TFMCCの混雑制御メカニズムは次のように機能します。
o Each receiver measures the loss event rate and its Round-Trip Time (RTT) to the sender.
o 各受信者は、損失イベント率とその往復時間（RTT）を送信者に測定します。
o Each receiver then uses this information, together with an equation for TCP throughput, to derive a TCP-friendly sending rate.
o 次に、各レシーバーは、この情報をTCPスループットの方程式とともに使用して、TCPに優しい送信率を導き出します。
o Through a distributed feedback suppression mechanism, only a subset of the receivers is allowed to give feedback to prevent a feedback implosion at the sender. The feedback mechanism ensures that receivers reporting a low desired transmission rate have a high probability of sending feedback.
o 分散フィードバック抑制メカニズムを介して、受信機のサブセットのみが、送信者でのフィードバックの爆発を防ぐためにフィードバックを与えることができます。フィードバックメカニズムにより、低い希望の伝送速度を報告するレシーバーがフィードバックを送信する可能性が高いことが保証されます。
o Receivers whose feedback is not suppressed report the calculated transmission rate back to the sender in so-called receiver reports. The receiver reports serve two purposes: they inform the sender about the appropriate transmit rate, and they allow the receivers to measure their RTT.
o フィードバックが抑制されていない受信者は、いわゆる受信機レポートで、計算された伝送速度を送信者に戻します。受信機のレポートは、2つの目的を果たします。彼らは、適切な送信率について送信者に通知し、受信機がRTTを測定できるようにします。
o The sender selects the receiver that reports the lowest rate as the current limiting receiver (CLR). Whenever feedback with an even lower rate reaches the sender, the corresponding receiver becomes the CLR and the sending rate is reduced to match that receiver's calculated rate. The sending rate increases when the CLR reports a calculated rate higher than the current sending rate.
o 送信者は、現在の制限レシーバー（CLR）として最低レートを報告する受信機を選択します。さらに低いレートでフィードバックが送信者に到達すると、対応するレシーバーがCLRになり、送信率がそのレシーバーの計算レートに一致するように低下します。CLRが現在の送信率よりも高い計算レートを報告すると、送信率が増加します。
TFMCC was intended for fixed-size packets with variable rate. SRMP applies it to variable-size SRMP messages that are mostly the same size because the best-effort updates typically all represent the same sort of simulation information and are grouped into bundles of size just under one MTU during periods of heavy network activity. Future developments in TFMCC for variable-size messages will be of high value for inclusion in SRMP if, as expected, they prove to be appropriate for the types of traffic SRMP is intended to support.
TFMCCは、変動レートの固定サイズのパケットを対象としています。SRMPは、通常、最高のエフォルトの更新はすべて同じ種類のシミュレーション情報を表し、重いネットワークアクティビティの期間中に1つのMTU未満のサイズのバンドルにグループ化されるため、ほとんど同じサイズの可変サイズのSRMPメッセージに適用します。変数サイズのメッセージのTFMCCの将来の開発は、SRMPがサポートすることを目的としているトラフィックの種類に適していることが証明されている場合、SRMPに含めるのに高い価値があります。
SRMP is intended for general use under applications that need its services and may exist in parallel instances on the same host. The UDP port is therefore established ad hoc from available application ports; accordingly, it would not be appropriate to have a well-known port for SRMP.
SRMPは、そのサービスを必要とするアプリケーションで一般的に使用することを目的としており、同じホストに並行して存在する可能性があります。したがって、UDPポートは、利用可能なアプリケーションポートからアドホックに確立されています。したがって、SRMPの有名なポートを持つことは適切ではありません。
3.1. Bundle Message Format:
3.1. バンドルメッセージ形式：
--------------------------------------------------------------------
| bundle header | SRT Message 0 | SRT message 1 | SRT message 2 |...
--------------------------------------------------------------------
A bundle is an aggregation of multiple SRMP messages destined for the same multicast address. A bundle can contain only Mode 0 and Mode 1 messages; Mode 2 messages are exchanged using unicast addresses.
バンドルは、同じマルチキャストアドレスに向けられた複数のSRMPメッセージの集約です。バンドルには、モード0とモード1のメッセージのみを含めることができます。モード2メッセージは、ユニキャストアドレスを使用して交換されます。
SRMP identifies the sender and receiver using their 32-bit Sender_ID, which may be an IPv4 address. For use with IPv6, a user group will need to establish a unique identifier per host. There is no requirement for this identifier to be unique in the Internet; it only needs to be unique in the communicating group.
SRMPは、32ビットSender_IDを使用して送信者と受信機を識別します。これはIPv4アドレスである可能性があります。IPv6で使用するには、ユーザーグループがホストごとに一意の識別子を確立する必要があります。この識別子がインターネットで一意になる必要はありません。コミュニケーショングループではユニークである必要があります。
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |fb_nr | flag | bundle_SN |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| x_supp | R_max |
+--------------+--------------+--------------+--------------+
| DSN_count | padding | Length |
+--------------+--------------+--------------+--------------+
| 0 to 255 DSN: <dataID, SN, NoSegs> of this sender |
+-----------------------------------------------------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits 0000 - indicates bundle
タイプ：4ビット0000-バンドルを示します
fb_nr: 4 bits feedback round, range 0-15
FB_NR：4ビットフィードバックラウンド、範囲0〜15
flag: 4 bits 0001 Is_CLR other bits reserved
フラグ：4ビット0001 IS_CLRその他のビットは予約されています
bundle_SN: 16 bits range 0-65535
bundle_sn：16ビット範囲0-65535
Sender_Timestamp: 16 bits Representing the time that the bundle was sent out (in milliseconds) based on the sender's local clock.
sender_timestamp：送信者のローカル時計に基づいてバンドルが（ミリ秒単位）送信された時間を表す16ビット。
Receiver_Timestamp: 16 bits Echo of the Receiver_Time_Stamp field (in milliseconds) of the receiver feedback message. If the sender has time delay between receiving the feedback and echoing the timestamp, it MUST adjust the Receiver_Timestamp value to compensate.
Receiver_Timestamp：レシーバーフィードバックメッセージのReceiver_Time_Stampフィールド（ミリ秒）の16ビットエコー。送信者がフィードバックを受信してタイムスタンプをエコーするまでの時間遅延がある場合、補償するためにReceiver_Timestamp値を調整する必要があります。
Receiver_ID 32 bits Unique identifier for the receiver within the multicast group. IPv4 addresses may be used.
マルチキャストグループ内の受信機のReceiver_id 32ビットユニークな識別子。IPv4アドレスを使用できます。
Sender_ID: 32 bits Unique identifier for the sender within the multicast group. IPv4 addresses may be used.
sender_id：マルチキャストグループ内の送信者向けの32ビットユニークな識別子。IPv4アドレスを使用できます。
X_supp: 16 bits The suppression rate corresponding to the sender, in bits/s. Only those receivers whose desired rate is less than the suppression rate, or whose RTT is larger than R_max, may send feedback information to the sender. The suppression rate is represented as a 16-bit floating point value with 8 bits for the unsigned exponent and 8 bits for the unsigned mantissa.
x_supp：16ビット送信者に対応する抑制率、ビット/s。希望の速度が抑制率よりも少ない、またはRTTがR_MAXよりも大きいレシーバーのみが、送信者にフィードバック情報を送信する場合があります。抑制率は、署名されていない指数で8ビット、署名されていないマンティッサで8ビットで16ビットの浮動小数点値として表されます。
R_max: 16 bits The maximum of the RTTs of all receivers, in milliseconds. The Maximum RTT should be represented as a 16-bit floating point value with 8 bits for the unsigned exponent and 8 bits for the unsigned mantissa.
r_max：16ビットすべてのレシーバーのRTTの最大値をミリ秒単位でビットします。最大RTTは、署名されていない指数で8ビット、署名されていないマンティッサで8ビットで16ビットの浮動小数点値として表現する必要があります。
DSN_count: 8 bits The count of DSN blocks following the header.
DSN_Count：8ビットヘッダーに続くDSNブロックのカウントをビットします。
Length: 16 bits Range from 0~65535. The total length of the bundle in octets (including the header).
長さ：16ビットの範囲は0〜65535です。オクテットのバンドルの全長（ヘッダーを含む）。
DSN: 32 bits There can be up to 256 of these in a header. An SRMP implementation MUST support a minimum of 1. Each DSN consists of three fields:
DSN：32ビットヘッダーに最大256個のビットがあります。SRMPの実装は、最低1をサポートする必要があります。各DSNは3つのフィールドで構成されています。
dataID: 16 bits A unique number associated with a particular data element on the sending host, used to identify a Mode 1 message. SN: 9 bits Sequence number associated with a particular Mode 1 transmission of a particular dataID. NoSegs: 7 bits Number of segments, if the dataID was long enough to require segmentation; otherwise 0x0.
DataID：16モード1メッセージを識別するために使用される、送信ホストの特定のデータ要素に関連付けられた一意の数字。SN：特定のモードに関連付けられた9ビットシーケンス番号1特定のDataIDの伝送。Nosegs：DataIDがセグメンテーションを必要とするのに十分な長さである場合、7ビットのセグメント数。それ以外の場合は0x0。
Note that the number of DSNs reflects the number of different Mode 1 DataIDs being supported at this time by this instance of SRMP, and is not the count of SRMP messages bundled in this transmission.
DSNSの数は、このインスタンスのSRMPによってサポートされている異なるモード1データイドの数を反映しており、この伝送にバンドルされたSRMPメッセージのカウントではないことに注意してください。
Note also that 16-bit timestamps will wrap around in 65536 milliseconds. This should not be a problem unless an RTT is greater than 65 seconds. If a timestamp is less than its predecessor (treating the 16 bits as an unsigned integer), its value must be increased by 65536 for comparisons against the predecessor.
また、16ビットのタイムスタンプは65536ミリ秒で包み込まれていることに注意してください。RTTが65秒を超えない限り、これは問題になりません。タイムスタンプがその前身よりも少ない場合（16ビットを署名のない整数として扱う）、前身との比較のためにその値を65536増加させる必要があります。
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | fb_nr| flag | X_r |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits value 0001
タイプ：4ビット値0001
fb_nr: 4 bits current feedback round of the sender
FB_NR：4ビットの電流フィードバックラウンドの送信者
flag: 4 bits 0001 - have_RTT 0010 - have_loss 0100 - receiver_leave other values reserved
フラグ：4ビット0001 -have_rtt 0010 -have_loss 0100 -receiver_leaveその他の値は予約されています
X_r: 16 bits desired sending rate X_r in bits/s, calculated by the receiver to be TCP-friendly, 16 bit floating point value with 8 bits for the unsigned exponent and 8 bits for the unsigned mantissa.
X_R：16ビットの希望は、レートX_Rをビット/sで送信します。受信機によってTCPフレンドリーであると計算され、署名されていない指数の8ビット、署名されていないマンティッサで8ビットで16ビットのフローティングポイント値が計算されます。
Sender_Timestamp: 16 bits Echo of the Sender_Timestamp in bundle header. If the receiver has time delay between receiving the bundle and echoing the timestamp, it MUST adjust the Sender_Timestamp value correspondently.
sender_timestamp：バンドルヘッダーのsender_timestampの16ビットエコー。受信者がバンドルを受け取ることからタイムスタンプをエコーするまでの時間遅延がある場合、sender_timestamp値を対応して調整する必要があります。
Receiver_Timestamp: 16 bits The time when the feedback message was sent out from the receiver.
Receiver_Timestamp：16ビットフィードバックメッセージが受信機から送信された時間。
Receiver_ID: 32 bits Unique identifier for the receiver within the multicast group. IPv4 addresses may be used. (Identifies the receiver that sends the feedback message).
Receiver_id：マルチキャストグループ内の受信機の32ビット一意の識別子。IPv4アドレスを使用できます。（フィードバックメッセージを送信する受信機を識別します）。
Sender_ID: 32 bits Unique identifier for the sender within the multicast group. IPv4 addresses may be used. (Identifies the sender that is the destination of the current feedback message.)
sender_id：マルチキャストグループ内の送信者向けの32ビットユニークな識別子。IPv4アドレスを使用できます。（現在のフィードバックメッセージの宛先である送信者を識別します。）
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 000 | 00000000 | Length |
+--------------+--------------+--------------+--------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits 0000
タイプ：4ビット0000
Mode: 3 bits 000
モード：3ビット000
Padding: 8 bits 00000000
パディング：8ビット00000000
Length: 11 bits Length of the payload data in octets (does not include the header).
長さ：オクテットのペイロードデータの11ビットの長さ（ヘッダーは含まれません）。
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 001 | SegNo | Length |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits 0000
タイプ：4ビット0000
Mode: 3 bits 001
モード：3ビット001
SegNo: 7 bits The index number of this segment.
Segno：7は、このセグメントのインデックス番号をビットします。
Length: 14 bits Length of the payload data in octets (does not include the header).
長さ：オクテットのペイロードデータの14ビットの長さ（ヘッダーは含まれません）。
DSN: 32 bits Same as in the bundle header. Note that this contains NoSegs, whereas SegNo is a separate element.
DSN：バンドルヘッダーと同じ32ビット。これには鼻が含まれているのに対し、Segnoは別の要素であることに注意してください。
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |010 | 00000 | Length |
+--------------+--------------+--------------+--------------+
| SN |
+--------------+--------------+--------------+--------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits 0010
タイプ：4ビット0010
Mode: 3 bits 010
モード：3ビット010
Padding: 5 bits 00000
パディング：5ビット00000
Length: 16 bits Length of the payload data in octets (does not the include header).
長さ：オクテットのペイロードデータの16ビットの長さ（ヘッダーを含むものではありません）。
SN: 32 bits Same as in bundle header.
SN：バンドルヘッダーと同じ32ビット。
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |111 | 00000 | reserved |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
| Sender Address |
+--------------+--------------+--------------+--------------+
Version: 4 bits currently 0010
バージョン：4ビット現在0010
Type: 4 bits 0010
タイプ：4ビット0010
Mode: 3 bits 111
モード：3ビット111
Padding: 5 bits 00000
パディング：5ビット00000
Reserved: 16 bits
予約済み：16ビット
DSN: 32 bits sequence number
DSN：32ビットシーケンス番号
Sender Address: The IP address of the sender of the message being NACKed.
送信者アドレス：nackされているメッセージの送信者のIPアドレス。
Name Minimum Value Recommended Value Units
名前最小値推奨値単位
DSN_Max 1 32 messages
dataID_Timeout none none ms
Segment_Timeout 50 250 ms
Bundle_Timeout 1 10 ms
Heartbeat_Interval 1 none s
Mode2_Max 1 none messages
ACK_Threshold none worst RTT in group ms
The RECOMMENDED throughput equation for SRMP is a slightly simplified version of the throughput equation for Reno TCP from [5]:
SRMPの推奨されるスループット方程式は、[5]のReno TCPのスループット方程式のわずかに簡素化されたバージョンです。
8*s
X = ------------------------------------------------------ (1)
R * (sqrt(2*p/3) + (3*sqrt(6*p) * p * (1+32*p^2)))
(the formula may be simplified for implementation), where
（式は実装のために簡素化される場合があります）
X is the transmit rate in bits/second.
xはビット/秒単位の送信率です。
s is the message size in bytes.
Sはバイトのメッセージサイズです。
R is the round-trip time in seconds.
rは秒単位の往復時間です。
p is the loss event rate, between 0.0 and 1.0, of the number of loss events as a fraction of the number of messages transmitted.
Pは、送信されたメッセージの数の一部としての損失イベントの数の0.0〜1.0の損失イベント率です。
In the future, different TCP formulas may be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来的には、この方程式のために異なるTCP式を置き換えることができます。要件は、スループット方程式が、コンフォーマントTCP混雑制御のTCPの送信率の合理的な近似であることです。
Multiple SRMP messages will be encapsulated into a bundle. When a new SRMP message (Mode 0 or Mode 1) arrives, the SRMP daemon will try to add the new message into the current bundle.
複数のSRMPメッセージがバンドルにカプセル化されます。新しいSRMPメッセージ（モード0またはモード1）が到着すると、SRMPデーモンは現在のバンドルに新しいメッセージを追加しようとします。
The SRMP daemon MUST keep a timer, which will be reset when the first SRMP message is added into the bundle. After Bundle_Timeout, the timer will time out, and the current bundle should be transmitted immediately. A new bundle will then be initialized to hold new SRMP messages. Bundle_Timeout SHALL NOT be less than 1 ms. The recommended value is 10 ms.
SRMPデーモンはタイマーを保持する必要があります。タイマーは、最初のSRMPメッセージがバンドルに追加されるとリセットされます。bundle_timeoutの後、タイマーがタイムアウトし、現在のバンドルをすぐに送信する必要があります。新しいバンドルが初期化され、新しいSRMPメッセージが保持されます。bundle_timeoutは1ミリ秒以上ではありません。推奨値は10ミリ秒です。
Also, the bundle length MUST NOT exceed LENGTH_MAX. If adding a new SRMP message will produce a greater length, the SRMP daemon MUST initialize a new bundle for the new SRMP messages, and the current bundle should be transmitted immediately. The recommended value for LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header lengths).
また、バンドルの長さはlength_maxを超えてはなりません。新しいSRMPメッセージを追加すると、より長い長さが生成される場合、SRMPデーモンは新しいSRMPメッセージの新しいバンドルを初期化する必要があり、現在のバンドルはすぐに送信する必要があります。Length_Maxの推奨値は1454バイト（イーサネットMTUからIPおよびUDPヘッダーの長さ）です。
In a bundle, there may exist multiple SRMP messages with the same dataID. In this case, only the latest version of that dataID is useful. SRMP may check for duplicate dataIDs in the same bundle and delete all but the latest one. If a Mode 1 message appears in the outgoing bundle, then the corresponding DSN should not appear in the bundle header.
バンドルには、同じDataIDを持つ複数のSRMPメッセージが存在する場合があります。この場合、そのdataIDの最新バージョンのみが便利です。SRMPは、同じバンドルのDataIDの重複をチェックし、最新のバンドル以外のすべてを削除する場合があります。発信バンドルにモード1メッセージが表示される場合、対応するDSNはバンドルヘッダーに表示されないはずです。
The bundle header contains the DSN <dataID,SN,NoSegs> for Mode 1 messages from this sender. The absolute maximum number of DSN is 255; however, an implementation may apply a user-specified DSN_Max, no smaller than 1. An implementation may support a user-defined dataID_Timeout, after which a given dataID will not be announced in the bundle header unless a new Mode 1 message has been sent. If the sender has more dataIDs sent (and not timed out) than will fit in the bundle header, the DSNs MUST be announced on a round-robin basis, with the exception that no bundle header will announce a DSN for a Mode 1 message contained within that bundle. If a duplicate DSN is received, it may be silently discarded.
バンドルヘッダーには、この送信者からのモード1メッセージのdsn <dataId、sn、nosegs>が含まれています。DSNの絶対最大数は255です。ただし、実装は、1以下のユーザー指定のDSN_MAXを適用する場合があります。実装は、ユーザー定義のdataID_TIMEOUTをサポートする場合があります。その後、新しいモード1メッセージが送信されない限り、特定のDataIDはバンドルヘッダーで発表されません。送信者がバンドルヘッダーに収まるよりも多くのデータIDを送信（タイミングで留めていない）場合、DSNSはラウンドロビンベースで発表する必要があります。そのバンドル内。重複したDSNを受信した場合、静かに廃棄される可能性があります。
The congestion control mechanism operates as described in [7].
輻輳制御メカニズムは、[7]に記載されているように動作します。
SRMP uses the Any-Source Multicast Mode. Each sender will determine its maximum RTT, suppression data rate, and sending rate with respect to each sender. Each receiver will measure its RTT and desired rate to each sender in the group, and send feedback to every sender by sending to the multicast group.
SRMPは、任意のソースマルチキャストモードを使用します。各送信者は、各送信者に関する最大RTT、抑制データレート、および送信レートを決定します。各レシーバーは、グループ内の各送信者にRTTと希望のレートを測定し、マルチキャストグループに送信してすべての送信者にフィードバックを送信します。
Under SRMP, each group member in a multicast group is a sender as well as a receiver. Each receiver may need to participate in TFMCC information exchange with all senders. Thus, when a receiver sends a feedback message, it must identify to which source the message should be sent using the "Sender ID" field in the header.
SRMPの下では、マルチキャストグループの各グループメンバーは、送信者および受信者です。各レシーバーは、すべての送信者とのTFMCC情報交換に参加する必要がある場合があります。したがって、レシーバーがフィードバックメッセージを送信する場合、ヘッダーの「送信者ID」フィールドを使用してメッセージを送信するソースを特定する必要があります。
The feedback is multicast to the group. Depending on the network situation, senders may select different receivers to provide feedback. Feedback messages from receivers that are not among those selected by the local TFMCC to provide feedback should be silently discarded.
フィードバックはグループのマルチキャストです。ネットワークの状況に応じて、送信者はフィードバックを提供するために異なる受信機を選択できます。フィードバックを提供するためにローカルTFMCCによって選択されたものの中にないレシーバーからのフィードバックメッセージは、静かに破棄する必要があります。
TFMCC is designed for traffic with a fixed message size. The maximum bundle size (including header) for SRMP is set to a configurable maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header lengths). The bundle size will be used in a TCP throughput equation, to get a desired source rate. However, in SRMP, the message size is variable because:
TFMCCは、固定メッセージサイズのトラフィック用に設計されています。SRMPの最大バンドルサイズ（ヘッダーを含む）は、構成可能な最大値、通常1454バイト（イーサネットMTUからIPおよびUDPヘッダーの長さ）に設定されます。バンドルサイズは、目的のソースレートを取得するために、TCPスループット方程式で使用されます。ただし、SRMPでは、メッセージサイズは次のために変動します。
1. After bundle time out, the current bundle will not wait for new SRMP messages. This happens with sources sending at a slow rate.
1. バンドルタイムアウト後、現在のバンドルは新しいSRMPメッセージを待ちません。これは、速度で送信されるソースで発生します。
2. In long messages, there is no further space in the current bundle for new SRMP messages. This will happen with sources sending at a high rate or sending messages with a length over half of the bundle payload size.
2. 長いメッセージでは、新しいSRMPメッセージの現在のバンドルにはそれ以上のスペースがありません。これは、ソースが高いレートで送信するか、バンドルペイロードサイズの半分以上の長さのメッセージを送信する場合に発生します。
The case 1 bundle size is likely to be much smaller than that of case 2.
ケース1バンドルサイズは、ケース2のバンドルサイズよりもはるかに小さい可能性があります。
Therefore, in SRMP, the mean value of the 10 most recent bundles' sizes will be used as the bundle size in the TCP throughput equation. This mean value is independent from the network condition and reflects current activity of the source.
したがって、SRMPでは、10の最新バンドルのサイズの平均値が、TCPスループット方程式のバンドルサイズとして使用されます。この平均値はネットワーク条件から独立しており、ソースの現在の活動を反映しています。
Each host will have a single instance of SRMP supporting all of its applications. Thus, the sender's source rate is the sum of the rates of all the clients of the same multicast group.
各ホストには、すべてのアプリケーションをサポートするSRMPの単一インスタンスがあります。したがって、送信者のソースレートは、同じマルチキャストグループのすべてのクライアントのレートの合計です。
If the source rate is larger than the sender's desired transmission rate, it is the sender's responsibility to do traffic shaping. Any method that conforms to the target sending rate may be used. The RECOMMENDED method is to randomly discard enough Mode 0 messages to meet the target rate.
ソースレートが送信者の望ましい伝送レートよりも大きい場合、トラフィックの形成を行うことは送信者の責任です。ターゲットの送信率に準拠するすべての方法を使用できます。推奨される方法は、目標レートを満たすために十分なモード0メッセージをランダムに破棄することです。
Bundle header processing includes checking each DSN in the bundle header and scheduling a NACK for each DSN bearing a dataID for which some application has indicated interest, if the SN/SegNo in that DSN indicates that a NACK is needed. NACKs are sent in bundles and may be bundled with data messages. A NACK is required if:
バンドルヘッダー処理には、バンドルヘッダーの各DSNを確認し、DSNのSN/SEGNOがNACKが必要であることを示している場合、一部のアプリケーションが関心を示しているDATAIDのNACKをスケジュールすることが含まれます。Nacksはバンドルで送信され、データメッセージがバンドルされる場合があります。次の場合、NACKが必要です。
o the SN is one or more greater (mod 512) than the latest received Mode 1 message for that dataID, or
o SNは、そのdataIDの最新の受信モード1メッセージよりも1つ以上大きい（mod 512）または
o the SegNo has not been received, some segment of the <dataID,SN> has been received, and a user-defined Segment_Timeout, which SHALL NOT be less than 50 ms, has expired since receipt of the first SegNo for the <dataID,SN>.
o segnoは受信されておらず、<dataId、sn>の一部のセグメントが受信され、50ミリ秒未満ではないユーザー定義済みのsegment_timeoutは、<dataId、snの最初のsegnoの受信以来失効しています。>。
The bundling sublayer will pass the DSN list in any received bundle header to the SRT sublayer. It also will suppress NACKs in outgoing bundles, as described in the next section.
バンドリングサブレイヤーは、受信したバンドルヘッダーのDSNリストをSRTサブレイヤーに渡します。また、次のセクションで説明されているように、発信バンドルのNACKを抑制します。
Negative acknowledgements are used by SRMP for multicast messages in order to avoid the congestion of an "ACK implosion" at the original sender that would likely occur if positive acknowledgements were used instead. However, with a large multicast group spread out over a congested wide-area network, there is the potential for enough members of the multicast group to fail to receive the message and generate NACKs to cause considerable congestion at the original sender despite the use of negative acknowledgements instead of positive acknowledgements. For this reason, SRMP uses a NACK suppression mechanism to reduce the number of NACKs generated in response to any single lost message.
マルチキャストメッセージには、否定的な承認がマルチキャストメッセージに使用されます。これは、代わりに肯定的な承認が使用された場合に発生する可能性が高い元の送信者での「ACK爆発」の輻輳を回避するためです。ただし、大規模なマルチキャストグループが混雑している幅広いネットワークに広がっているため、マルチキャストグループのメンバーがメッセージを受信できず、NACKを生成して、ネガティブな送信者にかなりのうっ血を引き起こす可能性があります。肯定的な謝辞の代わりに謝辞。このため、SRMPはNACK抑制メカニズムを使用して、単一の失われたメッセージに応じて生成されたNACKの数を減らします。
The NACK suppression mechanism uses the Bundle_Timeout to distribute NACKs over an appropriate time window. This assumes that the user has selected a bundle timeout appropriate for the needs of the application for real-time responsiveness.
NACK抑制メカニズムは、bundle_timeoutを使用して、適切な時間ウィンドウでNACKを配布します。これは、ユーザーがリアルタイムの応答性のためにアプリケーションのニーズに適したバンドルタイムアウトを選択したことを前提としています。
When the bundling sublayer is ready to send a bundle, it removes from the bundle any NACKs for which a response has been sent by another member of the multicast group within the NACK_Repeat_Timeout window. If the original Bundle_Timeout has not expired, transmission of the bundle may then be delayed until the original Bundle_Timeout expires or the bundle is full, whichever happens first.
バンドリングサブレイヤーがバンドルを送信する準備ができたら、NACK_REPEAT_TIMEOUTウィンドウ内のマルチキャストグループの別のメンバーによって応答が送信されたNACKをバンドルから削除します。元のbundle_timeoutが期限切れになっていない場合、バンドルの送信は、元のbundle_timeoutが有効期限が切れるか、バンドルがいっぱいになるまで遅延することがあります。
After a receiver completes congestion control processing on a bundle, it parses the bundle into SRT messages and sends these to the SRT sublayer.
レシーバーがバンドルの輻輳制御処理を完了した後、バンドルをSRTメッセージに解析し、これらをSRTサブレイヤーに送信します。
SRMP implementations may support a user-defined Heartbeat_Interval, which SHALL NOT be less than one second. At the end of each heartbeat interval, if the sender has not sent any bundle, an empty bundle will be sent in order to trigger Mode 1 loss detection.
SRMPの実装は、ユーザー定義のHeartbeat_intervalをサポートする場合がありますが、これは1秒以上ではありません。各ハートビート間隔の最後に、送信者がバンドルを送信していない場合、モード1の損失検出をトリガーするために空のバンドルが送信されます。
SRMP operates in three distinct transmission modes in order to deliver varying levels of reliability: Mode 0 for multicast data that does not require reliable transmission, Mode 1 for data that must be received reliably by all members of a multicast group, and Mode 2 for data that must be received reliably by a single dynamically determined member of a multicast group.
SRMPは、信頼性のさまざまなレベルのレベルを提供するために3つの異なる伝送モードで動作します。信頼できる伝送を必要としないマルチキャストデータのモード0、マルチキャストグループのすべてのメンバーが確実に受信する必要があるデータのモード1、データのモード2それは、マルチキャストグループの単一の動的に決定されたメンバーによって確実に受信されなければなりません。
Mode 0 operates as a pure best-effort service. Mode 1 operates with negative acknowledgements only, triggered by bundle arrivals that indicate loss of a Mode 1 message. Mode 2 uses a positive acknowledgement for each message to provide reliability and low latency. Mode 2 is used where a transaction between two members of a multicast group is needed. Because there can be many members in such a group, use of a transaction protocol, with reliability achieved by SRMP retransmission, avoids the potentially large amount of connection setup and associated state that would be required if each pair of hosts in the group established a separate TCP connection.
モード0は、純粋なベストエフォルトサービスとして動作します。モード1は、モード1メッセージの損失を示すバンドル到着によってトリガーされる否定的な承認のみで動作します。モード2は、各メッセージの肯定的な承認を使用して、信頼性と低遅延を提供します。モード2は、マルチキャストグループの2人のメンバー間のトランザクションが必要な場合に使用されます。このようなグループには多くのメンバーがいる可能性があるため、SRMPの再送信によって信頼性が達成されたトランザクションプロトコルの使用は、グループ内の各ホストのペアが別のホストを確立した場合に必要な潜在的に大量の接続セットアップと関連状態を回避します。TCP接続。
Use of SRMP anticipates that only a small fraction of messages will require reliable multicast, and a comparably small fraction will require reliable unicast. This is due to a property of distributed virtual simulation: the preponderance of messages consist of state update streams for object attributes such as position and orientation. SRMP is unlikely to provide effective reliable multicast if the traffic does not have this property.
SRMPの使用は、少数のメッセージのみが信頼できるマルチキャストを必要とすることを予測し、比較的少ない割合には信頼できるユニキャストが必要であると予想します。これは、分散仮想シミュレーションのプロパティによるものです。メッセージの優勢は、位置や方向などのオブジェクト属性の状態更新ストリームで構成されています。SRMPは、トラフィックにこのプロパティがない場合、効果的な信頼できるマルチキャストを提供する可能性は低いです。
In SRMP, "dataID" is used to associate related messages with each other. Typically, all messages with the same dataID are associated with the same application entity. All the messages with the same dataID must be transmitted in the same mode. Among all the messages with the same dataID, the latest version will obsolete all older messages.
SRMPでは、「DataID」を使用して、関連するメッセージを互いに関連付けます。通常、同じDataIDを持つすべてのメッセージは、同じアプリケーションエンティティに関連付けられています。同じDataIDを持つすべてのメッセージは、同じモードで送信する必要があります。同じDataIDを持つすべてのメッセージの中で、最新バージョンはすべての古いメッセージを廃止します。
Mode 0 is for multicast messages that do not require reliable transmission because they are part of a real-time stream of data that is periodically updated with high frequency. Any such message is very likely to have been superceded by a more recent update before retransmission could be completed.
モード0は、高周波で定期的に更新されるリアルタイムのデータストリームの一部であるため、信頼性の高い送信を必要としないマルチキャストメッセージ用です。そのようなメッセージは、再送信が完了する前に、より最近の更新によって超越された可能性が非常に高いです。
When an application requests transmission of Mode 0 data, a destination multicast group must be provided to SRMP along with the data to be sent. After verifying the data length and multicast group, the following steps MUST be performed by the SRT sublayer:
アプリケーションがモード0データの送信を要求する場合、送信するデータとともに宛先マルチキャストグループをSRMPに提供する必要があります。データの長さとマルチキャストグループを確認した後、SRTサブレイヤーは次の手順を実行する必要があります。
1. An SRT message MUST be generated with the following characteristics:
1. 次の特性を使用して、SRTメッセージを生成する必要があります。
the version is set to the current version, the message type is set to 0x0, the mode is set to 0x0. User data is included after the message header. If the message cannot be generated as described above, the user data is discarded and the error MUST be reported to the application.
バージョンは現在のバージョンに設定され、メッセージタイプは0x0に設定され、モードは0x0に設定されます。メッセージヘッダーの後にユーザーデータが含まれています。上記のようにメッセージを生成できない場合、ユーザーデータが破棄され、エラーをアプリケーションに報告する必要があります。
2. If step 1 was completed without error, the newly generated message MUST be sent to the bundling sublayer. The implementation MUST report to the application whether the message was ultimately accepted by UDP.
2. ステップ1がエラーなしで完了した場合、新しく生成されたメッセージをバンドリングサブレイヤーに送信する必要があります。実装は、メッセージが最終的にUDPによって受け入れられたかどうかをアプリケーションに報告する必要があります。
When a Mode 0 message is received by SRMP, it MUST be processed as follows: after verifying the version, message type, and destination multicast address fields, the user data MUST be delivered to all applications that are associated with the multicast group in the message. If the SRMP receiver has never received any Mode 1 messages before the Mode 0 message is received, the Mode 0 message should be silently discarded.
モード0メッセージがSRMPによって受信される場合、次のように処理する必要があります。バージョン、メッセージタイプ、および宛先マルチキャストアドレスフィールドを確認した後、ユーザーデータは、メッセージ内のマルチキャストグループに関連付けられているすべてのアプリケーションに配信する必要があります。。SRMPレシーバーがモード0メッセージを受信する前にモード1メッセージを受信したことがない場合、モード0メッセージは静かに破棄する必要があります。
It is RECOMMENDED that the following information be provided to the receiving applications: message body, multicast address.
受信アプリケーションに次の情報を提供することをお勧めします：メッセージ本文、マルチキャストアドレス。
Mode 1 is for multicast data that requires reliable transmission. A Mode 1 message can be either a data message or a NACK. Mode 1 data messages are expected to be part of a data stream. This data stream is likely to contain Mode 0 messages as well (see section 5.1.1), but it is possible for a data stream to be comprised solely of Mode 1 messages.
モード1は、信頼性の高い送信が必要なマルチキャストデータ用です。モード1メッセージは、データメッセージまたはNACKのいずれかです。モード1データメッセージは、データストリームの一部になると予想されます。このデータストリームには、モード0メッセージも含まれている可能性があります（セクション5.1.1を参照）が、データストリームはモード1メッセージのみで構成される可能性があります。
After the data length, dataID, and destination multicast group are verified, SRT MUST take the following steps:
データの長さ、DataID、および宛先マルチキャストグループが検証された後、SRTは次の手順を実行する必要があります。
1. If the message will not fit in an empty bundle with DSN_Max DSN in the header, the message MUST be segmented. The remaining steps pertain to each segment of the message. Each segment receives a unique SegNo, starting with 0 and ending with (NoSegs-1).
1. メッセージがヘッダーにDSN_MAX DSNを使用した空のバンドルに収まらない場合、メッセージをセグメント化する必要があります。残りの手順は、メッセージの各セグメントに関係します。各セグメントは、0で始まり、（NOSEGS-1）で終了する一意のSegnoを受け取ります。
2. An SRT message is generated with the following characteristics: the version is set to 0x02, the message type is set to 0x0, the transmission mode is set to 0x01, the SN is set equal to the SN of the most recently sent Mode 1 complete message of the same dataID, incremented by 1 modulo 512. If no such Mode 1 message exists, the SN is set to 0x0.
2. SRTメッセージは次の特性で生成されます：バージョンは0x02に設定され、メッセージタイプは0x0に設定され、送信モードは0x01に設定され、SNは最近送信されたモード1完全メッセージのSNに等しく設定されます同じDATAIDのうち、1 Modulo 512で増加します。そのようなモード1メッセージが存在しない場合、SNは0x0に設定されます。
3. The newly generated message (all segments) must then be buffered, replacing any formerly buffered Mode 1 message of the same dataID, destination multicast address. If the message cannot be buffered, the user data is discarded and the error is reported to the application.
3. 次に、新しく生成されたメッセージ（すべてのセグメント）をバッファリングする必要があり、以前にバッファリングされたモード1のメッセージを交換する必要があります。メッセージをバッファリングできない場合、ユーザーデータが破棄され、エラーがアプリケーションに報告されます。
4. If step 2 was completed without error, the newly generated message is sent to the TFMCC sublayer.
4. ステップ2がエラーなしで完了した場合、新しく生成されたメッセージがTFMCCサブレイヤーに送信されます。
When a Mode 1 data message is received by SRT, it will be processed as follows (assuming that the version field has already been verified to be 0x02):
モード1のデータメッセージがSRTによって受信されると、次のように処理されます（バージョンフィールドがすでに0x02であることが確認されていると仮定して）：
1. The destination address MUST be verified to be a valid IP multicast address on which this instance of SRMP is a member. If this is not the case, the message should be silently discarded.
1. 宛先アドレスは、SRMPのこのインスタンスがメンバーである有効なIPマルチキャストアドレスであることを確認する必要があります。そうでない場合は、メッセージを静かに破棄する必要があります。
2. The destination address MUST be verified to be one for which some application has indicated interest. Otherwise, the message should be silently discarded.
2. 宛先アドレスは、一部のアプリケーションが関心を示しているものであることを確認する必要があります。それ以外の場合、メッセージは静かに破棄する必要があります。
3. The SN, SegNo, source_ip_address, and the body of the received message MUST be buffered, and the user data MUST then be delivered to all applications that have indicated interest in the multicast group of the received message.
3. SN、SEGNO、SOURCE_IP_ADDRESS、および受信メッセージの本文をバッファリングする必要があり、ユーザーデータを受信したメッセージのマルチキャストグループに関心を示したすべてのアプリケーションに配信する必要があります。
4. When a new DSN value is received with NoSegs greater than zero, a timer should be set for Segment_Timeout, after which a NACK should be sent to the bundling sublayer and the timer should be restarted for Segment_Timeout.
4. ゼロより大きいNOSEGを使用して新しいDSN値を受信した場合、segment_timeoutにタイマーを設定する必要があります。その後、NACKをバンドルサブレイヤーに送信する必要があり、segment_timeoutにタイマーを再起動する必要があります。
5. If NoSegs in the received message is not 0, a reassembly process MUST be started. Each segment MUST be buffered. If receipt of the current message completes the segment, the reassembled message MUST be released to the application and the Segment_Timeout timer cancelled.
5. 受信したメッセージのNOSEGSが0ではない場合、再組み立てプロセスを開始する必要があります。各セグメントはバッファリングする必要があります。現在のメッセージの受信がセグメントに記入された場合、再構成されたメッセージをアプリケーションにリリースし、segment_timeoutタイマーをキャンセルする必要があります。
6. If a new DSN is received before all segments of the previous DSN are received, the segments that have been received should be dropped silently.
6. 以前のDSNのすべてのセグメントを受信する前に新しいDSNを受信した場合、受信されたセグメントは静かにドロップする必要があります。
7. It is RECOMMENDED that the following information be provided to the receiving applications: message body, dataID, source_ip_address, multicast_group address.
7. 受信アプリケーションに次の情報を提供することをお勧めします：メッセージ本文、dataID、source_ip_address、multicast_groupアドレス。
8. When a client signs on to a new multicast group, all locally buffered Mode 1 messages related to that multicast group should be delivered to the client immediately.
8. クライアントが新しいマルチキャストグループにサインオンした場合、そのマルチキャストグループに関連するすべてのローカルバッファリングモード1メッセージは、すぐにクライアントに配信する必要があります。
Whenever a bundle is received, the bundling sublayer will forward the DSN list from the bundle header to the SRT sublayer. The SRT sublayer will examine buffered values of <SenderID,dataID,SN,SegNo> to determine whether a NACK is required. If so, it will generate a NACK message and send it to the bundling sublayer. The NACK message will have version set to 0x2, message type set to 0x2, and transmission mode set to 0x7. dataID, SN, and destination address are set to that of the Mode 1 message for which the NACK is being sent. If a NACK has been received from any member of the destination multicast group for the Mode 1 message in question within the NACK threshold, no NACK is generated.
バンドルが受信されるたびに、バンドリングサブレイヤーはDSNリストをバンドルヘッダーからSRTサブレイヤーに転送します。SRTサブレイヤーは、NACKが必要かどうかを判断するために、<senderid、dataId、sn、segno>の緩衝値を調べます。もしそうなら、それはnackメッセージを生成し、それをバンドリングサブレイヤーに送信します。NACKメッセージには、バージョンが0x2に設定され、メッセージタイプが0x2に設定され、送信モードが0x7に設定されます。DataID、SN、および宛先アドレスは、NACKが送信されているモード1メッセージのアドレスに設定されています。NACKのしきい値内で問題のモード1メッセージについて、Destination Multicast GroupのメンバーからNACKを受信した場合、NACKは生成されません。
For segmented messages, there are two possible types of NACKs:
セグメント化されたメッセージには、2つのタイプのNACKがあります。
o Based on the DSN list in the bundle header, the SRT implementation may determine that an entire segmented Mode 1 message was lost. In this case, the NACK MUST carry SegNo=0x7F (all in one field).
o バンドルヘッダーのDSNリストに基づいて、SRTの実装により、セグメント化されたモード1メッセージが失われたと判断される場合があります。この場合、NACKはsegno = 0x7f（すべて1つのフィールド）を運ぶ必要があります。
o Based on the Segment Timeout, the SRT implementation may determine that one or more segments of a message have not been delivered. In this case, a NACK will be sent for each missing segment.
o セグメントタイムアウトに基づいて、SRTの実装により、メッセージの1つ以上のセグメントが配信されていないことが判断される場合があります。この場合、欠落しているセグメントごとにNACKが送信されます。
When a NACK is received by SRT, it MUST be processed as follows, after verifying the multicast address, dataID, source IP address, and transmission mode:
NACKがSRTによって受信された場合、マルチキャストアドレス、DataID、ソースIPアドレス、および送信モードを確認した後、次のように処理する必要があります。
1. If this instance of SRT's most recent Mode 1 message of the dataID indicated in the NACK has an SN newer than the SN in the NACK, that message (which is buffered) should be immediately retransmitted to the multicast address indicated in the received NACK. If the most recent Mode 1 message has an SN equal to the SN indicated in the NACK, and if the SegNo field in the NACK contains 0x7F, all segments of the buffered Mode 1 message MUST be retransmitted; if the SegNo has some other value, only the indicated segment should be retransmitted.
1. NACKに示されているDataIDのSRTの最新モード1メッセージのこのインスタンスには、NACKのSNよりも新しいSNがある場合、そのメッセージ（バッファリングされています）は、受信したNACKに示されているマルチキャストアドレスにすぐに再送信する必要があります。最新のモード1メッセージにNACKに示されたSNに等しいSNがあり、NACKのSEGNOフィールドに0x7Fが含まれている場合、バッファーモード1メッセージのすべてのセグメントを再送信する必要があります。Segnoに他の値がある場合、示されたセグメントのみを再送信する必要があります。
2. Whether or not step 1 results in the retransmission of a message, the event of receiving the NACK and the (local machine) time at which the NACK was received should be buffered. Each instance of SRT MUST buffer the number of NACKs that have been received for each dataID-multicast address pair, since the most recent Mode 1 message of the same pair was received and the time at which the most recent of these NACKs was received.
2. ステップ1がメッセージの再送信をもたらすかどうか、NACKを受け取るイベント、およびNACKを受け取った（ローカルマシン）時間を緩衝する必要があります。SRTの各インスタンスは、同じペアの最新のモード1メッセージとこれらのNACKの最新のメッセージが受信された時間を受け取ったため、DataID-Multicastアドレスペアごとに受信されたNACKの数をバッファリングする必要があります。
Mode 2 is for infrequent reliable transaction-oriented communication between two dynamically determined members of a multicast group. TCP could be used for such communication, but there would be unnecessary overhead and delay in establishing a stream-oriented connection for a single exchange of data, whereas there is already an ongoing stream of best-effort data between the hosts that require Mode 2 transmission. An example is a Distributed Interactive Simulation (DIS) collision PDU.
モード2は、マルチキャストグループの動的に決定された2つのメンバー間のまれな信頼性の高いトランザクション指向の通信用です。TCPはそのような通信に使用できますが、単一のデータ交換のためのストリーム指向の接続の確立に不必要なオーバーヘッドと遅延がありますが、モード2の伝送を必要とするホスト間で最良のデータの継続的なストリームがすでにあります。。例は、分散インタラクティブシミュレーション（DIS）衝突PDUです。
When an application requests transmission of Mode 2 data, a dataID and a destination unicast IP address MUST be provided to SRT along with the data to be sent. After verifying the data length, dataID, and destination address, SRT MUST perform the following steps:
アプリケーションがモード2データの送信を要求する場合、DataIDと宛先ユニキャストIPアドレスをSRTに提供する必要があります。データの長さ、DataID、および宛先アドレスを確認した後、SRTは次の手順を実行する必要があります。
1. An SRT message is generated with the following characteristics: the version is set to 0x02, the message type is set to 0x02, the transmission mode is set to 0x2, the dataID is set to the application-provided value, and the destination address is set to the application-provided IP address. The SN is set equal to the SN of the most recently sent Mode 2 message of the same dataID incremented by 1 modulo 65536. If no such Mode 1 message exists, it is set to 0x0.
1. SRTメッセージは次の特性で生成されます：バージョンは0x02に設定され、メッセージタイプは0x02に設定され、送信モードは0x2に設定され、DataIDはアプリケーションが提供する値に設定され、宛先アドレスは設定されますアプリケーションが提供するIPアドレスに。SNは、1 Modulo 65536で増分された同じDataIDの最近送信されたモード2メッセージのSNに等しく設定されます。そのようなモード1メッセージが存在しない場合、0x0に設定されます。
2. The newly generated message is buffered. This new message does not replace any formerly buffered Mode 2 messages. An implementation MUST provide a Mode 2 message buffer that can hold one or more Mode 2 messages. Mode 2 messages are expected to be infrequent (less than 1 percent of total traffic), but it is still strongly RECOMMENDED that an implementation provide a buffer of user-configurable size Mode2_Max that can hold more than a single Mode 2 message. If the message cannot be buffered, the user data is discarded and the error MUST be reported to the application. If the message can be buffered, it should be sent to UDP immediately after being buffered.
2. 新しく生成されたメッセージはバッファリングされています。この新しいメッセージは、以前にバッファリングされたモード2メッセージを置き換えません。実装は、1つ以上のモード2メッセージを保持できるモード2メッセージバッファーを提供する必要があります。モード2メッセージは頻繁に（総トラフィックの1％未満）と予想されますが、実装では、単一のモード2メッセージを保持できるユーザー構成サイズモード2_MAXのバッファーを提供することを強くお勧めします。メッセージをバッファリングできない場合、ユーザーデータが破棄され、エラーをアプリケーションに報告する必要があります。メッセージをバッファリングできる場合は、バッファリングされた直後にUDPに送信する必要があります。
3. If step 2 was completed without error, the newly generated message MUST be sent to the IP address contained in its destination address field, encapsulated within a UDP datagram. If the UDP interface on the sending system reports an error to SRT when the attempt to send the SRT message is made, an implementation may attempt to resend the message any finite number of times. However, every implementation MUST provide a mode in which no retries are attempted. Implementations should default to this latter mode of operation. The implementation MUST report to the application whether the message was ultimately accepted by UDP.
3. ステップ2がエラーなしで完了した場合、新しく生成されたメッセージは、UDPデータグラム内にカプセル化された宛先アドレスフィールドに含まれるIPアドレスに送信する必要があります。送信システムのUDPインターフェイスが、SRTメッセージの送信試行が行われたときにSRTにエラーを報告した場合、実装は有限数の回数を再送信しようとする場合があります。ただし、すべての実装は、再試行が行われないモードを提供する必要があります。実装は、この後者の操作モードにデフォルトする必要があります。実装は、メッセージが最終的にUDPによって受け入れられたかどうかをアプリケーションに報告する必要があります。
4. If some user-configurable "ACK_Threshold" (which should be greater than the worst-case round-trip time for the multicast group) elapses without receipt of an ACK for the Mode 2 message, it is retransmitted. An implementation may define a maximum number of retransmissions to be attempted before the Mode 2 message is removed from the buffer.
4. モード2メッセージのACKを受信せずに、一部のユーザー構成可能な「ACK_THRESHOLD」（マルチキャストグループの最悪のラウンドトリップ時間よりも大きくなるはずです）は、再送信されます。実装により、モード2メッセージがバッファから削除される前に、最大数の再送信を試みることができます。
When a Mode 2 data message is received by SRT, it should be processed as follows after verifying version, dataID, sender address, and SN:
モード2データメッセージがSRTによって受信される場合、バージョン、dataID、送信者アドレス、およびSNを確認した後、次のように処理する必要があります。
1. For Mode 2 messages, the sequence number field is used to associate the required positive acknowledgement with a specific Mode 2 message. If the message passes verification, the encapsulated user data is delivered to all applications that have indicated interest in the dataID and multicast address of the received message, regardless of the value of the SN field.
1. モード2メッセージの場合、シーケンス番号フィールドを使用して、必要な肯定的な確認を特定のモード2メッセージに関連付けます。メッセージが検証に合格した場合、カプセル化されたユーザーデータは、SNフィールドの値に関係なく、受信したメッセージのDataIDおよびマルチキャストアドレスへの関心を示すすべてのアプリケーションに配信されます。
2. Additionally, an ACK MUST be sent to the host from which the Mode 2 data message originated. See section 5.3.3. below for details.
2. さらに、ACKをホストに送信する必要があります。ホストからは、モード2データメッセージが発信されます。セクション5.3.3を参照してください。詳細については、以下。
A positive acknowledgement (ACK) is triggered by the receipt of a Mode 2 data message. To send an ACK, a new SRT message is generated with version set to 0x02, message type set to 0x2, and transmission mode set to 0x2. The dataID and SN are those of the Mode 2 data message being acknowledged. The destination address field is set to the source IP address from which the data message was received. Since Mode 2 data messages are unicast, there is little concern about an ACK implosion causing excessive congestion at the original sender, so no suppression mechanism is necessary.
モード2データメッセージを受信することにより、肯定的な承認（ACK）がトリガーされます。ACKを送信するには、新しいSRTメッセージが0x02に設定され、メッセージタイプが0x2に設定され、送信モードが0x2に設定された新しいSRTメッセージが生成されます。DataIDとSNは、確認されているモード2データメッセージのものです。宛先アドレスフィールドは、データメッセージが受信されたソースIPアドレスに設定されます。モード2のデータメッセージはユニキャストであるため、ACKの爆発が元の送信者に過度の鬱血を引き起こすことについてはほとんど懸念があるため、抑制メカニズムは必要ありません。
When an ACK is received by SRT, after verifying the transmission mode, dataID, and source IP address against outstanding Mode 2 transmission, SRT MUST remove the pending transmission from its buffer.
ACKがSRTによって受信された場合、送信モード、DataID、およびSource IPアドレスを未解決のモード2送信に対して検証した後、SRTはバッファーから保留中の送信を削除する必要があります。
This section provides answers to the questions posed by RFC 2357 for reliable multicast protocols, which are quoted.
このセクションでは、引用されている信頼性の高いマルチキャストプロトコルについて、RFC 2357が提起した質問に対する回答を提供します。
"How scalable is the protocol to the number of senders or receivers in a group, the number of groups, and wide dispersion of group members?"
「グループ内の送信者または受信機の数、グループの数、およびグループメンバーの幅広い分散に対するプロトコルはどの程度スケーラブルですか？」
SRMP is intended to scale at least to hundreds of group members. It has been designed not to impose limitations on the scalability of the underlying multicast network. No problems have been identified in its mechanisms that would preclude this on uncongested networks.
SRMPは、少なくとも数百人のグループメンバーにスケーリングすることを目的としています。基礎となるマルチキャストネットワークのスケーラビリティに制限を課さないように設計されています。そのメカニズムに問題は特定されていません。このメカニズムは、充実していないネットワークでこれを排除することです。
"Identify the mechanisms which limit scalability and estimate those limits."
「スケーラビリティを制限し、それらの制限を推定するメカニズムを特定します。」
There is a practical concern with use of TFMCC, in that the receiver with the most congested path constrains delivery to the entire group. Distributed virtual simulation requires data delivery at rates perceived as continuous by humans. Therefore, it may prove necessary to assign such receivers to different, lower-fidelity groups as a practical means of sustaining performance to the majority of participating hosts. SRMP does not have a mechanism to support such pruning at this time.
TFMCCの使用には実際的な懸念があります。これは、最も混雑した経路を持つ受信者がグループ全体への配信を制限するという点で、実際に懸念しています。分散仮想シミュレーションには、人間によって連続的であると認識されるレートでのデータ配信が必要です。したがって、参加しているホストの大半にパフォーマンスを維持するための実際的な手段として、そのようなレシーバーを異なる低忠実度グループに割り当てる必要があることが証明されるかもしれません。SRMPには、現時点でそのような剪定をサポートするメカニズムはありません。
"How does the protocol protect the Internet from congestion? How well does it perform? When does it fail? Under what circumstances will the protocol fail to perform the functions needed by the applications it serves? Is there a congestion control mechanism? How well does it perform? When does it fail?"
「プロトコルはどのように輻輳からインターネットを保護しますか？それはどの程度うまく機能しますか？いつ失敗しますか？どのような状況では、プロトコルが提供するアプリケーションで必要な機能を実行できませんか？混雑制御メカニズムはありますか？それは実行されますか？いつ失敗しますか？」
Both simulations and tests indicate that SRMP with TFMCC displays backoff comparable to that of TCP under conditions of significant packet loss. The mechanism fails in a network-friendly way, in that under severe congestion, it reduces sending of the best-effort traffic to a very small rate that typically is unsatisfactory to support a virtual simulation. This is possible because the reliable traffic typically is a small percentage of the overall traffic and SRMP is NACK oriented, with NACK suppression, so that reliable traffic loss adds little traffic to the total. If the traffic mix assumption is not met, the reliable traffic (which does not back off under increased RTT) could produce a higher level of traffic than a comparable TCP connection. However, levels of reliable traffic this large are not in the intended application domain of SRMP.
シミュレーションとテストの両方が、TFMCCを備えたSRMPが、重大なパケット損失の条件下でTCPのバックオフに匹敵するバックオフを表示することを示しています。メカニズムは、ネットワークに優しい方法で失敗します。それは、深刻な輻輳の下で、仮想シミュレーションをサポートするのに一般的に不十分な非常に小さなレートへのベストエフォルトトラフィックの送信を減らすことです。これは、信頼できるトラフィックは通常、トラフィック全体のわずかな割合であり、SRMPがNACK抑制を伴うNACK指向であるため、信頼できるトラフィックの損失が合計にほとんどトラフィックを追加しないためです。トラフィックミックスの仮定が満たされていない場合、信頼できるトラフィック（RTTの増加の下では後退しません）は、同等のTCP接続よりも高いレベルのトラフィックを生成する可能性があります。ただし、これが大きい信頼できるトラフィックのレベルは、SRMPの意図したアプリケーションドメインにはありません。
"Include a description of trials and/or simulations which support the development of the protocol and the answers to the above questions."
「プロトコルの開発と上記の質問への回答をサポートする試行および/またはシミュレーションの説明を含めます。」
SRMP has been simulated using a discrete event simulator developed for academic use [8]. The design assumptions were validated by the results. It also has been emulated in a LAN-based cluster and application-tested in a wide-area testbed under its intended traffic mix (distributed virtual simulation) and using a traffic generator with losses emulated by random dropping of packets [9].
SRMPは、学業用に開発された離散イベントシミュレーターを使用してシミュレートされています[8]。設計の仮定は、結果によって検証されました。また、LANベースのクラスターでエミュレートされ、意図したトラフィックミックス（分散仮想シミュレーション）の下で幅広いエリアテストでテストされ、パケットのランダムドロップによってエミュレートされた損失を伴うトラフィックジェネレーターを使用しています[9]。
"Include an analysis of whether the protocol has congestion avoidance mechanisms strong enough to cope with deployment in the Global Internet, and if not, clearly document the circumstances in which congestion harm can occur. How are these circumstances to be prevented?"
「プロトコルがグローバルなインターネットでの展開に対処するのに十分なcomming回避メカニズムを持っているかどうかの分析を含め、そうでない場合は、混雑の危害が発生する可能性がある状況を明確に文書化します。これらの状況はどのように防止されますか？」
Because it provides sending backoff comparable to TCP, SRMP is able to function as well as TCP for congestion avoidance, even in the Global Internet. The only way an SRMP sender can generate congestion is to use the protocol for unintended purposes, for example, reliable transmission of a large fraction of the traffic. Doing this would produce unsatisfactory results for the application, as SRMP's mechanism for providing reliability will not function well if the best-effort traffic does not constitute the majority of the total traffic.
TCPに匹敵するバックオフの送信を提供するため、SRMPは、グローバルなインターネットであっても、混雑回避のためにTCPと同様に機能することができます。SRMP送信者が混雑を生成できる唯一の方法は、意図しない目的でプロトコルを使用することです。たとえば、トラフィックの大部分の信頼できる送信です。これを行うと、信頼性を提供するためのSRMPのメカニズムは、最良のエフォルトトラフィックが総トラフィックの大部分を構成しない場合、適切に機能しないため、アプリケーションに不十分な結果が生じます。
"Include a description of any mechanisms which contain the traffic within limited network environments."
「限られたネットワーク環境内のトラフィックを含むメカニズムの説明を含めます。」
SRMP has no such mechanisms, as it is intended for use over the open Internet.
SRMPには、オープンなインターネットでの使用を目的としているため、そのようなメカニズムはありません。
"Reliable multicast protocols must include an analysis of how they address a number of security and privacy concerns."
「信頼できるマルチキャストプロトコルには、多くのセキュリティおよびプライバシーの懸念にどのように対処するかの分析を含める必要があります。」
See section 7 below.
以下のセクション7を参照してください。
As a transport protocol, SRMP is subject to denial of service by hostile third parties sending conflicting values of its parameters on the multicast address. SRMP could attempt to protect itself from this sort of behavior. However, it can be shielded from such attacks by traffic authentication at the network layer, as described below. A comparable level of authentication also could be obtained by a message using MD5, or a similar message hash in each bundle, and using the SRMP bundle header to detect duplicate transmissions from a given host. However, this would duplicate the function of existing network layer authentication protocols.
輸送プロトコルとして、SRMPは敵対的な第三者がマルチキャストアドレスにそのパラメーターの矛盾する値を送信することにより、サービスの拒否の対象となります。SRMPは、この種の動作から身を守ろうとすることができます。ただし、以下で説明するように、ネットワークレイヤーでのトラフィック認証により、このような攻撃から保護できます。同等のレベルの認証は、MD5を使用したメッセージ、または各バンドルで同様のメッセージハッシュを使用し、SRMPバンドルヘッダーを使用して特定のホストからの重複送信を検出することでも取得できます。ただし、これにより、既存のネットワークレイヤー認証プロトコルの機能が複製されます。
Specific threats that can be eliminated by packet-level authentication are as follows:
パケットレベルの認証によって排除できる特定の脅威は次のとおりです。
a. Amplification attack: SRMP receivers could be manipulated into sending large amounts of NACK traffic, which could cause network congestion or overwhelm the processing capabilities of a sender. This could be done by sending them faked traffic indicating that a reliable transmission has been lost. SRMP's NACK suppression limits the effect of such manipulation. However, true protection requires authentication of each bundle.
a. 増幅攻撃：SRMPレシーバーを操作して大量のNACKトラフィックを送信することができます。これは、信頼できるトランスミッションが失われたことを示す偽造トラフィックを送信することで実行できます。SRMPのNACK抑制は、そのような操作の影響を制限します。ただし、真の保護には各バンドルの認証が必要です。
b. Denial-of-service attack: If an SRMP sender accepts a large number of forged NACKs, it will flood the multicast group with repair messages. This attack also is stopped by per-bundle authentication.
b. サービス拒否攻撃：SRMP送信者が多数の鍛造NACKを受け入れると、マルチキャストグループに修理メッセージがあふれます。この攻撃は、バンドルごとの認証によっても停止されます。
c. Replay attack: The attacker could copy a valid, authenticated bundle containing a NACK and send it repeatedly to the original sender of the NACKed data. Protection against this attack requires a sequence number per transmission per source host. The SRMP bundle header sequence number would satisfy this need. However, the SN also can be applied at a lower layer.
c. リプレイ攻撃：攻撃者は、NACKを含む有効で認証されたバンドルをコピーして、Nackedデータの元の送信者に繰り返し送信できます。この攻撃に対する保護には、ソースホストごとの送信ごとのシーケンス番号が必要です。SRMPバンドルヘッダーシーケンス番号は、このニーズを満たします。ただし、SNは下層でも適用できます。
d. Reverse path forwarding attack (spoofing): If checks are not enabled in all network routers and switches along the path from each sender to all receivers, forged packets can be injected into the multicast tree data path to manipulate the protocol into sending a large volume of repairs. Packet-level authentication can eliminate this possibility.
d. リバースパス転送攻撃（スプーフィング）：各ネットワークルーターと各送信者からすべてのレシーバーにパスに沿ってチェックが有効になっていない場合、鍛造パケットをマルチキャストツリーデータパスに注入して、プロトコルを操作して大量の大量を送信します修理。パケットレベルの認証は、この可能性を排除できます。
e. Inadvertent errors: A receiver with an incorrect or corrupted implementation of TFMCC could respond with values of RTT that might stimulate a TFMCC sender to create or increase congestion in the path to that sender. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.
e. 不注意なエラー：TFMCCの誤ったまたは破損した実装を備えたレシーバーは、TFMCC送信者を刺激してその送信者への道の混雑を作成または増加させる可能性のあるRTTの値で応答できます。したがって、受信者は、セッションに参加するために必要なセッションの説明を受け取る前に、自分自身を正当であると特定する必要があることをお勧めします。受信者が自分自身を合法として識別する方法は、このドキュメントの範囲外です。
The required authentication could become part of SRMP or could be accomplished by a lower layer protocol. In any case, it needs to be (1) scalable and (2) not very computationally demanding so it can be performed with minimal delay on a real-time virtual simulation stream. Public-key encryption meets the first requirement but not the second. Using the IPsec Authentication Header (AH) (RFC 4302 [3]) meets the second requirement using symmetric-key cryptography. See RFC 4302 [3] for guidance on multicast per-packet authentication. In practice, users of distributed simulation are likely to work over a (possibly virtual) private network and thus will not need special authentication for SRMP.
必要な認証は、SRMPの一部になる可能性があるか、下層プロトコルによって達成される可能性があります。いずれにせよ、（1）スケーラブルであり、（2）あまり計算的に要求されていないため、リアルタイムの仮想シミュレーションストリームで最小限の遅延で実行できます。パブリックキー暗号化は、最初の要件を満たしていますが、2番目の要件ではありません。IPSEC認証ヘッダー（AH）（RFC 4302 [3]）を使用すると、対称キー暗号化を使用して2番目の要件を満たします。マルチキャストごとのパケット認証に関するガイダンスについては、RFC 4302 [3]を参照してください。実際には、分散シミュレーションのユーザーは（おそらく仮想）プライベートネットワークで動作する可能性が高いため、SRMPの特別な認証は必要ありません。
ACK - positive acknowledgement AH - Authentication Header CLR - current limiting receiver IPSEC - Internet Protocol Security MTU - maximum transmission unit NACK - negative acknowledgement RTT - round-trip time SA - security association SRMP - Selectively Reliable Multicast Protocol SRT - Selectively Reliable Transport TFMCC - TCP-Friendly Multicast Congestion Control
ACK-肯定的な承認AH-認証ヘッダーCLR-現在の制限レシーバーIPSEC-インターネットプロトコルセキュリティMTU-最大送信ユニットNACK -NEGATION AUMPONDACTING RTT -ROUND -TRIP TIME SA-セキュリティアソシエーションSRMP-選択的に信頼できるマルチキャストプロトコルSRT-選択的に信頼できる輸送TFMCC-TCPに優しいマルチキャスト輻輳制御
We gratefully acknowledge the significant contributions of two people without whom this RFC would not have been developed. Vincent Laviano created the first specification and implementation of SRMP (at that time called SRTP). Babu Shanmugam employed SRMP in a sizable distributed virtual simulation environment, where he revised the implementation and helped revise the design to support distributed virtual simulation workload effectively.
このRFCが開発されなかった2人の2人の重要な貢献に感謝します。Vincent Lavianoは、SRMPの最初の仕様と実装を作成しました（当時はSRTPと呼ばれます）。Babu Shanmugamは、かなりの分散分布の仮想シミュレーション環境でSRMPを採用し、実装を改訂し、分散仮想シミュレーションワークロードを効果的にサポートするために設計を修正しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] J. Widmer, M. Handley, Extending Equation-Based Congestion Control to Multicast Applications, ACM SIGCOMM Conference, San Diego, August 2001. <http://www.sigcomm.org/sigcomm2001/p22- widmer.pdf>
[2] J. Widmer、M。Handley、方程式ベースの混雑制御をマルチキャストアプリケーションに拡張、ACM Sigcomm Conference、サンディエゴ、2001年8月。
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[4] Pullen, M., Myjak, M., and C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment", RFC 2502, February 1999.
[4] Pullen、M.、Myjak、M。、およびC. Bouwens、「分散シミュレーションのためのインターネットプロトコルスイートの制限大規模なマルチキャスト環境」、RFC 2502、1999年2月。
[5] J. Padhye, V. Firoiu, D. Towsley and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of ACM SIGCOMM 1998.
[5] J. Padhye、V。Firoiu、D。Towsley、J。Kurose、「モデリングTCPスループット：単純なモデルとその経験的検証」、ACM Sigcomm 1998の議事録。
[6] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[6] Mankin、A.、Romanow、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[7] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[7] フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[8] J. M. Pullen, "The Network Workbench: Network Simulation Software for Academic Investigation of Internet Concepts," Computer Networks Vol 32 No 3 pp 365-378, March 2000.
[8] J. M. Pullen、「ネットワークワークベンチ：インターネット概念の学術調査のためのネットワークシミュレーションソフトウェア」、コンピューターネットワークVol 32 No 3 PP 365-378、2000年3月。
[9] J. M. Pullen, R. Simon, F. Zhao and W. Chang, "NGI-FOM over RTI-NG and SRMP: Lessons Learned," Proceedings of the IEEE Fall Simulation Interoperability Workshop, paper 03F-SIW-111, Orlando, FL, September 2003.
[9] J. M.プーレン、R。サイモン、F。Zhao、W。チャン、「RTI-NGおよびSRMPをめぐるNGI-FOM：学んだ教訓」2003年9月。
[10] D. Cohen, "NG-DIS-PDU: The Next Generation of DIS-PDU (IEEE-P1278)", 10th Workshop on Standards for Interoperability of Distributed Simulations, March 1994.
[10] D. Cohen、「Ng-Dis-PDU：次世代のDIS-PDU（IEEE-P1278）」、1994年3月、分散シミュレーションの相互運用性の基準に関する第10回ワークショップ。
[11] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[11] Handley、M.、Floyd、S.、Whetten、B.、Kermode、R.、Vicisano、L。、およびM. Luby、「バルクデータ転送用の信頼できるマルチキャスト設計スペース」、RFC 2887、2000年8月。
[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[12] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コード（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[13] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[13] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 3451、2002年12月。
[14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[14] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 3452、2002年12月。
[15] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[15] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
Authors' Addresses
著者のアドレス
J. Mark Pullen C4I Center George Mason University Fairfax, VA 22030 USA
J.マークプーレンC4Iセンタージョージメイソン大学フェアファックス、バージニア州22030米国
EMail: mpullen@gmu.edu
Fei Zhao C4I Center George Mason University Fairfax, VA 22030 USA
Fei Zhao C4I Center George Mason University Fairfax、VA 22030 USA
EMail: fzhao@netlab.gmu.edu
Danny Cohen Sun Microsystems M/S UMPK16-160 16 Network Circle Menlo Park, CA 94025 USA
Danny Cohen Sun Microsystems M/S UMPK16-160 16ネットワークサークルメンロパーク、カリフォルニア州94025 USA
EMail: danny.cohen@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。