RFC3048 日本語訳
3048 Reliable Multicast Transport Building Blocks for One-to-ManyBulk-Data Transfer. B. Whetten, L. Vicisano, R. Kermode, M. Handley,S. Floyd, M. Luby. January 2001. (Format: TXT=48965 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Whettenがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3048年のTalarianカテゴリ: 9秒間の噴水2001年1月のフロイドACIRI M.Lubyデジタルの情報のL.のR.カーモードモトローラM.ハンドレーVicisanoコクチマスACIRI
Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer
多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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.
このドキュメントは大量のデータの信頼できるマルチキャスト輸送の標準化のためにフレームワークについて説明します。 それは、数人のクラスの現代の信頼できるマルチキャスト輸送の展開の間に行われた経験を当てにして、多くのブロックへのこれらのクラスのプロトコルの間に共通点を引き抜くのを試みます。 そのために、このドキュメントは、複数のプロトコルのクラスに共通のあるコンポーネントが「ブロック」として標準化されることを勧めます。 プロトコル非常に特有の、そして、しっかりからみ合っている機能から成って、プロトコルの残存部分は「プロトコルコア」として指定されるものとします。 したがって、そして、複数のプロトコルの向こう側に再使用できる多くの「ブロック」に「プロトコルコア」を合併することによって、各プロトコルを構成できます。
Whetten, et al. Informational [Page 1] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [1ページ]情報のRFC3048RMTブロック2001年1月
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
1つの序論… 2 1.1 ファミリーについて議定書の中で述べてください… 5 2ブロック原理… 6 2.1のブロック利点… 6 2.2 ブロックリスク… 7 2.3 ブロック要件… 8 3はコンポーネントについて議定書の中で述べます… 8 3.1 サブコンポーネント定義… 9 4のブロック推薦… 12 4.1 ナックベースの信頼性… 13 4.2 FECコード化… 13 4.3 混雑コントロール… 13 4.4 ジェネリックルータサポート… 14 4.5木の構成… 14 4.6データ機密保護… 15 4.7個の一般的なヘッダー… 15 4.8 コアについて議定書の中で述べてください… 15 5セキュリティ… 15 6 IANA問題… 15 7つの結論… 16 8つの承認… 16 9つの参照箇所… 16 10人の作者のアドレス… 19 11の完全な著作権宣言文… 20
1. Introduction
1. 序論
RFC 2357 lays out the requirements for reliable multicast protocols that are to be considered for standardization by the IETF. They include:
RFC2357は標準化のために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) 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 スケーラビリティ。 プロトコルは複数のネットワークtopologies、リンク速度、および受信機セットサイズを含んでいるさまざまな状態の下で働くことができるべきです。 プロトコルが壊れるどのように、時に関する良い理解を持っているかはそれが働いている時より重要です。
Whetten, et al. Informational [Page 2] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [2ページ]情報のRFC3048RMTブロック2001年1月
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 Reliable Multicast Research Group(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グループあたり少なくとも1,000--1万台の同時の受信機の注文にはあるかもしれないか、または結局、大きいインターネットの何百万台もの受信機まで比例さえできました。
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
o 配送保証。 多くのアプリケーションでは、論理的に定義されたユニットかユニットのデータは複数のクライアントに提供されることです、ストックの例えば、ファイル、1セットのファイル、ソフトウェアパッケージ、株価またはパッケージが引用します、イベント通知、ビデオからスライド、フレームまたは1ブロックの1セット。 アプリケーションデータ単位は、アプリケーションの役に立つデータの論理的に分離できるユニットになるように定義されます。 いくつかの場合、アプリケーションデータ単位が単一のパケットに収まることができるくらい短いかもしれない、(例えば、イベント
Whetten, et al. Informational [Page 3] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [3ページ]情報のRFC3048RMTブロック2001年1月
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.
通知か株価)、アプリケーションデータ単位がそうする他の場合では、パケット(例えば、ソフトウェアパッケージ)より長いいろいろな事はそうです。 プロトコルはアプリケーションデータ単位の良い効率を受信機に供給しなければなりません。 これは、受信機に提供されるほとんどのデータが彼らが受けようとしているアプリケーションデータ単位を回復する際に役に立つことを意味します。 受信機が、データがいつ提供されたかを送付者に知らせるように、プロトコルは任意に配送確認、すなわち、メカニズムを提供するかもしれません。 データ単位が平らにするアプリケーションにおいてパケット・レベルにおいて確認の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 Topologiesをネットワークでつないでください。 完全なインターネットで配布されると、プロトコルはネットワークを破ってはいけません。 しかしながら、私たちは、また、イントラネットも展開の最初の波が起こるところであるのでサポートするために非常に重要であると認めます。 したがって、衛星ネットワーク(地球のリターンパスにもかかわらず、リターンパスがないそれらを全く含んでいる)のサポートは、奨励されますが、必要ではありません。
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 会員資格を分類してください。 グループ会員資格アルゴリズムはスケーラブルであるに違いありません。 会員資格は、匿名(送付者が受信機のリストを知らないところ)、または完全に分配できます(送付者が受信機の数のカウントを受けて、任意に、aが失敗について記載するところ)。
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
このドキュメントの残りでは、次の用語は特定の含蓄と共に使用されるでしょう: 「プロトコルコンポーネント」、「ブロック」という「プロトコルファミリー」は、「コアについて議定書の中で述べ」て、「具体化について議定書の中で述べます」。 「プロトコルファミリー」は共通する特徴を共有する広いクラスのRMプロトコルです。 私たちの分類では、この特性は信頼性を獲得するのに使用されるメカニズムです。 「プロトコルコンポーネント」は特定の機能性を扱うプロトコルの論理的な部分です。 「ブロック」は、コンポーネントの1つを実装するプロトコルの構成要素、1以上または一部です。 「プロトコルコア」は必要である機能性のセットです。
Whetten, et al. Informational [Page 4] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [4ページ]情報のRFC3048RMTブロック2001年1月
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.
aの具体化はプロトコルを完成して、それはどんなブロックによっても指定されません。 最終的に「プロトコル具体化」は、ブロックの用語で定義された実際のRMプロトコルとプロトコルコアです。
1.1. Protocol Families
1.1. プロトコルファミリー
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 ナック専用。 SRM[FJM95]やMDP2[MA99]などのプロトコルは、パケット「再-トランスミッション」を要求するのにNACKsを使用するだけでトラフィックを制限するのを試みます。 彼らはネットワークインフラを必要としません。
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])は、肯定応答(ACKs)を使用します。 ACKのベースのプロトコルは配送確認を提供する補っているプロトコルの必要性を減少させます、このためにACKSを使用できるとき。 拡大している展開における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]を含んでいる)は、良い効率を確実にするのに受信機かネットワークからフィードバックなしで送付者ベースのForward Error Correction(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のように、PGM[FLST98]や[LG97]などのプロトコルはパケット回復に否定応答を使用します。 これらのプロトコルは、強制的な否定応答と「再-トランスミッション」をするのに新しいルータソフトウェアを利用します。 また、ルータアシストプロトコルは、プロトコルを終わらせるために終わりより効率的に他の機能性を提供できます。 例えば、[LVS99]は目立ちます。
Whetten, et al. Informational [Page 5] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [5ページ]情報のRFC3048RMTブロック2001年1月
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.
区別が必ず正確で互いに排他的でないところで中でファミリーについて議定書の中で述べることに注意してください。 実際のプロトコルは階級が違うメカニズムの組み合わせを使用するかもしれません。 例えば、ハイブリッドナック/ACKに基づいているプロトコル([WBPM98]などの)は可能です。 他の例はルータサポートを利用するクラス1〜3に属すプロトコルです。
2. Building Blocks Rationale
2. ブロック原理
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.
RFC2357[MRBP98]で指定されるように、どんなただ一つの信頼できるマルチキャストプロトコルもおそらくすべてのアプリケーションの需要を満たさないでしょう。 したがって、IETFはアプリケーションに適合する多くのプロトコルを標準化して、特定の必要性をネットワークでつなぐと予想します。 このドキュメントは「多くへの1回のバルク・データ転送」のための要件に集中しますが、将来他のタイプのアプリケーションの必要性を扱う追加議定書とビルブロックが予想されます、含んでいる、「多く、-、-、多く、」 アプリケーション。 バルク・データ転送がデータのタイムリーさであるのについて言及しないというメモ、むしろそれはセッションのときに移すために多量のデータがあると述べます。 これらの追加シナリオのためにプロトコルの開発に取られた範囲とアプローチは本書では進められた「ブロック」アプローチの成功のかなりの部分によるでしょう。
2.1. Building Blocks Advantages
2.1. ブロック利点
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 減少している検証とデバッグ時間。 減少している複雑さはモジュールをデバッグする減少している時間で結果として生じます。 また、通常、1セットのただ一つの、より大きいモジュールより小さいモジュールを確かめるのもさらに速いです。
Whetten, et al. Informational [Page 6] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [6ページ]情報のRFC3048RMTブロック2001年1月
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が明確に定義されるなら、それぞれのモジュールの開発は平行で続くことができます。
2.2. Building Block Risks
2.2. ブロックリスク
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 先の仕事を捨てます。 強健なトランスポート・プロトコルの開発は長い、そして、時間の徹底的なプロセスです。(そのプロセスは本当の展開によってずっしりとフィードバックに依存しています)。 RMTP-IIや、SRMや、PGMなどのプロトコルの成分の過去5年間大きな仕事をしています。 これらのコンポーネントを劇的に再設計するのを試みるのがこの先の仕事の恩恵を失う危険を冒します。
Whetten, et al. Informational [Page 7] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [7ページ]情報のRFC3048RMTブロック2001年1月
2.3. Building Block Requirements
2.3. ブロック要件
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 パフォーマンス。 可能な範囲内で、ブロックは、「ファストトラック」、またはよくある例パケット処理を終えるのを避けるのを試みるべきです。
3. Protocol Components
3. プロトコルコンポーネント
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.
以下のリストは、様々な輸送機能部品をカバーしていて、サブコンポーネントでそれらを分けます。
Whetten, et al. Informational [Page 8] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [8ページ]情報のRFC3048RMTブロック2001年1月
o Data Reliability (ensuring good throughput) |
| - Loss Detection/Notification
| - Loss Recovery
| - Loss Protection
o データReliability(良い効率を確実にします)| | - 損失検出/通知| - 損失回復| - 損失保護
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.
すべてのコンポーネントがすべてのプロトコルによって必要とされるというわけではないことに注意してください、プロトコルによって提供されている完全に定義されたサービスによって。 特に、何人かの最小量のサービスモデルはこれらの機能の多くを必要としません、損失通知、損失回復、およびグループ会員資格を含んでいて。
3.1. Sub-Components Definition
3.1. サブコンポーネント定義
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人以上のエージェントに伝播されるかを含んでいます(伝送エラーから回復するために指定されます)。 適切に扱われないなら、このタスクは、主要なスケーラビリティ問題を提起して、フィードバック内部破裂と不十分なスループットにつながることができます。 TRACKs(木のベースの積極的な承認)かNACKs(否定的承認)に基づくメカニズムは、この機能を実行するのに最も広く使用されます。 また、TRACKsとNACKsの組み合わせに基づくメカニズムも可能です。
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パケットの形のそれらのパケットのコピーの形で。 この機能が実装される方法はプロトコルのスケーラビリティにかなり影響できます。
Whetten, et al. Informational [Page 9] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [9ページ]情報のRFC3048RMTブロック2001年1月
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.
損失保護。 この機能が、パケット損失にマスクをかけるのを試みるので、それらはLoss Notificationイベントになりません。 FECパケットの先を見越すトランスミッションでこの機能を実現できます。 それぞれのFECパケットは全体のアプリケーションデータ単位[LMSSS97]かアプリケーションデータ単位の一部[RV97]から作成されます、[BKKKLZ95]、受信機がいくらかのパケット損失から一層の「再-トランスミッション」なしで回収される事実。 「再-トランスミッション」を必要としながら外から回復できる損害件数は第一に送られたFECパケットの量に依存します。 また、良い効率が少しもLoss Detection/通知とLoss Recoveryの機能性なしで達成されるとき、損失保護を極端に押すことができます、上で定義されたプロトコルの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 送付者Authentication(どんなホストもグループに発信できるので)
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 輸送保護(輸送状態の不正、または権限のないリソースに関する要求によるサービス不能攻撃)
Whetten, et al. Informational [Page 10] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [10ページ]情報のRFC3048RMTブロック2001年1月
o Group Key Management (since hosts may join and leave a group at
any time) [WHA98]
o グループKey Management(ホストがいつでもグループに加わって、出るかもしれないので)[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.
Source Specific Multicastサービスモデル(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.
送付者認証、データ暗号化、およびグループKey Management。 これらの機能は通常そういうもののトランスポート層の一部ではありませんが、プロトコルは、それがデータ機密保護にどんな分岐を持っているかを理解するのが必要であり、これらの分岐に対応するためにセキュリティ層に特別なインタフェースを必要とするかもしれません。
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.
会員資格追跡を分類してください。 オプション機能として、プロトコルは大きいグループにおける、それぞれの受信機のアイデンティティを追跡するコンポーネントに連結するかもしれません。 そうだとすれば、この特徴は、バンドから通常実装されて、上側の平らなプロトコルによって実装されるかもしれません。 これはシステム、支払い、および用法レポートの用法を追跡するのを必要とするサービスの役に立つかもしれません。
Whetten, et al. Informational [Page 11] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [11ページ]情報のRFC3048RMTブロック2001年1月
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などの)を含んでいるプロトコルに、マルチキャストルーティングトポロジーがある大体の適合を持っている方法でこれらの要素を構成するのは重要です。 セッション構成ツールの一部として木の構成を含むことができましたが、この構成を自動にすることができるなら、明確に良いです。
4. Building Block Recommendations
4. ブロック推薦
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のところを持っているかもしれません。 また、ほとんどのブロックには、管理APIがあるべきです。そこでは、それがSNMP、そして/または、他の管理プロトコルに交信します。
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に示されたファミリーであると実装するのが必要である機能部品の大部分をカバーするように思える多くのブロックを記載するつもりです。 それにもかかわらず、このリストは「最も良い現在の推測」を表します、そして、そういうものとして、徹底的であることは意味されません。 また、実際のブロック分解(すなわち、ブロックへの機能部品の分割)は将来、改訂されなければならないかもしれません。
Whetten, et al. Informational [Page 12] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [12ページ]情報のRFC3048RMTブロック2001年1月
4.1. NACK-based Reliability
4.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:
このブロックはナックベースの損失検出/通知と回復を定義します。 それが扱う大変な問題は、内部破裂防止(抑圧)とナック意味論(すなわち、再送されるべきパケットは選択するのとFEC損失修理の場合で両方の、どう指定されるべきである)です。 考えられる抑圧メカニズムは以下の通りです。
o Multicast NACKs o Unicast NACKs and Multicast confirmation
o マルチキャストNACKs o Unicast NACKsとMulticast確認
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.
これらの抑圧メカニズムは、主としてまた、余分なメッセージを最小にしている間、ともに遅れを最小にする必要があります。 また、彼らはCongestion Feedbackと共に扱う特別な重さを必要とするかもしれません。
4.2. FEC coding
4.2. FECコード化
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パケットを指定します。
4.3. Congestion Control
4.3. 輻輳制御
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.
両方のアプローチがまだ研究のフェーズにあって、しかしながら、1番目は標準化過程を始まらせるのを許容するほど熟すように[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つ以上の追加ブロックの今後の標準化につながるかもしれません。
Whetten, et al. Informational [Page 13] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [13ページ]情報のRFC3048RMTブロック2001年1月
4.4. Generic Router Support
4.4. ジェネリックルータサポート
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.
このコンポーネントには、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.
シグナリングプロトコルの重要な成分は複数のプロトコルのパケットのヘッダーの間の何らかのレベルの共通点です。(その共通点は、ヘッダーを見分けて、解釈するためにルータを許容します)。
4.5. Tree Configuration
4.5. 木の構成
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
データの配送を助けるこれらのエージェントの有効性はそれらが交信するのに使用する論理的な木が基本的なルーティングトポロジーにどれくらいよく合っているかに非常に依存しています。 目的
Whetten, et al. Informational [Page 14] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [14ページ]情報のRFC3048RMTブロック2001年1月
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.
このブロックは、エージェントに接する論理的な木を、組み立てて、管理することになっているでしょう。 理想的に、このブロックはセッション会員資格、ルーティングトポロジー、およびネットワークの有用性における変化に順応する方法でこれらの機能を実行するでしょう。
4.6. Data Security
4.6. データ機密保護
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の中で標準化されるでしょう。
4.7. Common Headers
4.7. 一般的なヘッダー
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.
ジェネリックルータサポート部で指摘されるように、パケットのヘッダーの向こう側に何らかのレベルの共通点を持っているのは重要です。 また、他の理由で一般的なデータヘッダー形式を持っているのも役に立つかもしれません。 このブロックはプロトコルが自分たちの向こう側に一般的にするべきである彼らのパケットのヘッダーのフィールドにおける推薦から成るでしょう。
4.8. Protocol Cores
4.8. プロトコルコア
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からの他の機能は「プロトコルコア」の一部として実装されるべきです、標準化された各プロトコルに、特定です。
5. Security Considerations
5. セキュリティ問題
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.
「Transport Areaディレクターによって見直された信頼できるマルチキャストインターネット草稿は明らかに提案されたデザインのセキュリティ局面を探検しなければなりません。」と、RFC2357は明確に述べます。 明確に、RMTブロック執筆中の作品は全体のインターネットでブロックで作られていて、ブロックで影響を受けることができるサービス不能攻撃を調べなければなりません。 この要件がすなわち、データ機密保護、操作に関してどんな議論に加えている、または、権限のない受信機へのセッション情報の暴露。 読者は、さらに詳しい明細についてはRFC2357の5.eを区分するのに参照されます。
6. IANA Considerations
6. IANA問題
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
1つ以上のブロックがあるでしょう、そして、それらのデザインとしての個々のブロックのことによると複数のバージョンが洗練されています。 この理由で、新しい建物ブロックと新しい建物ブロックバージョンの作成はブロック登録を通して管理されるでしょう。
Whetten, et al. Informational [Page 15] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [15ページ]情報のRFC3048RMTブロック2001年1月
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で説明されたブロックが例えば、提示されて、目的を設計するので。 それらがRFC公表のために承認されるとき(RFC2434[RFC2434]で説明されるように「仕様が必要である」という方針を使用して)、要求されたIANAブロック登録に仕様から居住されるでしょう。 登録はブロック名、バージョン番号、簡潔なテキスト記述、仕様RFC番号、および責任者から成るでしょう。(IANAはその責任者に形式数を割り当てるでしょう)。
7. Conclusions
7. 結論
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回の信頼できるバルク・データ転送のアプリケーションスペースで使用されるために簡潔に信頼できるマルチキャストプロトコルの世代に使用されるかもしれないブロックの数について説明しました。 このスペースのプロトコルが実行しなければならない機能とこれらの機能がどう分類されるべきであるかを考えるのから提示されたブロックのリストを得ました。 このリストは、すべてを含みますが、代わりにReliable Multicast Transport WGの中でどのブロックが標準化の間考えられるかに関するガイドとしての行為に処理することを意図しません。
8. Acknowledgements
8. 承認
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.
このドキュメントは1のために多くの標準化のRMTワーキンググループの中で準備ができるかもしれないバルク・データ転送に多くのブロックの概要を表します。 提示された考えが作者のものでない、むしろ彼らはIRTF Reliable Multicast Research Groupでの様々なプレゼンテーションと議論に結合されたマルチキャスト輸送の何年も研究の総括です。 それらはここに記載できないくらい非常に多いのですが、私たちは彼らの貢献のためにこれらの議論に参加した皆に感謝します。
9. References
9. 参照
[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.Luby、D.ザッカーマン、「XORベースの消去弾力があるコード構成」、ICSI技術報告書No. 1995年8月のTR-95-048。
[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.Luby、M.Mitzenmacher、A.リージ、「大量のデータの信頼できる分配へのデジタル噴水アプローチ」、Proc ACM SIGCOMM98。
[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.ジェーコブソン、S.McCanne、「軽量のセッションとアプリケーションレベル縁どりのための信頼できるマルチキャストフレームワーク」、Proc ACM SIGCOMM95、1995年8月ページ 342-356.
Whetten, et al. Informational [Page 16] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [16ページ]情報のRFC3048RMTブロック2001年1月
[FLST98] D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM
reliable transport protocol specification," Work in
Progress.
[FLST98]D.ファリナッチとS.リン、T.SpeakmanとA.Tweedly、「PGMの信頼できる輸送プロトコル仕様」、ProgressのWork。
[HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman Specification
for TCP Friendly (Reliable) Multicast Congestion Control
(TFMCC)," Work in Progress.
[HFW99] M.ハンドレー、S.フロイド、「TCPの好意的な(信頼できる)マルチキャスト輻輳制御(TFMCC)のためのわら人形仕様」というB.Whettenは進行中で働いています。
[HJ98] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[HJ98] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.
B.Whetten、「RMTP-IIのためのセキュリティ要件」という[HW99]T.Hardjornoは進歩、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.とカーモードとR.とフロイドとS.とVicisanoとL.とM.Luby、「バルク・データ転送のための信頼できるマルチキャストデザインスペース」、RFC2887、2000年8月。
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable
multicast (TRAM)," Work in Progress.
[KCW98] M.Kadansky、D.チウ、およびJ.ウエスリー、「木のベースの信頼できるマルチキャスト(TRAM)」、ProgressのWork。
[Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with
Forward Error Correction," Proc ACM SIGCOMM 98, Sept
1998.
[Kermode98]R.カーモード、「前進型誤信号訂正との見られたハイブリッド自動反復要求」、Proc ACM SIGCOMM98、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。 リュウ、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、「ルート設定ラベルでインターネットマルチキャストルート設定を改良します」、Networkプロトコルに関するIEEEの国際コンファレンス(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:」 「Reliable Multicast Transportプロトコル」、IEEE INFOCOMM1996、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対Stemann、「実用的な損失弾力があるコード」、コンピューティング、1997年の理論に関するProc ACMシンポジウム
Whetten, et al. Informational [Page 17] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [17ページ]情報のRFC3048RMTブロック2001年1月
[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.Macker、B.アダムソン。 「マルチキャストDisseminationプロトコルバージョン2(MDPv2)」、Progress、 http://manimac.itd.nrl.navy.mil/MDP のWork
[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.、ブランダー、S.、および「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(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問題部に書くためのガイドライン」BCP26、RFC2434(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.バーマン。 「2つの信頼できるマルチキャストプロトコルのスケーラビリティ」(処理中の作業)は1999がそうするかもしれません。
[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] コミュニケーション、Vol.15、No.3(1997年4月)における選択された領域に関する「信頼できるマルチキャストトランスポート・プロトコル(RMTP)」とS.ポールとK.K.Sabnani、J.C.リンとS.Bhattacharyya、IEEEジャーナル。
[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。高性能通信系(HPCS97年)のアーキテクチャと実装に関する第4IEEEワークショップでは、Saniが浜に乗り上げます、Chalkidiki、ギリシア1997年6月23日〜25日。
[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 Infocom98年では、1998を行進させてください。
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N.
Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL,"
Work in Progress.
M.Basavaiah、S.ポール、T.モンゴメリ、N.ラストーギ、J.コンラン、およびT.イップ、「RMTP-IIプロトコル」という[WBPM98]B.Whettenは進行中で働いています。
[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 で働いています。
Whetten, et al. Informational [Page 18] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [18ページ]情報のRFC3048RMTブロック2001年1月
10. Authors' Addresses
10. 作者のアドレス
Brian Whetten Talarian Corporation, 333 Distel Circle, Los Altos, CA 94022, USA
ブライアンWhetten Talarian社、333ディステル会、ロスアルトス、カリフォルニア 94022、米国
EMail: whetten@talarian.com
メール: whetten@talarian.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
サンノゼ、170の西タスマン博士カリフォルニア 95134、ロレンツォVicisanoシスコシステムズ(米国)
EMail: lorenzo@cisco.com
メール: lorenzo@cisco.com
Roger Kermode Motorola Australian Research Centre Level 3, 12 Lord St, Botany NSW 2019, Australia
ロジャー・カーモード・モトローラオーストラリアの研究センターレベル3、12 主の通り、NSW2019、Botanyオーストラリア
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、バークレー、カリフォルニア 94704、米国を中心に置きます。
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.
マイケルLuby600アラバマ通りサンフランシスコ、カリフォルニア94110のデジタル噴水Inc.
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
Whetten, et al. Informational [Page 19] RFC 3048 RMT Building Blocks January 2001
Whetten、他 [19ページ]情報のRFC3048RMTブロック2001年1月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Whetten, et al. Informational [Page 20]
Whetten、他 情報[20ページ]
一覧
スポンサーリンク
