Network Working Group A. Romanow
Request for Comments: 4297 Cisco
Category: Informational J. Mogul
HP
T. Talpey
NetApp
S. Bailey
Sandburst
December 2005
Remote Direct Memory Access (RDMA) over IP Problem Statement
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.
オーバーヘッドにより高速でエンド・システム・ネットワークI / O処理経路におけるユーザデータの移動に重要であり、相互接続ネットワークのインターネットプロトコルの使用を制限しており、インターネット自体 - 特にここで、高帯域幅、低レイテンシ、および/または低オーバーヘッドホストされたアプリケーションが必要とされています。
This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA).
この文書では、このオーバーヘッドを調べ、リモートダイレクトメモリアクセス（RDMA）を有効にすることによって、その除去のための建築、IPベースの「コピー回避」ソリューションに対応しています。
Table of Contents
目次
1. Introduction ....................................................2
2. The High Cost of Data Movement Operations in Network I/O ........4
2.1. Copy avoidance improves processing overhead. ...............5
3. Memory bandwidth is the root cause of the problem. ..............6
4. High copy overhead is problematic for many key Internet
applications. ...................................................8
5. Copy Avoidance Techniques ......................................10
5.1. A Conceptual Framework: DDP and RDMA ......................11
6. Conclusions ....................................................12
7. Security Considerations ........................................12
8. Terminology ....................................................14
9. Acknowledgements ...............................................14
10. Informative References ........................................15
This document considers the problem of high host processing overhead associated with the movement of user data to and from the network interface under high speed conditions. This problem is often referred to as the "I/O bottleneck" [CT90]. More specifically, the source of high overhead that is of interest here is data movement operations, i.e., copying. The throughput of a system may therefore be limited by the overhead of this copying. This issue is not to be confused with TCP offload, which is not addressed here. High speed refers to conditions where the network link speed is high, relative to the bandwidths of the host CPU and memory. With today's computer systems, one Gigabit per second (Gbits/s) and over is considered high speed.
この文書は、高速条件下でのネットワーク・インターフェースへとからのユーザデータの移動に関連する高いホスト処理オーバーヘッドの問題を考慮する。この問題は、多くの場合、「I / Oボトルネック」[CT90]と呼ばれています。より具体的には、ここで関心のある高いオーバーヘッドのソースは、データ移動操作、即ち、複写です。システムのスループットは、したがって、このコピーのオーバーヘッドによって制限され得ます。この問題は、ここで扱われていないTCPオフロードと混同してはなりません。高速ネットワークリンク速度は、ホストCPUとメモリの帯域幅に対して、ハイである状態を指します。今日のコンピュータ・システム、毎秒1台のギガビット（ギガビット/秒）とし、上に高速と考えられています。
High costs associated with copying are an issue primarily for large scale systems. Although smaller systems such as rack-mounted PCs and small workstations would benefit from a reduction in copying overhead, the benefit to smaller machines will be primarily in the next few years as they scale the amount of bandwidth they handle. Today, it is large system machines with high bandwidth feeds, usually multiprocessors and clusters, that are adversely affected by copying overhead. Examples of such machines include all varieties of servers: database servers, storage servers, application servers for transaction processing, for e-commerce, and web serving, content distribution, video distribution, backups, data mining and decision support, and scientific computing.
コピーに関連した高いコストは、主に大規模システムのための問題です。こうしたラックマウント型PCや小型ワークステーションなど小規模なシステムは、コピーのオーバーヘッドの削減から利益を得るであろうが、彼らは、彼らが扱う帯域幅の量を尺度として、小さいマシンへのメリットは、今後数年間で主になります。今日、それは悪のオーバーヘッドをコピーすることによって影響される高帯域幅フィード、通常、マルチプロセッサおよびクラスタを持つ大規模なシステム・マシンです。データベースサーバ、ストレージサーバ、アプリケーションサーバトランザクション処理のために、電子商取引のための、およびウェブ配信、コンテンツ配信、映像配信、バックアップ、データマイニングや意思決定支援、および科学計算：このようなマシンの例としては、すべてのサーバーの種類が含まれます。
Note that such servers almost exclusively service many concurrent sessions (transport connections), which, in aggregate, are responsible for > 1 Gbits/s of communication. Nonetheless, the cost of copying overhead for a particular load is the same whether from few or many sessions.
そのようなサーバがほぼ独占的に集約して、通信の> 1Gビット/秒を担当している、多くの同時セッション（トランスポート接続）、サービスということに注意してください。それにもかかわらず、特定の負荷のためのオーバーヘッドをコピーするコストは、数または多数のセッションからも同じです。
The I/O bottleneck, and the role of data movement operations, have been widely studied in research and industry over the last approximately 14 years, and we draw freely on these results. Historically, the I/O bottleneck has received attention whenever new networking technology has substantially increased line rates: 100 Megabit per second (Mbits/s) Fast Ethernet and Fibre Distributed Data Interface [FDDI], 155 Mbits/s Asynchronous Transfer Mode [ATM], 1 Gbits/s Ethernet. In earlier speed transitions, the availability of memory bandwidth allowed the I/O bottleneck issue to be deferred. Now however, this is no longer the case. While the I/O problem is significant at 1 Gbits/s, it is the introduction of 10 Gbits/s Ethernet which is motivating an upsurge of activity in industry and research [IB, VI, CGY01, Ma02, MAF+02].
I / Oのボトルネック、およびデータ移動操作の役割は、広く最後の約14年間の研究と産業界で研究されている、と我々はこれらの結果に自由に描きます。毎秒100メガビット（メガビット/秒）の高速イーサネットとファイバデータインターフェイス[FDDI]を分散、155Mビット/秒非同期転送モード[ATM]：新しいネットワーキング技術は、実質的にラインレートを増加しているときは常に歴史的に、I / Oのボトルネックが注目されています、1ギガビット/秒イーサネット。以前の速度トランジションでは、メモリ帯域幅の利用可能性は、I / Oボトルネックの問題を延期することを可能にしました。さてしかし、これはもはやケースです。 I / Oの問題は、1ギガビット/秒で有意であるが、産業および研究の活動の盛り上がり[IB、VI、CGY01、MA02、MAF + 02]動機付けされる10ギガビット/秒イーサネット（登録商標）の導入です。
Because of high overhead of end-host processing in current implementations, the TCP/IP protocol stack is not used for high speed transfer. Instead, special purpose network fabrics, using a technology generally known as Remote Direct Memory Access (RDMA), have been developed and are widely used. RDMA is a set of mechanisms that allow the network adapter, under control of the application, to steer data directly into and out of application buffers. Examples of such interconnection fabrics include Fibre Channel [FIBRE] for block storage transfer, Virtual Interface Architecture [VI] for database clusters, and Infiniband [IB], Compaq Servernet [SRVNET], and Quadrics [QUAD] for System Area Networks. These link level technologies limit application scaling in both distance and size, meaning that the number of nodes cannot be arbitrarily large.
なぜなら、現在の実装ではエンドホスト処理の高いオーバーヘッド、TCP / IPプロトコルスタックは、高速転送のために使用されていません。代わりに、一般的にリモートダイレクトメモリアクセス（RDMA）として知られている技術を使用して特別な目的のネットワークファブリックは、開発されており、広く使用されています。 RDMAは、直接に、アプリケーション・バッファからデータを操縦するために、アプリケーションの制御下で、ネットワークアダプタを可能にする機構の集合です。このような相互接続ファブリックの例としては、ブロックストレージ転送のためのFibre Channel [ファイバー]、データベースクラスタの仮想インターフェイスアーキテクチャ[VI]、およびインフィニバンド[IB]、コンパックのServerNet [SRVNET]、およびシステム・エリア・ネットワーク用のQuadrics [QUAD]が含まれます。これらのリンク・レベルの技術は、ノードの数は任意に大きくすることができないことを意味し、距離及びサイズの両方のアプリケーションのスケーリングを制限します。
This problem statement substantiates the claim that in network I/O processing, high overhead results from data movement operations, specifically copying; and that copy avoidance significantly decreases this processing overhead. It describes when and why the high processing overheads occur, explains why the overhead is problematic, and points out which applications are most affected.
この問題文は、具体的にコピーデータ移動操作からネットワークI / O処理では、高いオーバーヘッドの結果、という主張を実証します。そのコピー回避が大幅にこの処理のオーバーヘッドを減少させます。それは、いつ、なぜ高い処理オーバーヘッドが発生し記述するオーバーヘッドが問題になる理由を説明し、アプリケーションが最も影響を受けていると指摘します。
The document goes on to discuss why the problem is relevant to the Internet and to Internet-based applications. Applications that store, manage, and distribute the information of the Internet are well suited to applying the copy avoidance solution. They will benefit by avoiding high processing overheads, which removes limits to the available scaling of tiered end-systems. Copy avoidance also eliminates latency for these systems, which can further benefit effective distributed processing.
文書は、問題は、インターネットへのインターネットベースのアプリケーションに関連する理由を議論することになります。インターネットの情報を保存、管理、および配布するアプリケーションは、コピー回避溶液を塗布に適しています。これらは、階層エンドシステムの利用可能なスケーリングの限界を除去する高い処理オーバーヘッドを回避することによって利益を得るであろう。コピー回避はさらに効果的な分散処理を受けることができ、これらのシステムのための待ち時間がなくなります。
In addition, this document introduces an architectural approach to solving the problem, which is developed in detail in [BT05]. It also discusses how the proposed technology may introduce security concerns and how they should be addressed.
また、この文書は[BT05]に詳細に開発されている問題を解決するためのアーキテクチャアプローチを導入します。また、提案されている技術は、セキュリティ上の問題を導入することができるし、彼らがどのように対処すべきかについて説明します。
Finally, this document includes a Terminology section to aid as a reference for several new terms introduced by RDMA.
最後に、この文書では、RDMAにより導入されたいくつかの新しい用語のための基準として支援するための用語のセクションが含まれています。
A wealth of data from research and industry shows that copying is responsible for substantial amounts of processing overhead. It further shows that even in carefully implemented systems, eliminating copies significantly reduces the overhead, as referenced below.
研究と産業界からのデータの富をコピー処理のオーバーヘッドのかなりの量の責任であることを示しています。さらに、以下で参照としても慎重に実装システムにおいて、著しくコピーを排除することは、オーバーヘッドを減少させることを示しています。
Clark et al. [CJRS89] in 1989 shows that TCP [Po81] overhead processing is attributable to both operating system costs (such as interrupts, context switches, process management, buffer management, timer management) and the costs associated with processing individual bytes (specifically, computing the checksum and moving data in memory). They found that moving data in memory is the more important of the costs, and their experiments show that memory bandwidth is the greatest source of limitation. In the data presented [CJRS89], 64% of the measured microsecond overhead was attributable to data touching operations, and 48% was accounted for by copying. The system measured Berkeley TCP on a Sun-3/60 using 1460 Byte Ethernet packets.
クラークら。 【CJRS89] 1989年にTCP [Po81]オーバーヘッド処理と、（具体的に個々のバイトを処理するコンピューティングに関連するコスト（例えば割り込み、コンテキストスイッチ、プロセス管理、バッファ管理、タイマ管理など）の両方のオペレーティングシステムのコストに起因していることを示していますチェックサムと）メモリにデータを移動。彼らは、メモリ内のデータを移動することは、コストのより重要であり、彼らの実験は、メモリ帯域幅が制限の最大の源であることを示していることがわかりました。 【CJRS89】提示されたデータでは、測定されたマイクロ秒のオーバーヘッドの64％は、操作をタッチデータに起因し、そして48％をコピーすることによって占めました。このシステムは1460個のバイトイーサネットパケットを使用して、Sun-3/60にバークレーTCPを測定しました。
In a well-implemented system, copying can occur between the network interface and the kernel, and between the kernel and application buffers; there are two copies, each of which are two memory bus crossings, for read and write. Although in certain circumstances it is possible to do better, usually two copies are required on receive.
よく実装されたシステムでは、コピーは、ネットワークインタフェースと、カーネル、カーネル及びアプリケーションバッファの間に起こり得ます。読み取りおよび書き込み用の2つのメモリバス交差しているそれぞれの2つのコピーが、あります。特定の状況では、それはより良い行うことは可能ですが、通常2つのコピーが受信に必要とされています。
Subsequent work has consistently shown the same phenomenon as the earlier Clark study. A number of studies report results that data-touching operations, checksumming and data movement, dominate the processing costs for messages longer than 128 Bytes [BS96, CGY01, Ch96, CJRS89, DAPP93, KP96]. For smaller sized messages, per-packet overheads dominate [KP96, CGY01].
その後の研究は一貫して、以前のクラークの研究と同じ現象を示しています。研究報告の数が128バイトより長いメッセージの処理コストを支配し、[BS96、CGY01、Ch96、CJRS89、DAPP93、KP96]をそのデータ・タッチ操作、チェックサムおよびデータ移動をもたらします。より小さいサイズのメッセージのために、パケットごとのオーバヘッドは[KP96、CGY01]を支配します。
The percentage of overhead due to data-touching operations increases with packet size, since time spent on per-byte operations scales linearly with message size [KP96]. For example, Chu [Ch96] reported substantial per-byte latency costs as a percentage of total networking software costs for an MTU size packet on a SPARCstation/20 running memory-to-memory TCP tests over networks with 3 different MTU sizes. The percentage of total software costs attributable to per-byte operations were:
時間以降当たりバイト動作に費やさによるパケットサイズのデータ・タッチ操作が増大するオーバーヘッドの割合は、[KP96]メッセージのサイズと共に線形にスケーリングします。例えば、チュー[Ch96]は、3つの異なるMTUサイズのネットワークを介して、メモリ - メモリTCPテストを実行するのSPARCstation / 20上のMTUサイズのパケットの総ネットワーク・ソフトウェア費用の割合として実質当たりバイト待ち時間コストを報告しました。バイトあたりの操作に起因する総ソフトウェアコストの割合は以下の通りでした。
1500 Byte Ethernet 18-25% 4352 Byte FDDI 35-50% 9180 Byte ATM 55-65%
1500バイトイーサネット（登録商標）18から25パーセント4352バイトFDDI 35から50パーセント9180バイトATM 55から65パーセント
Although many studies report results for data-touching operations, including checksumming and data movement together, much work has focused just on copying [BS96, Br99, Ch96, TK95]. For example, [KP96] reports results that separate processing times for checksum from data movement operations. For the 1500 Byte Ethernet size, 20% of total processing overhead time is attributable to copying. The study used 2 DECstations 5000/200 connected by an FDDI network. (In this study, checksum accounts for 30% of the processing time.)
多くの研究が一緒にチェックサムとデータ移動を含むデータ、タッチ操作の結果を報告しますが、多くの仕事はただのコピー[BS96、Br99、Ch96、TK95]に焦点を当てています。例えば、[KP96]レポートの結果は、データ移動操作からチェックサムのための処理時間を分離しています。 1500バイトイーサネットサイズのため、全体の処理オーバーヘッド時間の20％は、コピーに起因します。研究では、FDDIネットワークによって接続された2つのDECstations 200分の5000を使用します。 （この研究では、チェックサムは、処理時間の30％を占めます。）
A number of studies show that eliminating copies substantially reduces overhead. For example, results from copy-avoidance in the IO-Lite system [PDZ99], which aimed at improving web server performance, show a throughput increase of 43% over an optimized web server, and 137% improvement over an Apache server. The system was implemented in a 4.4BSD-derived UNIX kernel, and the experiments used a server system based on a 333MHz Pentium II PC connected to a switched 100 Mbits/s Fast Ethernet.
多くの研究は、コピーを排除することは、実質的にオーバーヘッドを減少させることを示しています。例えば、Webサーバの性能を向上させることを目的とIO-Liteのシステム[PDZ99]にコピー回避に起因する、Apacheサーバ上最適化ウェブ・サーバ上43％のスループットの増加、137％の改善を示します。システムは、4.4BSD由来のUNIXカーネルに実装し、実験が切り替わっ100 Mビット/秒の高速イーサネットに接続されている333MHzのペンティアムII PCに基づいてサーバシステムを使用しました。
There are many other examples where elimination of copying using a variety of different approaches showed significant improvement in system performance [CFF+94, DP93, EBBV95, KSZ95, TK95, Wa97]. We will discuss the results of one of these studies in detail in order to clarify the significant degree of improvement produced by copy avoidance [Ch02].
異なる様々なアプローチを使用してコピーの除去は、システム性能に有意な改善を示した他の多くの例がある[CFF + 94、DP93、EBBV95、KSZ95、TK95、Wa97]。私たちは、コピー回避[CH02]によって生成改善の重要度を明確にするために詳細にこれらの研究の一つの結果を説明します。
Recent work by Chase et al. [CGY01], measuring CPU utilization, shows that avoiding copies reduces CPU time spent on data access from 24% to 15% at 370 Mbits/s for a 32 KBytes MTU using an AlphaStation XP1000 and a Myrinet adapter [BCF+95]. This is an absolute improvement of 9% due to copy avoidance.
チェイスらによる最近の研究。 [CGY01]、CPU使用率を測定し、コピーを回避する32キロバイトのAlphaStation XP1000とMyrinetのアダプタを使用してMTU [BCF + 95] 370メガビット/秒で15％まで24％からのデータアクセスに費やされるCPU時間を短縮することを示しています。これは回避コピーによる9％の絶対的な改善です。
The total CPU utilization was 35%, with data access accounting for 24%. Thus, the relative importance of reducing copies is 26%. At 370 Mbits/s, the system is not very heavily loaded. The relative improvement in achievable bandwidth is 34%. This is the improvement we would see if copy avoidance were added when the machine was saturated by network I/O.
CPU使用率の合計は、データアクセスが24％を占めて、35％でした。したがって、還元コピーの相対的な重要性は26％です。 370 Mビット/秒で、システムは非常に高負荷ではありません。達成可能な帯域幅の相対的な改善は34％です。これは、マシンがネットワークI / Oで飽和されたときにコピー回避が追加された場合、我々が見ることが改善されています。
Note that improvement from the optimization becomes more important if the overhead it targets is a larger share of the total cost. This is what happens if other sources of overhead, such as checksumming, are eliminated. In [CGY01], after removing checksum overhead, copy avoidance reduces CPU utilization from 26% to 10%. This is a 16% absolute reduction, a 61% relative reduction, and a 160% relative improvement in achievable bandwidth.
それは対象オーバーヘッドは総コストの大きな割合であれば、最適化の改善がより重要になることに注意してください。これは、チェックサムのようなオーバーヘッドの他のソースは、排除された場合に何が起こるかです。 【CGY01]において、チェックサムオーバーヘッドを除去した後、コピー回避は26％から10％にCPU使用率を減少させます。これは、16％の絶対的減少、61％の相対的減少、及び達成可能な帯域幅160％の相対改善です。
In fact, today's network interface hardware commonly offloads the checksum, which removes the other source of per-byte overhead. They also coalesce interrupts to reduce per-packet costs. Thus, today copying costs account for a relatively larger part of CPU utilization than previously, and therefore relatively more benefit is to be gained in reducing them. (Of course this argument would be specious if the amount of overhead were insignificant, but it has been shown to be substantial. [BS96, Br99, Ch96, KP96, TK95])
実際には、今日のネットワーク・インターフェース・ハードウェアは、一般的にバイトあたりのオーバーヘッドの他のソースを削除するチェックサムを、オフロードします。彼らはまた、パケットごとのコストを削減するために割り込みを合体します。このように、今日のコピーコストは以前に比べてCPU使用率の比較的大きな部分を占めるので、比較的多くの利点は、それらを減らすことで得られることです。 （オーバーヘッドの量は微々たるものであったが、実質的であることが示されている場合はもちろん、この引数は、もっともらしいことである。[BS96、Br99、Ch96、KP96、TK95]）
Data movement operations are expensive because memory bandwidth is scarce relative to network bandwidth and CPU bandwidth [PAC+97]. This trend existed in the past and is expected to continue into the future [HP97, STREAM], especially in large multiprocessor systems.
メモリ帯域幅は、ネットワーク帯域幅とCPUの帯域幅[PAC + 97]に乏しい相対的であるため、データ移動操作が高価です。この傾向は、過去に存在し、特に大規模なマルチプロセッサシステムでは、将来の[HP97、STREAM]に続くと予想されます。
With copies crossing the bus twice per copy, network processing overhead is high whenever network bandwidth is large in comparison to CPU and memory bandwidths. Generally, with today's end-systems, the effects are observable at network speeds over 1 Gbits/s. In fact, with multiple bus crossings it is possible to see the bus bandwidth being the limiting factor for throughput. This prevents such an end-system from simultaneously achieving full network bandwidth and full application performance.
ネットワーク帯域幅は、CPUやメモリ帯域幅に比べて大きい時はいつでもコピーはコピー二回バスを横断して、ネットワーク処理のオーバーヘッドが高いです。一般的に、今日のエンドシステムで、効果が1Gビット/秒を超えるネットワーク速度で観測可能です。実際には、複数のバス交差点でスループットの制限要因であることバス帯域幅を確認することが可能です。これは、同時に完全なネットワーク帯域幅と完全なアプリケーションのパフォーマンスを達成することから、このようなエンドシステムを防ぎます。
A common question is whether an increase in CPU processing power alleviates the problem of high processing costs of network I/O. The answer is no, it is the memory bandwidth that is the issue. Faster CPUs do not help if the CPU spends most of its time waiting for memory [CGY01].
一般的な質問は、CPUの処理能力の増加は、ネットワークI / Oの高い処理コストの問題を軽減するかどうかです。答えはノー、それは問題であるメモリ帯域幅です。 CPUがメモリを待っているそのほとんどの時間を費やしている場合はより高速なCPUは[CGY01]は役立ちません。
The widening gap between microprocessor performance and memory performance has long been a widely recognized and well-understood problem [PAC+97]. Hennessy [HP97] shows microprocessor performance grew from 1980-1998 at 60% per year, while the access time to DRAM improved at 10% per year, giving rise to an increasing "processor-memory performance gap".
マイクロプロセッサ性能とメモリ性能との間の拡大ギャップが長く、広く認識され、十分に理解問題[PAC + 97]でした。ヘネシー[HP97]はDRAMへのアクセス時間が増加し、「プロセッサ・メモリのパフォーマンスギャップ」を生じる、年間10％改善し、マイクロプロセッサの性能は、年間60％で1980年から1998年の成長を示しています。
Another source of relevant data is the STREAM Benchmark Reference Information website, which provides information on the STREAM benchmark [STREAM]. The benchmark is a simple synthetic benchmark program that measures sustainable memory bandwidth (in MBytes/s) and the corresponding computation rate for simple vector kernels measured in MFLOPS. The website tracks information on sustainable memory bandwidth for hundreds of machines and all major vendors.
関連データの別のソースは、STREAMベンチマーク[STREAM]についての情報を提供しSTREAMベンチマークリファレンス情報ウェブサイトです。ベンチマークは、（メガバイト/秒で）持続可能なメモリ帯域幅を測定する単純な合成ベンチマークプログラムとMFLOPSで測定された単純なベクトルカーネルのための対応する計算速度です。ウェブサイトは、マシンとすべての主要ベンダーの何百ものための持続可能なメモリ帯域幅に関する情報を追跡します。
Results show measured system performance statistics. Processing performance from 1985-2001 increased at 50% per year on average, and sustainable memory bandwidth from 1975 to 2001 increased at 35% per year, on average, over all the systems measured. A similar 15% per year lead of processing bandwidth over memory bandwidth shows up in another statistic, machine balance [Mc95], a measure of the relative rate of CPU to memory bandwidth (FLOPS/cycle) / (sustained memory ops/cycle) [STREAM].
結果は、測定システムのパフォーマンス統計情報を表示します。 1985-2001からの処理性能は平均で年間50％増加し、持続可能なメモリ帯域幅1975から2001まで測定したすべてのシステム上で、平均で、年間35％に増加しました。メモリ帯域幅にわたって処理帯域幅の同様の15％の年間のリードは、メモリ帯域幅（FLOPS /サイクル）/（持続性メモリOPS /サイクル）と、別の統計に現れ、機械バランス[Mc95]、CPUの相対速度の尺度ストリーム]。
Network bandwidth has been increasing about 10-fold roughly every 8 years, which is a 40% per year growth rate.
ネットワーク帯域幅は、約40％の年間成長率である、すべての8年間およそ10倍に増加してきています。
A typical example illustrates that the memory bandwidth compares unfavorably with link speed. The STREAM benchmark shows that a modern uniprocessor PC, for example the 1.2 GHz Athlon in 2001, will move the data 3 times in doing a receive operation: once for the network interface to deposit the data in memory, and twice for the CPU to copy the data. With 1 GBytes/s of memory bandwidth, meaning one read or one write, the machine could handle approximately 2.67 Gbits/s of network bandwidth, one third the copy bandwidth. But this assumes 100% utilization, which is not possible, and more importantly the machine would be totally consumed! (A rule of thumb for databases is that 20% of the machine should be required to service I/O, leaving 80% for the database application. And, the less, the better.)
典型的な例では、メモリ帯域幅がリンク速度に不利比較ことを示しています。 STREAMベンチマークは、2001年に1.2 GHzのアスロン例えば、現代のユニプロセッサPCことを示し、受信動作を行うことで、データを3回移動します：メモリ内のデータを堆積させるためのネットワークインタフェースの後、二回コピーするCPUのためにデータ。メモリ帯域幅の1ギガバイト/秒で、1回の読み取りまたは1件の書き込みを意味し、マシンがネットワーク帯域幅の約2.67ギガビット/秒、三分の一コピー帯域幅を扱うことができます。しかし、これは不可能である100％の使用率を、前提とし、さらに重要なマシンが完全に消費されます！ （データベースのための経験則は、機械の20％がデータベース・アプリケーションのための80％を残し、O / Iにサービスを提供するために必要とされるべきであるということである。そして、より少ない、よりよいです。）
In 2001, 1 Gbits/s links were common. An application server may typically have two 1 Gbits/s connections: one connection backend to a storage server and one front-end, say for serving HTTP [FGM+99]. Thus, the communications could use 2 Gbits/s. In our typical example, the machine could handle 2.7 Gbits/s at its theoretical maximum while doing nothing else. This means that the machine basically could not keep up with the communication demands in 2001; with the relative growth trends, the situation only gets worse.
2001年には、1ギガビット/秒のリンクが一般的でした。アプリケーションサーバは、典型的には2つ1ギガビット/秒接続有していてもよい：ストレージサーバーと1つのフロントエンドへの1つの接続のバックエンドを、HTTP [FGM + 99]を提供するため言います。したがって、通信は、2ギガビット/秒を使用することができます。他に何もしないながら、私たちの典型的な例では、マシンは理論上の最大値で2.7ギガビット/秒を扱うことができます。これは、マシンは基本的に2001年の通信需要に追いつくことができなかったことを意味します。相対的な成長傾向で、状況は悪化するだけ。
4. High copy overhead is problematic for many key Internet applications.
4.高コピーオーバーヘッドは多くの主要なインターネットアプリケーションのための問題があります。
If a significant portion of resources on an application machine is consumed in network I/O rather than in application processing, it makes it difficult for the application to scale, i.e., to handle more clients, to offer more services.
アプリケーション・マシン上のリソースの大部分は、ネットワークI / Oではなく、アプリケーション処理で消費されている場合、それはより多くのサービスを提供するために、すなわち、より多くのクライアントを処理するために、スケールに適用するためのことを困難にしています。
Several years ago the most affected applications were streaming multimedia, parallel file systems, and supercomputing on clusters [BS96]. In addition, today the applications that suffer from copying overhead are more central in Internet computing -- they store, manage, and distribute the information of the Internet and the enterprise. They include database applications doing transaction processing, e-commerce, web serving, decision support, content distribution, video distribution, and backups. Clusters are typically used for this category of application, since they have advantages of availability and scalability.
数年前にほとんど影響を受けるアプリケーションは、クラスタ[BS96]に、マルチメディア、並列ファイルシステム、およびスーパーコンピュータをストリーミングされました。また、今日のオーバーヘッドをコピー苦しむのアプリケーションは、インターネット・コンピューティングでは、より中心である - 彼らは、保存、管理、およびインターネットや企業の情報を配布します。彼らは、データベースのトランザクション処理を行うアプリケーション、電子商取引、ウェブサービス提供、意思決定支援、コンテンツ配信、映像配信、およびバックアップが含まれます。彼らは可用性とスケーラビリティの利点を持っているので、クラスタは、通常、アプリケーションのこのカテゴリに使用されています。
Today these applications, which provide and manage Internet and corporate information, are typically run in data centers that are organized into three logical tiers. One tier is typically a set of web servers connecting to the WAN. The second tier is a set of application servers that run the specific applications usually on more powerful machines, and the third tier is backend databases. Physically, the first two tiers -- web server and application server -- are usually combined [Pi01]. For example, an e-commerce server communicates with a database server and with a customer site, or a content distribution server connects to a server farm, or an OLTP server connects to a database and a customer site.
今日提供し、インターネットや企業の情報を管理し、これらのアプリケーションは、一般的に3つの論理階層に編成されているデータセンターで実行されます。一つの層は、通常、WANに接続するWebサーバのセットです。第二層は、より強力なマシンでは、通常、特定のアプリケーションを実行するアプリケーションサーバの集合であり、第3層は、バックエンドのデータベースです。物理的には、最初の2つの層 - Webサーバとアプリケーションサーバは、 - 通常合成される[PI01]。例えば、eコマースサーバは、データベースサーバと、顧客サイトと通信、またはコンテンツ配信サーバは、サーバファームに接続し、またはOLTPサーバはデータベースと、顧客サイトに接続します。
When network I/O uses too much memory bandwidth, performance on network paths between tiers can suffer. (There might also be performance issues on Storage Area Network paths used either by the database tier or the application tier.) The high overhead from network-related memory copies diverts system resources from other application processing. It also can create bottlenecks that limit total system performance.
ネットワークI / Oがあまりにも多くのメモリ帯域幅を使用する場合、階層間のネットワーク経路上のパフォーマンスが低下することができます。 （また、データベース層またはアプリケーション層のいずれかによって使用されるストレージエリアネットワークパス上のパフォーマンスの問題があるかもしれません。）ネットワーク関連のメモリコピーから高いオーバーヘッドは、他のアプリケーション処理からシステムリソースを分岐させます。また、システム全体のパフォーマンスを制限するボトルネックを作成することができます。
There is high motivation to maximize the processing capacity of each CPU because scaling by adding CPUs, one way or another, has drawbacks. For example, adding CPUs to a multiprocessor will not necessarily help because a multiprocessor improves performance only when the memory bus has additional bandwidth to spare. Clustering can add additional complexity to handling the applications.
、一つの方法または別のCPUを追加することにより、スケーリング、欠点を持っているので、各CPUの処理能力を最大化するために、高いモチベーションがあります。マルチプロセッサは、メモリバスは余裕が追加の帯域幅を持っているだけで、パフォーマンスを向上するため例えば、マルチプロセッサにCPUを追加することは必ずしも助けにはなりません。クラスタリングは、アプリケーションを処理する追加の複雑さを追加することができます。
In order to scale a cluster or multiprocessor system, one must proportionately scale the interconnect bandwidth. Interconnect bandwidth governs the performance of communication-intensive parallel applications; if this (often expressed in terms of "bisection bandwidth") is too low, adding additional processors cannot improve system throughput. Interconnect latency can also limit the performance of applications that frequently share data between processors.
クラスタまたはマルチプロセッサシステムを拡張するためには、比例相互接続帯域幅を拡張しなければなりません。相互接続帯域幅は、通信集約並列アプリケーションの性能を支配します。これは、（しばしば「二等分帯域」で表現）が低すぎる場合は、追加のプロセッサを追加すると、システムのスループットを向上させることができません。インターコネクトの待ち時間も、頻繁にプロセッサ間でデータを共有するアプリケーションのパフォーマンスを制限することができます。
So, excessive overheads on network paths in a "scalable" system both can require the use of more processors than optimal, and can reduce the marginal utility of those additional processors.
だから、「スケーラブル」システムにおけるネットワークパス上の過度のオーバーヘッドの両方が最適よりもプロセッサの使用を必要とすることができ、それらの追加のプロセッサの限界効用を減少させることができます。
Copy avoidance scales a machine upwards by removing at least two-thirds of the bus bandwidth load from the "very best" 1-copy (on receive) implementations, and removes at least 80% of the bandwidth overhead from the 2-copy implementations.
コピー回避は上向きに実装（受信時に）「最高の」1-コピーからバス帯域幅の負荷の少なくとも三分の二を除去することによって機械をスケーリング、および2コピーの実装から帯域幅のオーバーヘッドの少なくとも80％を除去します。
The removal of bus bandwidth requirements, in turn, removes bottlenecks from the network processing path and increases the throughput of the machine. On a machine with limited bus bandwidth, the advantages of removing this load is immediately evident, as the host can attain full network bandwidth. Even on a machine with bus bandwidth adequate to sustain full network bandwidth, removal of bus bandwidth load serves to increase the availability of the machine for the processing of user applications, in some cases dramatically.
バス帯域幅の要件の除去は、今度は、ネットワーク処理経路からボトルネックを除去し、機械のスループットを増加させます。限られたバス帯域幅を持つマシンでは、この負荷を取り除くことの利点は、ホストが完全なネットワーク帯域幅を達成することができるよう、直ちに明らかです。完全なネットワーク帯域幅を維持するのに十分なバス帯域幅を有するマシンに、バス帯域幅の負荷の除去が劇的にある場合には、ユーザアプリケーションの処理のための機械の可用性を高めるのに役立ちます。
An example showing poor performance with copies and improved scaling with copy avoidance is illustrative. The IO-Lite work [PDZ99] shows higher server throughput servicing more clients using a zero-copy system. In an experiment designed to mimic real world web conditions by simulating the effect of TCP WAN connections on the server, the performance of 3 servers was compared. One server was Apache, another was an optimized server called Flash, and the third was the Flash server running IO-Lite, called Flash-Lite with zero copy. The measurement was of throughput in requests/second as a function of the number of slow background clients that could be served. As the table shows, Flash-Lite has better throughput, especially as the number of clients increases.
コピー回避とコピーと改善スケーリングとパフォーマンスの低下を示す例は例示です。 IO-Liteの作業は[PDZ99]ゼロコピーシステムを使用して、より多くのクライアントにサービスを提供し、より高いサーバーのスループットを示しています。サーバー上のTCP WAN接続の効果をシミュレートすることによって、現実世界のWeb条件を模倣するように設計された実験では、3台のサーバのパフォーマンスを比較しました。 1台のサーバが別のフラッシュと呼ばれる最適化されたサーバーで、第三には、Flash-Liteのゼロコピーと呼ばれるIO-Liteは、実行中のフラッシュ・サーバーた、Apacheのでした。測定は、提供することができ、低速背景クライアントの数の関数として第2の要求/でのスループットでした。表が示すように、フラッシュ-Liteは、特にクライアント数の増加に伴って、より優れたスループットを持っています。
Apache Flash Flash-Lite
------ ----- ----------
#Clients Throughput reqs/s Throughput Throughput
0 520 610 890 16 390 490 890 32 360 490 850 64 360 490 890 128 310 450 880 256 310 440 820
０ ５２０ ６１０ ８９０ １６ ３９０ ４９０ ８９０ ３２ ３６０ ４９０ ８５０ ６４ ３６０ ４９０ ８９０ １２８ ３１０ ４５０ ８８０ ２５６ ３１０ ４４０ ８２０
Traditional Web servers (which mostly send data and can keep most of their content in the file cache) are not the worst case for copy overhead. Web proxies (which often receive as much data as they send) and complex Web servers based on System Area Networks or multi-tier systems will suffer more from copy overheads than in the example above.
（主にデータを送信し、ファイルキャッシュにその内容のほとんどを保つことができる）従来のWebサーバーでは、コピーのオーバーヘッドのための最悪のケースではありません。システムエリアネットワークやマルチティア・システムに基づいて（彼らが送るよう、多くの場合、できるだけ多くのデータを受信）Webプロキシや複雑なWebサーバーは、上記の例よりもコピーオーバーヘッドから多くを被るだろう。
There have been extensive research investigation and industry experience with two main alternative approaches to eliminating data movement overhead, often along with improving other Operating System processing costs. In one approach, hardware and/or software changes within a single host reduce processing costs. In another approach, memory-to-memory networking [MAF+02], the exchange of explicit data placement information between hosts allows them to reduce processing costs.
二つの主要な選択肢を持つ大規模な研究調査や業界経験は、多くの場合、他のオペレーティングシステムの処理コストを改善するとともに、データ移動のオーバーヘッドを排除へのアプローチがありました。 1つのアプローチでは、単一のホスト内のハードウェアおよび/またはソフトウェアの変更は、処理コストを削減します。別のアプローチでは、メモリ - メモリネットワーキング[+ 02 MAF]は、ホスト間の明示的なデータ配置情報の交換は、それらが処理コストを削減することを可能にします。
The single host approaches range from new hardware and software architectures [KSZ95, Wa97, DWB+93] to new or modified software systems [BS96, Ch96, TK95, DP93, PDZ99]. In the approach based on using a networking protocol to exchange information, the network adapter, under control of the application, places data directly into and out of application buffers, reducing the need for data movement. Commonly this approach is called RDMA, Remote Direct Memory Access.
単一のホストアプローチは、新規または変更されたソフトウェアシステムに新しいハードウェアおよびソフトウェアアーキテクチャ[KSZ95、Wa97、DWB + 93]の範囲[BS96、Ch96、TK95、DP93、PDZ99]。 、アプリケーションの制御下で、情報、ネットワークアダプタを交換するネットワークプロトコルを使用することに基づくアプローチでは、データ移動の必要性を減らす、に、アプリケーション・バッファから直接データを置きます。一般的に、このアプローチは、RDMA、リモートダイレクトメモリアクセスと呼ばれています。
As discussed below, research and industry experience has shown that copy avoidance techniques within the receiver processing path alone have proven to be problematic. The research special purpose host adapter systems had good performance and can be seen as precursors for the commercial RDMA-based adapters [KSZ95, DWB+93]. In software, many implementations have successfully achieved zero-copy transmit, but few have accomplished zero-copy receive. And those that have done so make strict alignment and no-touch requirements on the application, greatly reducing the portability and usefulness of the implementation.
以下に述べるように、研究と業界での経験だけでは問題があることが証明されている受信機処理パスの中に回避技術をコピーすることが示されています。研究特別な目的のホストアダプタシステムは、優れた性能を有しており、商用RDMAベースのアダプタ[KSZ95、DWB + 93]の前駆体として見ることができます。ソフトウェアでは、多くの実装が正常にゼロコピー送信を達成しているが、いくつかは、ゼロコピーを受け取る達成しました。そして、そうしたものが大幅に実装の移植性と有用性を減らし、アプリケーションの厳格なアライメントとノータッチ要件を作ります。
In contrast, experience has proven satisfactory with memory-to-memory systems that permit RDMA; performance has been good and there have not been system or networking difficulties. RDMA is a single solution. Once implemented, it can be used with any OS and machine architecture, and it does not need to be revised when either of these are changed.
これとは対照的に、経験がRDMAを許可するメモリ - メモリシステムとの十分な証明しています。パフォーマンスが良いされているシステムやネットワーク上の問題があっていません。 RDMAは、単一のソリューションです。実装されると、それは、任意のOSやマシンアーキテクチャで使用することができ、これらのいずれかが変更された場合には、改定する必要はありません。
In early work, one goal of the software approaches was to show that TCP could go faster with appropriate OS support [CJRS89, CFF+94]. While this goal was achieved, further investigation and experience showed that, though possible to craft software solutions, specific system optimizations have been complex, fragile, extremely interdependent with other system parameters in complex ways, and often of only marginal improvement [CFF+94, CGY01, Ch96, DAPP93, KSZ95, PDZ99]. The network I/O system interacts with other aspects of the Operating System such as machine architecture and file I/O, and disk I/O [Br99, Ch96, DP93].
初期の研究では、ソフトウェアのアプローチの一つの目標は、TCPは、適切なOSをサポート[CJRS89、CFF + 94]で速く行くことができることを示すことでした。この目標が達成されたが、さらなる調査と経験がクラフト・ソフトウェア・ソリューションへの可能なものの、特定のシステムの最適化は、複雑な脆弱な、複雑な方法で他のシステム・パラメータを持つ非常に相互に依存し、多くの場合の唯一のわずかな改善[CFF + 94となっている、ことを示しましたCGY01、Ch96、DAPP93、KSZ95、PDZ99]。ネットワークI / Oシステムは、このようなマシンアーキテクチャとファイルI / O、およびディスクI / O [Br99、Ch96、DP93]、オペレーティングシステムの他の側面と相互作用します。
For example, the Solaris Zero-Copy TCP work [Ch96], which relies on page remapping, shows that the results are highly interdependent with other systems, such as the file system, and that the particular optimizations are specific for particular architectures, meaning that for each variation in architecture, optimizations must be re-crafted [Ch96].
例えば、ページ再マッピングに依存しているSolarisのゼロコピーTCP仕事[Ch96]は、結果は、ファイルシステムのような他のシステムと高度に相互依存していること、及び特定の最適化は、つまり、特定のアーキテクチャに特異的であることを示していますアーキテクチャ内の各変化のために、最適化は、[Ch96]再細工されなければなりません。
With RDMA, application I/O buffers are mapped directly, and the authorized peer may access it without incurring additional processing overhead. When RDMA is implemented in hardware, arbitrary data movement can be performed without involving the host CPU at all.
RDMAと、アプリケーションのI / Oバッファは直接マッピングされ、そして認可ピアが追加の処理オーバーヘッドを招くことなく、それにアクセスすることができます。 RDMAをハードウェアで実現する場合、任意のデータ移動は、すべてのホストCPUを介さずに行うことができます。
A number of research projects and industry products have been based on the memory-to-memory approach to copy avoidance. These include U-Net [EBBV95], SHRIMP [BLA+94], Hamlyn [BJM+96], Infiniband [IB], Winsock Direct [Pi01]. Several memory-to-memory systems have been widely used and have generally been found to be robust, to have good performance, and to be relatively simple to implement. These include VI [VI], Myrinet [BCF+95], Quadrics [QUAD], Compaq/Tandem Servernet [SRVNET]. Networks based on these memory-to-memory architectures have been used widely in scientific applications and in data centers for block storage, file system access, and transaction processing.
研究プロジェクトや工業製品の数は、回避をコピーするために、メモリ・ツー・メモリのアプローチに基づいています。これらは、U-Netの[EBBV95]、エビ[BLA + 94]、ハムリン[BJM + 96]、インフィニバンド[IB]、Winsockのダイレクト[PI01]が挙げられます。いくつかのメモリ・ツー・メモリシステムが広く使用されており、一般的に、堅牢に優れた性能を有すること、および実装が比較的簡単であることが判明しています。これらは、VI [VI]のMyrinet [BCF + 95]のQuadrics [QUAD]、コンパック/タンデムSERVERNET [SRVNET]が挙げられます。これらのメモリ・ツー・メモリ・アーキテクチャに基づくネットワークは、科学的なアプリケーションにし、ブロックストレージ、ファイルシステムへのアクセス、およびトランザクション処理のためのデータセンターで広く使用されています。
By exporting direct memory access "across the wire", applications may direct the network stack to manage all data directly from application buffers. A large and growing class that takes advantage of such capabilities of applications has already emerged. It includes all the major databases, as well as network protocols such as Sockets Direct [SDP].
「ワイヤ間で」ダイレクトメモリアクセスをエクスポートすることにより、アプリケーションは、アプリケーション・バッファから直接、すべてのデータを管理するために、ネットワークスタックを指示することができます。アプリケーションのこのような機能を活用して大規模で成長しているクラスがすでに浮上しています。これは、すべての主要なデータベース、ならびにこのようなソケット直接[SDP]などのネットワーク・プロトコルを含んでいます。
An RDMA solution can be usefully viewed as being comprised of two distinct components: "direct data placement (DDP)" and "remote direct memory access (RDMA) semantics". They are distinct in purpose and also in practice -- they may be implemented as separate protocols.
「直接データ配置（DDP）」および「リモートダイレクトメモリアクセス（RDMA）のセマンティクス」：RDMA溶液有用二つの別個の構成要素からなるものと見なすことができます。彼らは目的にしても、実際には別個のものである - 彼らは別のプロトコルとして実装されてもよいです。
The more fundamental of the two is the direct data placement facility. This is the means by which memory is exposed to the remote peer in an appropriate fashion, and the means by which the peer may access it, for instance, reading and writing.
2のより基本的には、直接的なデータ配置の施設です。これは、メモリが適切な方法でリモートピアに露出させる手段、およびピアは、例えば、読み書きのために、それにアクセスすることができる手段です。
The RDMA control functions are semantically layered atop direct data placement. Included are operations that provide "control" features, such as connection and termination, and the ordering of operations and signaling their completions. A "send" facility is provided.
RDMA制御機能は、意味的に直接データ配置の上に積層されています。このような接続と終了、および操作の順序とその完了をシグナルとして「制御」の機能を、提供操作が含まれます。 「送信」機能が提供されています。
While the functions (and potentially protocols) are distinct, historically both aspects taken together have been referred to as "RDMA". The facilities of direct data placement are useful in and of themselves, and may be employed by other upper layer protocols to facilitate data transfer. Therefore, it is often useful to refer to DDP as the data placement functionality and RDMA as the control aspect.
（潜在的およびプロトコル）機能は別個であるが、歴史的に一緒になって、両方の態様を「RDMA」と呼ばれてきました。直接データ配置の施設は、それ自体が有用であり、データの転送を容易にするために、他の上位層プロトコルによって使用されてもよいです。したがって、制御態様としてデータ配置機能とRDMAとしてDDPを参照することがしばしば有用です。
[BT05] develops an architecture for DDP and RDMA atop the Internet Protocol Suite, and is a companion document to this problem statement.
[BT05]は、インターネットプロトコルスイートの上にDDPとRDMAのためのアーキテクチャを開発し、この問題文の仲間ドキュメントです。
This Problem Statement concludes that an IP-based, general solution for reducing processing overhead in end-hosts is desirable.
この問題ステートメントは、エンドホストでの処理オーバヘッドを低減するためのIPベースの、一般的な解決策が望ましいと結論します。
It has shown that high overhead of the processing of network data leads to end-host bottlenecks. These bottlenecks are in large part attributable to the copying of data. The bus bandwidth of machines has historically been limited, and the bandwidth of high-speed interconnects taxes it heavily.
これは、ネットワーク・データの処理の高いオーバーヘッドがボトルネック、ホスト端につながることが示されています。これらのボトルネックは、大部分のデータのコピーに起因しています。マシンのバス帯域幅は、歴史的に限定されていた、高速相互接続の帯域幅が大きく、それを課税します。
An architectural solution to alleviate these bottlenecks best satisfies the issue. Further, the high speed of today's interconnects and the deployment of these hosts on Internet Protocol-based networks leads to the desirability of layering such a solution on the Internet Protocol Suite. The architecture described in [BT05] is such a proposal.
建築ソリューションは、これらのボトルネックを最もよく満たす問題を緩和します。さらに、今日の相互接続の高速インターネットプロトコルベースのネットワーク上でこれらのホストの展開は、インターネットプロトコルスイートのようなソリューションを積層することが望ましいことにつながります。 [BT05]に記載のアーキテクチャはそのような提案です。
Solutions to the problem of reducing copying overhead in high bandwidth transfers may introduce new security concerns. Any proposed solution must be analyzed for security vulnerabilities and any such vulnerabilities addressed. Potential security weaknesses -- due to resource issues that might lead to denial-of-service attacks, overwrites and other concurrent operations, the ordering of completions as required by the RDMA protocol, the granularity of transfer, and any other identified vulnerabilities -- need to be examined, described, and an adequate resolution to them found.
高帯域幅の転送にコピーのオーバーヘッドを削減する問題への解決策は、新たなセキュリティ上の懸念を導入することができます。任意の提案されたソリューションは、セキュリティの脆弱性を分析する必要があり、そのような脆弱性に対処しました。サービス拒否攻撃につながる可能性があるため、リソースの問題に、上書きされ、他の並行操作、RDMAプロトコル、転送の細かさ、およびその他の識別された脆弱性により、必要に応じて補完の順序 - - 潜在的なセキュリティ上の弱点が必要調べ説明、及びそれらへの十分な解像度が発見されます。
Layered atop Internet transport protocols, the RDMA protocols will gain leverage from and must permit integration with Internet security standards, such as IPsec and TLS [IPSEC, TLS]. However, there may be implementation ramifications for certain security approaches with respect to RDMA, due to its copy avoidance.
インターネットトランスポートプロトコルの上に重ね、RDMAプロトコルはからレバレッジを獲得すると、そのようなIPsecとTLS [IPSEC、TLS]などのインターネットセキュリティ標準との統合を許可する必要があります。しかし、そのコピー回避のためにRDMAに対して一定のセキュリティアプローチの実装な影響があるかもしれません。
IPsec, operating to secure the connection on a packet-by-packet basis, seems to be a natural fit to securing RDMA placement, which operates in conjunction with transport. Because RDMA enables an implementation to avoid buffering, it is preferable to perform all applicable security protection prior to processing of each segment by the transport and RDMA layers. Such a layering enables the most efficient secure RDMA implementation.
IPsecは、パケットごとの接続を確保するために動作し、輸送と連動して動作RDMAの配置を、安全に自然にフィットするようです。 RDMAバッファリングを避けるために、実装を可能にするので、輸送とRDMA層によって、各セグメントの処理に先立って適用されるすべてのセキュリティ保護を行うことが好ましいです。このような積層化は、最も効率的な安全なRDMAの実装を可能にします。
The TLS record protocol, on the other hand, is layered on top of reliable transports and cannot provide such security assurance until an entire record is available, which may require the buffering and/or assembly of several distinct messages prior to TLS processing. This defers RDMA processing and introduces overheads that RDMA is designed to avoid. Therefore, TLS is viewed as potentially a less natural fit for protecting the RDMA protocols.
TLSレコード・プロトコルは、一方で、信頼性の高いトランスポートの上に積層され、レコード全体が前TLS処理にいくつかの別個のメッセージのバッファリングおよび/または組み立てを必要とすることができる、利用可能になるまで、セキュリティの保証を提供することができません。これは、RDMA処理を延期し、RDMAを回避するように設計されたオーバーヘッドを紹介しています。したがって、TLSは、RDMAプロトコルを保護するための潜在的にあまり自然にフィットと見なされます。
It is necessary to guarantee properties such as confidentiality, integrity, and authentication on an RDMA communications channel. However, these properties cannot defend against all attacks from properly authenticated peers, which might be malicious, compromised, or buggy. Therefore, the RDMA design must address protection against such attacks. For example, an RDMA peer should not be able to read or write memory regions without prior consent.
このようなRDMA通信チャネル上の機密性、完全性、および認証などの特性を保証する必要があります。しかし、これらのプロパティは、正しく認証悪意のあるかもしれないピア、妥協、またはバギーからのすべての攻撃を防御することはできません。したがって、RDMAの設計は、このような攻撃に対する保護に取り組む必要があります。例えば、RDMAピアは、事前の同意なしにメモリ領域を読み書きすることがあってはなりません。
Further, it must not be possible to evade memory consistency checks at the recipient. The RDMA design must allow the recipient to rely on its consistent memory contents by explicitly controlling peer access to memory regions at appropriate times.
さらに、受信者のメモリ整合性チェックを回避することは可能であってはなりません。 RDMAの設計は、受信者が明示的に適切なタイミングでメモリ領域へのピアのアクセスを制御することによって、その一貫性のあるメモリの内容に依存することができるようにする必要があります。
Peer connections that do not pass authentication and authorization checks by upper layers must not be permitted to begin processing in RDMA mode with an inappropriate endpoint. Once associated, peer accesses to memory regions must be authenticated and made subject to authorization checks in the context of the association and connection on which they are to be performed, prior to any transfer operation or data being accessed.
上位レイヤによって認証および承認チェックを通過しないピア接続が不適切なエンドポイントとRDMAモードで処理を開始することを許可してはなりません。関連したら、ピアがメモリ領域へのアクセスを認証し、それらが前の任意の転送動作またはアクセスされるデータに、実行されるべきでアソシエーションおよび接続のコンテキストで権限チェックの対象としなければなりません。
The RDMA protocols must ensure that these region protections be under strict application control. Remote access to local memory by a network peer is particularly important in the Internet context, where such access can be exported globally.
RDMAプロトコルは、これらの地域の保護が厳しいアプリケーション制御下にあることを確認する必要があります。ネットワークピアによってローカルメモリへのリモートアクセスは、そのようなアクセスをグローバルにエクスポートすることができ、インターネットの文脈で特に重要です。
This section contains general terminology definitions for this document and for Remote Direct Memory Access in general.
このセクションでは、この文書のと、一般的にリモートダイレクトメモリアクセスのための一般的な用語の定義が含まれています。
Remote Direct Memory Access (RDMA) A method of accessing memory on a remote system in which the local system specifies the location of the data to be transferred.
リモートダイレクトメモリアクセス（RDMA）ローカルシステムが転送するデータの場所を指定したリモート・システム上のメモリにアクセスする方法。
RDMA Protocol A protocol that supports RDMA Operations to transfer data between systems.
RDMAプロトコルシステム間でデータを転送するRDMAオペレーションをサポートするプロトコル。
Fabric The collection of links, switches, and routers that connect a set of systems.
ファブリックシステムのセットを接続するリンク、スイッチ、ルータのコレクション。
Storage Area Network (SAN) A network where disks, tapes, and other storage devices are made available to one or more end-systems via a fabric.
ストレージエリアネットワーク（SAN）ディスク、テープ、およびその他のストレージデバイスをファブリックを介して1つまたは複数のエンドシステムに利用可能にされるネットワーク。
System Area Network A network where clustered systems share services, such as storage and interprocess communication, via a fabric.
システムエリアネットワークファブリックを介して、ストレージ及びプロセス間通信として、クラスタ化システム共有サービス、ネットワーク、。
Fibre Channel (FC) An ANSI standard link layer with associated protocols, typically used to implement Storage Area Networks. [FIBRE]
ファイバチャネル（FC）関連プロトコルとANSI標準のリンク層は、通常、ストレージ・エリア・ネットワークを実装するために使用されます。 [ファイバ]
Virtual Interface Architecture (VI, VIA) An RDMA interface definition developed by an industry group and implemented with a variety of differing wire protocols. [VI]
仮想インターフェイスアーキテクチャ（VI、VIA）RDMAインタフェース定義業界団体によって開発され、ワイヤプロトコルの異なる様々な実装。 [VI]
Infiniband (IB) An RDMA interface, protocol suite and link layer specification defined by an industry trade association. [IB]
インフィニバンド（IB）の業界団体によって定義されたRDMAインタフェース、プロトコルスイートとリンク層仕様。 [IB]
Jeff Chase generously provided many useful insights and information. Thanks to Jim Pinkerton for many helpful discussions.
ジェフ・チェースは寛大に多くの有用な知見や情報を提供しました。多くの有用な議論のためのジム・ピンカートンに感謝します。
[ATM] The ATM Forum, "Asynchronous Transfer Mode Physical Layer Specification" af-phy-0015.000, etc. available from http://www.atmforum.com/standards/approved.html.
[ATM] ATMフォーラム、 "非同期転送モード物理層仕様" AF-PHY-0015.000などhttp://www.atmforum.com/standards/approved.htmlから入手できます。
[BCF+95] N. J. Boden, D. Cohen, R. E. Felderman, A. E. Kulawik, C. L. Seitz, J. N. Seizovic, and W. Su. "Myrinet - A gigabit-per-second local-area network", IEEE Micro, February 1995.
【BCF + 95] N. J.ボーデン、D.コーエン、R. E. Felderman、A. E. Kulawik、C. L.サイツ、J. N. Seizovic、及びW.蘇。 「のMyrinet - ギガビット毎秒のローカル・エリア・ネットワーク」、IEEEマイクロ、1995年2月。
[BJM+96] G. Buzzard, D. Jacobson, M. Mackey, S. Marovich, J. Wilkes, "An implementation of the Hamlyn send-managed interface architecture", in Proceedings of the Second Symposium on Operating Systems Design and Implementation, USENIX Assoc., October 1996.
[BJM + 96]オペレーティングシステム設計と実装上の第二のシンポジウムにおけるG.ノスリ、D.ヤコブソン、M.マッケイ、S. Marovich、J.ウィルクス、「ハムリン送信管理インターフェースアーキテクチャの実装」、 、USENIX准、1996年10月。
[BLA+94] M. A. Blumrich, K. Li, R. Alpert, C. Dubnicki, E. W. Felten, "A virtual memory mapped network interface for the SHRIMP multicomputer", in Proceedings of the 21st Annual Symposium on Computer Architecture, April 1994, pp. 142- 153.
[BLA + 94] MA Blumrich、K.リー、R.・アルパート、C. Dubnicki、EW Felten、「エビマルチコンピュータの仮想メモリマップされたネットワーク・インタフェース」、コンピュータアーキテクチャ上の第21回シンポジウム、1994年4月で、頁。142- 153。
[Br99] J. C. Brustoloni, "Interoperation of copy avoidance in network and file I/O", Proceedings of IEEE Infocom, 1999, pp. 534-542.
[Br99] J. C. Brustoloni、IEEEインフォコム、1999、頁534から542までの議事録 "ネットワークとファイルI / Oの中にコピー回避の相互運用"。
[BS96] J. C. Brustoloni, P. Steenkiste, "Effects of buffering semantics on I/O performance", Proceedings OSDI'96, USENIX, Seattle, WA October 1996, pp. 277-291.
[BS96] J. C. Brustoloni、P. Steenkiste、議事OSDI'96、USENIX、シアトル、WA 1996年10月、頁 "I / Oのパフォーマンスにバッファリングセマンティクスの影響"。277から291まで。
[BT05] Bailey, S. and T. Talpey, "The Architecture of Direct Data Placement (DDP) And Remote Direct Memory Access (RDMA) On Internet Protocols", RFC 4296, December 2005.
[BT05]ベイリー、S.とT. Talpey、 "インターネットプロトコル上で直接データ配置（DDP）とリモートダイレクトメモリアクセス（RDMA）のアーキテクチャ"、RFC 4296、2005年12月。
[CFF+94] C-H Chang, D. Flower, J. Forecast, H. Gray, B. Hawe, A. Nadkarni, K. K. Ramakrishnan, U. Shikarpur, K. Wilde, "High-performance TCP/IP and UDP/IP networking in DEC OSF/1 for Alpha AXP", Proceedings of the 3rd IEEE Symposium on High Performance Distributed Computing, August 1994, pp. 36-42.
[CFF + 94] CHチャン、D.花、J.予測、H.グレー、B. HAWE、A. Nadkarni、KKラマクリシュナン、U. Shikarpur、K.ワイルド、「高性能TCP / IPおよびUDP / IP高性能分散コンピューティング、1994年8月、頁36-42上のAlpha AXPのために12月OSF / 1」、第3回IEEEシンポジウムでのネットワーク。
[CGY01] J. S. Chase, A. J. Gallatin, and K. G. Yocum, "End system optimizations for high-speed TCP", IEEE Communications Magazine, Volume: 39, Issue: 4 , April 2001, pp 68-74. http://www.cs.duke.edu/ari/publications/end-system.{ps,pdf}.
【CGY01] J. S.チェイス、A. J.ガラティン、及びK. G. Yocum、 "高速TCPのエンドシステムの最適化"、IEEE通信誌、巻：39号：4、2001年4月、頁68-74。 http://www.cs.duke.edu/ari/publications/end-system.{ps,pdf}。
[Ch96] H.K. Chu, "Zero-copy TCP in Solaris", Proc. of the USENIX 1996 Annual Technical Conference, San Diego, CA, January 1996.
[Ch96] H.K.チュー、 "SolarisのでゼロコピーTCP"、PROC。 USENIX 1996年次技術会議、サンディエゴ、CA、1996年1月の。
[Ch02] Jeffrey Chase, Personal communication.
[CH02]ジェフリー・チェイス、個人的なコミュニケーション。
[CJRS89] D. D. Clark, V. Jacobson, J. Romkey, H. Salwen, "An analysis of TCP processing overhead", IEEE Communications Magazine, volume: 27, Issue: 6, June 1989, pp 23-29.
【CJRS89] D. D.クラーク、V. Jacobsonの、J. Romkey、H. Salwen、 "TCP処理オーバーヘッドの解析"、IEEE通信雑誌、体積：27号：6、1989年6月、頁23-29。
[CT90] D. D. Clark, D. Tennenhouse, "Architectural considerations for a new generation of protocols", Proceedings of the ACM SIGCOMM Conference, 1990.
[CT90] D. D.クラーク、D. Tennenhouse、 "プロトコルの新しい世代のための建築の配慮"、ACM SIGCOMM会議、1990年の議事。
[DAPP93] P. Druschel, M. B. Abbott, M. A. Pagels, L. L. Peterson, "Network subsystem design", IEEE Network, July 1993, pp. 8-17.
【DAPP93] P. Druschel、M. B.アボット、M. A. Pagels、L. L. Petersonの、 "ネットワークサブシステムの設計"、IEEEネットワーク、1993年7月、頁8-17。
[DP93] P. Druschel, L. L. Peterson, "Fbufs: a high-bandwidth cross-domain transfer facility", Proceedings of the 14th ACM Symposium of Operating Systems Principles, December 1993.
[DP93] P. Druschel、L. L.ピーターソン、「Fbufs：高帯域幅のクロスドメインの転送機能」、オペレーティングシステムの原則、1993年12月の第14回ACMシンポジウム。
[DWB+93] C. Dalton, G. Watson, D. Banks, C. Calamvokis, A. Edwards, J. Lumley, "Afterburner: architectural support for high-performance protocols", Technical Report, HP Laboratories Bristol, HPL-93-46, July 1993.
[DWB + 93] C.ダルトン、G.ワトソン、D.銀行、C. Calamvokis、A.エドワーズ、J.ラムリー、 "アフターバーナー：高性能プロトコルのアーキテクチャサポート"、技術報告書、HP研究所ブリストル、HPL- 93から46まで、1993年7月。
[EBBV95] T. von Eicken, A. Basu, V. Buch, and W. Vogels, "U-Net: A user-level network interface for parallel and distributed computing", Proc. of the 15th ACM Symposium on Operating Systems Principles, Copper Mountain, Colorado, December 3-6, 1995.
【EBBV95] T.フォンEicken、A. Basuさん、V.ブーフ、及びW. VOGELS、 "Uネット：並列分散コンピューティングのためのユーザーレベルのネットワーク・インターフェース"、PROC。オペレーティングシステムの原理、カッパーマウンテン、コロラド州、12月3-6、1995年第15回ACMシンポジウムの。
[FDDI] International Standards Organization, "Fibre Distributed Data Interface", ISO/IEC 9314, committee drafts available from http://www.iso.org.
[FDDI]国際標準化機構、ISO / IEC 9314、http://www.iso.orgから入手委員会原案の "ファイバーは、データインタフェースを分散します"。
[FGM+99] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[FGM + 99]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、「ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[FIBRE] ANSI Technical Committee T10, "Fibre Channel Protocol (FCP)" (and as revised and updated), ANSI X3.269:1996 [R2001], committee draft available from http://www.t10.org/drafts.htm#FibreChannel
[FIBER] ANSI T10技術委員会、 "ファイバ・チャネル・プロトコル（FCP）"（改訂や更新など）、ANSI X3.269：1996 [R2001]、http://www.t10.org/draftsから入手委員会草案。 HTM番号のファイバチャネル
[HP97] J. L. Hennessy, D. A. Patterson, Computer Organization and Design, 2nd Edition, San Francisco: Morgan Kaufmann Publishers, 1997.
[HP97] J. L.ヘネシー、D. A.パターソン、コンピュータの構成と設計、第2版、サンフランシスコ：モルガン・カウフマン出版、1997。
[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification, Volumes 1 and 2", Release 1.1, November 2002, available from http://www.infinibandta.org/specs.
[IB]インフィニバンド展覧会、 "インフィニバンドアーキテクチャ仕様、ボリューム1及び2"、http://www.infinibandta.org/specsから入手1.1、2002年11月にリリース。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[KP96] J. Kay, J. Pasquale, "Profiling and reducing processing overheads in TCP/IP", IEEE/ACM Transactions on Networking, Vol 4, No. 6, pp.817-828, December 1996.
[KP96] J.ケイ、J.パスクアーレ、 "プロファイリングおよびTCP / IPの処理オーバヘッドを低減する"、ネットワーキング、第4巻、第6号、pp.817-828、1996年12月にIEEE / ACMトランザクション。
[KSZ95] K. Kleinpaste, P. Steenkiste, B. Zill, "Software support for outboard buffering and checksumming", SIGCOMM'95.
[KSZ95] K. Kleinpaste、P. Steenkiste、B. Zill、 "船外バッファリングとチェックサムのためのソフトウェアサポート"、SIGCOMM'95。
[Ma02] K. Magoutis, "Design and Implementation of a Direct Access File System (DAFS) Kernel Server for FreeBSD", in Proceedings of USENIX BSDCon 2002 Conference, San Francisco, CA, February 11-14, 2002.
USENIX BSDCon 2002会議、サンフランシスコ、CA、2月11-14、2002年の議事録で[MA02] K. Magoutis、 "ダイレクト・アクセス・ファイル・システムFreeBSD用（DAFS）カーネルサーバの設計と実装"、。
[MAF+02] K. Magoutis, S. Addetia, A. Fedorova, M. I. Seltzer, J. S. Chase, D. Gallatin, R. Kisley, R. Wickremesinghe, E. Gabber, "Structure and Performance of the Direct Access File System (DAFS)", in Proceedings of the 2002 USENIX Annual Technical Conference, Monterey, CA, June 9-14, 2002.
[MAF + 02] K. Magoutis、S. Addetia、A.フェドロワ、MIセルツァー、JSチェイス、D.ガラティン、R.キズリー、R. Wickremesinghe、E.多弁家、「構造とダイレクトアクセスファイルシステムのパフォーマンス（ DAFS）」、2002 USENIX年次技術会議議事録、モントレー、カリフォルニア州、6月9-14、2002インチ
[Mc95] J. D. McCalpin, "A Survey of memory bandwidth and machine balance in current high performance computers", IEEE TCCA Newsletter, December 1995.
[Mc95] J. D. McCalpin、「現在の高性能コンピュータのメモリ帯域幅とマシンバランスの調査」、IEEE TCCAニュースレター、1995年12月。
[PAC+97] D. Patterson, T. Anderson, N. Cardwell, R. Fromm, K. Keeton, C. Kozyrakis, R. Thomas, K. Yelick , "A case for intelligient RAM: IRAM", IEEE Micro, April 1997.
[PAC + 97] D.パターソン、T.アンダーソン、N.カードウェル、R.フロム、K.キートン、C. Kozyrakis、R.トーマス、K. Yelick、 "intelligient RAM用ケース：IRAM"、IEEEマイクロ、 1997年4月。
[PDZ99] V. S. Pai, P. Druschel, W. Zwaenepoel, "IO-Lite: a unified I/O buffering and caching system", Proc. of the 3rd Symposium on Operating Systems Design and Implementation, New Orleans, LA, February 1999.
[PDZ99] V. S.パイ、P. Druschel、W. Zwaenepoel、 "IO-Liteは：ユニファイドI / Oバッファリングとキャッシングシステム"、PROC。オペレーティングシステムの設計と実装、ニューオーリンズ、LA、1999年2月の第3回シンポジウム。
[Pi01] J. Pinkerton, "Winsock Direct: The Value of System Area Networks", May 2001, available from http://www.microsoft.com/windows2000/techinfo/ howitworks/communications/winsock.asp.
[PI01] J.ピンカートン、 "Winsockの直接：システムエリアネットワークの価値"、2001年5月、http://www.microsoft.com/windows2000/techinfo/ howitworks /通信/ winsock.aspから入手できます。
[Po81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
【Po81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[QUAD] Quadrics Ltd., Quadrics QSNet product information, available from http://www.quadrics.com/website/pages/02qsn.html.
[4]のQuadrics社、http://www.quadrics.com/website/pages/02qsn.htmlから市販のQuadrics QSNet製品情報、。
[SDP] InfiniBand Trade Association, "Sockets Direct Protocol v1.0", Annex A of InfiniBand Architecture Specification Volume 1, Release 1.1, November 2002, available from http://www.infinibandta.org/specs.
[SDP]インフィニバンド展覧会、「ソケット直接プロトコルv1.0を」、インフィニバンドアーキテクチャ仕様の第1巻の附属書A、1.1をリリース、2002年11月、http://www.infinibandta.org/specsから入手できます。
[SRVNET] R. Horst, "TNet: A reliable system area network", IEEE Micro, pp. 37-45, February 1995.
[SRVNET] R.ホルスト、 "Tネット：信頼性の高いシステム・エリア・ネットワーク"、IEEEマイクロ、頁37-45、1995年2月。
[STREAM] J. D. McAlpin, The STREAM Benchmark Reference Information, http://www.cs.virginia.edu/stream/.
[STREAM] J. D. McAlpin、STREAMベンチマーク基準情報、http://www.cs.virginia.edu/stream/。
[TK95] M. N. Thadani, Y. A. Khalidi, "An efficient zero-copy I/O framework for UNIX", Technical Report, SMLI TR-95-39, May 1995.
[TK95] M. N. Thadani、Y. A. Khalidi、 "UNIXのための効率的なゼロコピーI / Oフレームワーク"、技術報告書、SMLI TR-95から39まで、1995年5月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[VI] D. Cameron and G. Regnier, "The Virtual Interface Architecture", ISBN 0971288704, Intel Press, April 2002, more info at http://www.intel.com/intelpress/via/.
[VI] D.キャメロンとG.レニエ、 "仮想インターフェイスアーキテクチャ"、ISBN 0971288704、インテルプレス、2002年4月、http://www.intel.com/intelpress/via/の詳細情報。
[Wa97] J. R. Walsh, "DART: Fast application-level networking via data-copy avoidance", IEEE Network, July/August 1997, pp. 28-38.
[Wa97] J. R.ウォルシュ、 "DART：データコピー回避による高速アプリケーションレベルのネットワーキング"、IEEEネットワーク、1997年7月/ 8月、頁28-38。
Authors' Addresses
著者のアドレス
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA
スティーブン・ベイリーSandburst社600連邦ストリートアンドーバー、MA 01810 USA
Phone: +1 978 689 1614 EMail: steph@sandburst.com
電話：+1 978 689 1614 Eメール：steph@sandburst.com
Jeffrey C. Mogul HP Labs Hewlett-Packard Company 1501 Page Mill Road, MS 1117 Palo Alto, CA 94304 USA
ジェフリーC.モーグルHP Labsのヒューレット・パッカード社1501ページミルロード、MS 1117パロアルト、CA 94304 USA
Phone: +1 650 857 2206 (EMail preferred) EMail: JeffMogul@acm.org
電話：+1 650 857 2206（Eメール優先）メール：JeffMogul@acm.org
Allyn Romanow Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA
アリンRomanowシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 525 8836 EMail: allyn@cisco.com
電話：+1 408 525 8836 Eメール：allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA
トムTalpeyネットワーク・アプライアンス1601 Trapelo道路ウォルサム、MA 02451 USA
Phone: +1 781 768 5329 EMail: thomas.talpey@netapp.com
電話：+1 781 768 5329 Eメール：thomas.talpey@netapp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。