[要約] 要約：RFC 4297は、RDMA over IPの問題を説明し、解決策を提案するものです。 目的：RDMA over IPの問題を特定し、効果的な解決策を提供することで、ネットワーク上での高速なデータ転送を実現することを目指しています。
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
IP問題ステートメント上のリモートダイレクトメモリアクセス（RDMA）
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).
Copyright（c）The Internet Society（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 Bottleneck」と呼ばれます[CT90]。より具体的には、ここで興味深い高いオーバーヘッドのソースは、データの移動操作、つまりコピーです。したがって、システムのスループットは、このコピーのオーバーヘッドによって制限される場合があります。この問題は、ここでは対処されていないTCPオフロードと混同されるべきではありません。高速は、ホストCPUとメモリの帯域幅に比べて、ネットワークリンク速度が高い条件を指します。今日のコンピューターシステムを使用すると、1秒あたり1ギガビット（GBITS/s）以上が高速と見なされます。
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や小さなワークステーションなどの小型システムは、オーバーヘッドのコピーの減少から恩恵を受けるでしょうが、小規模なマシンの利点は、主にそれらが処理する帯域幅の量をスケーリングするため、主に今後数年間になります。今日では、帯域幅の高いフィード、通常はマルチプロセッサとクラスターを備えた大規模なシステムマシンであり、オーバーヘッドをコピーすることで悪影響を受けます。このようなマシンの例には、すべての品種のサーバーが含まれます。データベースサーバー、ストレージサーバー、トランザクション処理用のアプリケーションサーバー、eコマース、コンテンツ配信、ビデオ配信、バックアップ、データマイニングと意思決定サポート、科学的コンピューティング。
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.
このようなサーバーは、ほぼ排他的に多くの同時セッション（輸送接続）を使用しており、集計では1つ以上の通信を担当しています。それにもかかわらず、特定の負荷のオーバーヘッドをコピーするコストは、少数のセッションであれ多くのセッションであろうと同じです。
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 Bottleneck、およびデータ運動操作の役割は、過去14年間にわたって研究と産業で広く研究されており、これらの結果について自由に導き出します。歴史的に、I/Oボトルネックは、新しいネットワーキングテクノロジーがラインレートを大幅に増加させるたびに注目を集めています：100メガビットあたり100メガビット（MBITS/S）高速イーサネットおよびファイバー分散データインターフェイス[FDDI]、155 MBITS/S非同期転送モード[ATM]、1 gbits/sイーサネット。以前の速度遷移では、メモリ帯域幅の可用性により、I/O Bottleneckの問題を延期することができました。しかし、今ではこれはもはやそうではありません。I/Oの問題は1 GBITS/sで重要ですが、業界と研究における活動の急増を動機付けている10 GBITS/Sイーサネットの導入です[IB、VI、CGY01、MA02、MAF 02]。
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は、アプリケーションの制御下で、ネットワークアダプターがアプリケーションバッファーに直接データを操作できるようにする一連のメカニズムです。このような相互接続ファブリックの例には、ブロックストレージ転送用ファイバーチャネル[ファイバー]、データベースクラスター用の仮想インターフェイスアーキテクチャ[VI]、Infiniband [IB]、Compaq Servernet [srvnet]、およびQuadrics [Quad]がシステムエリアネットワークの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でBerkeley 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]で直線的にスケールを拡大するため、パケットサイズとともに増加します。たとえば、CHU [CH96]は、3つの異なるMTUサイズを持つネットワークを介したSparcStation/20ランニングメモリからメモリへのTCPテストの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つのDecstation 5000/200を使用しました。（この調査では、チェックサムは処理時間の30％を占めています。）
2.1. Copy avoidance improves processing overhead.
2.1. コピー回避により、オーバーヘッドの処理が改善されます。
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]のコピー回避の結果は、最適化されたWebサーバーで43％のスループット増加とApacheサーバーで137％の改善を示しています。このシステムは4.4BSD由来のUNIXカーネルに実装され、実験は、切り替えられた100 mbits/sの高速イーサネットに接続された333MHz Pentium 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]。これらの研究の1つの結果について詳細に説明し、コピー回避によって生成される大幅な改善を明確にします[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.
Chase et alによる最近の研究。[CGY01]は、CPU使用率を測定して、コピーを回避すると、アルファストゼーションXP1000およびミリネアダプター[BCF 95]を使用して、32 kbytes MTUで370 mbitesで24％から15％のデータアクセスに費やされた時間を短縮することが示されています。これは、コピーの回避による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使用率は35％で、データアクセスは24％を占めています。したがって、コピーを減らすことの相対的な重要性は26％です。370 mbits/sでは、システムはそれほど重度のロードではありません。達成可能な帯域幅の相対的な改善は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]では、チェックサムのオーバーヘッドを削除した後、コピー回避によりCPUの使用率が26％から10％に減少します。これは、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]）））
3. Memory bandwidth is the root cause of the problem.
3. メモリ帯域幅は問題の根本原因です。
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、ストリーム]に続くと予想されています。
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.
コピーがコピーごとに2回バスを渡ると、ネットワーク処理のオーバーヘッドは、CPUやメモリ帯域幅と比較してネットワーク帯域幅が大きい場合は高くなります。一般に、今日の最終システムでは、効果は1 GBITS/sを超えるネットワーク速度で観察可能です。実際、複数のバスの交差点を使用すると、バスの帯域幅がスループットの制限要因であることがわかります。これにより、このような最終システムが完全なネットワーク帯域幅と完全なアプリケーションのパフォーマンスを同時に達成することができなくなります。
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]。Hennessy [HP97]は、マイクロプロセッサのパフォーマンスが1980年から1998年に年間60％で増加し、ドラムへのアクセス時間は年間10％で改善され、「プロセッサメモリのパフォーマンスギャップ」が増加することを示しています。
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.
関連するデータのもう1つのソースは、ストリームベンチマーク[ストリーム]に関する情報を提供するStream Benchmark Reference Information Webサイトです。ベンチマークは、持続可能なメモリ帯域幅（MBYTES/s）と、MFLOPSで測定された単純なベクターカーネルの対応する計算レートを測定する単純な合成ベンチマークプログラムです。このWebサイトは、数百のマシンとすべての主要なベンダーの持続可能なメモリ帯域幅に関する情報を追跡しています。
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％のリードが、メモリ帯域幅に対するCPUの相対速度の尺度である別の統計、マシンバランス[MC95]に表示されます。ストリーム]。
Network bandwidth has been increasing about 10-fold roughly every 8 years, which is a 40% per year growth rate.
ネットワーク帯域幅は、約8年ごとに約10倍増加しており、これは年間40％の成長率です。
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.)
典型的な例は、メモリ帯域幅がリンク速度と不利に比較されることを示しています。ストリームベンチマークは、たとえば2001年の1.2 GHz Athlonなどの最新のユニプロセッサPCが、受信操作を行う際にデータを3回移動することを示しています。ネットワークインターフェイスがメモリにデータをデポジットし、CPUがコピーするために2回データ。1つのメモリ帯域幅の1つのgbyte/sを意味する1つの読み取りまたは1つの書き込みを意味すると、マシンは約2.67 GBITS/sのネットワーク帯域幅を処理できます。しかし、これは100％の利用率を想定していますが、これは不可能であり、さらに重要なことは、マシンが完全に消費されることです！（データベースの経験則では、マシンの20％がI/Oをサービスを提供し、データベースアプリケーションに80％を残す必要があることです。
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つのgbits/sリンクが一般的でした。アプリケーションサーバーには、通常、2つの1つのGBITS/s接続があります。1つの接続バックエンドとストレージサーバーへのバックエンドと1つのフロントエンドは、HTTP [FGM 99]を提供する場合です。したがって、通信は2 Gbits/sを使用できます。典型的な例では、マシンは理論的な最大値で2.7 GBITS/sを処理でき、他に何もしません。これは、マシンが基本的に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]。さらに、現在、オーバーヘッドのコピーに苦しむアプリケーションは、インターネットコンピューティングの中心にあります。インターネットと企業の情報を保存、管理、配布しています。これらには、トランザクション処理、eコマース、Webサービング、意思決定サポート、コンテンツ配信、ビデオ配布、バックアップを行うデータベースアプリケーションが含まれます。クラスターは通常、このカテゴリのアプリケーションに使用されます。これは、可用性とスケーラビリティの利点があるためです。
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つの論理層に編成されたデータセンターで実行されます。1つの層は、通常、WANに接続するWebサーバーのセットです。2番目の層は、通常、より強力なマシンで特定のアプリケーションを実行するアプリケーションサーバーのセットであり、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の処理能力を最大化するという高い動機があります。たとえば、マルチプロセッサにCPUSを追加すると、メモリバスに追加の帯域幅がある場合にのみパフォーマンスが向上するため、必ずしも役立ちません。クラスタリングは、アプリケーションの処理に追加の複雑さを追加できます。
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.
コピー回避は、バスの帯域幅負荷の少なくとも3分の2を「最高の」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つのサーバーはApache、もう1つはFlashと呼ばれる最適化されたサーバーで、3つ目はIO-Liteを実行しているFlashサーバーで、ゼロコピーを備えたFlash-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.
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.
他のオペレーティングシステムの処理コストの改善に加えて、多くの場合、データの移動を排除するための2つの主要な代替アプローチを備えた2つの主要な代替アプローチを備えた広範な調査調査と業界の経験があります。1つのアプローチでは、単一のホスト内のハードウェアおよび/またはソフトウェアの変更が処理コストを削減します。別のアプローチであるメモリ間ネットワーキング[MAF 02]では、ホスト間で明示的なデータ配置情報を交換することで、処理コストを削減できます。
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.
以下で説明するように、研究と業界の経験は、受信機処理パス内のコピー回避技術だけで問題があることが証明されていることが示されています。Research Special目的のホストアダプターシステムは良好なパフォーマンスを備えており、市販の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].
初期の作業では、ソフトウェアのアプローチの目標の1つは、適切なOSサポートでTCPがより速く進むことができることを示すことでした[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 Zero-Copy 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]、Hamlyn [BJM 96]、Infiniband [Ib]、Winsock Direct [PI01]が含まれます。いくつかのメモリ間システムが広く使用されており、一般に堅牢であり、パフォーマンスが良好であり、実装が比較的簡単であることがわかっています。これらには、VI [VI]、MyRinet [BCF 95]、Quadrics [Quad]、Compaq/Tandem 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].
「ワイヤー全体」の直接メモリアクセスをエクスポートすることにより、アプリケーションはネットワークスタックにすべてのデータをアプリケーションバッファーから直接管理することができます。このようなアプリケーションの機能を活用する大規模で成長しているクラスは、すでに登場しています。これには、すべての主要なデータベースと、Sockets Direct [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.
RDMAソリューションは、「ダイレクトデータ配置（DDP）」と「リモートダイレクトメモリアクセス（RDMA）セマンティクス」という2つの異なるコンポーネントで構成されていると有用に見ることができます。それらは目的が明確であり、実際には、個別のプロトコルとして実装される場合があります。
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」と呼ばれています。直接データ配置の施設は、それ自体が有用であり、データ転送を容易にするために他の上層層プロトコルで採用される場合があります。したがって、DDPをデータプレースメント機能として、RDMAを制御の側面として参照することがしばしば役立ちます。
[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]
Infiniband（IB）RDMAインターフェイス、プロトコルスイート、およびリンク層の仕様は、業界貿易協会によって定義されています。[Ib]
Jeff Chase generously provided many useful insights and information. Thanks to Jim Pinkerton for many helpful discussions.
ジェフ・チェイスは、多くの有用な洞察と情報をgeneしみなく提供しました。多くの有益な議論をしてくれたジム・ピンカートンに感謝します。
[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. Boden、D。Cohen、R。E。Felderman、A。E。Kulawik、C。L。Seitz、J。N。Seizovic、およびW. Su。「Myrinet-ギガビットあたり1秒のローカルエリアネットワーク」、IEEE Micro、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. Buzzard、D。Jacobson、M。Mackey、S。Marovich、J。Wilkes、「Hamlyn Send管理インターフェイスアーキテクチャの実装」、オペレーティングシステムの設計と実装に関する2回目のシンポジウムの議事録、Usenix Assoc。、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] M. A. Blumrich、K。Li、R。Alpert、C。Dubnicki、E。W。Felten、「エビマルチコンピューター向けの仮想メモリマッピングネットワークインターフェイス」、1994年4月、コンピューターアーキテクチャに関する第21回年次シンポジウムの議事録、。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、「ネットワークおよびファイルI/Oにおけるコピー回避の相互操作」、IEEE Infocomの議事録、1999年、pp。534-542。
[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、「I/Oパフォーマンスに対するセマンティクスのバッファリングの影響」、Proceedings OSDI'96、USENIX、シアトル、ワシントン州1996年10月、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] Bailey、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] C-H Chang、D。Flower、J。Forecast、H。Gray、B。Hawe、A。Nadkarni、K。K。Ramakrishnan、U。Shikarpur、K。Wilde、 "高性能TCP/IPおよびUDP/IPネットワークAlpha Axpの12月1日/1では、1994年8月、36-42ページ、高性能分散コンピューティングに関する第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. Chase、A。J。Gallatin、およびK. G. Yocum、「高速TCPの最終システムの最適化」、IEEE Communications Magazine、Volume：39、Issue：4、4月、pp 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.Chu、「SolarisのゼロコピーTCP」、Proc。1996年1月、カリフォルニア州サンディエゴのUsenix 1996年次技術会議。
[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。ジェイコブソン、J。ロムキー、H。サルウェン、「TCP処理オーバーヘッドの分析」、IEEE Communications Magazine、Volume：27、Issue：6、June 1989、pp 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. Clark、D。Tennenhouse、「新世代のプロトコルに対する建築上の考慮事項」、ACM Sigcomm Conferenceの議事録、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。Abbott、M。A。Pagels、L。L。Peterson、「ネットワークサブシステム設計」、IEEEネットワーク、1993年7月、pp。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。Peterson、「FBUFS：A High BandWidth Cross Domain Transfer Facility」、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. Dalton、G。Watson、D。Banks、C。Calamvokis、A。Edwards、J。Lumley、「Afterburner：高性能プロトコルの建築サポート」、テクニカルレポート、HP研究所Bristol、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. Von Eicken、A。Basu、V。Buch、およびW. Vogels、「u-net：並列および分散コンピューティング用のユーザーレベルのネットワークインターフェイス」、Proc。1995年12月3〜6日、コロラド州カッパーマウンテンのオペレーティングシステム原則に関する第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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "Hypertext Transfer Protocol-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
[ファイバー] ANSIテクニカル委員会T10、「ファイバーチャネルプロトコル（FCP）」（および改訂および更新）、ANSI X3.269：1996 [R2001]、http://www.t10.org/draftsから入手可能。HTM＃FibreChannel
[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版、サンフランシスコ：Morgan Kaufmann Publishers、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] Infiniband Trade Association、「Infiniband Architecture Specification、Volumes 1および2」、リリース1.1、2002年11月、http：//www.infinibandta.org/specsから入手可能。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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. Kay、J。Pasquale、「TCP/IPでのオーバーヘッドのプロファイリングと削減」、NetworkingのIEEE/ACMトランザクション、Vol 4、No。6、pp.817-828、1996年12月。
[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.
[MA02] K. Magoutis、「FreeBSD用の直接アクセスファイルシステム（DAFS）カーネルサーバーの設計と実装」、Usenix BSDCON 2002会議の議事録、カリフォルニア州サンフランシスコ、2002年2月11〜14日。
[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。Fedorova、M。I。Seltzer、J。S。Chase、D。Gallatin、R。Kisley、R。Wickremesinghe、E。Gabber、 "直接アクセスファイルシステムの構造とパフォーマンス）」、2002年6月9〜14日、カリフォルニア州モントレーの2002年のUSENIX年次技術会議の議事録。
[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. Patterson、T。Anderson、N。Cardwell、R。Fromm、K。Keeton、C。Kozyrakis、R。Thomas、K。Yelick、「Intelligient RAM：IRAMのケース」、IEEE Micro、4月1997年。
[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. Pai、P。Druschel、W。Zwaenepoel、「Io-Lite：統一されたI/Oバッファリングおよびキャッシュシステム」、Proc。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 Direct：The Value of System Area Networks」、2001年5月、http：//www.microsoft.com/windows2000/techinfo/ howitworks/communications/winsock.aspから入手可能。
[Po81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[PO81] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[QUAD] Quadrics Ltd., Quadrics QSNet product information, available from http://www.quadrics.com/website/pages/02qsn.html.
[Quad] Quadrics Ltd.、Quadrics QSNet製品情報、http：//www.quadrics.com/website/pages/02qsn.htmlから入手可能。
[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] Infiniband Trade Association、「Sockets Direct Protocol V1.0」、Infiniband Architecture Specification Volume 1、Release 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. Horst、「TNET：信頼できるシステムエリアネットワーク」、IEEE Micro、pp。37-45、1995年2月。
[STREAM] J. D. McAlpin, The STREAM Benchmark Reference Information, http://www.cs.virginia.edu/stream/.
[Stream] J. D. McAlpin、The Stream Benchmark Reference Information、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] Dierks、T。およびC. Allen、「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. Cameron and G. Regnier、「Virtual Interface Architecture」、ISBN 0971288704、Intel Press、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. Walsh、「DART：データコピー回避による高速アプリケーションレベルのネットワーク」、IEEEネットワーク、1997年7月/8月、28-38ページ。
Authors' Addresses
著者のアドレス
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA
Stephen Bailey Sandburst Corporation 600 Federal Street Andover、MA 01810 USA
Phone: +1 978 689 1614
EMail: steph@sandburst.com
Jeffrey C. Mogul HP Labs Hewlett-Packard Company 1501 Page Mill Road, MS 1117 Palo Alto, CA 94304 USA
Jeffrey C. Mogul HP Labs Hewlett-Packard Company 1501 Page Mill Road、MS 1117 Palo Alto、CA 94304 USA
Phone: +1 650 857 2206 (EMail preferred)
EMail: JeffMogul@acm.org
Allyn Romanow Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA
Allyn Romanow Cisco Systems、Inc。170 W. Tasman Drive San Jose、CA 95134 USA
Phone: +1 408 525 8836
EMail: allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA
Tom Talpey Networkアプライアンス1601 Trapelo Road Waltham、MA 02451 USA
Phone: +1 781 768 5329
EMail: thomas.talpey@netapp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。