Network Working Group B. Whetten
Request for Comments: 3048 Talarian
Category: Informational L. Vicisano
Cisco
R. Kermode
Motorola
M. Handley
ACIRI 9
S. Floyd
ACIRI
M. Luby
Digital Fountain
January 2001
Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores". Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols.
この文書では、バルク・データ信頼性の高いマルチキャストトランスポートの標準化のためのフレームワークについて説明します。それは現代の信頼性の高いマルチキャストトランスポートのいくつかのクラスの展開時に得られた経験に基づいて構築、およびビルディングブロックの数にプロトコルのこれらのクラス間の共通点を引き出すしようとします。そのために、このドキュメントは、複数のプロトコルのクラスに共通する特定のコンポーネントは、「ビルディング・ブロック」として標準化することをお勧めします。特定非常プロトコル、しっかり絡み合っ関数、からなるプロトコルの残りの部分は、「プロトコルコア」として指定されなければなりません。従って、各プロトコルは、複数のプロトコルを横切って再使用することができる「ビルディングブロック」の数と「プロトコルコア」をマージすることによって構築することができます。
Table of Contents
目次
1 Introduction .................................................. 2
1.1 Protocol Families ........................................... 5
2 Building Blocks Rationale ..................................... 6
2.1 Building Blocks Advantages .................................. 6
2.2 Building Block Risks ........................................ 7
2.3 Building Block Requirements ................................. 8
3 Protocol Components ........................................... 8
3.1 Sub-Components Definition ................................... 9
4 Building Block Recommendations ................................ 12
4.1 NACK-based Reliability ...................................... 13
4.2 FEC coding .................................................. 13
4.3 Congestion Control .......................................... 13
4.4 Generic Router Support ...................................... 14
4.5 Tree Configuration .......................................... 14
4.6 Data Security ............................................... 15
4.7 Common Headers .............................................. 15
4.8 Protocol Cores .............................................. 15
5 Security ...................................................... 15
6 IANA Considerations ........................................... 15
7 Conclusions ................................................... 16
8 Acknowledgements .............................................. 16
9 References .................................................... 16
10 Authors' Addresses ........................................... 19
11 Full Copyright Statement ..................................... 20
RFC 2357 lays out the requirements for reliable multicast protocols that are to be considered for standardization by the IETF. They include:
RFC 2357は、IETFで標準化のために考慮されるべきである信頼性マルチキャストプロトコルのための要件をレイアウトします。彼らは、次のとおりです。
o Congestion Control. The protocol must be safe to deploy in the widespread Internet. Specifically, it must adhere to three mandates: a) it must achieve good throughput (i.e., it must not consistently overload links with excess data or repair traffic), b) it must achieve good link utilization, and c) it must not starve competing flows.
O輻輳制御。プロトコルは、広範囲のインターネットで展開するのは安全でなければなりません。具体的には、3つの義務を遵守する必要があります。a）それはつまり、それは一貫して超過したデータや修理トラフィックとのリンクをオーバーロードしてはならない（良いスループットを達成しなければならない）、b）はそれが良いリンク利用率を達成しなければならない、そしてc）それは、競合餓死してはなりません流れ。
o Scalability. The protocol should be able to work under a variety of conditions that include multiple network topologies, link speeds, and the receiver set size. It is more important to have a good understanding of how and when a protocol breaks than when it works.
Oスケーラビリティ。プロトコルは、複数のネットワークトポロジー、リンク速度、および受信機のセットのサイズを含む、様々な条件下で動作することができなければなりません。いつ、どのようにそれが動作するときよりもプロトコルの切断ををよく理解していることがより重要です。
o Security. The protocol must be analyzed to show what is necessary to allow it to cope with security and privacy issues. This includes understanding the role of the protocol in data confidentiality and sender authentication, as well as how the protocol will provide defenses against denial of service attacks.
Oセキュリティ。プロトコルは、セキュリティやプライバシーの問題に対処できるようにするためには何が必要かを示すために分析しなければなりません。これは、プロトコルは、サービス拒否攻撃からの防御を提供する方法、データの機密性と送信者認証におけるプロトコルの役割を理解するだけでなく、含まれています。
These requirements are primarily directed towards making sure that any standards will be safe for widespread Internet deployment. The advancing maturity of current work on reliable multicast congestion control (RMCC) [HFW99] in the IRTF Reliable Multicast Research Group (RMRG) has been one of the events that has allowed the IETF to charter the RMT working group. RMCC only addresses a subset of the design space for reliable multicast. Fortuitously, the requirements it addresses are also the most pressing application and market requirements.
これらの要件は、主にどの規格が普及、インターネットの展開のために安全であることを確認することに向けられています。信頼性マルチキャスト輻輳制御（RMCC）[HFW99] IRTFで信頼性の高いマルチキャスト研究グループ（RMRG）上の現在の作業の進行成熟度は、RMTワーキンググループ憲章にIETFを許可しているイベントの一つとなっています。 RMCCは唯一の信頼できるマルチキャストの設計空間のサブセットに対応しています。偶然、要件もアドレスも喫緊のアプリケーションと市場の要求です。
A protocol's ability to meet the requirements of congestion control, scalability, and security is affected by a number of secondary requirements that are described in a separate document [RFC2887]. In summary, these are:
プロトコルの輻輳制御の要件を満たす能力、スケーラビリティ、およびセキュリティを、別の文書[RFC2887]に記載されている二次の要件の数によって影響されます。要約すると、これらは以下のとおりです。
o Ordering Guarantees. A protocol must offer at least one of either source ordered or unordered delivery guarantees. Support for total ordering across multiple senders is not recommended, as it makes it more difficult to scale the protocol, and can more easily be implemented at a higher level.
O保証を注文します。プロトコルは、ソース命じたり順不同配信保証のいずれかの少なくとも一つを提供しなければなりません。それはより困難プロトコルを拡張することができ、より容易に、より高いレベルで実現することができるように、複数の送信者を横切る全順序のサポートは、推奨されません。
o Receiver Scalability. A protocol should be able to support a "large" number of simultaneous receivers per transport group. A typical receiver set could be on the order of at least 1,000 - 10,000 simultaneous receivers per group, or could even eventually scale up to millions of receivers in the large Internet.
レシーバスケーラビリティO。プロトコルは、トランスポート・グループ当たりの同時受信の「大」の数をサポートすることができなければなりません。典型的な受信機のセットは、少なくとも千台のオーダーである可能性 - グループ10,000の同時受信機、あるいは最終的に大規模なインターネットにおける受信機の数百万人にスケールアップできます。
o Real-Time Feedback. Some versions of RMCC may require soft real-time feedback, so a protocol may provide some means for this information to be measured and returned to the sender. While this does not require that a protocol deliver data in soft real-time, it is an important application requirement that can be provided easily given real-time feedback.
Oリアルタイムのフィードバック。 RMCCの一部のバージョンは、ソフトリアルタイムのフィードバックを必要とするかもしれないので、プロトコルは、この情報を測定し、送信者に返送するためのいくつかの手段を提供することができます。このプロトコルは、ソフトリアルタイムにデータを配信することを必要としませんが、それは簡単に与えられたリアルタイムのフィードバックを提供することができ、重要なアプリケーションの要件があります。
o Delivery Guarantees. In many applications, a logically defined unit or units of data is to be delivered to multiple clients, e.g., a file or a set of files, a software package, a stock quote or package of stock quotes, an event notification, a set of slides, a frame or block from a video. An application data unit is defined to be a logically separable unit of data that is useful to the application. In some cases, an application data unit may be short enough to fit into a single packet (e.g., an event notification or a stock quote), whereas in other cases an application data unit may be much longer than a packet (e.g., a software package). A protocol must provide good throughput of application data units to receivers. This means that most data that is delivered to receivers is useful in recovering the application data unit that they are trying to receive. A protocol may optionally provide delivery confirmation, i.e., a mechanism for receivers to inform the sender when data has been delivered. There are two types of confirmation, at the application data unit level and at the packet level. Application data unit confirmation is useful at the application level, e.g., to inform the application about receiver progress and to decide when to stop sending packets about a particular application data unit. Packet confirmation is useful at the transport level, e.g., to inform the transport level when it can release buffer space being used for storing packets for which delivery has been confirmed. Packet level confirmation may also aid in application data unit confirmation.
Oの配信保証。多くのアプリケーション、データの論理的に定義されたユニットまたはユニットは、複数のクライアントに配信される、例えば、ファイルまたはファイルのセット、ソフトウェアパッケージ、株価の株価やパッケージ、イベント通知のセットでスライド、ビデオからフレームまたはブロック。アプリケーションデータユニットは、アプリケーションに有用であり、データの論理的に分離可能なユニットであると定義されます。他のケースではアプリケーションデータユニットは、はるかに長いパケット（例えば、ソフトウェアよりも場合があるいくつかのケースでは、アプリケーションデータユニットは、（例えば、イベント通知や株価）単一のパケットに収まるほど短くてもよいですパッケージ）。プロトコルは、受信機に、アプリケーション・データ・ユニットの良好なスループットを提供しなければなりません。これは、受信者に配信されるほとんどのデータは、彼らが受け取るしようとしているアプリケーション・データ・ユニットの回復に有用であることを意味します。プロトコルは、必要に応じて送達確認、すなわち、データが配信されたときに受信機が送信者に通知するためのメカニズムを提供することができます。確認には2つのタイプがアプリケーションデータ単位レベルで、パケットレベルで、あります。アプリケーション・データ・ユニットの確認は、例えば、受信機進捗についてアプリケーションに通知すると、特定のアプリケーション・データ・ユニットについてのパケットの送信を停止するタイミングを決定するために、アプリケーションレベルで有用です。パケット確認は、配信が確認されたパケットを格納するために使用されるバッファ・スペースを解放することができる場合にトランスポート・レベルを知らせるために、例えば、トランスポート・レベルで有用です。パケットレベルの確認は、アプリケーションデータユニット確認を助けることができます。
o Network Topologies. A protocol must not break the network when deployed in the full Internet. However, we recognize that intranets will be where the first wave of deployments happen, and so are also very important to support. Thus, support for satellite networks (including those with terrestrial return paths or no return paths at all) is encouraged, but not required.
ネットワークトポロジO。フルインターネットで展開する際のプロトコルは、ネットワークを壊してはいけません。しかし、我々は、展開の最初の波が起こるところイントラネットがなることを認識し、そのためにもサポートすることは非常に重要です。したがって、（地上リターンパスまたは全くリターン経路を有するものを含む）衛星ネットワークのためのサポートを奨励するが、必要ではありません。
o Group Membership. The group membership algorithms must be scalable. Membership can be anonymous (where the sender does not know the list of receivers), or fully distributed (where the sender receives a count of the number of receivers, and optionally a list of failures).
グループメンバーシップO。グループメンバーシップアルゴリズムは、スケーラブルでなければなりません。会員は、（送信者が受信機の数のカウントを受け、障害のリストを必要に応じている）（ここで、送信者が受信者のリストを知らない）匿名で、または完全に分散することができます。
o Example Applications. Some of the applications that a RM protocol could be designed to support include multimedia broadcasts, real time financial market data distribution, multicast file transfer, and server replication.
Oサンプルアプリケーション。 RMプロトコルがサポートするように設計することができるアプリケーションのいくつかは、マルチメディア放送、リアルタイム金融市場データ配信、マルチキャストファイル転送、およびサーバーの複製が含まれます。
In the rest of this document the following terms will be used with a specific connotation: "protocol family", "protocol component", "building block", "protocol core", and "protocol instantiation". A "protocol family" is a broad class of RM protocols which share a common characteristic. In our classification, this characteristic is the mechanism used to achieve reliability. A "protocol component" is a logical part of the protocol that addresses a particular functionality. A "building block" is a constituent of a protocol that implements one, more than one or a part of a component. A "protocol core" is the set of functionality required for the instantiation of a complete protocol, that is not specified by any building block. Finally a "protocol instantiation" is an actual RM protocol defined in term of building blocks and a protocol core.
「プロトコルファミリ」、「プロトコルコンポーネント」、「ビルディングブロック」、「プロトコルコア」、および「プロトコルのインスタンス化」：本文書の残りの部分に、以下の用語は、特定の意味合いで使用されます。 「プロトコルファミリは、」共通の特性を共有するRMプロトコルの幅広いクラスです。私たちの分類では、この特性は、信頼性を達成するために使用されるメカニズムです。 「プロトコル成分」とは、特定の機能性に対処するプロトコルの論理的な部分です。 「ビルディングブロック」は、一つ以上またはコンポーネントの一部を実現するプロトコルの構成要素です。 「プロトコルコア」は、任意のビルディングブロックで指定されていない完全なプロトコルのインスタンス化のために必要な機能の集合です。最終的に「プロトコル・インスタンスは」ビルディングブロックとプロトコルコアの用語で定義された実際のRMプロトコルです。
The design-space document [RFC2887] also provides a taxonomy of the most popular approaches that have been proposed over the last ten years. After congestion control, the primary challenge has been that of meeting the requirement for ensuring good throughput in a way that scales to a large number of receivers. For protocols that include a back-channel for recovery of lost packets, the ability to take advantage of support of elements in the network has been found to be very beneficial for supporting good throughput for a large numbers of receivers. Other protocols have found it very beneficial to transmit coded data to achieve good throughput for large numbers of receivers.
デザインスペースドキュメント[RFC2887]はまた、最後の10年間に提案されている最も人気のあるアプローチの分類を提供します。輻輳制御の後、主な課題は、多数の受信機にスケールする方法で良いスループットを確保するための要件を満たすものとなっています。失われたパケットの回復のためのバックチャネルが含まれるプロトコルでは、ネットワーク内の要素のサポートを利用する機能は、受信機の多数のための良好なスループットをサポートするために非常に有益であることが判明しています。他のプロトコルは、受信機の多数のための良好なスループットを達成するためにコード化されたデータを送信することは非常に有益であることが分かってきました。
This taxonomy breaks proposed protocols into four families. Some protocols in the family provide packet level delivery confirmation that may be useful to the transport level. All protocols in all families can be supplemented with higher level protocols that provide delivery confirmation of application data units.
この分類の区切りは4つのファミリーにプロトコルを提案しました。家族の中でいくつかのプロトコルは、トランスポートレベルに有用である可能性があるパケットレベルの配信確認を提供します。すべての家族のすべてのプロトコルは、アプリケーション・データ・ユニットの配信確認を提供し、より高いレベルのプロトコルで補充することができます。
1 NACK only. Protocols such as SRM [FJM95] and MDP2 [MA99] attempt to limit traffic by only using NACKs for requesting packet retransmission. They do not require network infrastructure.
1 NACKのみ。そのようなSRM [FJM95]とMDP2などのプロトコルは、[MA99]のみパケットの再送を要求するNACKを使用してトラフィックを制限しようとします。彼らは、ネットワークインフラストラクチャを必要としません。
2 Tree based ACK. Protocols such as RMTP [LP96, PSLM97], RMTP-II [WBPM98] and TRAM [KCW98], use positive acknowledgments (ACKs). ACK based protocols reduce the need for supplementary protocols that provide delivery confirmation, as the ACKS can be used for this purpose. In order to avoid ACK implosion in scaled up deployments, the protocol can use servers placed in the network.
2ツリーベースのACK。そのようなRMTP [LP96、PSLM97]、RMTP-II [WBPM98]およびTRAM [KCW98]、などのプロトコルは、肯定応答（ACKを）使用します。 ACKベースのプロトコルは、ACKがこの目的のために使用できるよう、配信確認を提供し、補助プロトコルの必要性を減らします。スケールアップした展開でACK内部破裂を避けるために、プロトコルは、ネットワークに配置されたサーバーを使用することができます。
3 Asynchronous Layered Coding (ALC). These protocols (examples include [RV97] and [BLMR98]) use sender-based Forward Error Correction (FEC) methods with no feedback from receivers or the network to ensure good throughput. These protocols also used sender-based layered multicast and receiver-driven protocols to join and leave these layers with no feedback to the sender to achieve scalable congestion control.
コーディング3非同期階層（ALC）。これらのプロトコル（例は[RV97]を含み、[BLMR98]）は、良好なスループットを確保するために、受信機からのフィードバックなし又はネットワークとセンダベースの順方向誤り訂正（FEC）メソッドを使用します。これらのプロトコルはまた、スケーラブルな輻輳制御を実現するために参加し、送信者へのフィードバックなしに、これらの層を残すために、送信者ベースの階層化マルチキャストおよび受信機駆動型のプロトコルを使用していました。
4 Router assist. Like SRM, protocols such as PGM [FLST98] and [LG97] also use negative acknowledgments for packet recovery. These protocols take advantage of new router software to do constrained negative acknowledgments and retransmissions. Router assist protocols can also provide other functionality more efficiently than end to end protocols. For example, [LVS99] shows
4ルータの支援。 SRMのような、そのような[FLST98]及び[LG97]また、パケットの回復のための否定応答を使用PGMなどのプロトコル。これらのプロトコルは、拘束された否定応答および再送信を行うために新しいルータソフトウェアを活用します。ルータ支援プロトコルはまた、より効率的なプロトコルを終了する以外の端を他の機能を提供することができます。例えば、[LVS99]ショー
how router assist can provide fine grained congestion control for ALC protocols. Router assist protocols can be designed to complement all protocol families described above.
ルータは、ALCプロトコルのためのきめ細かい輻輳制御を提供できる支援方法。ルータ支援プロトコルは、上記のすべてのプロトコルファミリを補完するように設計することができます。
Note that the distinction in protocol families in not necessarily precise and mutually exclusive. Actual protocols may use a combination of the mechanisms belonging to different classes. For example, hybrid NACK/ACK based protocols (such as [WBPM98]) are possible. Other examples are protocols belonging to class 1 through 3 that take advantage of router support.
なお、必ずしも正確と相互に排他的ではないのプロトコルファミリーに区別。実際のプロトコルは、異なるクラスに属する機構の組合せを使用することができます。例えば、（例えば[WBPM98]など）ハイブリッドNACK / ACKベースのプロトコルが可能です。他の例としては、ルータのサポートを活用する3を通じてクラス1に属するプロトコルです。
As specified in RFC 2357 [MRBP98], no single reliable multicast protocol will likely meet the needs of all applications. Therefore, the IETF expects to standardize a number of protocols that are tailored to application and network specific needs. This document concentrates on the requirements for "one-to-many bulk-data transfer", but in the future, additional protocols and building-blocks are expected that will address the needs of other types of applications, including "many-to- many" applications. Note that bulk-data transfer does not refer to the timeliness of the data, rather it states that there is a large amount of data to be transferred in a session. The scope and approach taken for the development of protocols for these additional scenarios will depend upon large part on the success of the "building-block" approach put forward in this document.
[MRBP98] RFC 2357で指定されているように、単一の信頼できるマルチキャストプロトコルは、おそらくすべてのアプリケーションのニーズを満たしていないだろう。そのため、IETFは、アプリケーションとネットワークの特定のニーズに合わせて調整されているプロトコルの数を標準化することを期待します。この文書では、「多対多を含め、他の種類のアプリケーションのニーズに対応することを「一対多のバルク・データ転送」の要件に集中し、将来的には、追加のプロトコルおよびビルディング・ブロックが期待されています「アプリケーション。バルクデータ転送は、データの適時性を参照していないことに注意してください、むしろセッションに転送されるデータ量が多いと述べています。これらの追加シナリオのためのプロトコルの開発のために取ら範囲やアプローチは、本文書に前方に置く「ビルディング・ブロック」アプローチの成功に大きく依存します。
Building a large piece of software out of smaller modular components is a well understood technique of software engineering. Some of the advantages that can come from this include:
小さなモジュラーコンポーネントからソフトウェアの大部分を構築するソフトウェア工学のよく理解技術です。このことから来ることができる利点のいくつかは、次のとおりです。
o Specification Reuse. Modules can be used in multiple protocols, which reduces the amount of development time required.
O仕様の再利用。モジュールは、必要な開発時間の量を減少させる、複数のプロトコルで使用することができます。
o Reduced Complexity. To the extent that each module can be easily defined with a simple API, breaking a large protocol in to smaller pieces typically reduces the total complexity of the system.
O複雑さを軽減。各モジュールは容易により小さい部分に大きなプロトコルを壊し、単純なAPIを使用して定義することができる程度に、典型的にはシステムの全体の複雑さを低減します。
o Reduced Verification and Debugging Time. Reduced complexity results in reduced time to debug the modules. It is also usually faster to verify a set of smaller modules than a single larger module.
O検証とデバッグ時間を短縮。モジュールをデバッグする短縮された時間に、複雑結果を減少させました。単一のより大きなモジュールよりも小さいモジュールのセットを確認するためにも通常より高速です。
o Easier Future Upgrades. There is still ongoing research in reliable multicast, and we expect the state of the art to continue to evolve. Building protocols with smaller modules allows them to be more easily upgraded to reflect future research.
Oより簡単将来のアップグレード。そこ信頼性マルチキャストにおける進行中の研究はまだであり、我々は、最新技術が進化し続けることを期待しています。小さなモジュールで構築するプロトコルは、それらをより簡単に今後の研究を反映するようにアップグレードすることができます。
o Common Diagnostics. To the extent that multiple protocols share common packet headers, packet analyzers and other diagnostic tools can be built which work with multiple protocols.
一般的な診断O。複数のプロトコルが複数のプロトコルと連携構築できる共通のパケットヘッダ、パケットアナライザおよびその他の診断ツールを共有する程度に。
o Reduces Effort for New Protocols. As new application requirements drive the need for new standards, some existing modules may be reused in these protocols.
oは新しいプロトコルのための労力を削減します。新しいアプリケーション要件が新たな基準の必要性をドライブとして、いくつかの既存のモジュールは、これらのプロトコルで再利用することができます。
o Parallelism of Development. If the APIs are defined clearly, the development of each module can proceed in parallel.
開発の並列O。 APIが明確に定義されている場合、各モジュールの開発を並行して進めることができます。
Like most software specification, this technique of breaking down a protocol in to smaller components also brings tradeoffs. After a certain point, the disadvantages outweigh the advantages, and it is not worthwhile to further subdivide a problem. These risks include:
ほとんどのソフトウェアの仕様と同様に、小さな部品にしてプロトコルを破壊するこの技術はまた、トレードオフをもたらします。特定のポイントの後、欠点が利点を上回る、問題をさらに細分化する価値はありません。これらのリスクは、次のとおりです。
o Delaying Development. Defining the API for how each two modules inter-operate takes time and effort. As the number of modules increases, the number of APIs can increase at more than a linear rate. The more tightly coupled and complex a component is, the more difficult it is to define a simple API, and the less opportunity there is for reuse. In particular, the problem of how to build and standardize fine grained building blocks for a transport protocol is a difficult one, and in some cases requires fundamental research.
Oの開発を遅らせます。各二つのモジュールが相互運用方法については、APIを定義することは、時間と労力を要します。モジュールの数が増加するように、APIを数は線形速度以上に増加させることができます。成分がより緊密に結合され、複合体は、より困難それは、単純なAPI、および再利用のためにそこにある少ないチャンスを定義することです。具体的には、トランスポートプロトコルのためのきめ細かいビルディングブロックを構築し、標準化する方法の問題は難しいものであり、いくつかのケースでは基礎研究が必要です。
o Increased Complexity. If there are too many modules, the total complexity of the system actually increases, due to the preponderance of interfaces between modules.
oは複雑さを増加しました。あまりにも多くのモジュールがある場合、システムの総複雑性は、実際によるモジュール間のインターフェイスの優勢に、増加します。
o Reduced Performance. Each extra API adds some level of processing overhead. If an API is inserted in to the "common case" of packet processing, this risks degrading total protocol performance.
Oパフォーマンスの低下。各余分なAPIは、処理のオーバーヘッドのいくつかのレベルが追加されます。 APIは、パケット処理の「一般的な場合」に挿入されている場合、これは分解総プロトコル性能をリスク。
o Abandoning Prior Work. The development of robust transport protocols is a long and time intensive process, which is heavily dependent on feedback from real deployments. A great deal of work has been done over the past five years on components of protocols such as RMTP-II, SRM, and PGM. Attempting to dramatically re-engineer these components risks losing the benefit of this prior work.
O前仕事を放棄。堅牢なトランスポートプロトコルの開発は、実際の展開からのフィードバックに大きく依存して長い時間のかかるプロセスです。多くの作業は、このようなRMTP-II、SRM、およびPGMなどのプロトコルのコンポーネントに過去5年間行われてきました。劇的にこれらのコンポーネントを再設計しようとすると、この前の仕事の利益を失うリスク。
Given these tradeoffs, we propose that a building block must meet the following requirements:
これらのトレードオフを考えると、我々は、ビルディングブロックは、次の要件を満たす必要がありますことを提案します：
o Wide Applicability. In order to have confidence that the component can be reused, it should apply across multiple protocol families and allow for the component's evolution.
O広い適用。コンポーネントを再利用できるという自信を持つためには、複数のプロトコルファミリ全体に適用すべきであると、コンポーネントの進化を可能にします。
o Simplicity. In order to have confidence that the specification of the component APIs will not dramatically slow down the standards process, APIs must be simple and straight forward to define. No new fundamental research should be done in defining these APIs.
シンプルO。コンポーネントのAPIの仕様が大幅に標準化プロセスを遅くないだろうという確信を持っているために、APIが定義するためのシンプルでまっすぐ進むなければなりません。新たな基礎研究は、これらのAPIを定義する際に行われるべきではありません。
o Performance. To the extent possible, the building blocks should attempt to avoid breaking up the "fast track", or common case packet processing.
Oパフォーマンス。可能な限り、ビルディングブロックは、「ファストトラック」、または一般的なケースのパケット処理を壊す避けるために試みるべきです。
This section proposes a functional decomposition of RM bulk-data protocols from the perspective of the functional components provided to an application by a transport protocol. It also covers some components that while not necessarily part of the transport protocol, are directly impacted by the specific requirements of a reliable multicast transport. The next section then specifies recommended building blocks that can implement these components.
このセクションでは、トランスポートプロトコルによってアプリケーションに提供される機能構成要素の観点からRMバルクデータプロトコルの機能分解を提案しています。また、トランスポートプロトコルの必ずしも一部が、直接信頼できるマルチキャストトランスポートの特定の要件によって影響を受けるいくつかの構成要素を覆っています。次のセクションでは、これらのコンポーネントを実装することができ、推奨ビルディング・ブロックを指定します。
Although this list tries to cover all the most common transport-related needs of one-to-many bulk-data transfer applications, new application requirements may arise during the process of standardization, hence this list must not be interpreted as a statement of what the transport layer should provide and what it should not. Nevertheless, it must be pointed out that some functional components have been deliberately omitted since they have been deemed irrelevant to the type of application considered (i.e., one-to-many bulk-data transfer). Among these are advanced message ordering (i.e., those which cannot be implemented through a simple sequence number) and atomic delivery.
このリストは1対多のバルク・データ転送アプリケーションのすべての最も一般的なトランスポート関連のニーズをカバーしようとしますが、新しいアプリケーションの要件は、標準化のプロセス中に発生する可能性がある、それ故にこのリストには何の声明として解釈されてはなりませんトランスポート層は提供しなければならないとそれはいけません。それにもかかわらず、それらは（すなわち、1対多数のバルクデータ転送）を考えるアプリケーションの種類とは無関係とみなされているため、いくつかの機能コンポーネントは、意図的に省略されていることを指摘しなければなりません。これらのメッセージの順序を前進さの中（即ち、単純なシーケンス番号を介して実装することができないもの）と原子配達。
It is also worth mentioning that some of the functional components listed below may be required by other functional components and not directly by the application (e.g., membership knowledge is usually required to implement ACK-based reliability).
下記の機能構成要素の一部（例えば、会員の知識は通常ACKベースの信頼性を実現するために必要とされる）アプリケーションによって直接他の機能コンポーネントによって必要とされなくてもよいことにも言及する価値があります。
The following list covers various transport functional components and splits them in sub-components.
以下のリストは、様々な交通機関の機能コンポーネントをカバーし、サブコンポーネントでそれらを分割します。
o Data Reliability (ensuring good throughput) | | - Loss Detection/Notification | - Loss Recovery | - Loss Protection
Oデータの信頼性（優れたスループットを確保）| | - ロス検知/通知| - 損失回復| - 損失保護
o Congestion Control | | - Congestion Feedback | - Rate Regulation | - Receiver Controls
O輻輳制御| | - 輻輳フィードバック| - 料金規制| - レシーバコントロール
o Security
Oのセキュリティ
o Group membership | | - Membership Notification | - Membership Management
Oグループのメンバーシップ| | - 会員の通知| - 会員管理
o Session Management | | - Group Membership Tracking | - Session Advertisement | - Session Start/Stop | - Session Configuration/Monitoring
Oセッション管理| | - グループメンバーシップの追跡| - セッション広告| - セッションの開始/停止| - セッションの設定/監視
o Tree Configuration
Oツリー設定
Note that not all components are required by all protocols, depending upon the fully defined service that is being provided by the protocol. In particular, some minimal service models do not require many of these functions, including loss notification, loss recovery, and group membership.
ていないすべてのコンポーネントがプロトコルによって提供されている、完全に定義されたサービスに応じて、すべてのプロトコルによって必要とされることに留意されたいです。特に、いくつかの最低限のサービスモデルは、損失通知、損失回復、およびグループメンバーシップを含め、これらの機能の多くを必要としません。
Loss Detection/Notification. This includes how missing packets are detected during transmission and how knowledge of these events are propagated to one or more agents which are designated to recover from the transmission error. This task raises major scalability issues and can lead to feedback implosion and poor throughput if not properly handled. Mechanisms based on TRACKs (tree-based positive acknowledgements) or NACKs (negative acknowledgements) are the most widely used to perform this function. Mechanisms based on a combination of TRACKs and NACKs are also possible.
損失検出/通知。これは、送信とどのようにこれらのイベントの知識が伝送エラーから回復するために指定されている1つのまたは複数のエージェントに伝播されている中に検出されているか、欠落パケットを含んでいます。このタスクは、主要なスケーラビリティの問題を提起し、適切に処理されない場合は、フィードバック爆縮と貧しいスループットにつながることができます。トラック（ツリーベースの肯定応答）またはNACK信号（否定応答）に基づくメカニズムが最も広く、この機能を実行するために使用されます。トラックとNACKの組み合わせに基づいたメカニズムも可能です。
Loss Recovery. This function responds to loss notification events through the transmission of additional packets, either in the form of copies of those packets lost or in the form of FEC packets. The manner in which this function is implemented can significantly affect the scalability of a protocol.
損失回復。この機能は失われ、それらのパケットのコピーの形で、またはFECパケットの形式のいずれかで、追加のパケットの送信による損失の通知イベントに応答します。この機能が実装される方法が大幅プロトコルのスケーラビリティに影響を与えることができます。
Loss Protection. This function attempts to mask packet-losses so that they don't become Loss Notification events. This function can be realized through the pro-active transmission of FEC packets. Each FEC packet is created from an entire application data unit [LMSSS97] or a portion of an application data unit [RV97], [BKKKLZ95], a fact that allows a receiver to recover from some packet loss without further retransmissions. The number of losses that can be recovered from without requiring retransmission depends on the amount of FEC packets sent in the first place. Loss protection can also be pushed to the extreme when good throughput is achieved without any Loss Detection/Notification and Loss Recovery functionality, as in the ALC family of protocols defined above.
ロスプロテクション。この機能は、彼らが喪失通知イベントにならないように、パケットロスをマスクしようとします。この関数は、FECパケットのプロアクティブ伝送を通じて実現することができます。各FECパケットは、全体のアプリケーションデータユニット[LMSSS97]またはアプリケーションデータユニット[RV97]、[BKKKLZ95]、受信機は、さらに、再送信することなく、いくつかのパケット損失から回復することを可能にするという事実の部分から作成されています。再送を必要とせずから回収することができる損失の数は、最初の場所に送信されたFECパケットの量に依存します。良いスループットは任意の損失検出/通知と損失回復機能なしに達成されたときに損失保護はまた、上記で定義されたプロトコルのALCの家族のように、極端にプッシュすることができます。
Congestion Feedback. For sender driven congestion control protocols, the receiver must provide some type of feedback on congestion to the sender. This typically involves loss rate and round trip time measurements.
輻輳フィードバック。輻輳制御プロトコルを駆動し、送信者、受信機は、送信者に混雑のフィードバックのいくつかの種類を提供しなければなりません。これは、一般的に損失率、ラウンドトリップ時間測定を必要とします。
Rate Regulation. Given the congestion feedback, the sender then must adjust its rate in a way that is fair to the network. One proposal that defines this notion of fairness and other congestion control requirements is [Whetten99].
料金規制。混雑フィードバックを考えると、送信者は、ネットワークへの公正な方法でそのレートを調整する必要があります。公平性と他の輻輳制御要件のこの概念を定義する一つの提案は、[Whetten99]です。
Receiver Controls. In order to avoid allowing a receiver that has an extremely slow connection to the sender to stop all progress within single rate schemes, a congestion control algorithm will often require receivers to leave groups. For multiple rate approaches, receivers of all connection speeds can have data delivered to them according to the rate of their connection without slowing down other receivers.
受信機を制御します。シングルレートスキーム内のすべての進捗状況を停止するには、送信者に非常に低速な接続を持っている受信機を可能避けるために、輻輳制御アルゴリズムは、多くの場合、グループを残すために受信機が必要になります。複数のレートアプローチのために、すべての接続速度の受信機は、他の受信機を落とすことなく、それらの接続の割合に応じてそれらに配信されたデータを持つことができます。
Security. Security for reliable multicast contains a number of complex and tricky issues that stem in large part from the IP multicast service model. In this service model, hosts do not send traffic to another host, but instead elect to receive traffic from a multicast group. This means that any host may join a group and receive its traffic. Conversely, hosts may also leave a group at any time. Therefore, the protocol must address how it impacts the following security issues:
セキュリティ。信頼性の高いマルチキャストのセキュリティはIPマルチキャストサービスモデルから、大部分の幹複雑かつトリッキーな問題の数が含まれています。このサービスモデルでは、ホストが別のホストにトラフィックを送信、代わりにマルチキャストグループからトラフィックを受信することを選択しません。これは、すべてのホストがグループに参加し、そのトラフィックを受け取ることができることを意味します。逆に、ホストはいつでもグループを残すことができます。そのため、プロトコルがどのような影響を次のセキュリティ問題に対処する必要があります。
o Sender Authentication (since any host can send to a group),
O送信者認証（任意のホストグループに送信することができるので）、
o Data Encryption (since any host can join a group)
Oデータ暗号化（任意のホストがグループに参加できますので）
o Transport Protection (denial of service attacks, through corruption of transport state, or requests for unauthorized resources)
Oトランスポート保護（搬送状態の破損によるサービス拒否攻撃、または不正なリソースに対する要求）
o Group Key Management (since hosts may join and leave a group at any time) [WHA98]
Oグループ鍵管理（ホストはいつでもグループに参加して残すことができるので）[WHA98]
In particular, a transport protocol needs to pay particular attention to how it protects itself from denial of service attacks, through mechanisms such as lightweight authentication of control packets [HW99].
具体的には、トランスポートプロトコルは、このような制御パケット[HW99]の軽量認証などのメカニズムを介して、それがサービス拒否攻撃から自分自身を保護する方法に特に注意を払う必要があります。
With Source Specific Multicast service model (SSM), a host joins specifically to a sender and group pair. Thus, SSM offers more security against hosts receiving traffic from a denial of service attack where an arbitrary sender sends packets that hosts did not specifically request to receive. Nevertheless, it is recommended that additional protections against such attacks should be provided when using SSM, because the protection offered by SSM against such attacks may not be enough.
ソース固有マルチキャストサービスモデル（SSM）を使用すると、ホストは、送信者とグループのペアに特異的に結合します。このように、SSMは、任意の送信者は、具体的受け取るために要求しなかったホストのパケットを送信するサービス拒否攻撃からのトラフィックを受信するホストに対して複数のセキュリティを提供しています。それにもかかわらず、そのような攻撃に対してSSMによって提供される保護が十分ではない可能性があるため、SSMを使用する場合に、このような攻撃に対する追加の保護を提供することをお勧めします。
Sender Authentication, Data Encryption, and Group Key Management. While these functions are not typically part of the transport layer per se, a protocol needs to understand what ramifications it has on data security, and may need to have special interfaces to the security layer in order to accommodate these ramifications.
送信者認証、データ暗号化、およびグループ鍵管理。これらの機能は通常、それ自体がトランスポート層の一部ではありませんが、プロトコルは、データのセキュリティに持っているものな影響を理解する必要があり、これらの波及効果を収容するために、セキュリティ層への特別なインターフェースを持っている必要があります。
Transport Protection. The primary security task for a transport layer is that of protecting the transport layer itself from attack. The most important function for this is typically lightweight authentication of control packets in order to prevent corruption of state and other denial of service attacks.
トランスポート保護。トランスポート層のための主要なセキュリティタスクは、攻撃からトランスポート層自体を保護することです。このための最も重要な機能は、通常の状態とサービス攻撃の他の拒否の腐敗を防止するために、制御パケットの軽量認証です。
Membership Notification. This is the function through which the data source--or upper level agent in a possible hierarchical organization--learns about the identity and/or number of receivers or lower level agents. To be scalable, this typically will not provide total knowledge of the identity of each receiver.
会員通知。または可能な階層組織における上位剤 - - これは、を介してデータソース関数で同一性および/または受信機またはより低いレベルのエージェントの数について学習します。スケーラブルであるために、これは一般的に、各受信機のアイデンティティの総知識を提供することはありません。
Membership Management. This implements the mechanisms for members to join and leave the group, to accept/refuse new members, or to terminate the membership of existing members.
会員管理。メンバーは/新しいメンバーを拒否、または既存のメンバーのメンバーシップを終了するために受け入れるために、グループに参加して残すことのためにこれはメカニズムを実装しています。
Group Membership Tracking. As an optional feature, a protocol may interface with a component which tracks the identity of each receiver in a large group. If so, this feature will typically be implemented out of band, and may be implemented by an upper level protocol. This may be useful for services that require tracking of usage of the system, billing, and usage reports.
グループメンバーシップの追跡。オプションの特徴として、プロトコルは、大きなグループ内の各受信機のアイデンティティを追跡コンポーネントとインターフェースすることができます。もしそうであれば、この機能は、典型的には、帯域外で実施され、上位レベルのプロトコルによって実装されてもよいです。これは、システムの使用状況の追跡を必要とするサービス、課金、および使用状況レポートのために有用である可能性があります。
Session Advertisement. This publishes the session name/contents and the parameters needed for its reception. This function is usually performed by an upper layer protocol (e.g., [HPW99] and [HJ98]).
セッション広告。これは、セッション名/内容及びその受信のために必要なパラメータを公開しています。この関数は、通常、上位層プロトコル（例えば、[HPW99]及び[HJ98]）によって行われます。
Session Start/Stop. These functions determine the start/stop time of sender and/or receivers. In many cases this is implicit or performed by an upper level application or protocol. In some protocols, however, this is a task best performed by the transport layer due to scalability requirements.
セッション開始/停止。これらの機能は、送信者および/または受信機の起動/停止時間を決定します。多くの場合、これは、暗黙的または上位アプリケーションまたはプロトコルによって行われます。いくつかのプロトコルでは、しかし、これは最高のスケーラビリティ要件に起因するトランスポート層によって実行されるタスクです。
Session Configuration/Monitoring. Due to the potentially far reaching scope of a multicast session, it is particularly important for a protocol to include tools for configuring and monitoring the protocol's operation.
セッション構成/監視。起因して潜在的にはるかにマルチキャストセッションの範囲に達し、それはプロトコルの操作を設定し、監視するためのツールが含まれるように、プロトコルのために特に重要です。
Tree Configuration. For protocols which include hierarchical elements (such as PGM and RMTP-II), it is important to configure these elements in a way that has approximate congruence with the multicast routing topology. While tree configuration could be included as part of the session configuration tools, it is clearly better if this configuration can be made automatic.
ツリー設定。 （例えばPGMとRMTP-IIのような）階層的な要素を含むプロトコルの場合、マルチキャストルーティングトポロジとほぼ合同を有するようにこれらの要素を設定することが重要です。ツリー構成は、セッション構成ツールの一部として含めることができるが、この構成は自動することができれば、明らかに優れています。
The families of protocols introduced in section 1.1 generally use different mechanisms to implement the protocol functional components described in section 3. This section tries to group these mechanisms in macro components that define protocol building blocks.
セクション1.1で導入されたプロトコルのファミリーは、一般的にこのセクションでは、プロトコルのビルディングブロックを定義するマクロコンポーネントのグループにこれらのメカニズムを試行部3に記載のプロトコル機能コンポーネントを実装するために異なるメカニズムを使用します。
A building block is defined as "a logical protocol component that results in explicit APIs for use by other building blocks or by the protocol client."
ビルディングブロックは、以下のように定義される「他のビルディングブロックによってまたはプロトコルクライアントで使用するための明示的なAPIをもたらす論理プロトコルコンポーネント。」
Building blocks are generally specified in terms of the set of algorithms and packet formats that implement protocol functional components. A building block may also have API's through which it communicates to applications and/or other building blocks. Most building blocks should also have a management API, through which it communicates to SNMP and/or other management protocols.
ビルディングブロックは、一般的なアルゴリズムおよびプロトコル機能部品を実装するパケットフォーマットのセットに関して指定されています。ビルディングブロックはまた、アプリケーションおよび/または他のビルディングブロックに通信するためのAPIを持っていることがあります。ほとんどのビルディングブロックはまた、SNMPおよび/または他の管理プロトコルに通信するための管理APIを、持っている必要があります。
In the following section we will list a number of building blocks which, at this stage, seem to cover most of the functional components needed to implement the protocol families presented in section 1.1. Nevertheless this list represents the "best current guess", and as such it is not meant to be exhaustive. The actual building block decomposition, i.e., the division of functional components into building blocks, may also have to be revised in the future.
次のセクションでは、この段階では、セクション1.1で提示プロトコルファミリを実装するために必要な機能部品のほとんどをカバーしているように見える、ビルディング・ブロックの数が一覧表示されます。それにもかかわらず、このリストは、「最良の現在の推測」を表し、そのように網羅的であることを意味するものではありません。実際のビルディングブロックの分解、すなわち、ビルディングブロックに機能コンポーネントの分割は、また、将来的に改訂しなければならないかもしれません。
This building block defines NACK-based loss detection/notification and recovery. The major issues it addresses are implosion prevention (suppression) and NACK semantics (i.e., how packets to be retransmitted should be specified, both in the case of selective and FEC loss repair). Suppression mechanisms to be considered are:
このビルディングブロックは、NACKベースの損失検出/通知と回復を定義します。主要な問題、それのアドレスは、爆縮防止（抑制）とNACKセマンティクス（すなわち、再送信するパケットは、両方の選択とFEC損失修復の場合には、指定されなければならないか）です。考慮すべき抑制のメカニズムは以下のとおりです。
o Multicast NACKs o Unicast NACKs and Multicast confirmation
ユニキャストとマルチキャストのNACK確認OマルチキャストのNACK O
These suppression mechanisms primarily need to both minimize delay while also minimizing redundant messages. They may also need to have special weighting to work with Congestion Feedback.
この抑制メカニズムは、主に、冗長メッセージを最小限に抑えながら、遅延を最小限にするために、両方の必要があります。彼らはまた、輻輳のフィードバックで動作するように特別な重みを持っている必要があります。
This building block is concerned with packet level FEC information when FEC codes are used either proactively or as repairs in reaction to lost packets. It specifies the FEC codec selection and the FEC packet naming (indexing) for both reactive FEC repair and pro-active FEC.
FECコードは、いずれかの予防的または失われたパケットに反応して修復として使用される場合、このビルディングブロックは、パケットレベルのFEC情報に関するものです。これは、FECコーデック選択と反応FEC修理およびプロアクティブFECの両方のためのFECパケット命名（インデックス）を指定します。
There will likely be multiple versions of this building block, corresponding to different design policies in addressing congestion control. Two main approaches are considered for the time being: a source-based rate regulation with a single rate provided to all the receivers in the session, and a multiple rate receiver-driven approach with different receivers receiving at different rates in the same session. The multiple rate approach may use multiple layers of multicast traffic [VRC98] or router filtering of a single layer [LVS99]. The multiple rate approach is most applicable for ALC protocols.
おそらく輻輳制御に対処する上で、異なる設計方針に対応し、このビルディングブロックの複数のバージョン、があります。セッション内のすべての受信機に設けられた単一のレートでソースベースのレート調整、及び異なる受信機が同じセッションで異なる速度で受信すると、複数のレート受信機駆動型のアプローチ：二つの主なアプローチがある時間のために考慮されます。複数のレートアプローチは、マルチキャストトラフィック[VRC98]または単層[LVS99]のルータフィルタリングの複数の層を使用することができます。複数のレートアプローチは、ALCプロトコルのための最も適切です。
Both approaches are still in the phase of study, however the first seems to be mature enough [HFW99] to allow the standardization process to begin.
どちらのアプローチが研究の段階にまだある、しかし、最初は標準化プロセスを開始することを可能にするのに十分な[HFW99]成熟したと思われます。
At the time of writing this document, a third class of congestion control algorithm based on router support is beginning to emerge in the IRTF RMRG [LVS99]. This work may lead to the future standardization of one or more additional building blocks for congestion control.
このドキュメントの執筆時点で、ルータのサポートに基づいて輻輳制御アルゴリズムの第三のクラスはIRTF RMRG [LVS99]に出現し始めています。この作品は、輻輳制御のための1つの以上の追加のビルディング・ブロックの将来の標準化につながる可能性があります。
The task of designing RM protocols can be made much easier by the presence of some specific support in routers. In some application-specific cases, the increased benefits afforded by the addition of special router support can justify the resulting additional complexity and expense [FLST98].
RMプロトコルを設計する作業は、ルータでのいくつかの特定のサポートの存在によってはるかに容易に行うことができます。いくつかのアプリケーション固有のケースでは、特殊なルータのサポートの追加によってもたらされる増加の利点は、[FLST98】得られた追加的な複雑さと費用を正当化することができます。
Functional components which can take advantage of router support include feedback aggregation/suppression (both for loss notification and congestion control) and constrained retransmission of repair packets. Another component that can take advantage of router support is intentional packet filtering to provide different rates of delivery of packets to different receivers from the same multicast packet stream. This could be most advantageous when combined with ALC protocols [LVS99].
ルータのサポートを活用することができる機能的な構成要素は、フィードバック集合/抑制（両方損失通知および輻輳制御のための）およびリペアパケットの制約再送を含みます。ルータサポートを利用することができます別の成分は同じマルチキャストパケットストリームからの異なる受信機へのパケットの配信の異なるレートを提供するために、意図的なパケットフィルタリングです。 ALCプロトコル[LVS99]と組み合わせた場合に最も有利である可能性があります。
The process of designing and deploying these mechanisms inside routers can be much slower than the one required for end-host protocol mechanisms. Therefore, it would be highly advantageous to define these mechanisms in a generic way that multiple protocols can use if it is available, but do not necessarily need to depend on.
ルータ内のこれらの機構を設計し、展開するプロセスは、エンドホストプロトコルメカニズムのために必要なものよりはるかに遅くすることができます。したがって、利用可能な場合、複数のプロトコルを使用することができ、一般的な方法でこれらのメカニズムを定義することは非常に有利であろうが、必ずしも依存する必要はありません。
This component has two halves, a signaling protocol and actual router algorithms. The signaling protocol allows the transport protocol to request from the router the functions that it wishes to perform, and the router algorithms actually perform these functions. It is more urgent to define the signaling protocol, since it will likely impact the common case protocol headers.
このコンポーネントは、二つの半体、シグナリングプロトコルおよび実際のルータアルゴリズムを有しています。シグナリングプロトコルは、トランスポートプロトコルは、ルータからそれを実行したい機能を要求することができ、及びルータアルゴリズムは、実際にこれらの機能を実行します。それはおそらく、共通のケースプロトコルヘッダに影響を与えるので、シグナリングプロトコルを定義するために、より緊急です。
An important component of the signaling protocol is some level of commonality between the packet headers of multiple protocols, which allows the router to recognize and interpret the headers.
シグナリングプロトコルの重要な構成要素は、ルータが認識してヘッダを解釈することを可能にする複数のプロトコルのパケットヘッダとの間の共通のいくつかのレベルです。
It has been shown that the scalability of RM protocols can be greatly enhanced by the insertion of some kind of retransmission or feedback aggregation agents between the source and receivers. These agents are then used to form a tree with the source at (or near) the root, the receivers at the leaves of the tree, and the aggregation/local repair nodes in the middle. The internal nodes can either be dedicated software for this task, or they may be receivers that are performing dual duty.
RMプロトコルのスケーラビリティを大幅源と受信機との間の再送信またはフィードバック凝集剤のいくつかの種類を挿入することによって増強することができることが示されています。これらの薬剤は、ソースに（またはその近く）根、ツリーの葉における受信機、及び中央に凝集/ローカル修復ノードとツリーを形成するために使用されます。内部ノードは、いずれか、このタスクのためのソフトウェアを専用にすることができ、または、彼らは二重の義務を実行している受信機のかもしれません。
The effectiveness of these agents to assist in the delivery of data is highly dependent upon how well the logical tree they use to communicate matches the underlying routing topology. The purpose of this building block would be to construct and manage the logical tree connecting the agents. Ideally, this building block would perform these functions in a manner that adapts to changes in session membership, routing topology, and network availability.
データの配信を支援するためにこれらの薬剤の有効性は、それらが通信に使用する論理ツリーは、基本的なルーティングトポロジをどれだけ一致しているかに大きく依存しています。このビルディングブロックの目的は、エージェントを接続する論理ツリーを構築し、管理することです。理想的には、このビルディングブロックは、セッションメンバーシップ、ルーティングトポロジ、およびネットワークの可用性の変化に適応した方法でこれらの機能を実行することになります。
At the time of writing, the security issues are the subject of research within the IRTF Secure Multicast Group (SMuG). Solutions for these requirements will be standardized within the IETF when ready.
執筆時点では、セキュリティ上の問題はIRTFセキュアマルチキャストグループ（きざ）内の研究の対象となっています。これらの要件のためのソリューションは、準備ができたときにIETF内に標準化されます。
As pointed out in the generic router support section, it is important to have some level of commonality across packet headers. It may also be useful to have common data header formats for other reasons. This building block would consist of recommendations on fields in their packet headers that protocols should make common across themselves.
一般的なルータのサポートセクションで指摘したように、パケットヘッダ全体で共通のいくつかのレベルを持っていることが重要です。また、他の理由のために一般的なデータヘッダフォーマットを有することが有用であり得ます。このビルディングブロックは、プロトコル自身に共通するべき彼らのパケットヘッダー内のフィールド上の勧告で構成されます。
The above building blocks consist of the functional components listed in section 3 that appear to meet the requirements for being implemented as building blocks presented in section 2.
上記のビルディングブロックは、セクション2で提示ビルディングブロックとして実装されるための要件を満たすように見えるセクション3に記載されている機能コンポーネントから構成されています。
The other functions from section 3, which are not covered above, should be implemented as part of "protocol cores", specific to each protocol standardized.
上記被覆されていないセクション3、から他の機能は、標準化された各プロトコルに固有の、「プロトコルコア」の一部として実装されるべきです。
RFC 2357 specifically states that "reliable multicast Internet-Drafts reviewed by the Transport Area Directors must explicitly explore the security aspects of the proposed design." Specifically, RMT building block works in progress must examine the denial-of-service attacks that can be made upon building blocks and affected by building blocks upon the Internet at large. This requirement is in addition to any discussions regarding data-security, that is the manipulation of or exposure of session information to unauthorized receivers. Readers are referred to section 5.e of RFC 2357 for further details.
RFC 2357は、具体的には、「信頼性の高い交通エリアディレクターによって見直さマルチキャストインターネットドラフトは、明示的に提案された設計のセキュリティの側面を探求しなければならない。」と述べています具体的には、進行中のRMTビルディングブロック作品はビルディングブロック時に作られた、大規模でインターネット上にブロックを構築することにより影響を受けることができるサービス拒否攻撃を調べる必要があります。この要件は、それがの操作や不正受信機にセッション情報の暴露で、データ・セキュリティに関するいかなる議論に加えています。読者は、さらに詳細については、RFC 2357のセクション5.Eと呼ばれています。
There will be more than one building block, and possibly multiple versions of individual building blocks as their designs are refined. For this reason, the creation of new building blocks and new building block versions will be administered via a building block registry that will be administered by IANA. Initially, this registry will be empty, since the building blocks described in sections 4.1 to 4.3 are presented for example and design purposes. The requested IANA building block registry will be populated from specifications as they are approved for RFC publication (using the "Specification Required" policy as described in RFC 2434 [RFC2434]). A registration will consist of a building block name, a version number, a brief text description, a specification RFC number, and a responsible person, to which IANA will assign the type number.
自分たちのデザインが洗練されているように複数のビルディングブロック、そしておそらく個々のビルディング・ブロックの複数のバージョンがあります。このため、新しいビルディングブロックと新しいビルディングブロックのバージョンの作成は、IANAによって投与されるビルディング・ブロック・レジストリを介して投与されます。セクション4.3から4.1で説明したビルディングブロックは、例えば、設計の目的のために提示されているので、最初は、このレジストリは、空になります。それらはRFC公報（RFC 2434に記載されているように、「仕様が必要」ポリシーを使用して、[RFC2434]）のために承認されているように要求されたIANAビルディングブロックレジストリ仕様から移入されます。登録は、IANAはタイプ番号を割り当て先となるビルディング・ブロック名、バージョン番号、簡単なテキスト記述、仕様のRFC番号、および責任者、で構成されます。
In this document, we briefly described a number of building blocks that may be used for the generation of reliable multicast protocols to be used in the application space of one-to-many reliable bulk-data transfer. The list of building blocks presented was derived from considering the functions that a protocol in this space must perform and how these functions should be grouped. This list is not intended to be all-inclusive but instead to act as guide as to which building blocks are considered during the standardization process within the Reliable Multicast Transport WG.
この文書では、我々は、簡単に信頼できるマルチキャストプロトコルの発生が一対多の信頼性の高いバルクデータ転送のアプリケーション空間で使用するために使用することができるビルディングブロックの数を記載しました。提示ビルディング・ブロックのリストは、この空間でのプロトコルが実行しなければならないとどのようにこれらの機能をグループ化する機能を考慮に由来するものでした。このリストは、ビルディング・ブロックは、信頼性の高いマルチキャスト交通WG内の標準化プロセス中に考慮されたとして、ガイドとして機能する代わりにすべてを含むことを意図するものではなく、されていません。
This document represents an overview of a number of building blocks for one to many bulk data transfer that may be ready for standardization within the RMT working group. The ideas presented are not those of the authors, rather they are a summarization of many years of research into multicast transport combined with the varied presentations and discussions in the IRTF Reliable Multicast Research Group. Although they are too numerous to list here, we thank everyone who has participated in these discussions for their contributions.
この文書では、RMTワーキンググループ内の標準化のための準備ができても、多くのバルク・データ転送に1のためのビルディング・ブロックの数の概要を表しています。提示のアイデアではなく、彼らがIRTF信頼性の高いマルチキャスト研究グループでは様々なプレゼンテーションや議論と合わせマルチキャスト輸送の研究の長年の要約され、著者のそれらではありません。彼らはここに一覧表示するにはあまりにもたくさんありますが、我々は彼らの貢献のためにこれらの議論に参加しているすべての人に感謝します。
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. Zuckerman, "An XOR-based Erasure Resilient Coding Scheme," ICSI Technical Report No. TR-95-048, August 1995.
【BKKKLZ95] J. Bloemer、M. Kalfane、M. Karpinski、R.カープ、M.ルビー、D.ズッカーマン、ICSIテクニカルレポートNo. TR-95から048年8月 "符号化方式弾性XORベースの消去" 1995。
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data," Proc ACM SIGCOMM 98.
【BLMR98] J.バイヤーズ、M.ルビー、M. Mitzenmacher、A.レゲ、 "バルクデータの信頼性の分布にデジタルファウンテンアプローチ、" PROC ACM SIGCOMM 98。
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing," Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.
【FJM95] S.フロイド、V. Jacobsonの、S. McCanne、 "軽量セッションの高信頼マルチキャストフレームワークとアプリケーションレベルフレーミング、" PROC ACM SIGCOMM 95、1995年8月頁342から356。
[FLST98] D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM reliable transport protocol specification," Work in Progress.
【FLST98] D.ファリナッチ、S.リン、T.スピークマン、及びA. Tweedly、 "PGM信頼できるトランスポートプロトコル仕様、" 進行中の作業。
[HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman Specification for TCP Friendly (Reliable) Multicast Congestion Control (TFMCC)," Work in Progress.
【HFW99] M.ハンドレー、S.フロイド、B. Whetten、 "TCP可用Strawman仕様（信頼性）マルチキャスト輻輳制御（TFMCC）、" 進行中の作業。
[HJ98] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[HJ98]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[HPW99] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," Work in Progress, June 1999.
[HPW99] M.ハンドリー、C.パーキンス、E.ウィーラン、 "セッションアナウンスメントプロトコル、" 進歩、1999年6月での作業。
[HW99] T. Hardjorno, B. Whetten, "Security Requirements for RMTP-II," Work in Progress, June 1999.
[HW99] T. Hardjorno、B. Whetten、 "RMTP-IIのセキュリティ要件、" 進歩、1999年6月での作業。
[RFC2887] Handley, M., Whetten, B., Kermode, R., Floyd, S., Vicisano, L. and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887]ハンドリー、M.、Whetten、B.、Kermode、R.、フロイド、S.、Vicisano、L.およびM.ルビー、 "大量データ転送のための信頼できるマルチキャストデザインスペース"、RFC 2887、2000年8月。
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable multicast (TRAM)," Work in Progress.
【KCW98] M. Kadansky、D.チウ、及びJ.ウェスリーは、 "ツリー・ベースの信頼性の高いマルチキャスト（TRAM）、" 進行中の作業。
[Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with Forward Error Correction," Proc ACM SIGCOMM 98, Sept 1998.
[Kermode98] R. Kermodeは、PROC ACM SIGCOMM 98、1998年9月 "前方誤り訂正、とのハイブリッド自動再送要求をスコープ"。
[LDW98] M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error Recovery for Multimedia Streams in Wide-Area Multicast Networks".
[LDW98] M.ルーカス、B.デンプシー、A.ウィーバー、「MESH：広域マルチキャストネットワークにおけるマルチメディアストリームのための分散エラー回復」。
[LESZ97] C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error Recovery in SRM: Comparison of Two Approaches," USC Technical Report 97-648, Jan 1997.
【LESZ97] C-G。劉、D. Estrin、S. Shenkar、L.チャン、 "SRMでのローカルエラー回復：2つのアプローチの比較" USCテクニカルレポート97から648、1997年1月。
[LG97] B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet Multicast Routing with Routing Labels," IEEE International Conference on Network Protocols (ICNP-97), Oct 28-31, 1997, p.241-250.
[LG97] B。N.レヴァイン、J.J. Garcua - ルナ - ACEVES、 "ルーティングラベルとインターネットマルチキャストルーティングの改善、" ネットワークプロトコル（ICNP-97）、10月28-31、1997年、p.241-250にIEEE国際会議。
[LP96] K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424.
【LP96】K.リン及びS.ポール。 "RMTP：信頼できるマルチキャストトランスポートプロトコル、" IEEEインフォコム1996年、1996年3月、頁1414年から1424年。
[LMSSS97] M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V. Stemann, "Practical Loss-Resilient Codes", Proc ACM Symposium on Theory of Computing, 1997.
【LMSSS97] M.ルビー、M. Mitzenmacher、A.ショクロラヒ、D. Spielman、V. Stemann、 "実用的なロス弾性コード"、コンピューティング、1997の理論PROC ACMシンポジウム。
[LVS99] M. Luby, L. Vicisano, T. Speakman. "Heterogeneous multicast congestion control based on router packet filtering", RMT working group, June 1999, Pisa, Italy.
[LVS99] M.ルビー、L. Vicisano、T.スピークマン。 「異機種マルチキャスト輻輳制御ルータのパケットフィルタリングに基づいて」、RMTワーキンググループ、1999年6月、ピサ、イタリア。
[MA99] J. Macker, B. Adamson. "Multicast Dissemination Protocol version 2 (MDPv2)," Work in Progress, http://manimac.itd.nrl.navy.mil/MDP
[MA99] J. Macker、B.アダムソン。 「マルチキャスト普及プロトコルバージョン2（MDPv2）、」進行中の作業、http://manimac.itd.nrl.navy.mil/MDP
[MRBP98] Mankin, A., Romanow, A., Brander, S. and V.Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[MRBP98]マンキン、A.、Romanow、A.、Brander、S.とV.Paxson、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"、RFC 2357、1998年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[OXB99] O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two Reliable Multicast Protocols", Work in Progress, May 1999.
【OXB99】O. Ozkasap、Z.シャオ、K.バーマン。 「二つの信頼できるマルチキャストプロトコルの拡張性」、進歩、1999年5月に作業します。
[PSLB97] "Reliable Multicast Transport Protocol (RMTP)," S. Paul, K. K. Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE Journal on Selected Areas in Communications, Vol. 15, No. 3, April 1997.
【PSLB97 "高信頼マルチキャストトランスポートプロトコル（RMTP）、" S.ポール、K. K. Sabnani、J. C.リン、及びS.バタチャリヤ、IEEEジャーナル・コミュニケーションズ、VOLに選択された領域に。 15、第3号、1997年4月。
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast Data Distribution Protocol Based on Software FEC Techniques," Proc. of The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25, 1997.
[RV97] L.リゾー、L. Vicisano、 "ソフトウェアFEC技術に基づく信頼性の高いマルチキャストデータ配布プロトコル、" PROC。高性能通信システムのアーキテクチャと実装第4回IEEEワークショップ（HPCS'97）、サニビーチ、ハルキディキ、ギリシャ6月23-25、1997年。
[VRC98] L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like Congestion Control for Layered Multicast Data Transfer", Proc. of IEEE Infocom'98, March 1998.
【VRC98】L. Vicisano、L.リゾー、J.クロウクロフト、「階層化マルチキャストデータ転送のためのTCP様輻輳制御」、PROC。 IEEE Infocom'98、1998年3月の。
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N. Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL," Work in Progress.
【WBPM98] B. Whetten、M. Basavaiah、S.ポール、T.モンゴメリー、N. Rastogi、J.コンラン、およびT.葉、 "RMTP-IIプロトコル" 進行中の作業。
[WHA98] D. Wallner, E. Hardler, R. Agee, "Key Management for Multicast: Issues and Architectures," Work in Progress.
[WHA98] D.ウォルナー、E. Hardler、R.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ、" 進行中の作業。
[Whetten99] B. Whetten, "A Proposal for Reliable Multicast Congestion Control Requirements," Work in Progress. http://www.talarian.com/rmtp-ii/overview.htm
【Whetten99] B. Whetten、「高信頼マルチキャスト輻輳制御要件の提案、」進行中の作業。 http://www.talarian.com/rmtp-ii/overview.htm
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
ブライアンWhetten Talarian社、333 DISTELサークル、ロスアルトス、CA 94022、USA
EMail: whetten@talarian.com
メールアドレス：whetten@talarian.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
ロレンツォVicisanoシスコシステムズ、170西タスマン博士サンノゼ、CA 95134、USA
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
ロジャーKermodeモトローラオーストラリアの研究センターレベル3、12主の聖、ボタニーNSW 2019、オーストラリア
EMail: Roger.Kermode@motorola.com
メールアドレス：Roger.Kermode@motorola.com
Mark Handley, Sally Floyd ATT Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
マーク・ハンドリー、ICSIでのインターネット調査のためのサリーフロイドATTセンター、国際コンピュータサイエンス研究所、1947センターストリート、スイート600、バークレー、CA 94704、USA
EMail: mjh@aciri.org, floyd@aciri.org
電子メール：mjh@aciri.org、floyd@aciri.org
Michael Luby 600 Alabama Street San Francisco, CA 94110 Digital Fountain, Inc.
マイケル・ルビー600アラバマストリート、サンフランシスコ、CA 94110デジタル泉株式会社
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。