[要約] RFC 3048は、信頼性のあるマルチキャストトランスポートの構築に関する技術的なガイドラインです。このRFCの目的は、一対多の大量データ転送における信頼性のあるマルチキャストトランスポートの基本要素を提供することです。
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
1対多くのバルクデータ転送のための信頼性の高いマルチキャスト輸送ビルディングブロック
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.
Copyright（c）The Internet Society（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.
これらの要件は、主に、標準が広範囲にわたるインターネットの展開に安全であることを確認することに向けられています。IRTF信頼できるマルチキャスト研究グループ（RMRG）における信頼性の高いマルチキャスト輻輳制御（RMCC）[HFW99]に関する現在の作業の進歩の成熟度は、IETFがRMTワーキンググループをチャーターできるイベントの1つです。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 注文保証。プロトコルは、ソース順序付きまたは順序付けられていない配信保証の少なくとも1つを提供する必要があります。複数の送信者間の総注文のサポートは、プロトコルの拡張がより困難になり、より高いレベルでより簡単に実装できるため、推奨されません。
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 レシーバーのスケーラビリティ。プロトコルは、輸送グループごとに「多数」の同時受信機をサポートできる必要があります。典型的なレシーバーセットは、グループごとに少なくとも1,000〜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]などのプロトコルは、Packetの再送信を要求するために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]が含まれます）は、受信機またはネットワークからのフィードバックなしで、Senderベースのフォワードエラー補正（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 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.
4ルーターアシスト。SRMと同様に、PGM [FLST98]や[LG97]などのプロトコルも、パケットリカバリに否定的な確認を使用します。これらのプロトコルは、新しいルーターソフトウェアを利用して、制約された否定的な承認と再送信を行います。ルーターアシストプロトコルは、エンドツーエンドプロトコルよりも効率的に他の機能を提供することもできます。たとえば、[LVS99]は、ルーターアシストが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.
プロトコルファミリの区別は、必ずしも正確で相互に排他的ではないことに注意してください。実際のプロトコルは、異なるクラスに属するメカニズムの組み合わせを使用する場合があります。たとえば、ハイブリッドNACK/ACKベースのプロトコル（[WBPM98]など）が可能です。他の例は、ルーターのサポートを活用するクラス1から3に属するプロトコルです。
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.
RFC 2357 [MRBP98]で指定されているように、信頼できるマルチキャストプロトコルは、すべてのアプリケーションのニーズを満たす可能性があります。したがって、IETFは、アプリケーションおよびネットワーク固有のニーズに合わせて調整された多くのプロトコルを標準化することを期待しています。このドキュメントは、「1対Many Bulk-Data転送」の要件に集中していますが、将来的には、「多くの人から多くの」など、他のタイプのアプリケーションのニーズに対応する追加のプロトコルとビルディングブロックが期待されています。「アプリケーション。Bulk-Data転送は、データの適時性を指すものではなく、セッションで転送されるデータが大量にあると述べていることに注意してください。これらの追加シナリオのプロトコルの開発のために取られた範囲とアプローチは、このドキュメントで提案された「ビルディングブロック」アプローチの成功に大きく依存します。
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 開発の遅延。2つのモジュールがどのように操作するかについて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 以前の仕事を放棄します。堅牢な輸送プロトコルの開発は、長い時間的なプロセスであり、実際の展開からのフィードバックに大きく依存しています。過去5年間、RMTP-II、SRM、PGMなどのプロトコルのコンポーネントで多くの作業が行われました。これらのコンポーネントを劇的に再設計しようとすると、この以前の作業の利益を失うリスクがあります。
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パケットは、アプリケーションデータユニット[LMSS97]またはアプリケーションデータユニット[RV97]、[BKKLZ95]の一部から作成されます。再送信を必要とせずに回復できる損失の数は、そもそも送信された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].
レート規制。輻輳フィードバックを考えると、送信者はネットワークにとって公平な方法でそのレートを調整する必要があります。この公平性とその他の混雑制御要件のこの概念を定義する提案の1つは[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.
メンバーシップ通知。これは、データソース（可能な階層組織の上位レベルエージェント）が、IDおよび/または下位レベルのエージェントのアイデンティティおよび/または数について学習する機能です。スケーラブルであるために、これは通常、各受信機のアイデンティティに関する完全な知識を提供しません。
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.
グループメンバーシップトラッキング。オプションの機能として、プロトコルは、大規模なグループ内の各受信機のIDを追跡するコンポーネントとインターフェイスできます。その場合、この機能は通常、バンドから実装され、上位レベルのプロトコルによって実装される場合があります。これは、システムの使用、請求、および使用レポートを追跡する必要があるサービスに役立つ場合があります。
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
o マルチキャストnacks 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.
このビルディングブロックには、混雑制御に対処する際のさまざまな設計ポリシーに対応する複数のバージョンがある可能性があります。当面の2つの主要なアプローチが考慮されます。セッションのすべての受信機に単一のレートを提供するソースベースのレートレギュレーションと、同じセッションで異なるレートで受信する異なるレシーバー駆動型アプローチです。複数のレートアプローチでは、マルチキャストトラフィックの複数層[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.
このドキュメントの作成時点で、ルーターのサポートに基づいた3番目のクラスの混雑制御アルゴリズムが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].
ルーターのサポートを利用できる機能コンポーネントには、フィードバックの集約/抑制（損失通知と輻輳制御の両方）と修理パケットの再送信の制約が含まれます。ルーターサポートを利用できるもう1つのコンポーネントは、意図的なパケットフィルタリングであり、同じマルチキャストパケットストリームから異なる受信機にパケットの異なる配信率を提供します。これは、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.
このコンポーネントには、シグナル伝達プロトコルと実際のルーターアルゴリズムの2つの半分があります。シグナリングプロトコルにより、トランスポートプロトコルは実行したい機能をルーターに要求でき、ルーターアルゴリズムは実際にこれらの機能を実行します。共通のケースプロトコルヘッダーに影響を与える可能性が高いため、シグナル伝達プロトコルを定義する方が緊急です。
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 Secure Multicast Group（SMUG）内の研究の対象です。これらの要件のソリューションは、準備ができたら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.
上記のビルディングブロックは、セクション3に記載されている要件を満たしていると思われるセクション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.1〜4.3で説明されているビルディングブロックが、たとえば設計目的で提示されているため、このレジストリは空になります。要求されたIANAビルディングブロックレジストリは、RFC出版物（RFC 2434 [RFC2434]に記載されている「仕様が必要」ポリシーを使用）で承認されているように仕様から入力されます。登録は、ビルディングブロック名、バージョン番号、簡単なテキスト説明、仕様RFC番号、および責任者で構成され、IANAがタイプ番号を割り当てます。
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.
このドキュメントでは、1対多くの信頼できるバルクデータ転送のアプリケーションスペースで使用する信頼できるマルチキャストプロトコルの生成に使用できる多くのビルディングブロックについて簡単に説明しました。提示されたビルディングブロックのリストは、このスペースのプロトコルが実行する必要がある機能と、これらの関数をどのようにグループ化するかを考慮することから導き出されました。このリストは、すべての包括的であることではなく、信頼できるマルチキャストトランスポート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対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。Karp、M。Luby、D。Zuckerman、 "XORベースの消去レジリエントコーディングスキーム、" ICSIテクニカルレポートNo. TR-95-048、8月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. Byers、M。Luby、M。Mitzenmacher、A。Rege、「バルクデータの信頼できる分布へのデジタル噴水アプローチ」、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. Floyd、V。Jacobson、S。McCanne、「軽量セッションとアプリケーションレベルのフレーミングのための信頼できるマルチキャストフレームワーク」、Proc ACM Sigcomm 95、1995年8月pp。342-356。
[FLST98] D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM reliable transport protocol specification," Work in Progress.
[FLST98] D. Farinacci、S。Lin、T。Speakman、および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. Handley、S。Floyd、B。Whetten、「TCPフレンドリー（信頼性の高い）マルチキャスト混雑制御（TFMCC）のストローマン仕様」、進行中の作業。
[HJ98] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[HJ98] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[HPW99] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," Work in Progress, June 1999.
[HPW99] M. Handley、C。Perkins、E。Whelan、「セッションアナウンスプロトコル」、Work in Progress、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] Handley、M.、Whetten、B.、Kermode、R.、Floyd、S.、Vicisano、L。、およびM. Luby、「バルクデータ転送用の信頼できるマルチキャスト設計スペース」、RFC 2887、2000年8月。
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable multicast (TRAM)," Work in Progress.
[KCW98] M. Kadansky、D。Chiu、およびJ. Wesley、「Treeベースの信頼できるマルチキャスト（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。ウィーバー、「メッシュ：広いエリアマルチキャストネットワークのマルチメディアストリームの分散エラー回復」。
[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。Liu、D。Estrin、S。Shenkar、L。Zhang、「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-Luna-Aceves、「ルーティングラベルを備えたインターネットマルチキャストルーティングの改善」、IEEE Network Protocolsに関する国際会議（ICNP-97）、1997年10月28〜31日、p.241-250。
[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 InfoComm 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. Luby、M。Mitzenmacher、A。Shokrollahi、D。Spielman、V。Stemann、「実用的な損失依頼性コード」、Croc ACM Symposium on Computing、1997。
[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. Luby、L。Vicisano、T。Speakman。「ルーターパケットフィルタリングに基づく不均一なマルチキャスト輻輳制御」、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.マッカー、B。アダムソン。「マルチキャスト普及プロトコルバージョン2（MDPV2）」、Work in Progress、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] Mankin、A.、Romanow、A.、Brander、S。and 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。Xiao、K。Birman。「2つの信頼できるマルチキャストプロトコルのスケーラビリティ」、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。サブナニ、J。C。リン、およびS.バタチャリヤ、IEEEジャーナルのCommunications、vol。15、No。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. Rizzo、L。Vicisano、「ソフトウェアFEC技術に基づく信頼できるマルチキャストデータ分布プロトコル」、Proc。1997年6月23〜25日、ギリシャ、チャルキディキ、サニビーチ、高性能通信システム（HPCS'97）のアーキテクチャと実装に関する第4回IEEEワークショップのうち。
[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。Rizzo、J。Crowcroft、「層状マルチキャストデータ転送のための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。Paul、T。Montgomery、N。Rastogi、J。Conlan、およびT. Yeh、「RMTP-IIプロトコル」、進行中の作業。
[WHA98] D. Wallner, E. Hardler, R. Agee, "Key Management for Multicast: Issues and Architectures," Work in Progress.
[WHA98] D. Wallner、E。Hardler、R。Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、進行中の作業。
[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
ブライアン・ウェッテン・タリアン・コーポレーション、333ディステル・サークル、ロス・アルトス、カリフォルニア州94022、米国
EMail: whetten@talarian.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems、170 West Tasman Dr. San Jose、CA 95134、米国
EMail: lorenzo@cisco.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
ロジャーカーモードモトローラオーストラリアリサーチセンターレベル3、12ロードストリート、ボタニーNSW 2019、オーストラリア
EMail: 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
マークハンドリー、サリーフロイドATT ICSIのインターネット研究センター、国際コンピューターサイエンスインスティテュート、1947年センターストリート、スイート600、バークレー、カリフォルニア州94704、米国
EMail: mjh@aciri.org, floyd@aciri.org
Michael Luby 600 Alabama Street San Francisco, CA 94110 Digital Fountain, Inc.
マイケルルビー600アラバマストリートサンフランシスコ、カリフォルニア94110 Digital Fountain、Inc。
EMail: luby@digitalfountain.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。