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)
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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）は、任意の-to-anyのベストエフォート型トラフィックは信頼性の高いトラフィックよりも有意に大きい音量で発生するマルチキャスト環境での信頼性が高く、ベストエフォート型のメッセージのミックスを提供することを目的とトランスポートプロトコルであり、したがって、損失の検出のための信頼性の高いメッセージのシーケンス番号を運ぶことができます。 SRMPは、任意の特定のデータ識別子のための信頼性の高い伝送の唯一の最新の値が配信を要求する分散シミュレーションのアプリケーション環境での使用を意図しています。メッセージ集約及び輻輳制御を扱う結束サブレイヤ、選択的信頼性の高いトランスポート（SRT）サブレイヤ：SRMPは、二つの副層を有しています。信頼性が高く、ベストエフォート型のメッセージ間の選択は、アプリケーションによって実行されます。
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).
マルチキャストネットワーク上で信頼性の高い輸送を達成するために何も実行可能な汎用的なアプローチではありません。既存の成功したアプローチは、トランスポートプロトコルは、もともとコーエン[10]によって提案された方法で、トラフィックの特殊な性質を利用することが必要です。ごく一部のベストエフォート型メッセージの優勢の流れと混合し、信頼性の高い配信を、必要な：ここで説明するプロトコルは、メッセージの二つのカテゴリーの混合物を含むリアルタイムトラフィックに適用されます。トラフィックのこの種は、分散仮想シミュレーション（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のRFCを生産している信頼性の高いマルチキャストトランスポート（RMT）に成功したワーキンググループが行った2357年[6]、2887 [11]、及び3450 3453を介して - 信頼できるマルチキャストのためのビルディング・ブロック・プロトコルを定義[12 15]。選択的に信頼性の高いマルチキャストは、これらのプロトコルとその精神において似ており、実際には、それらの1つを使用するTCPフレンドリーマルチキャスト輻輳制御（TFMCC）。この文書では、実験的に使用するため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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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.
[2]、の順にウィドマーとハンドレーによって提案されているように、選択的に信頼性の高いトランスポート（SRT）とTCPフレンドリーマルチキャスト輻輳制御を実装する「バンドルサブレイヤ」（TFMCC）選択的高信頼マルチキャストプロトコル（SRMP）は2つの主要コンポーネントを有します輻輳回避のための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のための基本的な戦略は、各送信者に最近送信された信頼性の高いメッセージをバッファリングすると、関連するベストエフォート型のメッセージにシーケンス番号をピギーバックで信頼性のためにできるだけ少ないネットワーク容量を取引することです。この目的のために、送信の三つのモードが定義されています。
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メッセージの損失が検出されると、受信機はSRMPは、その送信者から最新の信頼性の高いメッセージを再送信する送信者にNACKを返送します。送信者は、複数の信頼性のあるメッセージがサポートされるストリーム可能、データ識別子（dataIDs）を定義します。モード1のメッセージは、最大131071バイト長であってもよく、 SRMPは、セグメンテーションと再構築のために提供しますが、唯一の任意の<sourceAddress、multicastAddress、データID>の最新モード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層の挙動はウィドマーとハンドリーによって記述メカニズムに従います。これは、方程式ベースのマルチキャスト輻輳制御メカニズムである：マルチキャストグループに、各受信機は、送信者に関して、その損失率を決定し、そのモデルTCPの定常状態の送信レートを式に基づいて所望のソース送信速度を算出します。分布帰還抑制機構は、最低希望レートを報告する可能性が高いこれらの受信機へのフィードバックを制限します。輻輳制御をランダムにベストエフォート（モード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は、ベストエフォート型の更新は、通常、すべてのシミュレーション情報の同じ種類を表しており、大量のネットワーク活動の期間中に一つだけMTU下のサイズの束にグループ化されているので、ほとんど同じサイズである可変サイズのSRMPメッセージに適用します。予想通り、彼らがサポートすることを意図されたトラフィックSRMPのタイプに適したことを証明する場合は、可変サイズのメッセージに対するTFMCCでの今後の展開は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ためのよく知られたポートを持つことが適切ではありません。
--------------------------------------------------------------------
| 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は、IPv4アドレスであってもよい、その32ビットSENDER_IDを使用して送信側と受信側を識別する。 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
フラグ：0001 Is_CLR他のビットは予約4ビット
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：受信機フィードバックメッセージの16ビット（ミリ秒）Receiver_Time_Stampフィールドのエコー。送信者がフィードバックを受信し、タイムスタンプをエコー間の時間遅延を持っている場合は、それが補償する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ビット抑制率は、ビット/秒では、送信側に対応します。その所望の速度抑制率未満である、又はその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：ヘッダに続くDSNブロックの8ビット数。
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の実装は、3つのフィールドから構成され、各DSN 1の最小値をサポートする必要があります。
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.
データID：16ビットモード1のメッセージを識別するために使用される送信側ホスト上の特定のデータ要素に関連付けられた一意の番号。 SN：特定のデータIDの特定のモード1の送信に関連付けられた9ビットのシーケンス番号。 NoSegs：7ビットセグメントの数、データIDは、セグメント化を必要とするのに十分な長さであれば、そうでない場合は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.
DSNの数が異なるモード1 DataIDsの数を反映SRMPのこのインスタンスにより、この時点で支持され、この送信にバンドル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_loss 0100 - - have_RTT 0010 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ビット符号なし指数8ビットと符号なしの仮数のための8ビットのTCP向け、16ビット浮動小数点値に受信機により算出され、ビット/秒で速度X_Rを送信希望しました。
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：バンドルヘッダ16ビットSender_Timestampのエコー。受信機は、バンドルを受信して、タイムスタンプをエコー間の時間遅延を有する場合、それはcorrespondently 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は別個の要素であるのに対し、これはNoSegsが含まれていることに注意してください。
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
なしなしMSは50〜250ミリ秒HEARTBEAT_INTERVAL 1どれもMode2_Max 1なしメッセージは、グループのMSになし最悪のRTTをACK_Threshold sはない1〜10ミリ秒Bundle_Timeout Segment_Timeout dataID_Timeout DSN_Max 1件の32メッセージ
The RECOMMENDED throughput equation for SRMP is a slightly simplified version of the throughput equation for Reno TCP from [5]:
SRMPに対して推奨スループット方程式[5]からリノ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.
バンドルで、同じデータIDを持つ複数のSRMPメッセージが存在してもよいです。この場合、そのデータIDの最新バージョンのみが有効です。 SRMPは同じバンドル内の重複dataIDsをチェックし、最新のものはなく、すべてを削除する場合があります。モード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 <データID、SN、NoSegs>を含みます。 DSNの絶対最大数は255です。しかし、実装がユーザ指定DSN_Maxを適用することができる、小さくない1以上の実装は、新しいモード1メッセージが送信されていない限り、指定されたデータIDがバンドルヘッダに発表されることはありませんその後、ユーザー定義dataID_Timeoutをサポートすることができます。バンドルヘッダに収まるよりも、送信者が送信され、よりdataIDsを持っている（とタイムアウトしていない）場合は、DSNは何のバンドルヘッダが含まれているモード1つのメッセージのためのDSNを発表しないことを除いて、ラウンドロビン方式で発表しなければなりませんそのバンドル内。重複した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が必要であることを示している場合、いくつかのアプリケーションは、関心を示したためデータIDを保有する各DSNに対するNACKをスケジューリングすることを含みます。 NACKをバンドルに送信され、データメッセージにバンドルすることができます。 NACKがあれば必要とされています。
o the SN is one or more greater (mod 512) than the latest received Mode 1 message for that dataID, or
SNは、そのデータIDの最新の受信モード1メッセージより（512 MOD）は、1つ以上大きい、またはO
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>.
SEGNOを受信していないO、50ms未満であってはならない<データID、SN>受信されたいくつかのセグメント、およびユーザー定義Segment_Timeoutは、データID、<ための第SEGNOの受信から有効期限が切れていますSN>。
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.
結束サブレイヤはSRTサブレイヤに任意の受信されたバンドルヘッダにDSNのリストを渡します。次のセクションで説明したように、それはまた、発信バンドルに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内部破裂」の混雑を避けるために、マルチキャストメッセージのためにSRMPで使用されています。大規模なマルチキャストグループが混雑広域ネットワークに広がるとともにしかし、負の使用にもかかわらず、元の送信者にかなりの混雑を引き起こすために、メッセージの受信に失敗して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抑制機構は、適切な時間窓にわたってNACKを分配するBundle_Timeoutを使用します。これにより、ユーザーはリアルタイム応答性のためのアプリケーションのニーズに適したバンドルのタイムアウトを選択したことを前提としています。
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実装は1秒未満であってはならないユーザ定義HEARTBEAT_INTERVALをサポートすることができます。送信者が任意のバンドルを送信していない場合には、各ハートビート間隔の終了時に、空の束は、モード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は、信頼性の様々なレベルを提供するために、三つの異なる送信モードで動作：データの信頼性の高い伝送を必要としないマルチキャストデータのためのモード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では、「データID」は、相互に関連したメッセージを関連付けるために使用されます。典型的には、同じデータIDを持つすべてのメッセージが同じアプリケーション・エンティティに関連付けられています。同じデータIDを持つすべてのメッセージは、同じモードで送信する必要があります。同じデータIDを持つすべてのメッセージを、最新バージョンの意志時代遅れすべての古いメッセージの中で。
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メッセージを受信する前に、モード0メッセージは静かに捨てられるべきで任意のモード1のメッセージを受け取ったことがない場合。
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
モード1は、信頼性の高い伝送を必要とするマルチキャストデータのためです。モード1メッセージはデータメッセージ又はNACKのいずれかであり得ます。モード1のデータ・メッセージは、データ・ストリームの一部であると予想されます。このデータ・ストリームは、（セクション5.1.1を参照）にもモード0のメッセージが含まれている可能性があるが、
it is possible for a data stream to be comprised solely of Mode 1 messages.
データ・ストリームが単独モード1のメッセージで構成されることが可能です。
After the data length, dataID, and destination multicast group are verified, SRT MUST take the following steps:
検証され、データ長、データID、及び宛先マルチキャストグループの後、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メッセージは次の特性を持つ生成されますバージョンは0×02に設定され、メッセージの種類が0x0に設定され、送信モードが0x01のに設定され、SNは、最も最近送信モード1のSNに等しく設定されています1つのモジュロ512だけ増分同じデータIDの完全なメッセージは、そのようなモード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.新たに生成されたメッセージ（すべてのセグメント）は、同じデータID、宛先マルチキャストアドレスのいずれか以前バッファ・モード1のメッセージを交換し、バッファリングされなければなりません。メッセージをバッファリングすることができない場合は、ユーザデータは破棄され、エラーがアプリケーションに報告されます。
4. If step 2 was completed without error, the newly generated message is sent to the TFMCC sublayer.
前記ステップ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によって受信されると、次のように（バージョン・フィールドがすでに0×02であることが確認されていると仮定して）処理されます。
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.
新しいDSN値がゼロより大きいNoSegsで受信された場合4.タイマは、NACKが結束サブレイヤに送信されるべきであり、タイマーがSegment_Timeoutために再起動する必要があり、その後、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.
メッセージ本文、データID、たsource_IP_address、multicast_groupアドレス：7次の情報を受信するアプリケーションに提供されることが推奨されます。
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.
新しいマルチキャストグループへのクライアントの兆候は、そのマルチキャストグループに関連するすべてのローカルバッファリングモード1のメッセージはすぐにクライアントに配信されなければならない8。
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.
バンドルが受信されるたびに、結束サブレイヤはSRTサブレイヤにバンドルヘッダからDSNのリストを転送します。 SRTサブレイヤは、NACKが必要かどうかを判断するために、<SenderIDの、データID、SN、SEGNO>のバッファされた値を調べます。そうだとすれば、それはNACKメッセージを生成し、バンドルサブレイヤに送信します。 NACKメッセージは、0x2の、0x2のに設定されたメッセージタイプ、および0x7のに設定された送信モードに設定されたバージョンを有することになります。データID、SN、及び宛先アドレスがNACKが送信されているモード1メッセージのものに設定されています。 NACKは、NACK閾値内の問題のモード1つのメッセージの宛先マルチキャストグループの任意のメンバーから受信された場合は、NACKが発生しません。
For segmented messages, there are two possible types of NACKs:
セグメント化されたメッセージの場合、スナック2つの可能なタイプがあります。
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によって受信されると、データID、送信元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.データIDのSRTの最新モード1のメッセージのこのインスタンスは、NACKに示されている場合はNACKでSNより新しいSNを持っている、（バッファリングされた）というメッセージがすぐに受信NACKに示されているマルチキャストアドレスに再送信する必要があります。最新のモード1のメッセージは、SNに等しいSNは、NACKに示されており、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.
NACKを受信した時刻をバッファリングしなければならないメッセージの再送信において1結果、NACKおよび（ローカルマシン）を受信した場合、ステップかどうか2。 SRTの各インスタンスは、同じペアの最新のモード1のメッセージを受信してから、各データID、マルチキャストアドレスペアに対して受信されたNACKの数及びこれら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つの動的に決定された部材間のまれな信頼性の高いトランザクション指向通信のためのものです。モード2送信を必要とするホスト間のベストエフォートデータの継続的なストリームが既に存在するのに対し、TCPは、そのような通信のために使用することができるが、単一のデータ交換のためのストリーム指向の接続を確立することで、不必要なオーバーヘッド及び遅延が存在することになります。例は、分散型のインタラクティブシミュレーション（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のデータの場合、アプリケーション要求の送信、データIDと宛先ユニキャストIPアドレスが送信されるべきデータと共にSRTに提供されなければなりません。データ長、データID、及び宛先アドレスを確認した後、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メッセージは、次の特性を持つ生成されますバージョンは0×02に設定され、メッセージタイプは0×02に設定され、送信モードは0x2のに設定され、データIDは、アプリケーションが提供する値、および宛先アドレスに設定されていますアプリケーションが提供するIPアドレスに設定されています。 SNは、そのようなモード1のメッセージが存在しない場合、それは0x0に設定されている1つのモジュロ65536インクリメント同じデータIDの最も最近送信モード2メッセージのSNに等しく設定されます。
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のメッセージに代わるものではありません。実装は、一つ以上のモード2のメッセージを保持することができるモード2メッセージバッファを提供しなければなりません。モード2つのメッセージは、（総トラフィックの1％未満）稀であると予想、それはまだ強く実装は単一モード2のメッセージよりも多くを保持することができるユーザ設定サイズMode2_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アドレスに送信されなければなりません。 SRTメッセージを送信しようとする試みが行われたときに送信側システム上のUDPインターフェイスが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.いくつかのユーザ設定（マルチキャストグループのための最悪のケースの往復時間よりも大きくなければならない）「ACK_Threshold」経過モード2メッセージに対するACKを受信しなければ、それは再送信されます。モード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によって受信されると、それはバージョンを確認した後、次のように処理されるべき、データID、送信者アドレス、および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フィールドの値の、全てのデータIDに関心を示してきたアプリケーションと、受信したメッセージのマルチキャストアドレスに配信されます。
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.
肯定応答（ACK）は、モード2のデータメッセージの受信によってトリガされます。 ACKを送信するために、新しいSRTメッセージは0×02にバージョンセットを0x2に設定されたメッセージタイプ、およびを0x2に設定された送信モードで生成されます。データIDと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によって受信されると、未処理のモード2の伝送に対する送信モード、データID、および送信元IPアドレスを確認した後、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のそれに匹敵するバックオフを表示することを示しています。メカニズムはネットワークに優しい方法で失敗し、深刻な輻輳下という点で、それは一般的に仮想シミュレーションをサポートするために不十分である非常に小さな割合にベストエフォート型トラフィックの送信を低減します。信頼性の高いトラフィックの損失は合計に少しトラフィックを追加するように、信頼性の高いトラフィックは、通常、NACKの抑制と、トラフィック全体の小さな割合であるとSRMPが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]学術使用するために開発離散事象シミュレータを用いてシミュレートされています。デザインの仮定は、結果によって検証されました。また、[9]その意図したトラフィックミックス（分散仮想シミュレーション）下の広域テストベッドでのLANベースのクラスタおよびアプリケーション・テストでエミュレートし、パケットのランダムドロップでエミュレート損失とトラフィックジェネレータを使用しています。
"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?"
「プロトコルは、グローバルインターネットでの展開に対処するのに十分な強輻輳回避メカニズムを持っているかどうかの分析を含め、そうでない場合、明確にどのように防止することがこのような状況である。混雑害が発生する可能性のある状況を文書化？」
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。 DoS攻撃：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を含む有効な、認証済みのバンドルをコピーして、NACKされデータの元の送信者にそれを繰り返し送信することができます。この攻撃に対する保護は、ソースホスト当たりの伝送あたりのシーケンス番号が必要です。 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.
電子。不慮のエラーが：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）非常に計算要求しないことが必要です。公開鍵暗号は、最初の要件ではなく、秒を満たしています。 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 - 否定応答RTT - ラウンドトリップ時間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人の重要な貢献を認めます。ヴィンセントLavianoは（SRTPと呼ばれる当時）SRMPの最初の明細書および実施を作成しました。バブーShanmugam氏は、実装を改訂し、効果的に分散仮想シミュレーションのワークロードをサポートするために設計を見直し助けかなりの分散仮想シミュレーション環境でSRMPを採用しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.ウィドマー、M.ハンドレー、マルチキャストアプリケーションに式ベースの輻輳制御を拡張し、ACM SIGCOMM会議、サンディエゴ、2001年8月<http://www.sigcomm.org/sigcomm2001/p22- widmer.pdf>
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3]ケント、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]プーレン、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.黒瀬、 "モデル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]マンキン、A.、Romanow、A.、ブラドナー、S.、およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するための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.プーレン、「ネットワークワークベンチ：インターネットの概念の学術研究のためのネットワークシミュレーションソフトウェア、」コンピュータネットワーク巻32ノー3頁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] JMプーレン、R.サイモン、F.趙及びW.チャン、 "RTI-NGとSRMPオーバーNGI-FOM：教訓、" IEEEの議事録は、シミュレーションの相互運用性ワークショップ、紙03F-SIW-111、オーランド秋、FL、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.コーエン、 "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]ハンドリー、M.、フロイド、S.、Whetten、B.、Kermode、R.、Vicisano、L.、およびM.ルビー、 "大量データ転送のための信頼できるマルチキャストデザインスペース"、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]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、RFC 3450 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、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]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "階層化符号化トランスポート（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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453 、2002年12月。
Authors' Addresses
著者のアドレス
J. Mark Pullen C4I Center George Mason University Fairfax, VA 22030 USA
J.マーク・プーレンC4Iセンタージョージ・メイソン大学フェアファックス、VA 22030 USA
EMail: mpullen@gmu.edu
メールアドレス：mpullen@gmu.edu
Fei Zhao C4I Center George Mason University Fairfax, VA 22030 USA
鉄I趙C4Iセンタージョージ・メイソン大学フェアファックス、VA 22030 USA
EMail: fzhao@netlab.gmu.edu
メールアドレス：fzhao@netlab.gmu.edu
Danny Cohen Sun Microsystems M/S UMPK16-160 16 Network Circle Menlo Park, CA 94025 USA
ダニー・コーエンSun MicrosystemsのM / S UMPK16-160 16ネットワークサークルメンロパーク、CA 94025 USA
EMail: danny.cohen@sun.com
メールアドレス：danny.cohen@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。