RFC4410 日本語訳
4410 Selectively Reliable Multicast Protocol (SRMP). M. Pullen, F.Zhao, D. Cohen. February 2006. (Format: TXT=65877 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Pullen
Request for Comments: 4410 F. Zhao
Category: Experimental George Mason Univ
D. Cohen
Sun Microsystems
February 2006
コメントを求めるワーキンググループM.ピューレンの要求をネットワークでつないでください: 4410年のF.チャオカテゴリ: 実験的なジョージのメイスンUniv D.コーエンサン・マイクロシステムズ2006年2月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
Selectively Reliable Multicastプロトコル(SRMP)は、トランスポート・プロトコルであり、最も良い努力交通が信頼できる交通よりかなり大きいボリュームで起こるマルチキャストのいずれへのいずれも環境における、信頼できてベストエフォート型のメッセージのミックスを提供するつもりであり、したがって、損失検出への信頼できるメッセージの一連番号を運ぶことができます。 SRMPは分散シミュレーション適用環境における使用のために意図します。(そこでは、どんな特定のデータ識別子のための信頼できるトランスミッションの最新の値だけも配送を必要とします)。 SRMPには、2つの副層があります: バンドリング副層取り扱いメッセージ集合、輻輳制御、およびSelectively Reliable Transport(SRT)副層。 信頼できてベストエフォート型のメッセージの間の選択はアプリケーションで実行されます。
Pullen, et al. Experimental [Page 1] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[1ページ]RFC4410
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
1. 序論…3 1.1. 用語…3 2. 記述について議定書の中で述べてください…4 3. メッセージ形式…6 3.1. メッセージ・フォーマットを束ねてください: .....................................6 3.2. ヘッダー形式を束ねてください…7 3.3. フィードバックメッセージ・フォーマット…9 3.4. SRTモード0ヘッダー形式…10 3.5. SRTモード1ヘッダー形式…11 3.6. SRTモード2ヘッダー形式…11 3.7. SRTナックFormat…12 3.8. ユーザ構成可能なパラメタ…13 4. TFMCC操作…13 4.1. TCPは、TFMCCのために予測が方程式であると評定します…13 4.2. バンドリング…13 4.3. 混雑コントロール…14 4.4. いくらか、-、ソース、マルチキャスト…14 4.5. 複数のソース…14 4.6. サイズを束ねてください…15 4.7. データ信号速度コントロール…15 4.8. モード1損失検出…16 4.8.1. 否定的承認を送ります…16 4.9. アンバンドリング…17 4.10. 鼓動バンドル…17 5. SRT操作…17 5.1. モード0操作…18 5.1.1. 送付モード0メッセージ…18 5.1.2. 受信モード0メッセージ…18 5.2. モード1操作…18 5.2.1. 送付モード1データメッセージ…19 5.2.2. 受信モード1データメッセージ…19 5.2.3. 否定的承認を送ります…20 5.2.4. 否定的承認を受けます…21 5.3. モード2操作…21 5.3.1. 送付モード2データメッセージ…21 5.3.2. 受信モード2データメッセージ…22 5.3.3. 積極的な承認を送ります…23 5.3.4. 積極的な承認を受けます…23 6. RFC2357分析…23 6.1. スケーラビリティ…23 6.2. 混雑…24 7. セキュリティ問題…25 8. 使用される頭文字語のリスト…26 9. 貢献…27 10. 参照…27
Pullen, et al. Experimental [Page 2] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[2ページ]RFC4410
1. Introduction
1. 序論
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]によって提案された交通の特別な性質を利用するのを必要とします。 ここで説明されたプロトコルはメッセージの2つのカテゴリのミックスを含むリアルタイムの交通に適切です: ベストエフォート型メッセージの勝つ流動に混ぜられた信頼できる配信を必要とするわずかな断片。 この種類の交通は分配された仮想シミュレーションに関連しています。(RFC2502[4])といくつかのフォームの分散型マルチメディア会議でも。 これらのアプリケーションにはめったに、または全く変化しないいくつかのデータが通常あるので、最高効率はそのデータを確かに送ることによって、実現されるでしょう(シミュレートされた乗り物の外部の外観は好例です)。 また、彼らはベストエフォート型流れ(例えば、乗り物の位置とオリエンテーション)のリアルタイムのトランスミッションを必要とします。 通常新しいアップデートが損失識別と「再-トランスミッション」が行われることができたより速く到着するので、この流れの信頼できるトランスミッションへの値が全くありません。 交通の各バンドルで最新の信頼できるトランスミッションの一連番号(SN)を背負うことによって、信頼できてベストエフォート型の交通は相乗効果的に共存できます。 このアプローチはSelectively Reliable Multicastプロトコル(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は信頼できるマルチキャストのためにブロックプロトコルを定義する3453[12--15]を通してRFCs2357[6]、2887[11]、および3450を生産したReliable Multicast Transport(RMT)でうまくいっているワーキンググループを指導しました。 選択的に信頼できるマルチキャストは、精神においてこれらのプロトコルと同様であり、事実上、それら(TCP好意的なMulticast Congestion Control(TFMCC))の1つを使用します。 このドキュメントは使用のために実験的にSRMPを指定する基礎にTFMCCを提供します。 ここで進展するRMTの過程の主要な要件はRFC2357[6]で指定されます。 これらは、一般に、スケーラビリティと輻輳制御に関連して、このドキュメントのセクション6で記述されます。
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[1]について説明して、対応する実現のために要件レベルを示すとき解釈されることであるべきですか?
Pullen, et al. Experimental [Page 3] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[3ページ]RFC4410
2. Protocol Description
2. プロトコル記述
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.
Selectively Reliable Multicastプロトコル(SRMP)には、2個の主要コンポーネントがあります: 選択的である、ウィトマーとハンドレー[2]によって提案されるように輻輳回避のためのRFC2357[6]に関する必要条件を満たすために、TCP好意的なMulticast Congestion Control(TFMCC)を実行するReliable Transport(SRT)と「バンドリング副層。」
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メッセージ。 Modeに関する1つのメッセージの損失が検出されるとき、受信機は送付者にナックを返送するでしょう、SRMPがその送付者から最新の信頼できるメッセージを再送するところで。 複数の信頼できるメッセージストリームが支持されるのを許容して、送付者はデータ識別子(dataIDs)を定義します。 モード1メッセージは最大13万1071バイト長であるかもしれません。 <sourceAddress、multicastAddress、dataID>を考えて、SRMPは分割と再アセンブリ、しかし、単にいずれへの最新のMode1メッセージに提供します。
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メッセージ。 Mode2メッセージを通して、SRMPはライト級(マルチキャストグループのどんな2人のメンバーの間の信頼できて、コネクションレスなピアツーピアユニキャスト取引交換)に備えます。 これは積極的な承認(ACK)を必要とするユニキャストメッセージです。
| Application |
----------------- ----------
| SRT |
----------------- -> SRMP
|Bundling(TFMCC)|
----------------- ----------
| UDP |
| アプリケーション| ----------------- ---------- | SRT| ----------------- ->SRMP|バンドリング(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.
バンドリング副層はSelectively Reliable Transport(SRT)副層に透明です。 それは、必要であるとソースでMode0メッセージを落として、短いタイムウィンドウの中にアプリケーションで提示される複数の短いメッセージを束ねることによって、輻輳制御を実行します。 また、それはナックの抑圧を実行します。
Pullen, et al. Experimental [Page 4] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[4ページ]RFC4410
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.
バンドリング副層データ単位はバンドルと呼ばれます。 バンドルはバンドルヘッダーと1Mode0とMode1SRMPメッセージで作られます。 Mode1メッセージのRetransmissionはオリジナルのバンドルの「再-トランスミッション」を含意しません。 再送されたメッセージは新しいバンドルの一部になります。
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)メッセージを落とすことによって、達成されます。 例えば、分配されたシミュレーションで、Mode0メッセージは地理的な位置などのダイナミックなデータのための州のアップデートの流れの一部です。 したがって、アプリケーションは、それらが落とされるとき、機能し(下側の信義で)続けることができます。
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 各受信機は損失イベント率とそのRound-旅行Time(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が、計算されたレートが現在の送付レートより高いと報告するとき、送付レートは増加します。
Pullen, et al. Experimental [Page 5] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[5ページ]RFC4410
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はベストエフォート型アップデートがすべて、通常同じ種類のシミュレーション情報を表すのでほとんど同じサイズである可変サイズSRMPメッセージにそれを適用して、重いネットワーク活動の期間、ちょうど1未満のサイズMTUのバンドルに分類されます。 可変サイズメッセージのための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. Message Formats
3. メッセージ・フォーマット
3.1. Bundle Message Format:
3.1. メッセージ・フォーマットを束ねてください:
-------------------------------------------------------------------- | bundle header | SRT Message 0 | SRT message 1 | SRT message 2 |... --------------------------------------------------------------------
-------------------------------------------------------------------- | バンドルヘッダー| SRTメッセージ0| SRTメッセージ1| SRTメッセージ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メッセージの集合です。 バンドルはMode0とMode1メッセージしか含むことができません。 ユニキャストアドレスを使用することでモード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との使用のために、ユーザ・グループは、1ホストあたり1つのユニークな識別子を確立する必要があるでしょう。 この識別子がインターネットで特有であるという要件が全くありません。 それは、交信グループで特有である必要があるだけです。
Pullen, et al. Experimental [Page 6] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[6ページ]RFC4410
3.2. Bundle Header Format
3.2. バンドルヘッダー形式
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 |
+-----------------------------------------------------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ|fb_nr| 旗| バンドル_SN| +--------------+--------------+--------------+--------------+ | 送付者_ID| +--------------+--------------+--------------+--------------+ | 受信機_ID| +--------------+--------------+--------------+--------------+ | 送付者_タイムスタンプ| 受信機_タイムスタンプ| +--------------+--------------+--------------+--------------+ | x_supp| R_最大| +--------------+--------------+--------------+--------------+ | DSN_カウント| 詰め物| 長さ| +--------------+--------------+--------------+--------------+ | 0〜255DSN: <dataID、SN、この送付者のNoSegs>。| +-----------------------------------------------------------+
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
以下に旗を揚げさせてください。 Is_CLR他の0001ビットが予約した4ビット
bundle_SN:
16 bits range 0-65535
_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.
送付者_タイムスタンプ: バンドルを出した(ミリセカンドで)時間の16ビットのRepresentingは送付者の地方の時計を基礎づけました。
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_Time_Stamp分野(ミリセカンドによる)の16ビットのEcho。 フィードバックを受けて、タイムスタンプを反映するとき、送付者に時間遅れがあるなら、それは代償するReceiver_Timestamp値を調整しなければなりません。
Pullen, et al. Experimental [Page 7] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[7ページ]RFC4410
Receiver_ID
32 bits Unique identifier for the receiver within the multicast
group. IPv4 addresses may be used.
マルチキャストグループの中の受信機のための受信機_ID32ビットUnique識別子。 IPv4アドレスは使用されるかもしれません。
Sender_ID:
32 bits Unique identifier for the sender within the multicast
group. IPv4 addresses may be used.
送付者_ID: マルチキャストグループの中の送付者への32ビットのUnique識別子。 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: ビット/sの送付者にとって、対応する抑圧率の16ビット。 必要なレートがR_最大より抑圧率かそれともだれのRTTが大きいかほどフィードバック情報を送付者に送らないかもしれないという、ことであるそれらの受信機だけ。 抑圧率は16ビットの浮動小数点値として無記名の解説者のための8ビットと無記名の仮数のための8ビットで表されます。
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_は最大限にします: 16ビット、ミリセカンドで表現されるすべての受信機のRTTsの最大。 Maximum RTTは16ビットの浮動小数点値として無記名の解説者のための8ビットと無記名の仮数のための8ビットで表されるべきです。
DSN_count:
8 bits The count of DSN blocks following the header.
DSN_カウント: ヘッダーに続くDSNのカウントが妨げる8ビット。
Length:
16 bits Range from 0~65535. The total length of the bundle
in octets (including the header).
長さ: 0~65535からの16ビットのRange。 八重奏(ヘッダーを含んでいる)における、バンドルの全長。
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ビットのThereは最大ヘッダーのこれらの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: Mode1メッセージを特定するのに使用される送付ホストの特定のデータ要素に関連している16ビットのAユニークな番号。 SN: 9ビットのSequence番号は特定のdataIDの1個のトランスミッションを特定のModeに関連づけました。 NoSegs: セグメントの7ビットのNumber dataIDが分割を必要とすることができるくらい長かったなら そうでなければ、0×0。
Pullen, et al. Experimental [Page 8] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[8ページ]RFC4410
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のこの例によって支持される異なったMode1DataIDsの数を反映して、このトランスミッションで束ねられた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増加しなければなりません。
3.3. Feedback Message Format
3.3. フィードバックメッセージ・フォーマット
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | fb_nr| flag | X_r |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ| fb_nr| 旗| X_r| +--------------+--------------+--------------+--------------+ | 送付者_タイムスタンプ| 受信機_タイムスタンプ| +--------------+--------------+--------------+--------------+ | 送付者_ID| +--------------+--------------+--------------+--------------+ | 受信機_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--_RTT0010を持ってください--_損失0100を持ってください--受信機_は他の値を予約されたままにします。
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: TCPに優しくなるように受信機によって計算されたビット/sでレートX_rを送りながら望まれていた16ビット、16は無記名の解説者のための8ビットと無記名の仮数のための8ビットで浮動小数点値に噛み付きました。
Pullen, et al. Experimental [Page 9] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[9ページ]RFC4410
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ビットのEcho。 バンドルを受けて、タイムスタンプを反映するとき、受信機に時間遅れがあるなら、それはSender_Timestamp値の対応を調整しなければなりません。
Receiver_Timestamp:
16 bits The time when the feedback message was sent out from the
receiver.
受信機_タイムスタンプ: 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).
受信機_ID: マルチキャストグループの中の受信機のための32ビットのUnique識別子。 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.)
送付者_ID: マルチキャストグループの中の送付者への32ビットのUnique識別子。 IPv4アドレスは使用されるかもしれません。 (電流帰還メッセージの目的地である送付者を特定します。)
3.4. SRT Mode 0 Header Format
3.4. SRTモード0ヘッダー形式
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 000 | 00000000 | Length |
+--------------+--------------+--------------+--------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ| 000 | 00000000 | 長さ| +--------------+--------------+--------------+--------------+
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ビットのLength。
Pullen, et al. Experimental [Page 10] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[10ページ]RFC4410
3.5. SRT Mode 1 Header Format
3.5. SRTモード1ヘッダー形式
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 001 | SegNo | Length |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ| 001 | SegNo| 長さ| +--------------+--------------+--------------+--------------+ | 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ビットのLength。
DSN:
32 bits Same as in the bundle header. Note that this contains
NoSegs, whereas SegNo is a separate element.
DSN: 32ビットのSame、バンドルヘッダーのように。 これがNoSegsを含んでいますが、SegNoが別々の要素であることに注意してください。
3.6. SRT Mode 2 Header Format
3.6. SRTモード2ヘッダー形式
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |010 | 00000 | Length |
+--------------+--------------+--------------+--------------+
| SN |
+--------------+--------------+--------------+--------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ|010 | 00000 | 長さ| +--------------+--------------+--------------+--------------+ | SN| +--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
バージョン: 4ビット、現在の0010
Type:
4 bits 0010
以下をタイプしてください。 4ビット0010
Mode:
3 bits 010
モード: 3ビット010
Pullen, et al. Experimental [Page 11] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[11ページ]RFC4410
Padding:
5 bits 00000
詰め物: 5ビット00000
Length:
16 bits Length of the payload data in octets (does not the
include header).
長さ: 八重奏(いずれのインクルードヘッダーもしない)におけるペイロードデータの16ビットのLength。
SN:
32 bits Same as in bundle header.
SN: 32ビットのSameは同じくらい中にヘッダーを束ねます。
3.7. SRT NACK Format
3.7. SRTナックFormat
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |111 | 00000 | reserved |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
| Sender Address |
+--------------+--------------+--------------+--------------+
0 8 16 24 32 +--------------+--------------+--------------+--------------+ |バージョン| タイプ|111 | 00000 | 予約されます。| +--------------+--------------+--------------+--------------+ | DSN| +--------------+--------------+--------------+--------------+ | 送付者アドレス| +--------------+--------------+--------------+--------------+
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.
送付者アドレス: NACKedであるメッセージ送信者のIPアドレス。
Pullen, et al. Experimental [Page 12] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[12ページ]RFC4410
3.8. User-Configurable Parameters
3.8. ユーザ構成可能なパラメタ
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
DSN_マックス1 32がdataID_Timeoutをなにもになにもに通信させる、ms Segment_Timeout50 250ms Bundle_Timeout1 10ms Heartbeat_Interval1、なにも、s Mode2_マックス1、なにも、中でなにもRTTを負かさないというメッセージACK_Thresholdはmsを分類します。
4. TFMCC Operation
4. TFMCC操作
4.1. TCP Rate Prediction Equation for TFMCC
4.1. TFMCCのためのTCPレート予測方程式
The RECOMMENDED throughput equation for SRMP is a slightly simplified version of the throughput equation for Reno TCP from [5]:
SRMPのためのRECOMMENDEDスループット方程式は[5]からのリノTCPのためのスループット方程式のわずかに簡易型のバージョンです:
8*s
X = ------------------------------------------------------ (1)
R * (sqrt(2*p/3) + (3*sqrt(6*p) * p * (1+32*p^2)))
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定石をこの方程式に代入するかもしれません。 要件はスループット方程式がconformant TCP輻輳制御のためのTCPの送付レートの合理的な近似であるということです。
4.2. Bundling
4.2. バンドリング
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かMode1)が到着すると、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
SRMPデーモンはタイマを保たなければなりません。(最初のSRMPメッセージがバンドルに加えられるとき、それは、リセットされるでしょう)。 Bundle_Timeout、タイマがタイムアウトを望んでいて、現在のバンドルが伝えられたべきであった後に
Pullen, et al. Experimental [Page 13] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[13ページ]RFC4410
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メッセージを保持するために初期化されるでしょう。 お勧めが評価する1つの原稿より少ない10が原稿でなかったなら_Timeout SHALLを束ねてください。
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バイト(IPを引いたイーサネットMTUと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は写しdataIDsがないかどうか同じバンドルでチェックして、最新のもの以外のすべてを削除するかもしれません。 Mode1メッセージが外向的なバンドルに現れるなら、対応する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.
バンドルヘッダーはこの送付者からのMode1メッセージのためにDSN<dataID、SN、NoSegs>を含んでいます。 DSNの絶対最大値番号は255です。 しかしながら、実現はユーザによって指定されたDSN_マックス、1より小さいノーを適用するかもしれません。 実現はユーザによって定義されたdataID_Timeoutを支持するかもしれません。(新しいMode1メッセージが送られないと、与えられたdataIDはその時、バンドルヘッダーで発表されなかったでしょう後)。 送付者が、より多くのdataIDsを送らせるなら(そして、外では、調節されていません)、バンドルヘッダーをうまくはめ込むより連続ベースでDSNsを発表しなければなりません、どんなバンドルヘッダーも、Mode1メッセージのためのDSNがそのバンドルの中に含んだと発表しない例外で。 写しDSNが受け取られているなら、それは静かに捨てられるかもしれません。
4.3. Congestion Control
4.3. 輻輳制御
The congestion control mechanism operates as described in [7].
混雑制御機構は[7]で説明されるように動作します。
4.4. Any-Source Multicast
4.4. いくらか、-、ソース、マルチキャスト
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はAny-ソースMulticast Modeを使用します。 各送付者は各送付者に関して最大のRTT、抑圧データ信号速度、および発信レートを測定するでしょう。 各受信機は、そのRTTと必要なレートをグループの各送付者に測定して、マルチキャストグループに発信することによって、すべての送付者にフィードバックを送るでしょう。
4.5. Multiple Sources
4.5. 複数のソース
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
SRMPの下では、マルチキャストグループのそれぞれのグループのメンバーは受信機と同様に送付者です。各受信機は、すべての送付者と共にTFMCC情報交換に参加する必要があるかもしれません。 aであるときに、したがって、受信機はaを送ります。
Pullen, et al. Experimental [Page 14] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[14ページ]RFC4410
feedback message, it must identify to which source the message should be sent using the "Sender ID" field in the header.
フィードバックメッセージ、それはヘッダーの「送付者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によって選択されたものにない受信機からのフィードバックメッセージは静かに捨てられるべきです。
4.6. Bundle Size
4.6. バンドルサイズ
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バイト(IPを引いたイーサネットMTUと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スループット方程式で使用されるでしょう。 この平均値は、ネットワーク状態から独立していて、ソースの現在の活動を反映します。
4.7. Data Rate Control
4.7. データ信号速度コントロール
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.
ソースレートが送付者の必要な通信速度より大きいなら、交通形成をするのは、送付者の責任です。 目標送付レートに従うどんな方法も使用されるかもしれません。 RECOMMENDED方法は手当たりしだいに目標金利を達成するMode0メッセージを十分捨てることです。
Pullen, et al. Experimental [Page 15] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[15ページ]RFC4410
4.8. Mode 1 Loss Detection
4.8. モード1損失検出
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をチェックして、何らかのアプリケーションが関心を示したdataIDを持っている各DSNのためにナックの計画をするのを含んでいます、そのDSNのSN/SegNoが、ナックが必要であることを示すなら。 NACKsはバンドルで送られて、データメッセージで束ねられるかもしれません。 ナックが必要である、:
o the SN is one or more greater (mod 512) than the latest received
Mode 1 message for that dataID, or
o またはSNがそれへの最新の受信されたMode1メッセージよりすばらしい(モッズ風の512)1dataIDである。
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>が受け取られていてユーザによって定義されたSegment_Timeoutであり、どのSHALL NOTが50未満msであり、<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副層に渡すでしょう。 また、それは次のセクションで説明されるように外向的なバンドルでNACKsを抑圧するでしょう。
4.8.1. Sending a Negative Acknowledgement
4.8.1. 否定的承認を送ります。
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によって使用されます。 しかしながら、大きいマルチキャストグループが混雑している広域ネットワークの上に広げられている状態で、積極的な承認の代わりに否定的承認の使用にもかかわらず、元の送り主でかなりの混雑を引き起こすためにメッセージを受け取って、マルチキャストグループの十分なメンバーがNACKsを発生させない可能性があります。 この理由で、SRMPは、どんなただ一つの無くなっているメッセージに対応して発生するNACKsの数を減少させるのにナック抑圧メカニズムを使用します。
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.
ナック抑圧メカニズムは、適切な時期ウィンドウの上にNACKsを分配するのに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.
バンドリング副層がバンドルを送る準備ができているとき、それはバンドルから応答がナック_Repeat_Timeoutの窓の中でマルチキャストグループの別のメンバーによって送られたどんなNACKsも取り外します。 オリジナルのBundle_Timeoutが期限が切れていないなら、Timeoutが吐き出すオリジナルのBundle_かバンドルが完全になるまで、バンドルの送信は遅れるかもしれません、どれが最初に起こっても。
Pullen, et al. Experimental [Page 16] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[16ページ]RFC4410
4.9. Unbundling
4.9. アンバンドリング
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副層にこれらを送ります。
4.10. Heartbeat Bundle
4.10. 鼓動バンドル
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を支持するかもしれなくて、どちらのSHALL NOTが、ある2番目より少ないですか? それぞれの鼓動間隔の終わりに、送付者がどんなバンドルも送らないなら、Modeの1回の損失の検出の引き金となるように空のバンドルを送るでしょう。
5. SRT Operation
5. SRT操作
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、マルチキャストグループのすべてのメンバーが確かに受け取らなければならないデータのためのMode1、およびマルチキャストの独身のダイナミックに断固としたメンバーが確かに受け取らなければならないデータのためのMode2は分類します。
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は純粋なベストエフォート型サービスとして作動します。 Mode1メッセージの損失を示すバンドル到着で引き起こされて、モード1は否定的承認だけで作動します。 モード2は信頼性と低遅延を提供する各メッセージに積極的な承認を使用します。 モード2はマルチキャストグループの2人のメンバーの間の取引が必要であるところで使用されます。 そのようなグループには多くのメンバーがいることができるので、信頼性がSRMP retransmissionによって獲得されている状態で、取引プロトコルの使用はグループのホストの各組が別々の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があるすべてのメッセージの中では、最新版はすべての、より古いメッセージを時代遅れにするでしょう。
Pullen, et al. Experimental [Page 17] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[17ページ]RFC4410
5.1. Mode 0 Operation
5.1. モード0操作
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はそれらが定期的に高周波でアップデートされるデータのリアルタイムのストリームの一部であるので信頼できるトランスミッションを必要としないマルチキャストメッセージのためのものです。 「再-トランスミッション」が完成できる前にそのようなどんなメッセージもより最近のアップデートで非常にスーパー割譲されそうでした。
5.1.1. Sending Mode 0 Messages
5.1.1. 送付モード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:
アプリケーションがMode0データの伝達を要求すると、目的地マルチキャストグループを送られるデータに伴う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.
バージョンは最新版に設定されて、メッセージタイプは0×0に用意ができて、モードは0×0に設定されます。 利用者データはメッセージヘッダーの後に含まれています。 メッセージが上で説明されるように発生できないなら、利用者データは捨てられます、そして、誤りをアプリケーションに報告しなければなりません。
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によって受け入れられたか否かに関係なく、実現はアプリケーションに報告しなければなりません。
5.1.2. Receiving Mode 0 Messages
5.1.2. 受信モード0メッセージ
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.
Mode0メッセージがSRMPによって受け取られるとき、以下の通りそれを処理しなければなりません: バージョン、メッセージタイプ、および目的地マルチキャストアドレス・フィールドについて確かめた後に、メッセージのマルチキャストグループに関連しているすべてのアプリケーションに利用者データを送らなければなりません。 Mode0メッセージが受信されている前にSRMP受信機が何かMode1メッセージを一度も受け取ったことがないなら、Mode0メッセージは静かに捨てられるべきです。
It is RECOMMENDED that the following information be provided to the receiving applications: message body, multicast address.
以下の情報を申し込みを受け付けに提供するのは、RECOMMENDEDです: メッセージ本体、マルチキャストアドレス。
5.2. Mode 1 Operation
5.2. モード1操作
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は信頼できるトランスミッションを必要とするマルチキャストデータのためのものです。 Mode1メッセージは、データメッセージかナックのどちらかであるかもしれません。 モード1データメッセージはデータ・ストリームの一部であると予想されます。 しかし、このデータ・ストリームはまた(セクション5.1.1を見る)、Mode0メッセージを含みそうです。
Pullen, et al. Experimental [Page 18] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[18ページ]RFC4410
it is possible for a data stream to be comprised solely of Mode 1 messages.
データ・ストリームが唯一Mode1メッセージから成るのは、可能です。
5.2.1. Sending Mode 1 Data Messages
5.2.1. 送付モード1データメッセージ
After the data length, dataID, and destination multicast group are verified, SRT MUST take the following steps:
データの長さ、dataID、および目的地マルチキャストグループが確かめられた後に、SRT MUSTは以下の方法を採ります:
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_マックス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に設定されて、タイプが0×0に用意ができて、転送方式が0×01に設定されて、SNが同じdataIDの最も最近送られたMode1の完全なメッセージのSNと等しいセットであるというメッセージは法512を1つ増加しました。 何かそのようなMode1メッセージが存在していないなら、SNは0×0に用意ができています。
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. 次に、新たに発生したメッセージ(すべてのセグメント)をバッファリングしなければなりません、同じdataID(送付先マルチキャストアドレス)のどんな以前バッファリングされたMode1メッセージも置き換えて メッセージをバッファリングできないなら、利用者データは捨てられます、そして、誤りはアプリケーションに報告されます。
4. If step 2 was completed without error, the newly generated message
is sent to the TFMCC sublayer.
4. 誤りなしでステップ2を終了したなら、新たに発生したメッセージをTFMCC副層に送ります。
5.2.2. Receiving Mode 1 Data Messages
5.2.2. 受信モード1データメッセージ
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):
Mode1データメッセージが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、ソース_ip_アドレス、およびボディーをバッファリングしなければなりません、そして、次に、受信されたメッセージのマルチキャストグループへの関心を示したすべてのアプリケーションに利用者データを送らなければなりません。
Pullen, et al. Experimental [Page 19] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[19ページ]RFC4410
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. NoSegsがゼロよりすばらしい状態で新しいDSN値を受け取るとき、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.
7. 以下の情報を申し込みを受け付けに提供するのは、RECOMMENDEDです: メッセージ本体、dataID、ソース_ip_アドレス、マルチキャスト_グループアドレス。
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. クライアントが新しいマルチキャストグループにサインすると、すぐに、そのマルチキャストグループに関連するすべての局所的にバッファリングされたMode1メッセージをクライアントに送るべきです。
5.2.3. Sending a Negative Acknowledgement
5.2.3. 否定的承認を送ります。
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副層は、ナックが必要であるかどうか決定するために<SenderID、dataID、SN、SegNo>のバッファリングされた値を調べるでしょう。 そうだとすれば、それは、ナックメッセージを発生させて、バンドリング副層にそれを送るでしょう。 バージョンがメッセージで0×2に設定するナック、メッセージタイプは0×2にセットしました、そして、0×7dataIDに設定された転送方式、SN、および送付先アドレスはナックが送られるMode1メッセージのものに用意ができています。 ナック敷居の中で問題のMode1メッセージのために目的地マルチキャストグループのどんなメンバーからもナックを受け取ったなら、ナックを全く発生させません。
For segmented messages, there are two possible types of NACKs:
区分されたメッセージを支持して、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実現は、全体の区分されたMode1メッセージが失われたことを決定するかもしれません。 この場合、ナックはSegNo=0x7F(オールインワン分野)を運ばなければなりません。
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 Segment Timeoutに基づいて、SRT実現は、メッセージの1つ以上のセグメントが伝達されていないことを決定するかもしれません。 この場合、それぞれのなくなったセグメントのためにナックを送るでしょう。
Pullen, et al. Experimental [Page 20] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[20ページ]RFC4410
5.2.4. Receiving a Negative Acknowledgement
5.2.4. 否定的承認を受けます。
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:
ナックが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. SNがdataIDに関する1つのメッセージがナックで示したSRTの最新のModeのこの例でナックでは、SNより新しくなるなら、そのメッセージ(バッファリングされる)はすぐに、容認されたナックで示されたマルチキャストアドレスに再送されるべきです。 最新のMode1メッセージではナックで示されたSNと等しいSNがあって、ナックのSegNo分野が0x7Fを含んでいるなら、バッファリングされたMode1メッセージのすべてのセグメントを再送しなければなりません。 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がメッセージの「再-トランスミッション」をもたらすか否かに関係なく、ナックを受ける出来事とナックが受け取られた(地方のマシン)時はバッファリングされるべきです。 SRT MUSTの各例が同じくらいの最新のMode1メッセージが受け取られないで以来それぞれのdataID-マルチキャストアドレス組のために受け取られているNACKsの数と時間をバッファリングする、どれ、最新である、これらのNACKsを受け取ったか。
5.3. Mode 2 Operation
5.3. モード2操作
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を使用できましたが、Mode2送信を必要とするホストの間には、ベストエフォート型データの進行中のストリームが既にあって、データのただ一つの交換のための流れ指向の接続を確立する不要なオーバーヘッドと遅れがあるでしょう。 例はDistributed Interactive Simulation(DIS)衝突PDUです。
5.3.1. Sending Mode 2 Data Messages
5.3.1. 送付モード2データメッセージ
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:
アプリケーションがModeのトランスミッションを要求すると、2つのデータ、dataID、および送付先ユニキャストIPアドレスを送られるデータに伴うSRTに提供しなければなりません。 データの長さ、dataID、および送付先アドレスについて確かめた後に、SRT MUSTは以下のステップを実行します:
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
1. SRTメッセージは以下の特性で発生します: バージョンは0×02に設定されます、そして、メッセージタイプは0×02に用意ができています、そして、転送方式は0×2に設定されます、そして、dataIDはアプリケーションで提供された値に用意ができています、そして、送付先アドレスはアプリケーションで提供されたIPアドレスに設定されます。 SNは同じdataIDに関する最も最近送られたMode2メッセージのSNと等しいセットです。
Pullen, et al. Experimental [Page 21] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[21ページ]RFC4410
incremented by 1 modulo 65536. If no such Mode 1 message exists,
it is set to 0x0.
法65536を1つ増加しました。 何かそのようなMode1メッセージが存在していないなら、それは0×0に設定されます。
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. 新たに発生したメッセージはバッファリングされます。 この新しいメッセージはどんな以前バッファリングされたMode2メッセージも置き換えません。 実現は1Mode2のメッセージを保持できるMode2メッセージ・バッファを提供しなければなりません。 モード2メッセージが珍しいと(1パーセント未満の総交通)予想されますが、実現がただ一つのMode2メッセージ以上を保持できるMode2_マックスをユーザ構成可能なサイズに関するバッファに提供するのは、強くRECOMMENDEDを静めることです。 メッセージをバッファリングできないなら、利用者データは捨てられます、そして、誤りをアプリケーションに報告しなければなりません。 メッセージをバッファリングできるなら、バッファリングされる直後それを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_敷居」(マルチキャストグループのための最悪の場合の往復の時間より長いはずである)がMode2メッセージのためのACKの領収書なしで経過するなら、それは再送されます。 実現は、Mode2メッセージがバッファから取り除かれる前に試みられるために「再-トランスミッション」の最大数を定義するかもしれません。
5.3.2. Receiving Mode 2 Data Messages
5.3.2. 受信モード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:
Mode2データメッセージが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. Mode2メッセージに関しては、一連番号分野は、特定のMode2メッセージに必要な積極的な承認を関連づけるのに使用されます。 メッセージが検証を通過するなら、受信されたメッセージのdataIDとマルチキャストアドレスへの関心を示したすべてのアプリケーションに要約の利用者データを送ります、SN分野の値にかかわらず。
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 MUST、Mode2データメッセージが由来したホストに送ってください。 詳細に関して.3 下のセクション5.3を見てください。
Pullen, et al. Experimental [Page 22] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[22ページ]RFC4410
5.3.3. Sending a Positive Acknowledgement
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)はMode2データメッセージの領収書で引き起こされます。 ACK、新しいSRTを送るために、メッセージはバージョンセットで0×02に発生しました、そして、メッセージタイプは0×2にセットしました、そして、転送方式は0×2にセットしました。 承認されていて、dataIDとSNはMode2データメッセージのものです。 目的地アドレス・フィールドはデータメッセージが受け取られたソースIPアドレスに設定されます。 Mode2データメッセージがユニキャストであるので、元の送り主でほとんど過度の混雑を引き起こさないACK内部破裂に関する心配があるので、どんな抑圧メカニズムも必要ではありません。
5.3.4. Receiving a Positive Acknowledgement
5.3.4. 積極的な承認を受けます。
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によって受け取られるとき、傑出しているMode2送信に対して転送方式、dataID、およびソースIPアドレスについて確かめた後に、SRT MUSTはバッファから未定のトランスミッションを取り除きます。
6. RFC 2357 Analysis
6. RFC2357分析
This section provides answers to the questions posed by RFC 2357 for reliable multicast protocols, which are quoted.
このセクションは引用される信頼できるマルチキャストプロトコルのためにRFC2357によって提出された質問の答えを提供します。
6.1. Scalability
6.1. スケーラビリティ
"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はこのとき、そのようなものを支持するメカニズムを剪定させません。
Pullen, et al. Experimental [Page 23] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[23ページ]RFC4410
6.2. Congestion
6.2. 混雑
"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のものに匹敵するbackoffを表示するのを示します。 メカニズムはネットワークに優しい道に失敗します、仮想シミュレーションを支持するためには通常不十分な非常にわずかなレートにベストエフォート型交通を発信させながら厳しい混雑で減少するので。 信頼できる交通が通常、総合的な交通のわずかな百分率であり、SRMPがナックの抑圧による指向のナックであるので、これは可能です、信頼できる交通の損失がほとんど合計に交通を加えないように。 交通ミックス仮定が迎えられないなら、信頼できる交通(増加する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?"
「プロトコルで輻輳回避メカニズムがGlobalインターネットで展開に対処できるくらい強くなるかどうかに関する分析を含めてください、そして、そうでなければ、明確に、混雑害が起こることができる事情を記録してください。」 「これらの事情によってどのように防がれることになっていますか?」
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に匹敵するbackoffを送りながら提供するので、SRMPは輻輳回避のためのTCPと同様に機能できます、Globalインターネットでさえ。 SRMP送付者が混雑を発生させることができる唯一の方法は故意でない目的、例えば、交通の大きい部分の信頼できるトランスミッションにプロトコルを使用することです。 これをすると、不十分な結果はアプリケーションのために生まれるでしょう、ベストエフォート型交通が総交通の大部分を構成しないと信頼性を提供するためのSRMPのメカニズムがよく機能しないとき。
Pullen, et al. Experimental [Page 24] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[24ページ]RFC4410
"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を見てください。
7. Security Considerations
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受信機を操作できました。(それは、ネットワークの混雑を引き起こすか、または送付者の処理能力を圧倒できました)。 信頼できるトランスミッションが失われたのを示す見せかけられた交通をそれらに送ることによって、これができるでしょう。 SRMPのナックの抑圧はそのような操作の効果を制限します。 しかしながら、本当の保護はそれぞれのバンドルの認証を必要とします。
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送付者が多くの偽造NACKsを受け入れると、それは修理メッセージでマルチキャストグループをあふれさせるでしょう。 この攻撃も1バンドルあたりの認証で止められます。
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。 反射攻撃: 攻撃者は、ナックを含む有効で、認証されたバンドルをコピーして、繰り返してNACKedデータの元の送り主にそれを送ることができました。 この攻撃に対する保護は送信元ホスト単位で1トランスミッションあたり1つの一連番号を必要とします。 SRMPバンドルヘッダー一連番号はこの需要を満たすでしょう。 しかしながら、下層でSNも適用できます。
Pullen, et al. Experimental [Page 25] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[25ページ]RFC4410
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の値で応じることができました。 したがって、彼らが記述がセッションに参加する必要があったSessionを受ける前に受信機が、自分たちが正統であると認識しなければならないのは、RECOMMENDEDです。 このドキュメントの範囲の外に受信機が、自分たちが正統であるとどう認識するかがあります。
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 Authentication Headerを使用する、(AH) (RFC4302[3])は、対称鍵暗号を使用することで2番目の必要条件を満たします。 1パケットあたりのマルチキャスト認証に指導のためのRFC4302[3]を見てください。 実際には、分配されたシミュレーションのユーザは、(ことによると仮想)の私設のネットワークの上で働きそうであって、その結果、特別な認証をSRMPに必要としないでしょう。
8. List of Acronyms Used
8. 使用される頭文字語のリスト
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--認証Header CLR--電流が選択的に、受信機IPSEC--インターネット・プロトコル・セキュリティーMTU--マキシマム・トランスミッション・ユニットナック--否定的承認RTT--往復の時間SA(セキュリティ協会SRMP)を制限する、Reliable MulticastプロトコルSRT--、選択的である、Reliable Transport TFMCC--、TCP好意的なMulticast Congestion Control
Pullen, et al. Experimental [Page 26] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[26ページ]RFC4410
9. Contributions
9. 貢献
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.
私たちは感謝して2人の人のこのRFCが開発されていない重要な貢献を承諾します。 ヴィンセントLavianoはSRMP(その時、SRTPと呼ばれる)の最初の仕様と実現を作成しました。 インド紳士Shanmugamは、かなり大きい分散仮想シミュレーション環境でSRMPを使って、有効に分配された仮想シミュレーションワークロードを支持するためにデザインを改訂するのを助けました。(そこでは、彼が実現を改訂しました)。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.ウィトマー、M.ハンドレー、方程式ベースの混雑を広げて、2001年8月にマルチキャストアプリケーション、ACM SIGCOMMコンファレンス、サンディエゴに制御してください。 <http://www.sigcomm.org/sigcomm2001/p22widmer.pdf>。
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[3] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
10.2. Informative References
10.2. 有益な参照
[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、「分配されたシミュレーションのためのインターネットプロトコル群の限界、大きいマルチキャスト環境、」、RFC2502(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スループット:」 「Simple ModelとそのEmpirical Validation」、ACM SIGCOMM1998のProceedings
[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評価基準」、RFC2357(1998年6月)。
[7] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[7] フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、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.ピューレン、「ネットワーク作業台:」 「インターネットConceptsのAcademic InvestigationのためのネットワークSimulation Software」、コンピュータNetworks Vol32ノー3pp365-378、2000年3月。
Pullen, et al. Experimental [Page 27] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[27ページ]RFC4410
[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.チャオ、およびW.チャン、「RTI-NGとSRMPの上のNGI-FOM:」 「レッスンLearned」、IEEE Fall Simulation Interoperability WorkshopのProceedings、03F-SIW-111、紙のオーランド(フロリダ)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はPDUをけなします」。 「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.、カーモード、R.、Vicisano、L.、およびM.Luby、「バルク・データ転送のための信頼できるマルチキャストデザインスペース」、RFC2887(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.、リゾー、L.、およびJ.クロウクロフト、「非同期な層にされたコード化(ALC)は具体化について議定書の中で述べます」、RFC3450、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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「コード化輸送(LCT)ブロックを層にしました」、RFC3451、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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453(2002年12月)。
Pullen, et al. Experimental [Page 28] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[28ページ]RFC4410
Authors' Addresses
作者のアドレス
J. Mark Pullen C4I Center George Mason University Fairfax, VA 22030 USA
J.マークピューレン・C4Iセンターのジョージ・メイスン・大学のヴァージニア22030フェアファクス(米国)
EMail: mpullen@gmu.edu
メール: mpullen@gmu.edu
Fei Zhao C4I Center George Mason University Fairfax, VA 22030 USA
Feiチャオ・C4Iセンターのジョージ・メイスン・大学のヴァージニア22030フェアファクス(米国)
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
ダニーコーエンサン・マイクロシステムズM/S UMPK16-160 16ネットワーク円のカリフォルニア94025メンローパーク(米国)
EMail: danny.cohen@sun.com
メール: danny.cohen@sun.com
Pullen, et al. Experimental [Page 29] RFC 4410 Selectively Reliable Multicast Protocol February 2006
ピューレン、他 マルチキャストプロトコル2006年2月に選択的に信頼できる実験的な[29ページ]RFC4410
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Pullen, et al. Experimental [Page 30]
ピューレン、他 実験的[30ページ]
一覧
スポンサーリンク
