RFC3941 日本語訳
3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM)Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT=92785 bytes) (Obsoleted by RFC5401) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Adamson
Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
コメントを求めるワーキンググループB.アダムソン要求をネットワークでつないでください: 3941年のNRLカテゴリ: 実験的なC.のM.ハンドレーUCL J.Macker NRLボルマンUniversitaetブレーメンTZI2004年11月
Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM)
Building Blocks
否定応答の(ナック)指向の信頼できるマルチキャスト(標準)ブロック
Status of this Memo
この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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.
このドキュメントは否定応答の(ナック)指向の信頼できるマルチキャスト(NORM)プロトコルの創造について議論します。 NORM目標と仮定のための原理は提示されます。 ナック指向の、そして、(いくつかの場合一般的)の信頼できるマルチキャストプロトコル操作のための技術的難関は特定されます。 これらの目標と挑戦はNORMプロトコル操作の異なった局面を記述する1セットの機能的な「ブロック」に変えられます。 これらのブロックが信頼できるマルチキャストプロトコルの異なった具体化を発生させる際に役に立つと予期されます。
Adamson, et al. Experimental [Page 1] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [1ページ]実験的なRFC3941標準ブロック2004年11月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 原理。 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. デリバリ・サービスモデル. . . . . . . . . . . . . . . . . 4 2.2。 会員資格力学. . . . . . . . . . . . . . . . 5 2.3を分類してください。 送付者/受信機関係. . . . . . . . . . . . . . 5 2.4。 サイズスケーラビリティを分類してください。 . . . . . . . . . . . . . . . . . 6 2.5. データ配送パフォーマンス. . . . . . . . . . . . . . . . 6 2.6。 環境をネットワークでつないでください。 . . . . . . . . . . . . . . . . . . 6 2.7. ルータ/中間システム支援. . . . . . . . . . 7 3。 機能性。 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. 標準送付者送信。 . . . . . . . . . . . . . . . . 10 3.2. 標準修理の過程. . . . . . . . . . . . . . . . . . . 11 3.2.1。 受信機ナックの過程開始. . . . . . . . . 11 3.2.2。 ナックSuppression. . . . . . . . . . . . . . . . . 13 3.2.3。 ナック内容. . . . . . . . . . . . . . . . . . . 17 3.2.3.1。 ナックとFECは戦略を修理します。 . . . . . 17 3.2.3.2. ナック満足している形式. . . . . . . . . . . 20 3.2.4。 送付者修理応答. . . . . . . . . . . . . . 21 3.3。 標準受信機は方針と手順を接合します。 . . . . . . . 23 3.4. 信頼できるマルチキャストメンバー識別。 . . . . . . . . 24 3.5. データ内容識別. . . . . . . . . . . . . . . 24 3.6。 エラー修正(FEC)を進めてください。 . . . . . . . . . . . . . 26 3.7. 往復のタイミング収集。 . . . . . . . . . . . . . . 27 3.7.1. 多くへの1つの送付者GRTT測定。 . . . . . . . 27 3.7.2. 多くへの1つの受信機RTT測定. . . . . . . 29 3.7.3。 多くへの多くRTT測定. . . . . . . . . . . 29 3.7.4。 送付者GRTT広告。 . . . . . . . . . . . . 30 3.8. サイズ決断/見積り. . . . . . . . . . . 31 3.9を分類してください。 輻輳制御操作。 . . . . . . . . . . . . . . 31 3.10 ルータ/中間システム支援. . . . . . . . . . 31 3.11標準の適用性。 . . . . . . . . . . . . . . . . . . . 31 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 32 5. 承認. . . . . . . . . . . . . . . . . . . . . . . 33 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1。 引用規格。 . . . . . . . . . . . . . . . . . . 33 6.2. 有益な参照。 . . . . . . . . . . . . . . . . . 33 7. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 35の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 36
Adamson, et al. Experimental [Page 2] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [2ページ]実験的なRFC3941標準ブロック2004年11月
1. Introduction
1. 序論
Reliable multicast transport is a desirable technology for the efficient and reliable distribution of data to a group on the Internet. The complexities of group communication paradigms necessitate different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users [3]. This document addresses the creation of negative-acknowledgment (NACK)- oriented reliable multicast (NORM) protocols. While different protocol instantiations may be required to meet specific application and network architecture demands [4], there are a number of fundamental components that may be common to these different instantiations. This document describes the framework and common "building block" components relevant to multicast protocols based primarily on NACK operation for reliable transport. While this document discusses a large set of reliable multicast components and issues relevant to NORM protocol design, it specifically addresses in detail the following building blocks which are not addressed in other IETF documents:
信頼できるマルチキャスト輸送はインターネットに関するグループへのデータの効率的で信頼できる分配のための望ましい技術です。 グループコミュニケーションパラダイムの複雑さは異なったプロトコルタイプ、性能の範囲と異なった潜在的高信頼のマルチキャストアプリケーションに関するスケーラビリティ必要条件を満たす具体化、およびユーザ[3]を必要とします。 このドキュメントは否定応答(ナック)の創造を記述します--信頼できるマルチキャスト(NORM)プロトコルを適応させます。 異なったプロトコル具体化が特定のアプリケーションとネットワークアーキテクチャ需要[4]にこたえるのに必要であるかもしれませんが、これらの異なった具体化に共通であるかもしれない多くの基本要素があります。 このドキュメントは信頼できる輸送のための主としてナックの操作に基づくマルチキャストプロトコルに関連している枠組みと一般的な「ブロック」コンポーネントについて説明します。 このドキュメントは信頼できるマルチキャストコンポーネントとNORMプロトコルデザインに関連している問題の大きいセットについて議論しますが、明確に詳細に他のIETFドキュメントで演説されない以下のブロックに演説します:
1) NORM sender transmission strategies,
1) NORM送付者トランスミッション戦略
2) NACK-oriented repair process with timer-based feedback
suppression, and
2) そしてタイマベースのフィードバック抑圧があるナック指向の修理の過程。
3) Round-trip timing for adapting NORM timers.
3) NORMタイマを適合させる往復のタイミング。
The potential relationships to other reliable multicast transport building blocks (Forward Error Correction (FEC), congestion control) and general issues with NORM protocols are also discussed. This document is a product of the IETF RMT WG and follows the guidelines provided in RFC 3269 [5]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
また、他の信頼できるマルチキャスト輸送ブロック(Error Correction(FEC)を進めてください、輻輳制御)との潜在的関係とNORMプロトコルの一般答弁について議論します。 このドキュメントは、IETF RMT WGの製品であり、RFC3269[5]に提供されたガイドラインに従います。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモはRFC2357によると、Reliable Multicast Transportプロトコルを完全に指定するのに必要な定義の一部を含んでいます。 RFC2357に従って、インターネットでのどんな信頼できるマルチキャストプロトコルの使用も適切な輻輳制御計画を必要とします。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
そのような計画が利用可能であるか、または既存の計画が適切であると立証されるのを待っている間、Reliable Multicast Transportワーキンググループ(RMT)はCommentsのために「実験的な」カテゴリでこのRequestを発行します。
Adamson, et al. Experimental [Page 3] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [3ページ]実験的なRFC3941標準ブロック2004年11月
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
それは上記の状態の次第IETF Proposed Standardが会われるときRMTがこの仕様を再提出する意図です。
2. Rationale
2. 原理
Each potential protocol instantiation using the building blocks presented here (and in other applicable building block documents) will have specific criteria that may influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas that each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include:
ここ(そして他の適切なブロックドキュメントで)に提示されたブロックを使用するそれぞれの潜在的プロトコル具体化が個々のプロトコルデザインに影響を及ぼすかもしれない特定の評価基準を持つでしょう。 適切なブロックの発展をサポートするために、運転する一般的なプロトコルデザイン目標と仮定を特定して、まとめるのは役に立ちます。 これらはそれぞれのプロトコル具体化が詳細に記述する必要がある領域です。 それぞれのブロック記述は本書ではこれらの設計基準の影響の議論を含むでしょう。 ここで考えられた設計基準のカテゴリは:
1) Delivery Service Model,
2) Group Membership Dynamics,
3) Sender/receiver relationships,
4) Group Size Scalability,
5) Data Delivery Performance,
6) Network Environments, and
7) Router/Intermediate System Interactions.
1) 2歳のデリバリ・サービスモデル) グループ会員資格力学、3) 送付者/受信機関係、4) グループサイズスケーラビリティ、5) データ配送パフォーマンス、6) ネットワーク環境、および7) ルータ/中間システム相互作用。
All of these areas are at least briefly discussed. Additionally, other reliable multicast transport building block documents such as [9] have been created to address areas outside of the scope of this document. NORM protocol instantiations may depend upon these other building blocks as well as the ones presented here. This document focuses on areas that are unique to NORM but may be used in concert with the other building block areas. In some cases, a building block may be able address a wide range of assumptions, while in other cases there will be trade-offs required to meet different application needs or operating environments. Where necessary, building block features are designed to be parametric to meet different requirements. Of course, an underlying goal will be to minimize design complexity and to at least recommend default values for any such parameters that meet a general purpose "bulk data transfer" requirement in a typical Internet environment.
簡潔にこれらの領域のすべてについて少なくとも議論します。 さらに、[9]などの他の信頼できるマルチキャスト輸送ブロックドキュメントは、このドキュメントの範囲の外に領域を記述するために作成されました。 NORMプロトコル具体化はここに提示されたものと同様にこれらの他のブロックに頼るかもしれません。 このドキュメントは、NORMにユニークな領域に焦点を合わせますが、他のブロック領域と協力して使用されるかもしれません。 いくつかの場合、ブロックは会うのに必要であるトレードオフが異なったアプリケーションの必要性か操作環境であったなら他の場合でさまざまな仮定がそこでそうするできるアドレスであるかもしれません。 必要であるところに、ブロックの特徴は、異なった必要条件を満たすパラメトリックになるように設計されています。 もちろん、基本的な目標は、デザインの複雑さを最小にして、典型的なインターネット環境における汎用の「バルク・データ転送」必要条件を満たすどんなそのようなパラメタのためにもデフォルト値を少なくとも推薦することでしょう。
2.1. Delivery Service Model
2.1. デリバリ・サービスモデル
The implicit goal of a reliable multicast transport protocol is the reliable delivery of data among a group of members communicating using IP multicast datagram service. However, the specific service the application is attempting to provide can impact design decisions. A most basic service model for reliable multicast transport is that of "bulk transfer" which is a primary focus of this and other related
信頼できるマルチキャストトランスポート・プロトコルの暗黙の目標はIPマルチキャストデータグラムサービスを使用することで交信するメンバーのグループのデータの信頼できる配信です。 しかしながら、アプリケーションが提供するのを試みている特定のサービスはデザイン決定に影響を与えることができます。 信頼できるマルチキャスト輸送のための最も基本的なサービスモデルはこの焦点である「バルク転送」のものです、そして、もう一方は関係しました。
Adamson, et al. Experimental [Page 4] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [4ページ]実験的なRFC3941標準ブロック2004年11月
RMT working group documents. However, the same principles in protocol design may also be applied to other services models, e.g., more interactive exchanges of small messages such as with white- boarding or text chat. Within these different models there are issues such as the sender's ability to cache transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be different depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other members have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drive the need for a number of different protocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details.
RMTワーキンググループドキュメント。 しかしながら、また、プロトコルデザインにおける同じ原則は他のサービスモデル(例えば、小さいメッセージの白い板囲いやテキストチャットなどの、より対話的な交換)に適用されるかもしれません。 あるこれらの異なったモデルの中では、キャッシュする送付者の能力などの問題は「再-トランスミッション」か修理のためのデータ(または、それに参照をつける州)を送りました。 データ内容によって、注文する必要性、そして/または、トランスミッションの系列の因果関係とグループのメンバーの中のレセプションは異なっているかもしれません。 グループコミュニケーションパラダイムは二地点間モデルからデータ内容タイプに頼っていて、いくつかの受信機がデータ内容の部分のレセプションを完成して、他のメンバーが内容を受け取る前にそれに作用できるかもしれないという点において有意差があります。 これは、許容できるのと(望ましいさえ。)であるかもしれません。他のものではなく、いくつかのアプリケーションのために。 これらの異なった要件は多くの異なったプロトコル具体化デザインの必要性を追い立てます。 特定のアプリケーションレベルの詳細を定義しないで、展開している一般に役に立つブロックメカニズムにおける重要な挑戦はこれらの能力の限られた範囲さえ収容しています。
2.2. Group Membership Dynamics
2.2. グループ会員資格力学
One area where group communication can differ from point-to-point communications is that even if the composition of the group changes, the "thread" of communication can still exist. This contrasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK timing, congestion control operation, etc.
グループコミュニケーションが二地点間コミュニケーションと異なることができる1つの領域はグループの構成が変化しても、コミュニケーションの「糸」がまだ存在できるということです。 これはコミュニケーション・プロセス(データの交換)がパーティーが2つのもののどちらかならいなくなるか、終えられるのとまたは(少なくともポーズされています)である二地点間コミュニケーションモデルとひどく違います。 信頼できるマルチキャスト輸送「セッション」のときに参加するのが遅く接合できるかもしれないアプリケーション目標、送付者、および受信機に頼って、いなくなってください、そして、「糸」という進行中のグループコミュニケーションがまだ機能的であって、役に立ったままで残っている間、潜在的に再び加わってください。 また、これがプロトコルメッセージ内容に影響を与えることができることに注意してください。 「故joiners」が支持されるなら、いくらかの量の追加情報が、この機能性に対応するためにメッセージヘッダーに置かれるかもしれません。 あるいはまた、すばらし過ぎると典型的なメッセージ送信のオーバーヘッドへの影響を考えるなら、それ自身のメッセージ(要求に応じてか断続的である)で情報を送るかもしれません。 また、グループ・ダイナミックスはナックタイミング、混雑制御機能などの他のプロトコルメカニズムに影響を与えることができます。
2.3. Sender/Receiver Relationships
2.3. 送付者/受信機関係
The relationship of senders and receivers among group members requires consideration. In some applications, there may be a single sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender _and_ receiver of data may exist.
グループのメンバーの中の送付者と受信機の関係は考慮を必要とします。 使用目的によっては、受信機のグループへのただ一つの送付者マルチキャスティングがあるかもしれません。 他の場合には、1人以上の送付者がいるかもしれませんか、またはデータの送付者_と_受信機であるグループの皆の可能性は存在するかもしれません。
Adamson, et al. Experimental [Page 5] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [5ページ]実験的なRFC3941標準ブロック2004年11月
2.4. Group Size Scalability
2.4. グループサイズスケーラビリティ
Native IP multicast [2] may scale to extremely large group sizes. It may be desirable for some applications to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-oriented protocol can apply without NACK implosion problems. Research suggests that NORM group sizes on the order of tens of thousands of receivers may operate with modest feedback to the sender using probabilistic, timer-based suppression techniques [7]. However, the potential for router assistance and/or other NACK suppression heuristics may enable these protocols to scale to very large group sizes. In large scale cases, it may be prohibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of applicable building blocks.
ネイティブのIPマルチキャスト[2]は非常に大きいグループサイズに比例するかもしれません。 いくつかのアプリケーションが比例するマルチキャストインフラストラクチャの能力と共に比例するのは、望ましいかもしれません。 最も簡単なフォームには、ナック内部破裂問題なしでナック指向のプロトコルを適用できるグループサイズへの限界があります。研究は、何万台もの受信機の注文のNORMグループサイズが確率的で、タイマベースのサプレッション技術[7]を使用しながら穏やかなフィードバックで送付者に作動するかもしれないのを示します。 しかしながら、ルータ支援、そして/または、他のナック抑圧発見的教授法の可能性は、これらのプロトコルが非常に大きいグループサイズに比例するのを可能にするかもしれません。 大規模場合では、メンバーがグループの他のすべてのメンバー(特定の、そして、他の受信機の)の上で状態を維持するのは、禁止であるかもしれません。 グループサイズの影響は、適切なブロックの発展で考えられる必要があります。
2.5. Data Delivery Performance
2.5. データ配送パフォーマンス
There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If probabilistic, timer- based NACK suppression is to be used, there will be some delays built into the NACK process to allow suppression to occur and for the sender of data to identify appropriate content for efficient repair transmission. For example, backoff timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at a cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks SHOULD allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalability trade-off that is made when such bounds are applied.
ナック指向のプロトコルを設計するとき、スケーラビリティとデータ配送潜在の間には、トレードオフがあります。 確率的であるなら、タイマベースのナックの抑圧が使用されていることである、いくつか遅滞するでしょうナックの過程が起こって、データの送付者が効率的な修理送信のための適切な内容を特定するように抑圧を許すために組み込まれた。 例えば、効率的なナックの抑圧と修理送信を確実にするのにbackoffタイムアウトを使用できますが、これは送付者と受信機の両方のための増加する配送潜在と増加するバッファリング要件の費用で来ます。 SHOULDがデータ配送性能のために領域をアプリケーションを確立させるブロック。 アプリケーション設計者がそのような領域が適用されているときされるスケーラビリティトレードオフを意識しているに違いないことに注意してください。
2.6. Network Environments
2.6. ネットワーク環境
The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively operating across a wide range of the networks to which general purpose IP service applies. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite and other wireless communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fan-out" to which IP multicast service is highly applicable. Additionally, policy and/or technical issues may result in topologies where multicast
インターネットプロトコルは異機種ネットワークtopologiesの向こう側に提供サービスの役割を歴史的に引き受けました。 事実上、信頼できるマルチキャストプロトコルが汎用のIPサービスが申請されるさまざまなネットワークの向こう側に作動できるのは、望ましいです。 今日のただ一つのグループのメンバーの間のリンクで利用可能な帯域幅は無線のリンクへのkbit/sと高速のための複数のGbit/sの低い数字の間でLAN接続を変えるかもしれません、他の流れからの異なった度の主張で。 最近、56のK/ADSLモデム、CATVインターネットサービス、衛星、および他の無線の通信サービスを含む多くの非対称のネットワーク・サービスが増殖し始めました。 本来これらの多くがIPマルチキャストサービスがどれであるかに非常に適切な潜在的に大きい「四方八方に広がってください」がある放送メディアです。 さらに、方針、そして/または、専門的な問題がtopologiesをもたらすかもしれない、どこ、マルチキャスト
Adamson, et al. Experimental [Page 6] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [6ページ]実験的なRFC3941標準ブロック2004年11月
connectivity is limited to a single source multicast (SSM) model from a specific source [8]. Receivers in the group may be restricted to unicast feedback for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks.
接続性は特定のソース[8]からただ一つのソースマルチキャスト(SSM)モデルに制限されます。 グループにおける受信機はNACKsと他のメッセージのためにユニキャストフィードバックに制限されるかもしれません。 ブロック開発とプロトコルデザインで基本的なネットワークの本質に対して考慮を払わなければなりません。
2.7. Router/Intermediate System Assistance
2.7. ルータ/中間システム支援
While intermediate assistance from devices/systems with direct knowledge of the underlying network topology may be used to leverage the performance and scalability of reliable multicast protocols, there will continue to be a number of instances where this is not available or practical. Any building block components for NACK- oriented reliable multicast SHALL be capable of operating without such assistance. However, it is RECOMMENDED that such protocols also consider utilizing these features when available.
基本的なネットワーク形態に関するダイレクト知識がある装置/システムからの中間的支援が信頼できるマルチキャストプロトコルの性能とスケーラビリティに投機するのに使用されているかもしれない間、これが利用可能でもなくて、また実用的でもない多くの例が続くでしょう。 ナックのためのどんなブロックコンポーネントも信頼できるマルチキャストSHALLを適応させました。そのような支援なしで作動できてください。 しかしながら、それはまたそのようなプロトコルが利用可能であるときに、これらの特徴を利用することで考えるRECOMMENDEDです。
3. Functionality
3. 機能性
The previous section has presented the role of protocol building blocks and some of the criteria that may affect NORM building block identification/design. This section describes different building block areas applicable to NORM protocols. Some of these areas are specific to NACK-oriented protocols. Detailed descriptions of such areas are provided. In other cases, the areas (e.g., node identifiers, forward error correction (FEC), etc.) may be applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those other general building block areas from the standpoint of NACK-oriented reliable multicast. Where applicable, other building block documents are referenced for possible contribution to NORM protocols.
前項はNORMブロック識別/デザインに影響するかもしれないプロトコルブロックの役割と評価基準のいくつかを提示しました。 このセクションはNORMプロトコルに適切な異なったブロック領域について説明します。 これらの領域のいくつかがナック指向のプロトコルに特定です。 そのような領域の詳述を提供します。 他の場合では、領域(例えば、ノード識別子、前進型誤信号訂正(FEC)など)は他のフォームの信頼できるマルチキャストに適切であるかもしれません。 それらの場合では、以下での議論はナック指向の信頼できるマルチキャストの見地からそれらの他の一般的なブロック領域に置かれた要件について説明します。 適切であるところでは、他のブロックドキュメントがNORMプロトコルへの可能な貢献のために参照をつけられます。
For each building block, a notional "interface description" is provided to illustrate any dependencies of one building block component upon another or upon other protocol parameters. A building block component may require some form of "input" from another building block component or other source to perform its function. Any "inputs" required by a building block component and/or any resultant "output" provided will be defined and described in each building block component's interface description. Note that the set of building blocks presented here do not fully satisfy each other's "input" and "output" needs. In some cases, "inputs" for the building blocks here must come from other building blocks external to this document (e.g., congestion control or FEC). In other cases NORM building block "inputs" must be satisfied by the specific protocol instantiation or implementation (e.g., application data and control).
各ブロックにおいて、1つのブロックコンポーネントの別のものか他のプロトコルパラメタに関するどんな依存も例証するために概念的な「インタフェース記述」を提供します。 ブロックコンポーネントは、機能を実行するために別のブロックコンポーネントか他のソースからの何らかのフォームの「入力」を必要とするかもしれません。 そして/またはどんな結果の「出力」も提供したブロックコンポーネントによって必要とされた「入力」は、それぞれのブロックコンポーネントのインタフェース記述で定義されて、説明されるでしょう。 ここに提示されたブロックのセットが完全に互いの「入力」と「出力」需要を満たすというわけではないことに注意してください。 いくつかの場合、ここのブロックのための「入力」はこのドキュメント(例えば、輻輳制御かFEC)への外部の他のブロックから来なければなりません。 他のケースNORMブロックでは、特定のプロトコル具体化か実現(例えば、アプリケーションデータとコントロール)で「入力」を満たさなければなりません。
Adamson, et al. Experimental [Page 7] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [7ページ]実験的なRFC3941標準ブロック2004年11月
The following building block components relevant to NORM are identified:
NORMに関連している以下のブロックコンポーネントは特定されます:
(NORM-Specific)
1) NORM Sender Transmission
2) NORM Repair Process
3) NORM Receiver Join Policies
(General Purpose)
4) Node (member) Identification
5) Data Content Identification
6) Forward Error Correction (FEC)
7) Round-trip Timing Collection
8) Group Size Determination/Estimation
9) Congestion Control Operation
10) Router/Intermediate System Assistance
11) Ancillary Protocol Mechanisms
(標準特有)の1) 標準送付者送信2) 標準修理の過程3) 標準受信機は方針(汎用)を接合します。 4) ノード(メンバー) 識別5) データ内容識別6) 前進型誤信号訂正(FEC) 7) 往復のタイミング収集8) グループサイズ決断/見積り9) 輻輳制御操作10) ルータ/中間システム支援11) 付属のプロトコルメカニズム
Figure 1 provides a pictorial overview of these building block areas and some of their relationships. For example, the content of the data messages that a sender initially transmits depends upon the "Node Identification", "Data Content Identification", and "FEC" components while the rate of message transmission will generally depend upon the "Congestion Control" component. Subsequently, the receivers' response to these transmissions (e.g., NACKing for repair) will depend upon the data message content and inputs from other building block components. Finally, the sender's processing of receiver responses will feed back into its transmission strategy.
図1はこれらのブロック領域とそれらの関係のいくつかの絵の概観を提供します。 例えば、メッセージ送信の速度は一般に「輻輳制御」コンポーネントによるでしょうが、送付者が初めは伝わるというデータメッセージの内容は「ノード識別」、「データ内容識別」、および"FEC"コンポーネントによります。 次に、これらのトランスミッション(例えば、修理のためのNACKing)への受信機の応答は他のブロックコンポーネントからのデータメッセージ内容と入力によるでしょう。 最終的に、送付者の受信機応答の処理はトランスミッション戦略にフィードバックされるでしょう。
Adamson, et al. Experimental [Page 8] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [8ページ]実験的なRFC3941標準ブロック2004年11月
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------' _.-' `-----------------------' |
.---------------------. _.-' .' | .--------------. |
| Data Identification |--' .'' | | Join Policy | |
`---------------------' .' ' v `--------------' |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK | |
| `---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| `---------------------'` `._ | `------------------' | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------' .`- ` | `------------------' | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------'`. ` ` | `------------------' | |
.---------------------. ` ` ` `------------------------' |
| Other | ` ` ` | .-----------------. |
`---------------------' ` ` ` | |Router Assistance| |
`. ` ` v `-----------------' |
`.`' .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------'
アプリケーションデータとコントロール| v。---------------------. .-----------------------. | ノード識別|、-、-、-、-、-、-、-、-、-、--、>| 送付者トランスミッション| <、-、-、-、-、--. `---------------------' _.-' `-----------------------' | .---------------------. _.-' .' | .--------------. | | データ識別|--' .'' | | 方針を接合してください。| | `---------------------''.'v‘--------------' | .---------------------. .' ' .------------------------. | .->| 輻輳制御|-' ' | 受信機ナック| | | `---------------------' .' | 修理の過程| | | .---------------------. .' | .------------------. | | | | FEC|'. | | ナックInitiation| | | | `---------------------'` `._ | `------------------' | | | .---------------------. ``. `-._ | .------------------. | | `--| RTT収集|._` ` `->|、| ナックContent| | | `---------------------' .`- ` | `------------------' | | .---------------------. \ `-`._ | .------------------. | | | サイズエストを分類してください。 |---.-`---`->|、| ナックSuppression| | | `---------------------'`. ` ` | `------------------' | | .---------------------. ` ` ` `------------------------' | | 他| ` ` ` | .-----------------. | `---------------------' ` ` ` | |ルータ支援| | ''.'v‘-----------------' | `.`' .-------------------------. | `>| 送付者ナックの処理|_____/ | そして、応答を修理してください。| `-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------'
^ ^ | | .-----------------------------. | (セキュリティ) | `-----------------------------'
Fig. 1 - NORM Building Block Framework
図1--標準ブロック枠組み
The components on the left side of this figure are areas that may be applicable beyond NORM. The most significant of these components are discussed in other building block documents such as [9]. A brief description of these areas and their role in the NORM protocol is given below. The components on the right are seen as specific to NORM protocols, most notably the NACK repair process. These areas are discussed in detail below. Some other components (e.g., "Security") impact many aspects of the protocol, and others such as "Router Assistance" may be more transparent to the core protocol processing. The sections below describe the "NORM Sender
この図の左側のコンポーネントはNORMで適切であるかもしれない領域です。 [9]などの他のブロックドキュメントでこれらのコンポーネントで最も重要であるのについて議論します。 NORMプロトコルにおけるこれらの領域とそれらの役割の簡単な説明を以下に与えます。 右のコンポーネントはNORMプロトコル、最も著しくナック修理の過程に特定であるとみなされます。 以下で詳細にこれらの領域について議論します。 ある他のコンポーネント(例えば、「セキュリティ」)はプロトコルの多くの局面に影響を与えます、そして、「ルータ支援」などの他のものはコアプロトコル処理により透明であるかもしれません。 下のセクションは「標準送付者」について説明します。
Adamson, et al. Experimental [Page 9] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [9ページ]実験的なRFC3941標準ブロック2004年11月
Transmission", "NORM Repair Process", and "RTT Collection" building blocks in detail. The relationships to and among the other building block areas are also discussed, focusing on issues applicable to NORM protocol design. Where applicable, specific technical recommendations are made for mechanisms that will properly satisfy the goals of NORM transport for the Internet.
詳細な「トランスミッション」、「標準修理の過程」、および「RTT収集」ブロック。 また、領域と他のブロック領域の中の関係について議論します、NORMプロトコルデザインに適切な問題に焦点を合わせて。 メカニズムのために適切で、特定の技術提言をするところでは、それは適切にインターネットのためのNORM輸送の目標を満たすでしょう。
3.1. NORM Sender Transmission
3.1. 標準送付者送信
NORM senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate, and with message sizes, determined by application and/or network architecture requirements. Any FEC encoding of sender transmissions SHOULD conform with the guidelines of [9]. When congestion control mechanisms are needed (REQUIRED for general Internet operation), NORM transmission SHALL be controlled by the congestion control mechanism. In any case, it is RECOMMENDED that all data transmissions from NORM senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other factors related to application operation may determine sender transmission formats and methods. For example, some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit.
NORM送付者はマルチキャストセッションまでデータ内容を伝えるでしょう。 データ内容はアプリケーションに依存するようになるでしょう。 送付者はレートにおいてメッセージサイズに満足していて、アプリケーション、そして/または、ネットワークアーキテクチャ要件で決定しているデータを送るでしょう。 トランスミッションSHOULDを送付者にコード化するどんなFECも[9]のガイドラインに従います。 制御されていて、混雑制御機構が必要な(一般的なインターネット操作のためのREQUIRED)NORMトランスミッションSHALLであるときには、混雑で、メカニズムを制御してください。 どのような場合でも、送付者を条件としているNORMからのすべてのデータ伝送が、制限がアプリケーションか輻輳制御アルゴリズムで決定していると評定するのは、RECOMMENDEDです。 送付者のトランスミッションSHOULDは有効な容量(アプリケーション輻輳制御で制限されるかもしれない)の良い利用をします。 その結果、データの新しい内容送信が修理内容に重ね合わせて、多重送信されるのがあると予想されます。 アプリケーション操作に関連する他の要素は送付者トランスミッション形式と方法を決定するかもしれません。 例えば、何らかの考慮が、それが送らないデータを全く持っている間欠活動していない期間、送付者の振舞いに与えられている必要があります。
In addition to data content, other sender messages or commands may be employed as part of protocol operation. These messages may occur outside of the scope of application data transfer. In NORM protocols, reliability of such protocol messages may be attempted by redundant transmission when positive acknowledgement is prohibitive due to group size scalability concerns. Note that protocol design SHOULD provide mechanisms for dealing with cases where such messages are not received by the group. As an example, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmission. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require following the rules of the NORM NACK procedure. For efficiency, the sender should allow sufficient time between the redundant transmissions to receive any NACK-oriented responses from the receivers to this command.
データ内容に加えて、他の送付者メッセージかコマンドがプロトコル操作の一部として使われるかもしれません。 これらのメッセージは適用範囲データ転送の外に現れるかもしれません。 NORMプロトコルでは、積極的な承認がグループサイズスケーラビリティ関心のために禁止であるときに、そのようなプロトコルメッセージの信頼性は余分なトランスミッションで試みられるかもしれません。 プロトコルデザインSHOULDがそのようなメッセージがグループによって受け取られないケースに対処するのにメカニズムを提供することに注意してください。 例として、コマンドメッセージは、一時トランスミッションを止めているのを(永久に)示すために送付者によって冗長に送られるかもしれません。 このとき、受信機がどんな傑出している修理のためにもNACKsと共に応じるように、約束を守るのをNORM NACK手順を要求するのは、適切であるかもしれません。 効率のために、送付者は余分なトランスミッションの間のどんなナック指向の受信機からこのコマンドまでの応答も受けることができるくらいの時間を許すべきです。
In general, when there is any resultant NACK or other feedback operation, the timing of redundant transmission of control messages issued by a sender and other NORM protocol timeouts should be dependent upon the group greatest round trip timing (GRTT) estimate
どんな結果のナックや他のフィードバック操作もあるとき、一般に、送付者によって発行されたコントロールメッセージと他のNORMプロトコルタイムアウトの余分なトランスミッションのタイミングはグループ最も大きい周遊旅行タイミング(GRTT)見積りに依存しているべきです。
Adamson, et al. Experimental [Page 10] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [10ページ]実験的なRFC3941標準ブロック2004年11月
and any expected resultant NACK or other feedback operation. The NORM GRTT is an estimate of the worst-case round-trip timing from a sender to any receivers in the group. It is assumed that the GRTT interval is a conservative estimate of the maximum span (with respect to delay) of the multicast group across a network topology with respect to given sender. NORM instantiations SHOULD be able to dynamically adapt to a wide range of multicast network topologies.
どんな予想された結果のナックや他のフィードバック操作。 送付者からどんな受信機までNORM GRTTはグループで、最悪の場合の往復のタイミングの見積りです。 GRTT間隔がネットワーク形態の向こう側の与えられた送付者に関するマルチキャストグループの最大スパン(遅れに関する)の内輪な見積りであると思われます。 NORM具体化SHOULD、ダイナミックにさまざまなマルチキャストネットワークtopologiesに順応できてください。
Sender Transmission Interface Description
送付者トランスミッションインタフェース記述
Inputs:
入力:
1) Application data and control
2) Sender node identifier
3) Data identifiers
4) Segmentation and FEC parameters
5) Transmission rate
6) Application controls
7) Receiver feedback messages (e.g., NACKs)
1) アプリケーションデータとコントロール2) 送付者ノード識別子3) データ識別子4) 分割とFECパラメタ5) 通信速度6) アプリケーション制御装置7) 受信機フィードバックメッセージ(例えば、NACKs)
Outputs:
出力:
1) Controlled transmission of messages with headers uniquely
identifying data or repair content within the context of the
NORM session.
2) Commands indicating sender's status or other transport
control actions to be taken.
1) ヘッダーがNORMセッションの文脈の中で唯一データか修理内容を特定しているメッセージの制御伝達。 2) 何らかの送付者の状態を示すコマンドは、取るためにコントロール動作を輸送します。
3.2. NORM Repair Process
3.2. 標準修理の過程
A critical component of NORM protocols is the NACK repair process. This includes the receiver's role in detecting and requesting repair needs, and the sender's response to such requests. There are four primary elements of the NORM repair process:
NORMプロトコルの重要な要素はナック修理の過程です。 これは修理の必要性を見つけて、要求することにおける受信機の役割、およびそのような要求への送付者の応答を含んでいます。 NORM修理の過程の4つの第一の要素があります:
1) Receiver NACK process initiation,
1) 受信機ナックの過程開始
3) NACK suppression,
3) ナックの抑圧
2) NACK message content,
2) ナックメッセージ内容
4) Sender NACK processing and response.
4) 送付者ナックの処理と応答。
3.2.1. Receiver NACK Process Initiation
3.2.1. 受信機ナックの過程開始
The NORM NACK process (cycle) will be initiated by receivers that detect a need for repair transmissions from a specific sender to achieve reliable reception. When FEC is applied, a receiver should
NORM NACK過程(サイクル)は特定の送付者からの修理送信が信頼できるレセプションを実現する必要性を見つける受信機によって開始されるでしょう。 FECが適用されているとき、受信機は適用されるべきです。
Adamson, et al. Experimental [Page 11] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [11ページ]実験的なRFC3941標準ブロック2004年11月
initiate the NACK process only when it is known its repair requirements exceed the amount of pending FEC transmission for a given coding block of data content. This can be determined at the end of the current transmission block (if it is indicated) or upon the start of reception of a subsequent coding block or transmission object. This implies the NORM data content is marked to identify its FEC block number and that ordinal relationship is preserved in order of transmission.
修理要件がデータ内容の与えられたコード化ブロックのための未定のFECトランスミッションの量を超えているのが知られていたらだけ、ナックの過程に着手してください。 これは変流器ブロック(それが示されるなら)の端において、または、その後のコード化ブロックかトランスミッション物のレセプションの始まりときの決定できます。 これは、NORMデータ内容がFEC街区番号を特定するためにマークされて、その序数の関係がトランスミッションの順に保存されるのを含意します。
Alternatively, if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, the receiver may be able to initiate the NACK processor earlier. Allowing receivers to initiate NACK cycles at any time they detect their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be useful to limit NACK process initiation to specific events such as at the end-of-transmission of an FEC coding block or upon detection of subsequent coding blocks. This can allow receivers to aggregate NACK content into a smaller number of NACK messages and provide some implicit loose synchronization among the receiver set to help facilitate effective probabilistic suppression of NACK feedback. The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, it is expected that the history will correspond to a record of pending or partially-received coding blocks.
あるいはまた、送付者のトランスミッションがそれがブロックに送るのを既に計画している修理パケットの量の広告を出すなら、受信機は、より早くナックプロセッサを開始できるかもしれません。 受信機が彼らが検出するサイクル何時でもナックを開始するのを彼らの修理の必要性が修理送信まで超えていた許容するのがわずかに迅速な修理サイクルで結果として生じるかもしれません。 しかしながら、ナックの過程開始をFECコード化ブロックのトランスミッションの端やその後のコード化ブロックの検出などの特定の出来事に制限するのは役に立つかもしれません。 これで、受信機は、より少ない数のナックメッセージへのナック内容に集めて、ナックフィードバックの有効な確率的な抑圧を容易にするのを助けるために何らかの暗黙のゆるい同期を受信機セットに供給できます。 受信機は現在の修理の必要性を決定するために送付者から受け取られたデータ内容の歴史を維持しなければなりません。 FECが採用しているとき、歴史が未定の、または、部分的に受信されたコード化ブロックの記録に一致すると予想されます。
For probabilistic, timer-base suppression of feedback, the NACK cycle should begin with receivers observing backoff timeouts. In conjunction with initiating this backoff timeout, it is important that the receivers record the current position in the sender's transmission sequence at which they initiate the NACK cycle. When the suppression backoff timeout expires, the receivers should only consider their repair needs up to this recorded transmission position in making the decision to transmit or suppress a NACK. Without this restriction, suppression is greatly reduced as additional content is received from the sender during the time a NACK message propagates across the network to the sender and other receivers.
フィードバックの確率的なタイマベース抑圧のために、受信機がbackoffタイムアウトを観測している状態で、ナックサイクルは始まるべきです。 このbackoffタイムアウトを起こすことに関連して、受信機が彼らがナックサイクルを開始する送付者のトランスミッション系列に現在の位置を記録するのは、重要です。 抑圧backoffタイムアウトが期限が切れると、受信機はナックを伝えるか、または抑圧するという決定をする際に彼らの修理の必要性をこの記録されたトランスミッション位置まで考えるだけであるはずです。 この制限がなければ、抑圧はナックメッセージがネットワークの向こう側に伝播される時の送付者から送付者と他の受信機まで追加内容を受け取るように大いに抑えられます。
Receiver NACK Process Initiation Interface Description
受信機ナックの過程開始インタフェース記述
Inputs:
入力:
1) Sender data content with sequencing identifiers from sender
transmissions.
2) History of content received from sender.
1) 送付者トランスミッションから識別子を配列することの送付者データ内容。 2) 内容の歴史は送付者から受信されました。
Adamson, et al. Experimental [Page 12] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [12ページ]実験的なRFC3941標準ブロック2004年11月
Outputs:
出力:
1) NACK process initiation decision
2) Recorded sender transmission sequence position.
1) ナックの過程開始決定2) 記録された送付者トランスミッション系列位置。
3.2.2. NACK Suppression
3.2.2. ナックSuppression
An effective NORM feedback suppression mechanism is the use of random backoff timeouts prior to NACK transmission by receivers requiring repairs [10]. Upon expiration of the backoff timeout, a receiver will request repairs unless its pending repair needs have been completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender. When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding a representation of NACK content it has received to the group at large or provide some other indicator of the repair information it will be subsequently transmitting.
有効なNORMフィードバック抑圧メカニズムは修理[10]を必要とする受信機によるナックのトランスミッションの前の無作為のbackoffタイムアウトの使用です。 backoffタイムアウトの満了のときに、未定の修理の必要性が他の受信機(受信機がマルチキャスティングNACKsであるときに)か何らかのインディケータから聞かれたナックメッセージによって送付者から完全に取って代わられるというわけではなかったと、受信機は修理を要求するでしょう。 受信機がナックメッセージをunicastingしているとき、送付者は、それが全体のグループに受け取ったナック内容の表現を進めることによってナックの抑圧を容易にするか、またはそれが次に伝える修理情報のある他のインディケータを提供するかもしれません。
For effective and scalable suppression performance, the backoff timeout periods used by receivers should be independently, randomly picked by receivers with a truncated exponential distribution [6]. This results in the majority of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of sender<->group GRTT and a group size estimate that is determined by other mechanisms within the protocol or preset by the multicast application.
有効でスケーラブルな抑圧性能において、受信機によって費やされたbackoffタイムアウト時間は受信機によって端が欠けている指数分布[6]で独自に、手当たりしだいに選ばれるはずです。 これは「前のNACKers」の、より少ない数がグループの残りの修理の必要性に取って代わるという仮定でナックメッセージの伝達を食い止めるように設定された受信機の大部分をもたらします。 分配の平均は、>グループGRTTとプロトコルの中の他のメカニズムによって測定されるグループサイズ見積りが送付者<の現状見積金額の機能として測定されて、マルチキャストアプリケーションであらかじめセットされるべきです。
A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g., NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T_maxBackoff) can be set to control reliable delivery latency versus volume of feedback traffic. A larger value of T_maxBackoff will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T_maxBackoff results in shorter latency which also reduces the buffering requirements of senders and receivers for reliable transport.
適切な分配がある無作為のbackoffタイムアウトを発生させるように簡単なアルゴリズムを構成できます。 受信機(R)の数を考えて、さらに、アルゴリズムは、backoff分配を最適化するようにフィードバックを潜在的に発生させながら、設計されるかもしれません。 この「最適化」はすべての受信機がナックを発生させる最悪の場合状況における、フィードバックメッセージ(例えば、ナック)の数を最小にします。 最大のbackoffタイムアウト(T_maxBackoff)がフィードバック交通のボリュームに従った信頼できる配信潜在を制御するように設定できます。 T_maxBackoffの、より大きい値は与えられた修理サイクルの間のフィードバック交通の低い密度をもたらすでしょう。 T_maxBackoffの、より小さい値はまた、信頼できる輸送のために送付者と受信機のバッファリング要件を減らすより短い潜在をもたらします。
Given the receiver group size (R), and maximum allowed backoff timeout (T_maxBackoff), random backoff timeouts (t') with a truncated exponential distribution can be picked with the following algorithm:
'受信機グループサイズ(R)、および最大の許容backoffタイムアウト(T_maxBackoff)を考えて、以下のアルゴリズムで端が欠けている指数分布がある無作為のbackoffタイムアウト(t')を選ぶことができます:
Adamson, et al. Experimental [Page 13] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [13ページ]実験的なRFC3941標準ブロック2004年11月
1) Establish an optimal mean (L) for the exponential backoff based on
the group size:
1) グループサイズに基づく指数のbackoffのために最適の平均(L)を設立してください:
L = ln(R) + 1
L=ln(R)+1
2) Pick a random number (x) from a uniform distribution over a range
of:
2) 以下の範囲の上の一様分布から乱数(x)を選んでください。
L L L
-------------------- to -------------------- + ----------
T_maxBackoff*(exp(L)-1) T_maxBackoff*(exp(L)-1) T_maxBackoff
L L L-------------------- to-------------------- + ---------- T_maxBackoff*(exp(L)-1)T_maxBackoff*(exp(L)-1)T_maxBackoff
3) Transform this random variate to generate the desired random
backoff time (t') with the following equation:
3) 'この無作為の変量を変えて、以下の方程式で必要な無作為のbackoff時間(t')を発生させてください:
t' = T_maxBackoff/L * ln(x * (exp(L) - 1) * (T_maxBackoff/L))
't'=T_maxBackoff/L*ln(x*(exp(L)--1)*(T_maxBackoff/L))
This C language function can be used to generate an appropriate random backoff time interval:
適切な無作為のbackoff時間間隔を発生させるのにこのC言語機能を使用できます:
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
二重RandomBackoff(maxTimeを倍にしてください、二重groupSize)二重λ=ログ(groupSize)+1; UniformRand(λ/maxTime)+λ二重x=/(maxTime*(exp(λ)-1); (maxTime/λ)*が登録するリターン(x*(exp(λ)-1)*(maxTime/λ)));//エンドRandomBackoff()
where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following C code can be used:
UniformRand(二重最大)が一様分布がある乱数を0の範囲から返すところ。最大限にしてください。 例えば、POSIX「底ならし革()」機能に基づいて、以下のCコードを使用できます:
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
二重UniformRand(二重最大)リターン(最大*((二重)の底ならし革()/(二重)のRAND_MAX))。
The number of expected NACK messages generated (N) within the first round trip time for a single feedback event is approximately:
単一のフィードバックイベントのための周遊旅行1回目の間の(N) 中で発生した予想されたナックメッセージの数はおよそ以下の通りです。
N = exp(1.2 * L / (2*T_maxBackoff/GRTT))
Nはexpと等しいです。(1.2*L/(_2*T maxBackoff/GRTT))
Thus the maximum backoff time can be adjusted to tradeoff worst-case NACK feedback volume versus latency. This is derived from [6] and assumes T_maxBackoff >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above.
したがって、見返り最悪の場合ナックフィードバックボリューム対潜在に最大のbackoff時間を調整できます。 これは、[6]から得られて、T_maxBackoff>=がGRTTであると仮定します、そして、Lは与えられたグループサイズのために上のアルゴリズムで示されるように最適化された分配の平均です。
Adamson, et al. Experimental [Page 14] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [14ページ]実験的なRFC3941標準ブロック2004年11月
Note that other mechanisms within the protocol may work to reduce redundant NACK generation further. It is suggested that T_maxBackoff be selected as an integer multiple of the sender's current advertised GRTT estimate such that:
プロトコルの中の他のメカニズムがさらに余分なナック世代を短縮するために働くかもしれないことに注意してください。 送付者の現在の広告を出しているGRTTの整数倍数が、そのようなものがそれであると見積もっているのでT_maxBackoffが選択されることが提案されます:
T_maxBackoff = K * GRTT ;where K >= 1
T_maxBackoff=K*GRTT; どこK>=1
For general Internet operation, a default value of K=4 is RECOMMENDED for operation with multicast (to the group at large) NACK delivery and a value of K=6 for unicast NACK delivery. Alternate values may be used to for buffer utilization, reliable delivery latency and group size scalability tradeoffs.
一般的なインターネット操作、Kのデフォルト値=4のために、マルチキャスト(全体のグループへの)ナックの配送による操作のためのRECOMMENDEDとユニキャストナックの配送のためのK=6の値はそうですか? 交互の値は、バッファ利用に中古の、そして、信頼できる配送潜在とグループサイズスケーラビリティ見返りであるかもしれません。
Given that (K*GRTT) is the maximum backoff time used by the receivers to initiate NACK transmission, other timeout periods related to the NACK repair process can be scaled accordingly. One of those timeouts is the amount of time a receiver should wait after generating a NACK message before allowing itself to initiate another NACK backoff/transmission cycle (T_rcvrHoldoff). This delay should be sufficient for the sender to respond to the received NACK with repair messages. An appropriate value depends upon the amount of time for the NACK to reach the sender and the sender to provide a repair response. This MUST include any amount of sender NACK aggregation period during which possible multiple NACKs are accumulated to determine an efficient repair response. These timeouts are further discussed in the section below on "Sender NACK Processing and Repair Response".
(K*GRTT)が受信機によって費やされた、ナックのトランスミッションを開始した最大のbackoff時間であるなら、それに従って、ナック修理の過程に関連する他のタイムアウト時間はスケーリングできます。 それらのタイムアウトの1つはそれ自体を許容する前にナックメッセージを発生させた後に受信機がもう1ナックのbackoff/トランスミッションサイクル(T_rcvrHoldoff)開始するのを待つはずである時間です。 送付者が修理メッセージで容認されたナックに反応するように、この遅れは十分であるべきです。 適切な値はナックが修理応答を提供するために送付者と送付者に連絡する時間に依存します。 これは可能な倍数NACKsが効率的な修理応答を決定するために蓄積されるどんな量の送付者ナック集合の期間も含まなければなりません。 「送付者ナックの処理と修理応答」のときに下のセクションでこれらのタイムアウトについてさらに議論します。
There are also secondary measures that can be applied to improve the performance of feedback suppression. For example, the sender's data content transmissions can follow an ordinal sequence of transmission. When repairs for data content occur, the receiver can note that the sender has "rewound" its data content transmission position by observing the data object, FEC block number, and FEC symbol identifiers. Receivers SHOULD limit transmission of NACKs to only when the sender's current transmission position exceeds the point to which the receiver has incomplete reception. This reduces premature requests for repair of data the sender may be planning to provide in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mechanism (particularly applicable when FEC is used) is for the sender to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisement of the number of FEC packets to be sent for the current applicable coding block.
また、フィードバック抑圧の性能を向上させるために適用できる二次測定があります。 例えば、送付者のデータ内容送信はトランスミッションの序数の順序に従うことができます。 データ内容のための修理が起こると、受信機は、送付者がデータ・オブジェクト、FEC街区番号、およびFECシンボル識別子を観察することによってデータ内容トランスミッション位置を「巻き戻した」と述べることができます。 受信機SHOULDは送付者の変流器位置が受信機が不完全なレセプションを開くポイントを超えている時だけまでNACKsのトランスミッションを制限します。 これは送付者が他の受信機要求に対応して提供するのを計画しているかもしれないデータの修理を求める時期尚早な要求を減らします。 他の受信機(または、送付者からのインディケータ)からのNACKsのトランスミッションが無くなるとき、高い損失状態におけるプロトコル集合に、このメカニズムは非常に効果的である場合があります。 別のメカニズム(特に適切なFECが使用されていると)は送付者が現在のパケットのトランスミッションが送った差し迫っている修理のしるしを埋め込むことです。 例えば、指示は現在の適切なコード化ブロックに送られるFECパケットの数の広告と同じくらい簡単であるかもしれません。
Adamson, et al. Experimental [Page 15] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [15ページ]実験的なRFC3941標準ブロック2004年11月
Finally, some consideration might be given to using the NACKing history of receivers to weight their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this requires there is correlation over successive intervals of time in the loss experienced by a receiver. Such correlation MAY not be present in multicast networks. This adjustment of backoff timeout selection may require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process that may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network.
最終的に、彼らのナックbackoffタイムアウト間隔の品揃えに重みを加えるために受信機のNACKing歴史を費やすことに対して何らかの考慮を払うかもしれません。 例えば、受信機が最大級の度の損失を歴史的に経験しているなら、それ自体を促進するかもしれない、統計的である、ナック、他の受信機より早く。 連続した間隔の間、これがそこで必要とする注意は受信機によって経験された損失で、時間の相関関係です。そのような相関関係はマルチキャストネットワークで存在していないかもしれません。 backoffタイムアウト選択のこの調整はこれらの歴史的なNACKersのために「初期のナック」スロットの創造を必要とするかもしれません。 ナックbackoffの窓のこの追加スロットはいくつかのアプリケーションには、望ましくないかもしれないより長い修理サイクルの過程をもたらすでしょう。 これらのトレードオフの解決はプロトコルの目標アプリケーションセットかネットワークに依存しているかもしれません。
After the random backoff timeout has expired, the receiver will make a decision on whether to generate a NACK repair request or not (i.e., it has been suppressed). The NACK will be suppressed when any of the following conditions has occurred:
無作為のbackoffタイムアウトが期限が切れた後に、受信機はナックの修理要求を発生させるかどうかに関して決定するでしょう(すなわち、それは抑圧されました)。 以下の条件のどれかが現れたとき、ナックは抑圧されるでしょう:
1) The accumulated state of NACKs heard from other receivers (or
forwarding of this state by the sender) is equal to or supersedes
the repair needs of the local receiver. Note that the local
receiver should consider its repair needs only up to the sender
transmission position recorded at the NACK cycle initiation (when
the backoff timer was activated).
1) 蓄積は、地方の受信機について他から聞かれたNACKsにおいて受信機(または、送付者によるこの状態の推進)が等しいと述べるか、または修理の必要性に取って代わります。地方の受信機が修理の必要性を単にナックのサイクル開始のときに記録された送付者トランスミッション位置まで考えるはずであることに注意してください(backoffタイマが動いたとき)。
2) The sender's data content transmission position "rewinds" to a
point ordinally less than that of the lowest sequence position of
the local receiver's repair needs. (This detection of sender
"rewind" indicates the sender has already responded to other
receiver repair needs of which the local receiver may not have
been aware). This "rewind" event can occur any time between 1)
when the NACK cycle was initiated with the backoff timeout
activation and 2) the current moment when the backoff timeout has
expired to suppress the NACK. Another NACK cycle must be
initiated by the receiver when the sender's transmission sequence
position exceeds the receiver's lowest ordinal repair point. Note
it is possible that the local receiver may have had its repair
needs satisfied as a result of the sender's response to the repair
needs of other receivers and no further NACKing is required.
2) 送付者のデータ内容トランスミッション位置は地方の受信機の修理の必要性の最も低い系列位置のものよりそれほど序数をポイントに「巻き戻します」。 (「巻き戻送付者」のこの検出は、送付者が既に地方の受信機が意識していなかったかもしれない他の受信機修理の必要性に応じたのを示します。) ナックサイクルがbackoffタイムアウト起動で開始された1と)2の何時でも) backoffタイムアウトがナックを抑圧するために期限が切れた現在の瞬間この「巻き戻し」出来事は起こることができます。 送付者のトランスミッション系列位置が受信機の最も低い序数の修理ポイントを超えているとき、受信機でもう1ナックサイクルを開始しなければなりません。 他の受信機の修理の必要性への送付者の応答の結果、地方の受信機で修理需要を満たしていたのが可能であり、一層のNACKingは全く必要でないことに注意してください。
If these conditions have not occurred and the receiver still has pending repair needs, a NACK message is generated and transmitted. The NACK should consist of an accumulation of repair needs from the receiver's lowest ordinal repair point up to the current sender transmission sequence position. A single NACK message should be generated and the NACK message content should be truncated if it exceeds the payload size of single protocol message. When such NACK
これらの状態が現れていなくて、受信機に未定の修理の必要性がまだあるなら、ナックメッセージは、発生して、送られます。 ナックは受信機の最も低い序数の修理ポイントからの修理の必要性の蓄積から現在の送付者トランスミッション系列位置まで成るべきです。 ただ一つのナックメッセージは発生するべきです、そして、ただ一つのプロトコルメッセージのペイロードサイズを超えているなら、ナックメッセージ内容は先端を切られるべきです。 そのようなWhenナック
Adamson, et al. Experimental [Page 16] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [16ページ]実験的なRFC3941標準ブロック2004年11月
payload limits occur, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender.
ペイロード限界は起こって、SHOULDが含むナック内容は序数的に最も低いように送付者から必要である修理内容を要求します。
NACK Suppression Interface Description
ナックの抑圧インタフェース記述
Inputs:
入力:
1) NACK process initiation decision.
2) Recorded sender transmission sequence position.
3) Sender GRTT.
4) Sender group size estimate.
5) Application-defined bound on backoff timeout period.
6) NACKs from other receivers.
7) Pending repair indication from sender (may be forwarded
NACKs).
8) Current sender transmission sequence position.
1) ナックの過程開始決定。 2) 記録された送付者トランスミッション系列位置。 3) 送付者GRTT。 4) 送付者グループサイズ見積り。 5) backoffタイムアウト時間のアプリケーションで定義されたバウンド。 6) 他の受信機からのNACKs。 7) 送付者(NACKsを進めるかもしれない)からの未定の修理指示。 8) 現在の送付者トランスミッション系列位置。
Outputs:
出力:
1) Yes/no decision to generate NACK message upon backoff timer
expiration.
1) backoffタイマ満了に関するナックメッセージを発生させるというはい/いいえ決定。
3.2.3. NACK Content
3.2.3. ナックContent
The content of NACK messages generated by reliable multicast receivers will include information detailing their current repair needs. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the sender to which the NACK is addressed and the data transport object (or stream) within the sender's transmission that needs repair. For the indicated transport entity, the NACK content will then identify the specific FEC coding blocks and/or symbols it requires to reconstruct the complete transmitted data. This content may consist of FEC block erasure counts and/or explicit indication of missing blocks or symbols (segments) of data and FEC content. It should also be noted that NORM can be effectively instantiated without a requirement for reliable NACK delivery using the techniques discussed here.
信頼できるマルチキャスト受信機で発生するナックメッセージの内容は彼らの現在の修理の必要性を詳しく述べる情報を含むでしょう。 特殊情報はNORM修理の過程によるFECの使用とタイプに頼っています。 修理の必要性の識別はデータ内容識別に依存しています(以下のセクション3.5を見てください)。 上層部によってナック内容は修理を必要とする送付者のトランスミッションの中でナックが宛てられる送付者とデータ伝送物(流れる)を特定するでしょう。 そして、示された輸送実体のために、ナック内容はそれが完全な伝えられたデータを再建するのを必要とする特定のFECコード化ブロック、そして/または、シンボルを特定するでしょう。 この内容はなくなったブロックのFECブロック消去カウント、そして/または、明白なしるしかデータとFEC内容のシンボル(セグメント)から成るかもしれません。 また、事実上、信頼できるナックの配送のための要件なしでここで議論したテクニックを使用することでNORMを例示できることに注意されるべきです。
3.2.3.1. NACK and FEC Repair Strategies
3.2.3.1. ナックとFEC修理戦略
Where FEC-based repair is used, the NACK message content will minimally need to identify the coding block(s) for which repair is needed and a count of erasures (missing packets) for the coding block. An exact count of erasures implies the FEC algorithm is capable of repairing _any_ loss combination within the coding block.
FECベースであるところでは、修理が使用されています、メッセージ内容が最少量で修理が必要であるコード化ブロックとコード化ブロックのための消去(なくなったパケット)のカウントを特定する必要があるナック。 消去の正確なカウントは、FECアルゴリズムが_コード化ブロックの中のどんな_損失組み合わせも修理できるのを含意します。
Adamson, et al. Experimental [Page 17] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [17ページ]実験的なRFC3941標準ブロック2004年11月
This count may need to be adjusted for some FEC algorithms. Considering that multiple repair rounds may be required to successfully complete repair, an erasure count also implies that the quantity of unique FEC parity packets the server has available to transmit is essentially unlimited (i.e., the server will always be able to provide new, unique, previously unsent parity packets in response to any subsequent repair requests for the same coding block). Alternatively, the sender may "round-robin" transmit through its available set of FEC symbols for a given coding block, and eventually affect repair. For a most efficient repair strategy, the NACK content will need to also _explicitly_ identify which symbols (information and/or parity) the receiver requires to successfully reconstruct the content of the coding block. This will be particularly true of small to medium size block FEC codes (e.g., Reed Solomon) that are capable of provided a limited number of parity symbols per FEC coding block.
このカウントは、いくつかのFECアルゴリズムのために調整される必要があるかもしれません。また、複数の修理ラウンドが首尾よく修理を終了するのに必要であるかもしれないと考える場合、消去カウントは、サーバが伝えるために利用可能にするユニークなFECパリティパケットの量が本質的には無制限であることを含意します(すなわち、サーバがいつも新しい状態で提供できるでしょう、ユニークである、以前に、いずれもに対応したその後のunsentパリティパケットは同じコード化ブロックに関する要求を修理します)。 あるいはまた、送付者は、利用可能なセットのFECシンボルを通して「コマドリ」で与えられたコード化ブロックに送って、結局、修理に影響するかもしれません。 最も効率的な修理戦略、内容が明らかに_にも必要とするナックに関して、_はどれを特定するか。受信機が首尾よくコード化ブロックの内容を再建するのを必要とするシンボル(情報、そして/または、同等)。 これは特に限られた数のFECコード化ブロックあたりのパリティシンボルに提供できる中くらいのサイズブロックFECコード(例えば、リード・ソロモン)に小さいのに関して本当になるでしょう。
When FEC is not used as part of the repair process, or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the delay*bandwidth*loss characteristics of the network topology), the NACK content will need to contain _explicit_ coding block and/or segment loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set.
FECが修理の過程の一部として使用されないか、またはプロトコル具体化が送付者がすべての利用可能な同等を与えられたコード化ブロックに送ったときさえ(トランスミッション歴史をバッファリングする送付者の能力はネットワーク形態の遅れ*帯域幅*損失特性で超えられています)、信頼性を提供するのに必要であるときに; ナック内容は、送付者が適切な修理パケット、そして/または、データ「再-トランスミッション」を提供できるように_明白な_コード化ブロック、そして/または、セグメント損失情報を含む必要があるでしょう。 また、ナック内容の明白な損失情報は潜在的に他の目的に役立つかもしれません。 例えば、受信機の中のボトルネックが設定する候補輻輳制御を微分するのを助けるのは受信機のグループで損失の特性を反関連させることの役に立つかもしれません。
When FEC is used and NACK content is designed to contain explicit repair requests, there is a strategy where the receivers can NACK for specific content that will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity symbols to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block (e.g., Reed Solomon) is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of data content to the group.
FECが使用されていて、ナック内容が明白な修理要求を含むように設計されているとき、受信機がナックの抑圧と修理効率を容易にするのを助ける特定の内容のためのナックをそうすることができる戦略があります。 この戦略のための仮定は送付者が与えられたコード化ブロックに利用可能な新しくて、ユニークなパリティパケットの供給を潜在的に枯渇させるかもしれなくて、信頼できる転送を終了するために明らかにいくつかのデータかパリティシンボルを再送しなければならないということです。 別の仮定はどんなパリティパケットもコード化ブロック(例えば、リード・ソロモン)の中のどんな消去もいっぱいにすることができるFECアルゴリズムが使用されているということです。 この戦略の目標は、信頼できるデータ転送内容の間、グループに利用可能な同等の最大の使用をして、最小量のデータ量と修理送信を提供することです。
When systematic FEC codes are used, the sender transmits the data content of the coding block (and optionally some quantity of parity packets) in its initial transmission. Note that a systematic FEC coding block is considered to be logically made up of the contiguous set of data vectors plus parity vectors for the given FEC algorithm
系統的なFECコードが使用されているとき、送付者がコード化ブロックのデータ内容を伝える、(任意に、いくらかの量のパリティパケット) 初期のトランスミッションで。 与えられたFECアルゴリズムのために隣接のセットのデータベクトルとパリティベクトルで系統的なFECコード化ブロックが論理的に作られると考えられることに注意してください。
Adamson, et al. Experimental [Page 18] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [18ページ]実験的なRFC3941標準ブロック2004年11月
used. For example, a coding scheme that provides for 64 data symbols and 32 parity symbols per coding block would contain FEC symbol identifiers in the range of 0 to 95.
使用にされる。 例えば、1コード化あたりシンボルと32のパリティシンボルが妨げる64のデータに備えるコード構成は0〜95の範囲にFECシンボル識別子を保管しているでしょう。
Receivers then can construct NACK messages requesting sufficient content to satisfy their repair needs. For example, if the receiver has three erasures in a given received coding block, it will request transmission of the three lowest ordinal parity vectors in the coding block. In our example coding scheme from the previous paragraph, the receiver would explicitly request parity symbols 64 to 66 to fill its three erasures for the coding block. Note that if the receiver's loss for the coding block exceeds the available parity quantity (i.e., greater than 32 missing symbols in our example), the receiver will be required to construct a NACK requesting all (32) of the available parity symbols plus some additional portions of its missing data symbols in order to reconstruct the block. If this is done consistently across the receiver group, the resulting NACKs will comprise a minimal set of sender transmissions to satisfy their repair needs.
そして、受信機は彼らの修理需要を満たすよう十分な内容に要求するナックメッセージを構成できます。 例えば、受信機が与えられた受信されたコード化ブロックに3つの消去を持っていると、それはコード化ブロックでの3つの最も低い序数のパリティベクトルの送信を要求するでしょう。 前のパラグラフからの私たちの例のコード構成で、受信機は、コード化ブロックに3つの消去をいっぱいにするよう明らかに64〜66にパリティシンボルに要求するでしょう。 コード化ブロックのための受信機の損失が有効なパリティ量(すなわち、私たちの例の32以上のなくなったシンボル)を超えていると、受信機がブロックを再建するために利用可能なパリティシンボルのすべての(32)と欠測値シンボルの数個の追加部分を要求するナックを組み立てなければならないことに注意してください。 受信機グループの向こう側に一貫してこれをすると、結果として起こるNACKsは、彼らの修理需要を満たすために1人の極小集合の送付者トランスミッションを包括するでしょう。
In summary, the rule is to request the lower ordinal portion of the parity content for the FEC coding block to satisfy the erasure repair needs on the first NACK cycle. If the available number of parity symbols is insufficient, the receiver will also request the subset of ordinally highest missing data symbols to cover what the parity symbols will not fill. Note this strategy assumes FEC codes such as Reed-Solomon for which a single parity symbol can repair any erased symbol. This strategy would need minor modification to take into account the possibly limited repair capability of other FEC types. On subsequent NACK repair cycles where the receiver may have received some portion of its previously requested repair content, the receiver will use the same strategy, but only NACK for the set of parity and/or data symbols it has not yet received. Optionally, the receivers could also provide a count of erasures as a convenience to the sender or intermediate systems assisting NACK operation.
概要では、規則は修理が最初のナックサイクルに必要とする消去を満たすようFECコード化ブロックでパリティ内容の下側の序数の部分に要求することです。 また、パリティシンボルの有効な数が不十分であるなら、受信機は、パリティシンボルがいっぱいにしないものをカバーするよう序数的に最も高い欠測値シンボルの部分集合に要求するでしょう。 この戦略がただ一つのパリティシンボルがどんな消されたシンボルも修理できるリード-ソロモンなどのFECコードを仮定することに注意してください。 この戦略は、他のFECタイプのことによると限られた修理能力を考慮に入れるために小さい方の変更を必要とするでしょう。 その後のナック修理サイクルに、受信機が以前に要求された修理内容の何らかの部分を受けたかもしれないところで受信機はそれがまだ受け取っていない同等、そして/または、データシンボルのセットに同じ戦略、しかし、ナックだけを使用するでしょう。 また、任意に、受信機は便利としてナックの操作を促進する送付者か中間システムに消去のカウントを供給するかもしれません。
After receipt and accumulation of NACK messages during the aggregation period, the sender can begin transmission of fresh (previously untransmitted) parity symbols for the coding block based on the highest receiver erasure count _if_ it has a sufficient quantity of parity symbols that were _not_ previously transmitted. Otherwise, the sender MUST resort to transmitting the explicit set of repair vectors requested. With this approach, the sender needs to maintain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use the same consistent algorithm to express their explicit repair needs, NACK suppression among receivers is simplified over the course of multiple repair cycles. The receivers
集合の期間のナックメッセージの領収書と蓄積の後に、__それに_以前に伝えられた_でなかった十分な数量のパリティシンボルがあるなら、送付者は最も高い受信機消去カウントに基づくコード化ブロックの新鮮な(以前に「非-伝え」られた)パリティシンボルの送信を始めることができます。 さもなければ、送付者は明白なセットの修理ベクトルが要求した伝えるのによく行かなければなりません。 このアプローチで、送付者は、ほとんどそれがグループからグループから修理要求の同期の必要性なしで受け取った要求の状態を維持しない必要があります。 すべての受信機が彼らの明白な修理の必要性を述べるのに同じ一貫したアルゴリズムを使用するので、受信機の中のナックの抑圧は複数の修理サイクルの過程にわたって簡素化されます。 受信機
Adamson, et al. Experimental [Page 19] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [19ページ]実験的なRFC3941標準ブロック2004年11月
can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages.
単に、それらが自己の未定のナックメッセージを送るべきであるか、または削除するべきであるかを決定するそれら自身の計算された修理の必要性に対して他の受信機から聞かれたNACKsは比較できます。
3.2.3.2. NACK Content Format
3.2.3.2. ナックContentの形式
The format of NACK content will depend on the protocol's data service model and the format of data content identification the protocol uses. This NACK format also depends upon the type of FEC encoding (if any) used. Figure 2 illustrates a logical, hierarchical transmission content identification scheme, denoting that the notion of objects (or streams) and/or FEC blocking is optional at the protocol instantiation's discretion. Note that the identification of objects is with respect to a given sender. It is recommended that transport data content identification is done within the context of a sender in a given session. Since the notion of session "streams" and "blocks" is optional, the framework degenerates to that of typical transport data segmentation and reassembly in its simplest form.
ナック内容の形式はプロトコルのデータサービスモデルとプロトコルが使用するデータ内容識別の形式に頼るでしょう。 また、このナック形式は(もしあれば)のコード化が使用したFECのタイプに頼っています。 図2はトランスミッションの論理的で、階層的な内容識別計画を例証します、物(または、流れ)、そして/または、FECブロッキングの概念がプロトコル具体化の裁量で任意であることを指示して。 与えられた送付者に関して物の識別があることに注意してください。 与えられたセッションのときに送付者の文脈の中で輸送データ内容識別をするのはお勧めです。 セッション「流れ」と「ブロック」の概念が任意であるので、枠組みは最も簡単なフォームでデータ分割と再アセンブリを典型的な輸送のものに堕落しています。
Session_
\_
Sender_
\_
[Object/Stream(s)]_
\_
[FEC Blocks]_
\_
Symbols
セッション_ \_送付者_ \_、[物/流れの(s)]_ \_[FECブロック]_ \_シンボル
Fig. 2: NORM Data Content Identification Hierarchy
図2: 標準データ内容識別階層構造
The format of NACK messages should meet the following goals:
ナックメッセージの形式は以下の目標を達成するべきです:
1) Able to identify transport data unit transmissions required to
repair a portion of the received content, whether it is an entire
missing object/stream (or range), entire FEC coding block(s), or
sets of symbols,
1) トランスミッションがそれが全体のなくなった物/流れ(及ぶ)であるか否かに関係なく、受信された内容の部分を修理するのを必要とした輸送データ単位、全体のFECコード化ブロック、またはセットのシンボルを特定できます。
2) Be simple to process for NACK aggregation and suppression,
2) ナック集合と抑圧のために処理するのは簡単にしてください。
3) Be capable of including NACKs for multiple objects, FEC coding
blocks and/or symbols in a single message, and
3) そしてただ一つのメッセージの複数の物、ブロックをコード化するFEC、そして/または、シンボルにおいてNACKsを含むことができてください。
4) Have a reasonably compact format.
4) 合理的にコンパクトな形式を持ってください。
If the NORM transport object/stream is identified with an <objectId> and the FEC symbol being transmitted is identified with an <fecPayloadId>, the concatenation of <objectId::fecPayloadId>
NORM輸送の物/流れが<objectId>とFECシンボルと同一視されているなら、伝えられるのは<fecPayloadId>と同一視されています、<objectIdの連結:、:fecPayloadId>。
Adamson, et al. Experimental [Page 20] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [20ページ]実験的なRFC3941標準ブロック2004年11月
comprises a basic transport protocol data unit (TPDU) identifier for symbols from a given source. NACK content can be composed of lists and/or ranges of these TPDU identifiers to build up NACK messages to describe the receivers repair needs. If no hierarchical object delineation or FEC blocking is used, the TPDU is a simple linear representation of the data symbols transmitted by the sender. When the TPDU represents a hierarchy for purposes of object/stream delineation and/or FEC blocking, the NACK content unit may require flags to indicate which portion of the TPDU is applicable. For example, if an entire "object" (or range of objects) is missing in the received data, the receiver will not necessarily know the appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for which to request repair and thus requires some mechanism to request repair (or retransmission) of the entire unit represented by an <objectId>. The same is true if entire FEC coding blocks represented by one or a range of <sourceBlockNumbers> have been lost.
与えられたソースからシンボルのための基本的なトランスポート・プロトコルデータ単位(TPDU)識別子を包括します。 修理が必要とする受信機について説明するナックメッセージを確立するためにこれらのTPDU識別子のリスト、そして/または、範囲でナック内容を構成できます。 階層的な物の輪郭描写かどんなFECブロッキングも使用されていないなら、TPDUは送付者によって伝えられたデータシンボルの簡単な直線的な表現です。 TPDUが物/流れの輪郭描写、そして/または、FECブロッキングの目的のために階層構造を表すとき、満足しているユニットが必要とするかもしれないナックは、TPDUのどの部分が適切であるかを示すために弛みます。 例えば、全体の「物」(または、物の範囲)が受信データでなくなるなら、受信機は、必ず修理を要求する<sourceBlockNumbers>か<encodingSymbolIds>の適切な範囲を知るというわけではなくて、その結果、<objectId>によって表された全体の単位の修理(または、「再-トランスミッション」)を要求するために何らかのメカニズムを必要とします。 1時までに表されたブロックかさまざまな<sourceBlockNumbers>をコード化する全体のFECがなくされたなら、同じくらいは本当です。
NACK Content Interface Description
ナックContentのインタフェース記述
Inputs:
入力:
1) Sender identification.
2) Sender data identification.
3) Sender FEC Object Transmission Information.
4) Recorded sender transmission sequence position.
5) Current sender transmission sequence position. History of
repair needs for this sender.
1) 送付者識別。 2) 送付者データ識別。 3) 送付者FEC物のトランスミッション情報。 4) 記録された送付者トランスミッション系列位置。 5) 現在の送付者トランスミッション系列位置。 この送付者の修理の必要性の歴史。
Outputs:
出力:
1) NACK message with repair requests.
1) 修理要求があるナックメッセージ。
3.2.4. Sender Repair Response
3.2.4. 送付者修理応答
Upon reception of a repair request from a receiver in the group, the
sender will initiate a repair response procedure. The sender may
wish to delay transmission of repair content until it has had
sufficient time to accumulate potentially multiple NACKs from the
receiver set. This allows the sender to determine the most efficient
repair strategy for a given transport stream/object or FEC coding
block. Depending upon the approach used, some protocols may find it
beneficial for the sender to provide an indicator of pending repair
transmissions as part of its current transmitted message content.
This can aid some NACK suppression mechanisms. The amount of time to
perform this NACK aggregation should be sufficient to allow for the
maximum receiver NACK backoff window ("T_maxBackoff" from Section
3.2.2) and propagation of NACK messages from the receivers to the
sender. Note the maximum transmission delay of a message from a
グループにおける受信機からの修理要求のレセプションでは、送付者は修理応答手順に着手するでしょう。 受信機セットから潜在的に複数のNACKsを蓄積できるくらいの時間を過すまで、送付者は修理内容の伝達を遅らせたがっているかもしれません。 これで、送付者は与えられた輸送流れ/物かFECコード化ブロックに最も効率的な修理戦略を決定できます。 使用されるアプローチによって、電流の一部がメッセージ内容を伝えたので送付者が未定の修理送信のインディケータを提供するのが、有益であることがいくつかのプロトコルによってわかるかもしれません。 これはいくつかのナック抑圧メカニズムを支援できます。このナック集合を実行する時間は、ナックメッセージの受信機から送付者までの最大の受信機ナックbackoffの窓(セクション3.2.2からの「T_maxBackoff」)と伝播を考慮するために十分であるべきです。 aからメッセージの最大のトランスミッション遅れに注意してください。
Adamson, et al. Experimental [Page 21] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [21ページ]実験的なRFC3941標準ブロック2004年11月
receiver to the sender may be approximately (1*GRTT) in the case of very asymmetric network topology with respect to transmission delay. Thus, if the maximum receiver NACK backoff time is T_maxBackoff = K*GRTT, the sender NACK aggregation period should be equal to at least:
送付者への受信機はトランスミッション遅れに関する非常に非対称のネットワーク形態の場合でおよそ1*GRTT()であるかもしれません。 _したがって、maxBackoffは最大の受信機ナックbackoff時間がTであるならK*GRTTと等しいです、少なくともナック集合の期間が等しいはずである送付者:
T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT
T_sndrAggregateはT_maxBackoff+1*GRTT=(K+1)*GRTTと等しいです。
Immediately after the sender NACK aggregation period, the sender will begin transmitting repair content determined from the aggregate NACK state and continue with any new transmission. Also, at this time, the sender should observe a "holdoff" period where it constrains itself from initiating a new NACK aggregation period to allow propagation of the new transmission sequence position due to the repair response to the receiver group. To allow for worst case asymmetry, this "holdoff" time should be:
送付者ナック集合の期間直後、送付者は、集合ナック状態から決定している修理内容を伝え始めて、どんな新しいトランスミッションも続行するでしょう。 またと、このとき、送付者は、それが自制する"holdoff"の期間が受信機グループへの修理応答のため新しいトランスミッション系列位置の伝播を許すために新しいナック集合の期間を開始しているのを観測するべきです。 この"holdoff"時間は、最悪の場合非対称を考慮するためには、以下の通りであるべきです。
T_sndrHoldoff = 1*GRTT
T_sndrHoldoffは1*GRTTと等しいです。
Recall that the receivers will also employ a "holdoff" timeout after generating a NACK message to allow time for the sender's response. Given a sender <T_sndrAggregate> plus <T_sndrHoldoff> time of (K+1)*GRTT, the receivers should use holdoff timeouts of:
また、送付者の応答のための時間を許容するナックメッセージを発生させた後に受信機が"holdoff"タイムアウトを使うと思い出してください。 (K+1)*GRTTの送付者<T_sndrAggregate>と<T_sndrHoldoff>時間を考えて、受信機は以下のholdoffタイムアウトを使用するはずです。
T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTT
T_rcvrHoldoffはT_sndrAggregate+T_sndrHoldoff=(K+2)*GRTTと等しいです。
This allows for a worst-case propagation time of the receiver's NACK to the sender, the sender's aggregation time and propagation of the sender's response back to the receiver. Additionally, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) a representation of its aggregated NACK content to the group to allow for NACK suppression when there is not multicast connectivity among the receiver set.
これは受信機への送付者の応答に関する送付者の受信機のナックの送付者への最悪の場合伝播時間、集合時間、および伝播を考慮します。受信機セットからのユニキャストフィードバックの場合では、さらに、送付者が受信機セットの中にマルチキャストの接続性がないとき、ナックの抑圧を考慮するために集められたナック内容の表現をグループに送るのは(マルチキャストで)、役に立つかもしれません。
At the expiration of the <T_sndrAggregate> timeout, the sender will begin transmitting repair messages according to the accumulated content of NACKs received. There are some guidelines with regards to FEC-based repair and the ordering of the repair response from the sender that can improve reliable multicast efficiency:
<T_sndrAggregate>タイムアウトの満了のときに、送付者はNACKsの蓄積された内容に従ったメッセージが受けた修理を伝え始めるでしょう。 FECベースの修理への尊敬があるいくつかのガイドラインと信頼できるマルチキャスト効率を高めることができる送付者からの修理応答の注文があります:
1) When FEC is used, it is beneficial that the sender transmit
previously untransmitted parity content as repair messages
whenever possible. This maximizes the receiving nodes' ability
to reconstruct the entire transmitted content from their
individual subsets of received messages.
1) FECが使用されているとき、可能であるときはいつも、送付者が修理メッセージとして以前に「非-伝え」られたパリティ内容を伝えるのは、有益です。 これはそれらの受信されたメッセージの個々の部分集合から全体の伝えられた内容を再建する受信ノードの性能を最大にします。
Adamson, et al. Experimental [Page 22] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [22ページ]実験的なRFC3941標準ブロック2004年11月
2) The transmitted object and/or stream data and repair content
should be indexed with monotonically increasing sequence numbers
(within a reasonably large ordinal space). If the sender observes
the discipline of transmitting repair for the earliest content
(e.g., ordinally lowest FEC blocks) first, the receivers can use a
strategy of withholding repair requests for later content until
the sender once again returns to that point in the object/stream
transmission sequence. This can increase overall message
efficiency among the group and help work to keep repair cycles
relatively synchronized without dependence upon strict time
synchronization among the sender and receivers. This also helps
minimize the buffering requirements of receivers and senders and
reduces redundant transmission of data to the group at large.
2) 伝えられた物、そして/または、流れのデータと修理内容は単調に増加する一連番号(合理的に大きい序数のスペースの中の)で索引をつけられるべきです。 送付者が、伝えることの規律が最初に最も初期の内容(例えば、序数的に最も少ないFECブロック)のために修理されるのを観測するなら、送付者が物/流れ転送系列でそのポイントにもう一度戻るまで、受信機は後の内容に修理要求を差し控える戦略を使用できます。 これは、送付者と受信機の中でグループで総合的なメッセージ効率を増加させて、厳しい時間同期化で修理サイクルを保つために働くのを依存なしで比較的連動していた状態で助けることができます。 これは、また、受信機と送付者のバッファリング要件を最小にするのを助けて、データの余分な伝達を全体のグループに抑えます。
Sender Repair Response Interface Description
送付者修理応答インタフェース記述
Inputs:
入力:
1) Receiver NACK messages
2) Group timing information
1) 受信機ナックメッセージ2) グループタイミング情報
Outputs
出力
1) Repair messages (FEC and/or Data content retransmission)
2) Advertisement of current pending repair transmissions when
unicast receiver feedback is detected.
1) 修理メッセージ(FEC、そして/または、Data内容「再-トランスミッション」) 2) ユニキャスト受信機フィードバックであるときに、現在の未定の修理送信の広告は検出されます。
3.3. NORM Receiver Join Policies and Procedures
3.3. 標準受信機は方針と手順を接合します。
Consideration should be given to the policies and procedures by which new receivers join a group (perhaps where reliable transmission is already in progress) and begin requesting repair. If receiver joins are unconstrained, the dynamics of group membership may impede the application's ability to meet its goals for forward progression of data transmission. Policies limiting the opportunities when receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial for receivers to attempt reliable reception from a newly-heard sender only upon non-repair transmissions of data in the first FEC block of an object or logical portion of a stream. The sender may also implement policies limiting the receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situations. Alternatively, it may be desirable to have a looser transport synchronization policy and rely upon session management mechanisms to limit group dynamics that can cause poor performance, in some types of bulk transfer applications (or for potential interactive reliable multicast applications).
新しい受信機が仲間に入って(恐らく信頼できるトランスミッションが既に進行しているところ)、修理を要求し始める方針と手順に対して考慮を払うべきです。 受信機が接合する、自由です、グループ会員資格の力学はデータ伝送の前進の進行の目標を達成するアプリケーションの能力を妨害するかもしれません。 受信機がナックの過程に参加し始めると機会を制限する方針は、望まれた行動を達成するのに使用されるかもしれません。 例えば、受信機が単に流れの物か論理的な部分の最初のFECブロックでのデータの非修理送信のときに新たに聞かれた送付者からの信頼できるレセプションを試みるのは、有益であるかもしれません。 また、送付者はいくつかの状況におけるスケーラビリティ理由で禁止でしかし、それが受け入れる受信機を制限するナックが要求するこれが政策であるかもしれないことを実施するかもしれません。 あるいはまた、不十分な性能を引き起こす場合があるグループ・ダイナミックスを制限するために、よりゆるい輸送同期方針を持って、セッション管理メカニズムを当てにするのは望ましいかもしれません、何人かのタイプのバルク転送アプリケーションで(潜在的対話的な信頼できるマルチキャスト、アプリケーション)
Adamson, et al. Experimental [Page 23] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [23ページ]実験的なRFC3941標準ブロック2004年11月
Group Join Policy Interface Description
グループは方針インタフェース記述に参加します。
Inputs:
入力:
1) Current object/stream data/repair content and sequencing
identifiers from sender transmissions.
1) 現在の物/流れのデータ/修理内容と送付者トランスミッションから識別子を配列すること。
Outputs:
出力:
1) Receiver yes/no decision to begin receiving and NACKing for
reliable reception of data
1) データの信頼できるレセプションのための受信機はい/いいえの受信し始めるという決定とNACKing
3.4. Reliable Multicast Member Identification
3.4. 信頼できるマルチキャストメンバー識別
In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces that result in different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier <sourceId> field should be present in packets transmitted by reliable multicast session members.
データの複数の源の可能性があるNORMプロトコル(または、他のマルチキャストプロトコル)では、グループの中で唯一、ソース(そして、いくつかの場合におけることによるといくつかかすべての受信機)を特定するために何らかのメカニズムを提供するのが必要です。 到着しているパケットソースアドレスに基づくアイデンティティはいくつかの理由で不十分です。 これらの理由は、ホストのために与えられたホストのための時間がたつにつれての異なったパケットソースアドレス、ネットワークアドレス変換(NAT)、ファイアウォール装置、または他の輸送/ネットワークの橋を架けることにおける結果がアプローチする複数のインタフェースで変化を発送するのを含んでいます。 その結果、タイプのユニークなソース識別子<sourceId>分野は頼もしいマルチキャストセッションメンバーによって伝えられたパケットに存在しているべきです。
3.5. Data Content Identification
3.5. データ内容識別
The data and repair content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will also be used in NACK messages generated. This building block document assumes two very general types of data that may comprise bulk transfer session content. One type is static, discrete objects of finite size and the other is continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these paradigms. While it may be possible for some applications to further generalize this model and provide mechanisms to encapsulate static objects as content embedded within a stream, there are advantages in many applications to provide distinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer, or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e., segmentation/reassembly, caching, integrated forward error correction coding, etc.) rather than being
NORM送付者によって送られたデータと修理内容はプロトコルヘッダーフィールドにおける、何らかの形式の識別を必要とします。 この識別が、信頼できるナック指向の修理の過程を容易にするのに必要です。 また、これらの識別子は発生するナックメッセージで使用されるでしょう。 このブロックドキュメントはバルク転送セッション内容を包括するかもしれない2つの非常に一般的なタイプに関するデータを仮定します。 1つのタイプが有限サイズの静的で、離散的な物です、そして、もう片方が連続した非有限な流れです。与えられたアプリケーションは、これらのパラダイムのどちらかか両方を使用することでマルチキャストデータ確かに満足していた状態でそうしたがっているかもしれません; いくつかのアプリケーションが流れの中で埋め込まれた内容として静的な物をカプセルに入れるためにさらにこのモデルを広めて、メカニズムを提供するのが、可能であるかもしれませんが、静的な大量の物とメッセージの異なったサポートを信頼できるマルチキャストセッションの文脈に提供する多くのアプリケーションにおける利点があります。 これらのアプリケーションは大量の内容でサーバ、ファイル転送、または協力的なツールをキャッシュする内容を含むかもしれません。 そして、これらの静的なオブジェクト・タイプのための要件があるアプリケーションは存在よりむしろトランスポート層メカニズム(すなわち、分割/再アセンブリ、キャッシュしていて、統合している前進型誤信号訂正コード化など)を利用できます。
Adamson, et al. Experimental [Page 24] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [24ページ]実験的なRFC3941標準ブロック2004年11月
required to provide their own mechanisms for these functions at the application layer.
応用層でのこれらの機能にそれら自身のメカニズムを提供するのが必要です。
As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-real-time message broadcasts (e.g., stock ticker) or some content types that are part of collaborative tools or other applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g., files) into one or more streams within a multicast session.
注意されるように、あるいはまた、いくつかのアプリケーションが、非有限なサイズの1つ以上の流れの形で大量の内容を伝えることを望むかもしれません。 例のストリームは連続した準リアルタイムのメッセージ放送(例えば、ストックチッカー)か協力的なツールか他のアプリケーションの一部である何人かの満足しているタイプを含んでいます。 そして、いくつかのアプリケーションがマルチキャストセッション以内に上で示されるように他の大量の内容(例えば、ファイル)を1つ以上の流れの中に要約したがっているかもしれません。
The components described within this building block document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast session. To support this requirement, the normal data content identification should include a field to uniquely identify the object or stream <objectId> within some reasonable temporal or ordinal interval. Note that it is _not_ expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session and during the time that sender is supporting a specific transport instance of that object or stream.
このブロックドキュメントの中に説明されたコンポーネントは、ただ一つのマルチキャストセッション以内に両方のタイプのミックスの可能性でこれらのモデルの両方に適切になるように思い描かれます。 この要件を支持するなら、データの通常の内容識別は、いくつかの妥当な時の、または、序数の間隔以内に唯一物を特定するか、または<objectId>を流すために分野を含むべきです。 _どんな_も、このデータ内容識別がグローバルにユニークになると予想しなかったということであることに注意してください。 物/流れの識別子が信頼できるマルチキャストセッションと送付者がその物か流れの特定の輸送例を支持する時間与えられた送付者に関してユニークになると予想されます。
Since the "bulk" object/stream content usually requires segmentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier that has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive transmissions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC the segment identification portion of the data content identifier may consist of a logical concatenation of a coding block identifier <sourceBlockNumber> and an identifier for the specific data or parity symbol <encodingSymbolId> of the code block. The FEC Building Block document [9] provides a standard message format for identifying FEC transmission content. NORM protocol instantiations using FEC SHOULD follow that document's guidelines.
「大量」の物/流れの内容が通常分割を必要とするので、また、何らかの形式のセグメント識別を提供しなければなりません。 このセグメント識別子は提供されたどんな物や流れの識別子に比例しているでしょう。 したがって、NORMプロトコル具体化は、平行な静的な物の複数の流れと1セット以上のためにトランスミッションを受けて、いくつかの場合、修理を要求できるかもしれません。 プロトコル具体化のために、FECを使って、データ内容識別子のセグメント識別部分はコード化ブロック識別子<sourceBlockNumber>の論理的な連結とコードブロックの特定のデータかパリティシンボル<encodingSymbolId>のための識別子から成るかもしれません。 FECビルBlockドキュメント[9]はFECトランスミッション内容を特定するための標準のメッセージ・フォーマットを提供します。 FEC SHOULDを使用するNORMプロトコル具体化がそのドキュメントのガイドラインに従います。
Additionally, flags to determine the usage of the content identifier fields (e.g., stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations.
さらに、満足している識別子分野(例えば、物に対して流れる)の用法を決定する旗は適切であるかもしれません。 また、旗はデータ内容識別における他の目的に役立つかもしれません。 定義されたどんな旗も個々のプロトコル具体化に依存するようになると予想されます。
In summary, the following data content identification fields may be required for NORM protocol data content messages:
概要では、以下のデータ内容識別分野がNORMプロトコルデータ内容メッセージに必要であるかもしれません:
1) Source node identifier (<sourceId>)
1) ソースノード識別子(<sourceId>)
Adamson, et al. Experimental [Page 25] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [25ページ]実験的なRFC3941標準ブロック2004年11月
2) Object/Stream identifier (<objectId>), if applicable.
2) 物/流れの識別子(<objectId>)で、適切です。
3) FEC Block identifier (<sourceBlockNumber>), if applicable.
3) FEC Block識別子(<sourceBlockNumber>)で、適切です。
4) FEC Symbol identifier (<encodingSymbolId>)
4) FEC Symbol識別子(<encodingSymbolId>)
5) Flags to differentiate interpretation of identifier fields or
identifier structure that implicitly indicates usage.
5) それとなく用法を示す識別子分野か識別子構造の解釈を微分する旗。
6) Additional FEC transmission content fields per FEC Building Block
6) FECビルBlockあたりのトランスミッションの追加FEC内容分野
These fields have been identified because any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NORM protocols that use these data content fields should also be compatible with support for intermediate system assistance to reliable multicast transport operation when available.
どんな発生しているナックメッセージも修理かデータの再伝送を要求する際にこれらの識別子を使用するので、これらの分野は特定されました。 また、利用可能であるときに、これらのデータ内容分野を使用するNORMプロトコルも信頼できるマルチキャスト輸送操作に対する中間システム支援のサポートと互換性があるべきです。
3.6. Forward Error Correction (FEC)
3.6. 前進型誤信号訂正(FEC)
Multiple forward error correction (FEC) approaches have been identified that can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast protocols [11], [12], [13]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its coding block size (in symbols). In NORM, parity repair packets generated will generally be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for transmitting some predetermined quantity of FEC repair packets multiplexed with the regular data symbol transmissions [14]. This can reduce the amount of NACK traffic generated with relatively little overhead cost when group sizes are very large or the network connectivity has a large delay*bandwidth product with some nominal level of expected packet loss. While the application of FEC is not unique to NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches that are applicable.
ナック指向の、そして、他の信頼できるマルチキャストプロトコル[11]の修理の過程にかなりのパフォーマンス強化を提供できる複数の前進型誤信号訂正(FEC)アプローチが特定されました、[12]、[13]。 FECベースの修理がコード化ブロック・サイズ(シンボルの)の領域の中で一般に_が必要とするどんな_にも修理内容の形式知をしないので、NORMプロトコルは付加的な利益を獲得できます。 一般に、NORMでは、パケットが発生させたパリティ修理は単にノードを受け取るのからのナックの修理要求に対応して伝えられるでしょう。 しかしながら、定期的なデータシンボル送信[14]と共に多重送信されたいくらかの予定された量のFEC修理パケットを伝えるためのいくつかのネットワーク環境には利益があります。 これはグループサイズが非常に大きいか、またはネットワークの接続性に何らかの名目上のレベルの予想されたパケット損失に伴う大きい遅れ*帯域幅生成物があると比較的小さい間接費で発生するナック交通の量を減少させることができます。 FECのアプリケーションがNORMにユニークでない間、これらの種類の要件は適切なアルゴリズムとプロトコルアプローチのタイプを決めるかもしれません。
A specific issue related to the use of FEC with NORM is the mechanism used to identify the portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concatenation of <sourceId::objectId::sourceBlockNumber::encodingSymbolId> during transport, it is expected that FEC packets will be identified in a similar manner. The FEC Building Block document [9] provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages.
NORMとのFECの使用に関連する特定の問題は特定のFECパケットが適切である伝えられたデータ内容の部分を特定するのにおいて中古のメカニズムです。 FECアルゴリズムが1セットのパリティ修理パケットを伝えられたデータ・パケットの対応するブロックに発生させるのに基づくと予想されます。 以来、データ内容パケットは<sourceIdの連結で唯一特定されます:、:objectId:、:sourceBlockNumber:、:encodingSymbolId>、輸送の間、FECパケットが同じように特定されると予想されます。 FECビルBlockドキュメント[9]はFECと標準書式の応用に関して関連する信頼できるマルチキャストプロトコルメッセージに詳細な推薦を提供します。
Adamson, et al. Experimental [Page 26] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [26ページ]実験的なRFC3941標準ブロック2004年11月
3.7. Round-trip Timing Collection
3.7. 往復のタイミング収集
The measurement of packet propagation round-trip time (RTT) among members of the group is required to support timer-based NACK suppression algorithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip information collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable manner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques that might be employed for increased efficiency [15]. And in some cases, there might be absolute time synchronization among hosts that may simplify RTT measurement. There are trade-offs in multicast congestion control design that require further consideration before a universal recommendation on RTT (or GRTT) measurement can be specified. Regardless of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for various timeouts used by receivers.
グループのメンバーの中のパケットの伝播の往復の時間(RTT)の測定が、タイマベースのナック抑圧アルゴリズムか送付者コマンドのタイミングかある修理機能と、混雑制御機能をサポートするのに必要です。 集められた往復の情報の本質はグループのメンバーの中で相互作用のタイプに依存しています。 「多くへの1」トランスミッションだけが必要である場合では、多分、送付者だけが受信機セットの中の最もすばらしいRTT(GRTT)に関するRTT知識、そして/または、グループの部分だけに関するRTT知識を必要とします。 ここに、GRTT情報は合理的にスケーラブルな方法で集められるかもしれません。 混雑制御機能において、RTT情報がグループにおける各受信機によって必要とされるのは、可能です。 この場合、代替のRTT収集計画は、受信機が個々のRTT測定を集めるところで送付者に関して利用されて、グループか送付者にそれらの広告を出すかもしれません。 信頼できるマルチキャストデータの交換がグループに起こりそうであるところに、増加する効率[15]に使われるかもしれない代替の測定技術が「多くへの多く」ベースでは、あります。 そして、いくつかの場合、RTT測定を簡素化するかもしれないホストの中に絶対時間同期があるかもしれません。 マルチキャスト輻輳制御デザインにおけるRTT(または、GRTT)測定の普遍的な推薦を指定できる前にさらなる考慮を必要とするトレードオフがあります。 RTT情報が輻輳制御か他の要件に関してどう集められるか(そして、より明確にGRTT)にかかわらず、送付者は、受信機によって使用される様々なタイムアウトのために現在のGRTT見積りのグループに広告を出す必要があるでしょう。
3.7.1. One-to-Many Sender GRTT Measurement
3.7.1. 多くへの1つの送付者GRTT測定
The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows.
この形式のRTT測定の目標は送付者が受信機の中の活発にNORM操作に参加しているGRTTを学ぶことです。 この過程に参加する受信機のセットは、プロトコル具体化の中で別のメカニズムから決定しているグループの全体のグループか何らかの部分集合であるかもしれません。 このGRTT情報を集めるアプローチは続きます。
The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a <sendTime> timestamp relative to an internal clock at the sender. Upon reception of this message, the receivers will record this <sendTime> timestamp and the time (referenced to their own clocks) at which it was received <recvTime>. When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantiation specification), it will construct a "response" using the formula:
送付者の内部クロックに比例して<sendTime>タイムスタンプを含んで、送付者は定期的にメッセージ(独立者かもう一方で「背負われて」トランスミッション)でグループに投票します。 このメッセージのレセプションに、受信機はそれが容認された<recvTime>であったこの<sendTime>タイムスタンプと時(それら自身の時計に参照をつけられる)を記録するでしょう。 受信機が送付者(明らかかプロトコル具体化仕様による他のフィードバックメッセージの一部とした)にフィードバックを提供するとき、公式を使用することで「応答」を組み立てるでしょう:
Adamson, et al. Experimental [Page 27] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [27ページ]実験的なRFC3941標準ブロック2004年11月
grttResponse = sendTime + (currentTime - recvTime)
grttResponseはsendTime+と等しいです。(currentTime--recvTime)
where the <sendTime> is the timestamp from the last probe message received from the source and the (<currentTime> - <recvTime>) is the amount of time differential since that request was received until the receiver generated the response.
そして、<sendTime>がソースから受け取られた最後の徹底的調査メッセージからのタイムスタンプである、(<currentTime>--<recvTime>) 受信機が応答を発生させるまでその要求が受信される時から、時間はデフ装置ですか?
The sender processes each receiver response by calculating a current RTT measurement for the receiver from whom the response was received using the following formula:
送付者は応答が以下の公式を使用することで受けられた受信機のための現在のRTT測定について計算することによって、それぞれの受信機応答を処理します:
RTT_rcvr = currentTime - grttResponse
RTT_rcvr=currentTime--grttResponse
During the each periodic GRTT probing interval, the source keeps the peak round trip timing measurement (RTT_peak) from the set of responses it has received. A conservative estimate of GRTT is kept to maximize the efficiency of redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules:
それぞれ周期的GRTTの間、間隔を調べて、ソースは、それが受けた応答のセットからピークが周遊旅行タイミング測定(RTT_ピーク)であることを保ちます。 GRTTの内輪な見積りは、余分なナックの抑圧と修理集合の効率を最大にするために保たれます。 ソースのGRTTの進行中の見積りへのアップデートは以下の規則を守り終わっています:
1) If a receiver's response round trip time (RTT_rcvr) is greater
than the current GRTT estimate, the GRTT is immediately updated to
this new peak value:
1) 受信機の応答周遊旅行時間(RTT_rcvr)が現在のGRTT見積りより大きいなら、すぐに、この新しいピーク値にGRTTをアップデートします:
GRTT = RTT_rcvr
GRTTはRTT_rcvrと等しいです。
2) At the end of the response collection period (i.e., the GRTT probe
interval), if the recorded "peak" response RTT_peak) is less than
the current GRTT estimate, the GRTT is updated to:
2) 応答収集の期間(すなわち、GRTT徹底的調査間隔)の終わり、記録された「ピーク」応答RTT_ピークであるなら以下のことのために現在のGRTTが見積もっているほどGRTTをアップデートしないという、ことです。
GRTT = MAX(0.9*GRTT, RTT_peak)
GRTTはマックスと等しいです。(0.9*GRTT、RTT_ピーク)
3) If no feedback is received, the sender GRTT estimate remains
unchanged.
3) どんなフィードバックも受け取られていないなら、送付者GRTT見積りは変わりがありません。
4) At the end of the response collection period, the peak tracking
value (RTT_peak) is reset to ZERO for subsequent peak detection.
4) 応答収集の期間の終わりに、ピーク追跡価値(RTT_ピーク)はその後のピーク検出のためにZEROにリセットされます。
The GRTT collection period (i.e., period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchanging, but be adjusted to track more dynamically during periods of variation
グループ会員資格、そして/または、ネットワーク形態力学のために予想されたその注文の値でGRTT収集の期間(すなわち、徹底的調査送信について以上)を修理できました。 丈夫さのために、より多くの頻繁で、安定したより状態でないのも間隔まで決着をつける前に、プロトコル始動で、より急速な調べを使用できました。 任意に、アルゴリズムは、ダイナミックに現在のGRTT見積り(または、それの変化)に対応したパケット損失に関する見積りにGRTT収集の期間を調整するために開発されるかもしれません。 GRTT見積りが安定していて変らないときに、次に、メッセージを調べるオーバーヘッドを下げることができましたが、変化の期間、よりダイナミックに追跡するには、調整されてください。
Adamson, et al. Experimental [Page 28] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [28ページ]実験的なRFC3941標準ブロック2004年11月
with correspondingly shorter GRTT collection periods. GRTT collection may also be coupled with collection of other information for congestion control purposes.
対応するより短いGRTT収集の期間で。 また、GRTT収集は混雑管理目的のための他の情報の収集に結びつけられるかもしれません。
In summary, although NORM repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not _strictly_ depend on highly accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environments where NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relatively high loss connectivity. The steady-state probing/update interval may potentially be varied to accommodate different levels of expected network dynamics in different environments.
NORM修理サイクルタイムアウトは概要GRTTに基づいていますが、プロトコルの集中的な操作がそうしないことに注意されるべきです。_厳密に、_は高精度なGRTT見積りによります。 現在のメカニズムはNORMのようなプロトコルがこれまで配備されたところでシミュレーションと環境で十分であると判明しました。 アルゴリズムで提供された見積りは比較的高い損失の接続性でさえ実際のGRTT(ネットワーク遅延と同様にオペレーティングシステム効果を含んでいる)のピーク封筒を追跡します。 定常状態調べ/アップデート間隔は、異なった環境における、異なったレベルの予想されたネットワーク力学に対応するために潜在的に変えられるかもしれません。
3.7.2. One-to-Many Receiver RTT Measurement
3.7.2. 多くへの1つの受信機RTT測定
In this approach, receivers send messages with timestamps to the sender. To control the volume of these receiver-generated messages, a suppression mechanism similar to that described for NACK suppression my be used. The "age" of receivers' RTT measurement should be kept by receivers and used as a metric in competing for feedback opportunities in the suppression scheme. For example, receiver who have not made any RTT measurement or whose RTT measurement has aged most should have precedence over other receivers. In turn the sender may have limited capacity to provide an "echo" of the receiver timestamps back to the group, and it could use this RTT "age" metric to determine which receivers get precedence. The sender can determine the GRTT as described in 3.7.1 if it provides sender timestamps to the group. Alternatively, receivers who note their RTT is greater than the sender GRTT can compete in the feedback opportunity/suppression scheme to provide the sender and group with this information.
このアプローチでは、受信機はタイムスタンプがあるメッセージを送付者に送ります。 これらの受信機で発生しているメッセージのボリュームを制御するために、それと同様の抑圧メカニズムがナックのために抑圧について説明した、私、使用されてください。 受信機のRTT測定の「時代」は、受信機によって保たれて、抑圧計画のフィードバックの機会を競争するメートル法のコネとして使用されるべきです。 例えば、少しのRTT測定もしていないか、または測定がRTTに最も年をとらせた受信機は他の受信機の上の先行を持っているはずです。 順番に、送付者は受信機タイムスタンプの「エコー」をグループに提供して戻す能力を制限したかもしれません、そして、それはどの受信機が先行を得るかを決定するためにはメートル法のこのRTT「時代」を使用するかもしれません。 送付者は、グループへのタイムスタンプを送付者に提供するなら3.7で.1について説明するので、GRTTを決定できます。 あるいはまた、それらのRTTが送付者GRTTよりすばらしいことに注意する受信機は、この情報を送付者とグループに提供するためにフィードバック機会/抑圧計画に参加することができます。
3.7.3. Many-to-Many RTT Measurement
3.7.3. 多くへの多くRTT測定
For reliable multicast sessions that involve multiple senders, it may be useful to have RTT measurements occur on a true "many-to-many" basis rather than have each sender independently tracking RTT. Some protocol efficiency can be gained when receivers can infer an approximation of their RTT with respect to a sender based on RTT information they have on another sender and that other sender's RTT with respect to the new sender of interest. For example, for receiver "a" and sender's "b" and "c", it is likely that:
複数の送付者にかかわる信頼できるマルチキャストセッションに、RTT測定値をRTTを追跡しながら各送付者が独自にいるより本当「多くへの多く」ベースでむしろ現れさせるのは、役に立つかもしれません。 受信機がそれらが別の送付者とその他の送付者のRTTに興味がある新しい送付者に関して持っているRTT情報に基づく送付者に関してそれらのRTTの近似を推論できるとき、何らかのプロトコル効率を獲得できます。 例えば、送付者の受信機“a"、「b」、および「c」に関して以下のことはありそうです。
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
RTT(<>b)<はRTTと等しいです(<>c))。 + RTT(b<>c)
Adamson, et al. Experimental [Page 29] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [29ページ]実験的なRFC3941標準ブロック2004年11月
Further refinement of this estimate can be conducted if RTT information is available to a node concerning its own RTT to a small subset of other group members and RTT information among those other group members it learns during protocol operation.
RTT情報がそれがプロトコル操作の間に学ぶそれらの他のグループのメンバーの中で他のグループのメンバーとRTT情報の小さい部分集合へのそれ自身のRTTに関してノードに利用可能であるなら、この見積りのさらなる気品を行うことができます。
3.7.4. Sender GRTT Advertisement
3.7.4. 送付者GRTT広告
To facilitate deterministic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (compressing) the GRTT estimate to a single byte of information. The following C- language functions allows this to be done over a wide range (RTT_MIN through RTT_MAX) of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large values. Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for RTT_MIN and RTT_MAX respectively. NORM applications may wish to place an additional, smaller upper limit on the GRTT advertised by senders to meet application data delivery latency constraints at the expense of greater feedback volume in some network environments.
決定論的なNORMプロトコル操作を容易にするために、送付者は強壮にGRTTの現在の見積りの受信機セットに広告を出すべきです。 一般的です、グループの送付者の現在の操作GRTT見積りに関する強健な知識で、プロトコルは最も効率的な方法に進歩できるでしょう。 強壮に送付者のGRTT見積りのグループに単に送付者によって送られたすべての適切なメッセージに見積りを埋め込むことによって、広告を出すことができます。 1バイトの情報にGRTT見積りを量子化することによって(圧縮します)、このオーバーヘッドをかなり小さくすることができます。 以下のC言語機能で、これは大きい値のための小さいGRTT値と、より少ない精度のために、より大きい範囲の精度を維持している間、広範囲(RTT_MAXを通したRTT_MIN)のGRTT値にわたってします。 1.0e-06秒と1000秒の値はそれぞれRTT_MINとRTT_MAXのためのRECOMMENDEDです。 NORMアプリケーションはいくつかのネットワーク環境における、より大きいフィードバックボリュームを犠牲にしてアプリケーションデータ配送潜在規制を満たすために送付者によって広告に掲載されたGRTTに関して追加していて、より小さい上限を課したがっているかもしれません。
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
無記名の炭のQuantizeGrtt(二重grtt)_(grtt>RTT_MAX)grttがRTTと等しいなら、ほかに、grttが(grtt<RTT_MIN)であるならRTT_MINと等しいというMAXは(grtt<(33*RTT_MIN))であるなら戻ります((無記名の炭)(grtt / RTT_MIN)--1); リターン(無記名の炭)(ceil(255.0(13.0*ログ(RTT_MAX/grtt))))ほかの
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
二重UnquantizeRtt(無記名の炭のqrtt)戻ってください((qrtt<=31)--((二重)(qrtt+1))の*(二重)RTT_MIN): (RTT_MAX/exp(((二重)の(255-qrtt)/(二重)の13.0)))
Adamson, et al. Experimental [Page 30] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [30ページ]実験的なRFC3941標準ブロック2004年11月
Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT estimates (e.g., limit the maximum value) for practical reasons.
この機能が1マイクロセカンドから1000秒の範囲でGRTTに回を量子化することの役に立つことに注意してください。 もちろん、NORMプロトコル実現は実際的な理由でさらに広告を出しているGRTT見積りを抑制したがっているかもしれません(例えば、最大値を制限します)。
3.8. Group Size Determination/Estimation
3.8. グループサイズ決断/見積り
When NORM protocol operation includes mechanisms that excite feedback from the group at large (e.g., congestion control), it may be possible to roughly estimate the group size based on the number of feedback messages received with respect to the distribution of the probabilistic suppression mechanism used. Note the timer-based suppression mechanism described in this document does not require a very accurate estimate of group size to perform adequately. Thus, a rough estimate, particularly if conservatively managed, may suffice. Group size may also be determined administratively. In absence of a group size determination mechanism a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NORM usage.
NORMプロトコル操作が全体のグループ(例えば、輻輳制御)からのフィードバックを興奮させるメカニズムを含んでいるとき、手荒く確率的な抑圧メカニズムの分配に関して受け取られたフィードバックメッセージの数に基づいているサイズが使用したグループを見積もっているのは可能であるかもしれません。 本書では説明されたタイマベースの抑圧メカニズムが適切に働くためにグループサイズの非常に正確な見積りを必要としないことに注意してください。 したがって、特に保守的に管理されるなら、概算は十分であるかもしれません。 また、グループサイズも行政上決定しているかもしれません。 グループサイズ決断メカニズムの欠如では、予想されたNORM用法のスケーラビリティを考えて、1万のデフォルトグループサイズ価値はフィードバックの合理的な管理のためのRECOMMENDEDです。
3.9. Congestion Control Operation
3.9. 輻輳制御操作
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. The TCP-Friendly Multicast Congestion Control (TFMCC) [16] or Pragmatic General Multicast Congestion Control (PGMCC) techniques [17] may be applied to NORM operation to meet this requirement.
他の信頼できるマルチキャストとTCP具体化と有効なネットワーク容量を公正に共有する輻輳制御は一般的なインターネット操作のためのREQUIREDです。 TCP好意的なMulticast Congestion Control(TFMCC)[16]かPragmatic Multicast Congestion Control司令官(PGMCC)テクニック[17]が、この必要条件を満たすためにNORM操作に適用されるかもしれません。
3.10. Router/Intermediate System Assistance
3.10. ルータ/中間システム支援
NACK-oriented protocols may benefit from general purpose router assistance. In particular, additional NACK suppression where routers or intermediate systems can aggregate NACK content (or filter duplicate NACK content) from receivers as it is relayed toward the sender could enhance NORM group size scalability. For NORM protocols using FEC, it is possible that intermediate systems may be able to filter FEC repair messages to provide an intelligent "subcast" of repair content to different legs of the multicast topology depending on the repair needs learned from previous receiver NACKs. Both of these types of assist functions would require router interpretation of transport data unit content identifiers and flags.
ナック指向のプロトコルは汎用のルータ支援の利益を得るかもしれません。 それが送付者に向かってリレーされるときルータか中間システムが受信機からのナック内容(または、フィルタ写しナック内容)に集められることができるところで特に、追加ナックの抑圧はNORMグループサイズスケーラビリティを高めるかもしれません。 FECを使用するNORMプロトコルにおいて、中間システムが前の受信機NACKsから学習された修理の必要性によるマルチキャストトポロジーの異なった脚に修理内容の知的な"「副-キャスト」"を提供するFEC修理メッセージをフィルターにかけることができるのは、可能です。 これらのタイプのアシスト関数の両方が輸送データ単位満足している識別子と旗のルータ解釈を必要とするでしょう。
3.11. NORM Applicability
3.11. 標準の適用性
The NORM building block applies to protocols wishing to employ negative acknowledgement to achieve reliable data transfer. Properly designed negative-acknowledgement (NACK)-oriented reliable multicast
NORMブロックは、確実な資料転送を達成するのに否定的承認を使いたがっているプロトコルに申し込みます。 適切に設計された否定的承認(ナック)指向の信頼できるマルチキャスト
Adamson, et al. Experimental [Page 31] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [31ページ]実験的なRFC3941標準ブロック2004年11月
(NORM) protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure above the basic Layer 3 IP multicast service (e.g., unicast or hybrid unicast/multicast data distribution trees). Additionally, the scalability property of NACK-oriented protocols [18], [19] is applicable where broad "fan-out" is expected for a single network hop (e.g., cable-TV data delivery, satellite, or other broadcast communication services). Furthermore, the simplicity of a protocol based on "flat" group-wide multicast distribution may offer advantages for a broad range of distributed services or dynamic networks and applications. NORM protocols can make use of reciprocal (among senders and receivers) multicast communication under the Any- Source Multicast (ASM) model defined in RFC 1112 [2], and are capable of scalable operation in asymmetric topologies such as Single-Source Multicast (SSM) [8] where there may only be unicast routing service from the receivers to the sender(s).
(NORM)プロトコルは様々な理由で、基本的なLayer3IPマルチキャストサービス(例えば、ユニキャストかハイブリッドユニキャスト/マルチキャスト情報配給木)を超えて、より高い注文配送インフラストラクチャを構成するのが禁止であるアプリケーション、そして/または、ネットワークtopologiesのためにスケーラビリティ利点を示します。 さらに、ナック指向のプロトコル[18]、[19]のスケーラビリティの特性は広いところで適切です。「四方八方に広がること」は単一のネットワークホップ(例えば、ケーブルテレビデータ配送、衛星、または他の放送通信サービス)のために予想されます。 その上、「平坦な」グループ全体のマルチキャスト分配に基づくプロトコルの簡単さは広範囲な分配されたサービスかダイナミックなネットワークとアプリケーションのために利点を示すかもしれません。 NORMプロトコルは、RFC1112[2]で定義されたAnyソースMulticast(ASM)モデルの下で相互的な(送付者と受信機の中の)マルチキャストコミュニケーションを利用できて、受信機から送付者までのユニキャストルーティングサービスがあるだけであるかもしれないSingle-ソースMulticast(SSM)[8]などの非対称のtopologiesでスケーラブルな操作ができます。
NORM operation is compatible with transport layer forward error correction coding techniques as described in [13] and congestion control mechanisms such as those described in [16] and [17]. A principal limitation of NORM operation involves group size scalability when network capacity for receiver feedback is very limited. NORM operation is also governed by implementation buffering constraints. Buffering greater than that required for typical point-to-point reliable transport (e.g., TCP) is recommended to allow for disparity in the receiver group connectivity and to allow for the feedback delays required to attain group size scalability.
NORM操作は[13]で説明されるようにテクニックをコード化するトランスポート層前進型誤信号訂正と[16]と[17]で説明されるそれらなどの混雑制御機構と互換性があります。 受信機フィードバックのためのネットワーク容量が非常に限られているとき、NORM操作の主要な制限はグループサイズスケーラビリティにかかわります。 また、NORM操作は規制をバッファリングする実現で治められます。 受信機グループの接続性の不一致を考慮して、フィードバック遅れを考慮するために典型的な二地点間信頼できる輸送(例えば、TCP)に必要であるそれがお勧めであるよりすばらしいバッファリングがグループサイズスケーラビリティに達するのが必要です。
4. Security Considerations
4. セキュリティ問題
NORM protocols are expected to be subject to the same sort of security vulnerabilities as other IP and IP multicast protocols. NORM is compatible with IP security (IPsec) authentication mechanisms [20] that are RECOMMENDED for protection against session intrusion and denial of service attacks. A particular threat for NACK based protocols is that of NACK replay attacks that would prevent a NORM sender from making forward progress in transmission. Any standard IPsec mechanisms that can provide protection against such replay attacks are RECOMMENDED for use. Additionally, NORM protocol instantiations SHOULD consider providing support for their own NACK replay attack protection when network layer mechanisms are not available. The IETF Multicast Security (msec) Working Group is also developing solutions which may be applicable to NORM in the future.
NORMプロトコルは他のIPとIPマルチキャストプロトコルへの同じ種類のセキュリティの脆弱性を受けることがあると予想されます。 NORMはセッション押しつけとサービス不能攻撃に対する保護のためのRECOMMENDEDであるIPセキュリティ(IPsec)認証機構[20]と互換性があります。 ナックがプロトコルを基礎づけたので、特定の脅威はNORM送付者がトランスミッションにおける前進の進歩をすることができないナック反射攻撃のものです。 そのような反射攻撃に対する保護を提供できるどんな標準のIPsecメカニズムも使用のためのRECOMMENDEDです。 さらに、NORMプロトコル具体化SHOULDは、ネットワーク層メカニズムが利用可能でないときに、それら自身のナックの反射攻撃保護のサポートを提供すると考えます。 また、IETF Multicast Security(msec)作業部会は将来NORMに適切であるかもしれない現像液です。
Adamson, et al. Experimental [Page 32] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [32ページ]実験的なRFC3941標準ブロック2004年11月
5. Acknowledgements (and these are not Negative)
5. 承認(これらはNegativeではありません)
The authors would like to thank Rick Jones, and Joerg Widmer for their valuable comments on this document. The authors would also like to thank the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for their support in development of this specification, and Sally Floyd for her early inputs into this document.
作者はこのドキュメントの彼らの貴重なコメントについてリック・ジョーンズ、およびヨルク・ウィトマーに感謝したがっています。 また、作者はこの仕様の開発における彼らのサポート、およびこのドキュメントへの彼女の早めの入力のためのサリー・フロイドについてRMTワーキンググループいす(ロジャー・カーモードとロレンツォVicisano)に感謝したがっています。
6. References
6. 参照
6.1. Normative References
6.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] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[2] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
6.2. Informative References
6.2. 有益な参照
[3] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[3] マンキン、A.、Romanow、A.、ブラドナー、S.、およびV.パクソン、「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)。
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols". In Proc. ACM SIGCOMM, pages
201--208, September 1990.
[4] クラークとD.とD.Tennenhouse、「プロトコルの新しい世代建築問題。」 Procで。 ACM SIGCOMM、201--208ページ、1990年9月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002.
[5] カーモード、R.、およびL.Vicisanoは「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、2002年4月。
[6] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback,"
in IEEE Infocom, San Francisco, California, p. 964, March/April
1998.
[6]NonnenmacherとJ.とE.Biersack、IEEE Infocom、サンフランシスコ、カリフォルニアpの「最適のマルチキャストフィードバック。」 964 1998年3月/4月。
[7] Macker, J. and R. Adamson, "Quantitative Prediction of Nack
Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM
2002, October 2002.
[7]MackerとJ.とR.アダムソン、「ナックの量的な予測は信頼できるマルチキャスト(標準)フィードバックを適応した」Proc。 2002年10月のIEEE MILCOM2002。
[8] Holbrook, H., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[8] ホルブルック、H.、「マルチキャストのためのチャンネルモデル」、博士号Dissertation、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア、2001年8月。
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[9]Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(2002年12月)。
Adamson, et al. Experimental [Page 33] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [33ページ]実験的なRFC3941標準ブロック2004年11月
[10] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang. "A
Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[10] フロイド、S.、ジェーコブソン、V.、McCanne、S.、リュウ、C.、およびL.チャン。 「軽量のセッションとアプリケーションレベル縁どりのための信頼できるマルチキャスト枠組み」、Proc。 1995年8月のACM SIGCOMM。
[11] Metzner, J., "An Improved Broadcast Retransmission Protocol",
IEEE Transactions on Communications, Vol. Com-32, No.6, June
1984.
[11]Metzner、J.、「改良された放送Retransmissionプロトコル」、コミュニケーションにおけるIEEE取引、Vol.Com-32、No.6、1984年6月。
[12] Macker, J., "Reliable Multicast Transport and Integrated
Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97,
October 1997.
[12]Mackerと、J.と、「信頼できるマルチキャスト輸送と統合消去ベースの前進型誤信号訂正」、Proc。 1997年10月のIEEE MILCOM97。
[13] 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.
[13]Luby、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453(2002年12月)。
[14] Gossink, D. and J. Macker, "Reliable Multicast and Integrated
Parity Retransmission with Channel Estimation", IEEE GLOBECOM
98'.
'[14]GossinkとD.とJ.Macker、「チャネル推定がある信頼できるマルチキャストの、そして、統合しているパリティRetransmission」IEEE GLOBECOM98'。
[15] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-
Overhead Network Delay Estimation", NCSU/AT&T White Paper,
February 1999.
[15]OzdemirとV.とMuthukrishnan、S.とI.Rhee、「スケーラブルで、頭上で低いネットワーク遅延見積り」、NCSU/AT&T白書、1999年2月。
[16] Widmer, J. and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM SIGCOMM 2001, San
Diego, August 2001.
[16] ウィトマー、J.、およびM.ハンドレー「方程式ベースの輻輳制御をマルチキャストアプリケーションに広げている」Proc ACM SIGCOMM2001、サンディエゴ2001年8月。
[17] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm,
August 2000.
[17] リゾー、L.は「以下をpgmccします」。 Proc ACM SIGCOMM2000、ストックホルム2000年8月の「TCPに優しい単一賃率マルチキャスト輻輳制御計画。」
[18] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast
Protocols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[18]Pingali、S.、Towsley、D.、およびJ.黒瀬、「送付者によって開始されて受信機で開始している信頼できるマルチキャストプロトコルの比較。」 Procで。 INFOCOM、サンフランシスコ(カリフォルニア)1993年10月。
[19] B.N. Levine, J.J. Garcia-Luna-Aceves, "A Comparison of Known
Classes of Reliable Multicast Protocols", Proc. International
Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct
29--Nov 1, 1996.
[19] B.N.レヴィン、J.J.ガルシアルーナAceves、「知られているクラスの信頼できるマルチキャストプロトコルの比較」、Proc。 10月29日--ネットワーク・プロトコル(ICNP-96)に関する国際会議、コロンブス、オハイオ、1996年11月1日。
[20] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[20] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Adamson, et al. Experimental [Page 34] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [34ページ]実験的なRFC3941標準ブロック2004年11月
7. Authors' Addresses
7. 作者のアドレス
Brian Adamson Naval Research Laboratory Washington, DC 20375
ブライアン・アダムソン・海軍研究試験所のワシントン、DC 20375
EMail: adamson@itd.nrl.navy.mil
メール: adamson@itd.nrl.navy.mil
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
EMail: cabo@tzi.org
メール: cabo@tzi.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
マーク・ハンドレー・コンピュータサイエンス学部ユニバーシティ・カレッジロンドンガウアー・ストリートロンドンWC1E 6BTイギリス
EMail: M.Handley@cs.ucl.ac.uk
メール: M.Handley@cs.ucl.ac.uk
Joe Macker Naval Research Laboratory Washington, DC 20375
ジョー・Macker海軍研究試験所のワシントン、DC 20375
EMail: macker@itd.nrl.navy.mil
メール: macker@itd.nrl.navy.mil
Adamson, et al. Experimental [Page 35] RFC 3941 NORM Building Blocks November 2004
アダムソン、他 [35ページ]実験的なRFC3941標準ブロック2004年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Adamson, et al. Experimental [Page 36]
アダムソン、他 実験的[36ページ]
一覧
スポンサーリンク
