RFC5040 日本語訳
5040 A Remote Direct Memory Access Protocol Specification. R. Recio,B. Metzler, P. Culley, J. Hilland, D. Garcia. October 2007. (Format: TXT=142247 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Recio
Request for Comments: 5040 B. Metzler
Category: Standards Track IBM Corporation
P. Culley
J. Hilland
Hewlett-Packard Company
D. Garcia
October 2007
Recioがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5040年のB.メツラーカテゴリ: 標準化過程IBM社のP.Culley J.Hillandヒューレット・パッカード会社D.ガルシア2007年10月
A Remote Direct Memory Access Protocol Specification
リモートダイレクトメモリアクセスプロトコル仕様
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation.
このドキュメントはDirect Data Placementプロトコル(DDPプロトコル)の上で作動するRemote Direct Memory Accessプロトコル(RDMAP)を定義します。 RDMAPは、読まれて、前提として、直接アプリケーションに対するサービスを書いて、データが中間的データコピーなしでUpper Layerプロトコル(ULP)バッファの直接中に移されるのを可能にします。 また、それはカーネル迂回実装を可能にします。
Recio, et al. Standards Track [Page 1] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[1ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Architectural Goals ........................................4
1.2. Protocol Overview ..........................................5
1.3. RDMAP Layering .............................................7
2. Glossary ........................................................8
2.1. General ....................................................8
2.2. LLP .......................................................10
2.3. Direct Data Placement (DDP) ...............................11
2.4. Remote Direct Memory Access (RDMA) ........................13
3. ULP and Transport Attributes ...................................15
3.1. Transport Requirements and Assumptions ....................15
3.2. RDMAP Interactions with the ULP ...........................16
4. Header Format ..................................................19
4.1. RDMAP Control and Invalidate STag Field ...................20
4.2. RDMA Message Definitions ..................................23
4.3. RDMA Write Header .........................................24
4.4. RDMA Read Request Header ..................................24
4.5. RDMA Read Response Header .................................26
4.6. Send Header and Send with Solicited Event Header ..........26
4.7. Send with Invalidate Header and Send with SE and
Invalidate Header .........................................26
4.8. Terminate Header ..........................................26
5. Data Transfer ..................................................32
5.1. RDMA Write Message ........................................32
5.2. RDMA Read Operation .......................................33
5.2.1. RDMA Read Request Message ..........................33
5.2.2. RDMA Read Response Message .........................35
5.3. Send Message Type .........................................36
5.4. Terminate Message .........................................37
5.5. Ordering and Completions ..................................38
6. RDMAP Stream Management ........................................41
6.1. Stream Initialization .....................................41
6.2. Stream Teardown ...........................................42
6.2.1. RDMAP Abortive Termination .........................43
7. RDMAP Error Management .........................................43
7.1. RDMAP Error Surfacing .....................................44
7.2. Errors Detected at the Remote Peer on Incoming
RDMA Messages .............................................45
8. Security Considerations ........................................46
8.1. Summary of RDMAP-Specific Security Requirements ...........46
8.1.1. RDMAP (RNIC) Requirements ..........................47
8.1.2. Privileged Resource Manager Requirements ...........48
8.2. Security Services for RDMAP ...............................49
8.2.1. Available Security Services ........................49
8.2.2. Requirements for IPsec Services for RDMAP ..........50
9. IANA Considerations ............................................51
1. 序論…4 1.1. 建築目標…4 1.2. 概要について議定書の中で述べてください…5 1.3. RDMAPレイヤリング…7 2. 用語集…8 2.1. 一般…8 2.2. LLP…10 2.3. データプレースメント(DDP)を指示してください…11 2.4. リモートダイレクトメモリアクセス(RDMA)…13 3. ULPと輸送属性…15 3.1. 要件と仮定を輸送してください…15 3.2. ULPとのRDMAP相互作用…16 4. ヘッダー形式…19 4.1. RDMAPは男一人で分野を制御して、無効にします…20 4.2. RDMAメッセージ定義…23 4.3. RDMAはヘッダーに書きます…24 4.4. RDMAは要求ヘッダーを読みます…24 4.5. RDMAは応答ヘッダを読みます…26 4.6. ヘッダーを送ってください、そして、請求されたイベントヘッダーと共に発信してください…26 4.7. 発信する、ヘッダーを無効にしてください、そして、SEと共に発信してください、そして、ヘッダーを無効にしてください…26 4.8. ヘッダーを終えてください…26 5. データ転送…32 5.1. RDMAはメッセージを書きます…32 5.2. RDMAは操作を読みます…33 5.2.1. RDMAは要求メッセージを読みます…33 5.2.2. RDMAは応答メッセージを読みます…35 5.3. メッセージタイプを送ってください…36 5.4. メッセージを終えてください…37 5.5. 注文と落成…38 6. RDMAPは管理を流します…41 6.1. 初期設定を流してください…41 6.2. 分解を流してください…42 6.2.1. RDMAPの不成功の終了…43 7. RDMAP誤り管理…43 7.1. RDMAP誤り表面化…44 7.2. リモートに検出された誤りは入って来るRDMAメッセージをじっと見ます…45 8. セキュリティ問題…46 8.1. RDMAP特有のセキュリティ要件の概要…46 8.1.1. RDMAP(RNIC)要件…47 8.1.2. 特権がある資源管理プログラム要件…48 8.2. RDMAPのためのセキュリティサービス…49 8.2.1. 利用可能なセキュリティー・サービス…49 8.2.2. RDMAPのためのIPsecサービスのための要件…50 9. IANA問題…51
Recio, et al. Standards Track [Page 2] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[2ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
10. References ....................................................52
10.1. Normative References .....................................52
10.2. Informative References ...................................53
Appendix A. DDP Segment Formats for RDMA Messages .................54
A.1. DDP Segment for RDMA Write ................................54
A.2. DDP Segment for RDMA Read Request .........................55
A.3. DDP Segment for RDMA Read Response ........................56
A.4. DDP Segment for Send and Send with Solicited Event ........56
A.5. DDP Segment for Send with Invalidate and Send with SE and
Invalidate ................................................57
A.6. DDP Segment for Terminate .................................58
Appendix B. Ordering and Completion Table .........................59
Appendix C. Contributors ..........................................61
10. 参照…52 10.1. 標準の参照…52 10.2. 有益な参照…53付録A.DDPセグメントはRDMAのためにメッセージをフォーマットします…54 A.1。 RDMAのためのDDPセグメントは書きます…54 A.2。 RDMAのためのDDPセグメントは要求を読みました…55 A.3。 RDMAのためのDDPセグメントは応答を読みました…56 A.4。 DDPセグメント、発信してください、そして、請求されたイベントと共に発信してください…56 A.5。 DDPセグメント、発信する、…を無効にして、SEと共に送って、無効にしてください…57 A.6。 DDPセグメント、終わってください…58 注文と完成が見送る付録B.…59 付録C.貢献者…61
Table of Figures
数値表
Figure 1: RDMAP Layering ...........................................7
Figure 2: Example of MPA, DDP, and RDMAP Header Alignment over TCP .8
Figure 3: DDP Control, RDMAP Control, and Invalidate STag Fields ..20
Figure 4: RDMA Usage of DDP Fields ................................22
Figure 5: RDMA Message Definitions ................................23
Figure 6: RDMA Read Request Header Format .........................24
Figure 7: Terminate Header Format .................................27
Figure 8: Terminate Control Field .................................27
Figure 9: Terminate Control Field Values ..........................29
Figure 10: Error Type to RDMA Message Mapping .....................32
Figure 11: RDMA Write, DDP Segment Format .........................54
Figure 12: RDMA Read Request, DDP Segment Format ..................55
Figure 13: RDMA Read Response, DDP Segment Format .................56
Figure 14: Send and Send with Solicited Event, DDP Segment Format .56
Figure 15: Send with Invalidate and Send with SE and Invalidate,
DDP Segment Format .....................................57
Figure 16: Terminate, DDP Segment Format ..........................58
Figure 17: Operation Ordering .....................................59
図1: RDMAPレイヤリング…7 図2: MPA、DDP、およびTCP.8数値3の上のRDMAPヘッダー整列に関する例: DDPが制御されて、RDMAPは男一人で分野を制御して、無効にします。20 図4: DDP分野のRDMA用法…22 図5: RDMAメッセージ定義…23 図6: RDMAは要求ヘッダー形式を読みます…24 図7: ヘッダー形式を終えてください…27エイト環: 制御フィールドを終えてください…27 図9: 制御フィールド値を終えてください…29 図10: RDMAメッセージマッピングへの誤りタイプ…32 図11: RDMAは書いて、DDPはセグメント形式です…54 図12: RDMAは要求、DDPセグメント形式を読みます…55 図13: RDMAは応答、DDPセグメント形式を読みます…56 図14: 請求されたイベント、DDPセグメント形式.56と共に図15を送って、送ってください: 発信する、無効にして、SEと共に送って、無効にする、DDPは形式を区分します… …57 図16: 終わってください、そして、DDPは形式を区分します…58 図17: 操作注文…59
Recio, et al. Standards Track [Page 3] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[3ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
1. Introduction
1. 序論
Today, communications over TCP/IP typically require copy operations, which add latency and consume significant CPU and memory resources. The Remote Direct Memory Access Protocol (RDMAP) enables removal of data copy operations and enables reduction in latencies by allowing a local application to read or write data on a remote computer's memory with minimal demands on memory bus bandwidth and CPU processing overhead, while preserving memory protection semantics.
今日、TCP/IPの上のコミュニケーションは、コピー操作を通常必要として、重要なCPUとメモリリソースを消費します。(操作は潜在を加えます)。 メモリプロテクション意味論を保存している間、局所塗布がリモート・コンピュータのメモリに関するデータを読むか、または最小量の要求はメモリバス帯域幅とCPU処理オーバヘッドにある状態で書くのを許容することによって、Remote Direct Memory Accessプロトコル(RDMAP)は、データコピー操作の取り外しを可能にして、潜在の減少を可能にします。
RDMAP is layered on top of Direct Data Placement (DDP) and uses the two buffer models available from DDP. DDP-related terminology is discussed in Section 2.3. As RDMAP builds on DDP, the reader is advised to become familiar with [DDP].
RDMAPはDirect Data Placement(DDP)の上で層にされて、DDPから手があいている2つのバッファモデルを使用します。 セクション2.3でDDP関連の用語について議論します。 RDMAPがDDPに建てるとき、読者が[DDP]になじみ深くなるようにアドバイスされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Architectural Goals
1.1. 建築目標
RDMAP has been designed with the following high-level architectural goals:
RDMAPは以下のハイレベルの建築目標で設計されています:
* Provide a data transfer operation that allows a Local Peer to
transfer up to 2^32 - 1 octets directly into a previously
Advertised Buffer (i.e., Tagged Buffer) located at a Remote Peer
without requiring a copy operation. This is referred to as the
RDMA Write data transfer operation.
* Local PeerがRemote Peerでコピー操作を必要としないで1最大2^32--八重奏を直接aに以前にAdvertised Buffer(すなわち、Tagged Buffer)位置していた状態で移すことができるデータ転送操作を提供してください。 これはRDMA Writeデータ転送操作と呼ばれます。
* Provide a data transfer operation that allows a Local Peer to
retrieve up to 2^32 - 1 octets directly from a previously
Advertised Buffer (i.e., Tagged Buffer) located at a Remote Peer
without requiring a copy operation. This is referred to as the
RDMA Read data transfer operation.
* コピー操作を必要としないで、Remote Peerで1 32--八重奏を直接aからLocal Peerが最大2^を検索できるデータ転送操作に以前にAdvertised Buffer(すなわち、Tagged Buffer)位置していた状態で提供してください。 これはRDMA Readデータ転送操作と呼ばれます。
* Provide a data transfer operation that allows a Local Peer to send
up to 2^32 - 1 octets directly into a buffer located at a Remote
Peer that has not been explicitly Advertised. This is referred to
as the Send (Send with Invalidate, Send with Solicited Event, and
Send with Solicited Event and Invalidate) data transfer operation.
* Local Peerが明らかにそうでないRemote Peerに位置するバッファの直接中に1 32--八重奏を最大2^に送ることができるデータ転送操作にAdvertisedを提供してください。 これが呼ばれる、Send、(Invalidateと共に発信してください、Solicited EventとSend、およびSolicited EventとInvalidate) データ転送操作があるSend。
* Enable the local ULP to use the Send Operation Type (includes
Send, Send with Invalidate, Send with Solicited Event, and Send
with Solicited Event and Invalidate) to signal to the remote ULP
the Completion of all previous Messages initiated by the local
ULP.
* 地方のULPが前のすべてのMessagesのCompletionが地方のULPで開始したリモートULPに合図するのに、Send Operation Type(Send、InvalidateとSend、Solicited EventとSend、およびSolicited EventとInvalidateとSendを含んでいる)を使用するのを可能にしてください。
Recio, et al. Standards Track [Page 4] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[4ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* Provide for all operations on a single RDMAP Stream to be reliably
transmitted in the order that they were submitted.
* オーダーで確かに伝えられるべき独身のRDMAP Streamでそれらを提出したのをすべての操作に前提としてください。
* Provide RDMAP capabilities independently for each Stream when the
LLP supports multiple data Streams within an LLP connection.
* LLPが、LLP接続の中で複数のデータがStreamsであるとサポートしたら、各Streamのために独自に能力をRDMAPに供給してください。
1.2. Protocol Overview
1.2. プロトコル概要
RDMAP provides seven data transfer operations. Except for the RDMA Read operation, each operation generates exactly one RDMA Message. Following is a brief overview of the RDMA Operations and RDMA Messages:
RDMAPは7つのデータ転送操作を提供します。 RDMA Read操作を除いて、各操作はちょうど1RDMA Messageを生成します。 以下に、RDMA OperationsとRDMA Messagesの簡潔な概要があります:
1. Send - A Send operation uses a Send Message to transfer data from
the Data Source into a buffer that has not been explicitly
Advertised by the Data Sink. The Send Message uses the DDP
Untagged Buffer Model to transfer the ULP Message into the Data
Sink's Untagged Buffer.
1. 発信してください--Send操作は、データをData Sourceから明らかにそうでないバッファの中に移すのにSend Messageを使用します。Data SinkによるAdvertised。 Send Messageは、Data SinkのUntagged BufferにULP Messageを移すのにDDP Untagged Buffer Modelを使用します。
2. Send with Invalidate - A Send with Invalidate operation uses a
Send with Invalidate Message to transfer data from the Data
Source into a buffer that has not been explicitly Advertised by
the Data Sink. The Send with Invalidate Message includes all
functionality of the Send Message, with one addition: an STag
field is included in the Send with Invalidate Message. After the
message has been Placed and Delivered at the Data Sink, the
Remote Peer's buffer identified by the STag can no longer be
accessed remotely until the Remote Peer's ULP re-enables access
and Advertises the buffer.
2. Invalidateと共に発信してください--Invalidate操作があるSendは、データをData Sourceから明らかにそうでないバッファの中に移すのにInvalidate MessageとSendを使用します。Data SinkによるAdvertised。 Invalidate MessageとSendは1つの追加でSend Messageのすべての機能性を含んでいます: STag分野はInvalidate Messageと共にSendに含まれています。 メッセージがData SinkでPlacedとDeliveredになった後に、Remote PeerのULPがアクセスを再可能にするまで、もうSTagによって特定されたRemote Peerのバッファに離れてアクセスできません、そして、バッファはAdvertisesがアクセスされます。
3. Send with Solicited Event (Send with SE) - A Send with Solicited
Event operation uses a Send with Solicited Event Message to
transfer data from the Data Source into an Untagged Buffer at the
Data Sink. The Send with Solicited Event Message is similar to
the Send Message, with one addition: when the Send with Solicited
Event Message has been Placed and Delivered, an Event may be
generated at the recipient, if the recipient is configured to
generate such an Event.
3. Solicited Eventと共に発信してください(SEと共に発信してください)--Solicited Event操作があるSendは、データをData SourceからData SinkのUntagged Bufferに移すのにSolicited Event MessageとSendを使用します。 Solicited Event MessageとSendは1つの追加についてSend Messageと同様です: Solicited Event MessageとSendがPlacedとDeliveredであるときに、Eventは受取人で生成されるかもしれません、受取人がそのようなEventを生成するために構成されるなら。
4. Send with Solicited Event and Invalidate (Send with SE and
Invalidate) - A Send with Solicited Event and Invalidate
operation uses a Send with Solicited Event and Invalidate Message
to transfer data from the Data Source into a buffer that has not
been explicitly Advertised by the Data Sink. The Send with
Solicited Event and Invalidate Message is similar to the Send
with Invalidate Message, with one addition: when the Send with
4. Solicited EventとInvalidateと共に発信してください(SEとInvalidateと共に発信してください)--Solicited EventとSendとInvalidate操作は、データをData Sourceから明らかにそうでないバッファの中に移すのにSolicited EventとInvalidate MessageとSendを使用します。Data SinkによるAdvertised。 Solicited EventとInvalidate MessageとSendはInvalidate Message、1つの追加についてSendと同様です: Sendです。
Recio, et al. Standards Track [Page 5] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[5ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Solicited Event and Invalidate Message has been Placed and
Delivered, an Event may be generated at the recipient, if the
recipient is configured to generate such an Event.
請求されたEventとInvalidate MessageがPlacedとDeliveredである、Eventは受取人で生成されるかもしれません、受取人がそのようなEventを生成するために構成されるなら。
5. Remote Direct Memory Access Write - An RDMA Write operation uses
an RDMA Write Message to transfer data from the Data Source to a
previously Advertised Buffer at the Data Sink.
5. リモートDirect Memory Access Write--、RDMA Write操作がData Sourceからのデータを移すのにRDMA Write Messageを使用する、以前に、Advertised Buffer、Data Sinkで。
The ULP at the Remote Peer, which in this case is the Data Sink,
enables the Data Sink Tagged Buffer for access and Advertises the
buffer's size (length), location (Tagged Offset), and Steering
Tag (STag) to the Data Source through a ULP-specific mechanism.
The ULP at the Local Peer, which in this case is the Data Source,
initiates the RDMA Write operation. The RDMA Write Message uses
the DDP Tagged Buffer Model to transfer the ULP Message into the
Data Sink's Tagged Buffer. Note: the STag associated with the
Tagged Buffer remains valid until the ULP at the Remote Peer
invalidates it or the ULP at the Local Peer invalidates it
through a Send with Invalidate or Send with Solicited Event and
Invalidate.
Remote PeerのULPはアクセス、バッファのサイズのAdvertises(長さ)、位置(タグ付けをされたOffset)、およびSteering Tag(STag)のためにULP特有のメカニズムを通してData Sink Tagged BufferをData Sourceに有効にします。(この場合、Remote PeerはData Sinkです)。 Local PeerのULPはRDMA Write操作を開始します。(この場合、Local PeerはData Sourceです)。 RDMA Write Messageは、Data SinkのTagged BufferにULP Messageを移すのにDDP Tagged Buffer Modelを使用します。 以下に注意してください。 Remote PeerのULPがそれを無効にするか、またはLocal PeerのULPがInvalidateかSendと共にSendを通してSolicited EventとInvalidateでそれを無効にするまで、Tagged Bufferに関連しているSTagは有効なままで残っています。
6. Remote Direct Memory Access Read - The RDMA Read operation
transfers data to a Tagged Buffer at the Local Peer, which in
this case is the Data Sink, from a Tagged Buffer at the Remote
Peer, which in this case is the Data Source. The ULP at the Data
Source enables the Data Source Tagged Buffer for access and
Advertises the buffer's size (length), location (Tagged Offset),
and Steering Tag (STag) to the Data Sink through a ULP-specific
mechanism. The ULP at the Data Sink enables the Data Sink Tagged
Buffer for access and initiates the RDMA Read operation. The
RDMA Read operation consists of a single RDMA Read Request
Message and a single RDMA Read Response Message, and the latter
may be segmented into multiple DDP Segments.
6. リモートDirect Memory Access Read--RDMA Read操作はLocal PeerのTagged Bufferにデータを移します、Remote PeerのTagged Bufferから。この場合、Local PeerはData Sinkです。(この場合、Remote PeerはData Sourceです)。 Data SourceのULPはアクセス、バッファのサイズのAdvertises(長さ)、位置(タグ付けをされたOffset)、およびSteering Tag(STag)のためにULP特有のメカニズムを通してData Source Tagged BufferをData Sinkに有効にします。 Data SinkのULPはアクセスのためにData Sink Tagged Bufferを有効にして、RDMA Read操作を開始します。 RDMA Read操作は独身のRDMA Read Request Messageと独身のRDMA Read Response Messageから成ります、そして、後者は複数のDDP Segmentsに区分されるかもしれません。
The RDMA Read Request Message uses the DDP Untagged Buffer Model
to Deliver the STag, starting Tagged Offset, and length for both
the Data Source and Data Sink Tagged Buffers to the Remote Peer's
RDMA Read Request Queue.
RDMA Read Request MessageはDeliver STagにDDP Untagged Buffer Modelを使用します、Data SourceとData Sink Tagged Buffersの両方のためにRemote PeerのRDMA Read Request QueueにTagged Offset、および長さを始動して。
The RDMA Read Response Message uses the DDP Tagged Buffer Model
to Deliver the Data Source's Tagged Buffer to the Data Sink,
without any involvement from the ULP at the Data Source.
RDMA Read Response MessageはDDP Tagged Buffer ModelをDeliverに使用します。Data SourceのULPからの少しもかかわり合いのないData SinkへのData SourceのTagged Buffer。
Note: the Data Source STag associated with the Tagged Buffer
remains valid until the ULP at the Data Source invalidates it or
the ULP at the Data Sink invalidates it through a Send with
以下に注意してください。 Data SourceのULPがそれを無効にするか、またはData SinkのULPがSendを通してそれを無効にするまで、Tagged Bufferに関連しているData Source STagは有効なままで残っています。
Recio, et al. Standards Track [Page 6] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[6ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Invalidate or Send with Solicited Event and Invalidate. The Data
Sink STag associated with the Tagged Buffer remains valid until
the ULP at the Data Sink invalidates it.
無効にするか、請求されたイベントと共に送って、または無効にします。 Data SinkのULPがそれを無効にするまで、Tagged Bufferに関連しているData Sink STagは有効なままで残っています。
7. Terminate - A Terminate operation uses a Terminate Message to
transfer to the Remote Peer information associated with an error
that occurred at the Local Peer. The Terminate Message uses the
DDP Untagged Buffer Model to transfer the Message into the Data
Sink's Untagged Buffer.
7. 終わってください--Terminate操作は、Local Peerに発生した誤りに関連しているRemote Peer情報に移すのにTerminate Messageを使用します。 Terminate Messageは、Data SinkのUntagged BufferにMessageを移すのにDDP Untagged Buffer Modelを使用します。
1.3. RDMAP Layering
1.3. RDMAPレイヤリング
RDMAP is dependent on DDP, subject to the requirements defined in Section 3.1, "Transport Requirements and Assumptions". Figure 1, "RDMAP Layering", depicts the relationship between Upper Layer Protocols (ULPs), RDMAP, DDP protocol, the framing layer, and the transport. For LLP protocol definitions of each LLP, see [MPA], [TCP], and [SCTP].
RDMAPはセクション3.1と、「輸送要件と仮定」で定義された要件を条件としたDDPに依存しています。 「RDMAPレイヤリング」という図1はUpper Layerプロトコル(ULPs)と、RDMAPと、DDPプロトコルと、縁どり層と、輸送との関係について表現します。 それぞれのLLPのLLPプロトコル定義に関しては、[MPA]、[TCP]、および[SCTP]を見てください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Upper Layer Protocol (ULP) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RDMAP |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DDP protocol |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MPA | |
| | |
+-+-+-+-+-+-+-+-+-+ SCTP |
| | |
| TCP | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 上側の層のプロトコル(ULP)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RDMAP| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DDPプロトコル| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | MPA| | | | | ++++++++++SCTP| | | | | TCP| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RDMAP Layering
図1: RDMAPレイヤリング
If RDMAP is layered over DDP/MPA/TCP, then the respective headers and ULP Payload are arranged as follows (Note: For clarity, MPA header and CRC fields are included but MPA markers are not shown):
RDMAPがDDP/MPA/TCPの上で層にされるなら、それぞれのヘッダーとULP有効搭載量は以下の通りアレンジされます(明快、MPAヘッダー、およびCRCによって以下に注意しなさい、ただし、分野は含まれていますが、MPAマーカーは見せられません):
Recio, et al. Standards Track [Page 7] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[7ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TCP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// DDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// RDMA Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ULP Payload //
// (shown with no pad bytes) //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //TCPヘッダー//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPAヘッダー| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | //DDPヘッダー//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //RDMAヘッダー//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //ULP有効搭載量////(パッドバイトなしで目立つ)//////| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of MPA, DDP, and RDMAP Header Alignment over TCP
図2: MPA、DDP、およびTCPの上のRDMAPヘッダー整列に関する例
2. Glossary
2. 用語集
2.1. General
2.1. 一般
Advertisement (Advertised, Advertise, Advertisements, Advertises) -
the act of informing a Remote Peer that a local RDMA Buffer is
available to it. A Node makes available an RDMA Buffer for
incoming RDMA Read or RDMA Write access by informing its RDMA/DDP
peer of the Tagged Buffer identifiers (STag, base address, and
buffer length). This Advertisement of Tagged Buffer information
is not defined by RDMA/DDP and is left to the ULP. A typical
method would be for the Local Peer to embed the Tagged Buffer's
Steering Tag, base address, and length in a Send Message destined
for the Remote Peer.
広告(広告、Advertisements広告を出して、Advertises)--地方のRDMA Bufferがそれに利用可能であることをRemote Peerに知らせる行為。 Nodeは、Tagged Buffer識別子(STag、ベースアドレス、およびバッファ長)についてRDMA/DDP同輩に知らせることによって、入って来るRDMA ReadかRDMA WriteアクセスのためのRDMA Bufferを利用可能にします。 Tagged Buffer情報のこのAdvertisementはRDMA/DDPによって定義されないで、ULPに残されます。 典型的なメソッドはLocal PeerがTagged BufferのSteering Tag、ベースアドレス、および長さをRemote Peerのために運命づけられたSend Messageに埋め込むだろうことです。
Completion - Refer to "RDMA Completion" in Section 2.4.
完成--セクション2.4における「RDMA完成」を参照してください。
Completed - See "RDMA Completion" in Section 2.4.
完成されました--セクション2.4で「RDMA完成」を見てください。
Complete - See "RDMA Completion" in Section 2.4.
完全である、--セクション2.4で「RDMA完成」を見てください
Recio, et al. Standards Track [Page 8] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[8ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Completes - See "RDMA Completion" in Section 2.4.
完成、--セクション2.4で「RDMA完成」を見てください
Data Sink - The peer receiving a data payload. Note that the Data
Sink can be required to both send and receive RDMA/DDP Messages
to transfer a data payload.
データSink--データペイロードを受け取る同輩。 Data Sinkがデータペイロードを移すためにともにRDMA/DDP Messagesを送って、受け取ることができなければならないことに注意してください。
Data Source - The peer sending a data payload. Note that the Data
Source can be required to both send and receive RDMA/DDP Messages
to transfer a data payload.
データSource--データペイロードを送る同輩。 Data Sourceがデータペイロードを移すためにともにRDMA/DDP Messagesを送って、受け取ることができなければならないことに注意してください。
Data Delivery (Delivery, Delivered, Delivers) - Delivery is defined
as the process of informing the ULP or consumer that a particular
Message is available for use. This is specifically different
from "Placement", which may generally occur in any order, while
the order of "Delivery" is strictly defined. See "Data
Placement" in Section 2.3.
データDelivery(配送、Delivered、デリバーズ)--配送は特定のMessageが使用に利用可能であることをULPか消費者に知らせるプロセスと定義されます。 これは一般に、順不同に起こるかもしれない「プレースメント」と明確に異なっています、厳密に「配送」の注文を定義しますが。 セクション2.3で「データプレースメント」を見てください。
Delivery - See Data Delivery in Section 2.1.
配送--セクション2.1でデータ配送を見てください。
Delivered - See Data Delivery in Section 2.1.
提供されました--セクション2.1でデータ配送を見てください。
Delivers - See Data Delivery in Section 2.1.
デリバーズ--セクション2.1でデータ配送を見てください。
Fabric - The collection of links, switches, and routers that connect
a set of Nodes with RDMA/DDP protocol implementations.
骨組み--Nodesの1セットをRDMA/DDPに接続するリンク集、スイッチ、およびルータが実装について議定書の中で述べます。
Fence (Fenced, Fences) - To block the current RDMA Operation from
executing until prior RDMA Operations have Completed.
フェンシングをしてください(Fences、囲われました)--先のRDMA OperationsにはCompletedがあるまで実行からの現在のRDMA Operationを妨げるために。
iWARP - A suite of wire protocols comprised of RDMAP, DDP, and MPA.
The iWARP protocol suite may be layered above TCP, SCTP, or other
transport protocols.
iWARP--RDMAP、DDP、およびMPAから成るひとそろいのワイヤプロトコル。 iWARPプロトコル群はTCP、SCTP、または他のトランスポート・プロトコルを超えて層にされるかもしれません。
Local Peer - The RDMA/DDP protocol implementation on the local end of
the connection. Used to refer to the local entity when
describing a protocol exchange or other interaction between two
Nodes.
地方のPeer--RDMA/DDPは接続の地方の終わりで実装について議定書の中で述べます。 2Nodesの間のプロトコル交換か他の相互作用について説明するとき、ローカル要素について言及するのにおいて、使用されています。
Node - A computing device attached to one or more links of a Fabric
(network). A Node in this context does not refer to a specific
application or protocol instantiation running on the computer. A
Node may consist of one or more RNICs installed in a host
computer.
ノード--コンピュータ・デバイスはFabric(ネットワーク)の1個以上のリンクに付きました。 Nodeは、コンピュータで動きながら、このような関係においては特定のアプリケーションかプロトコル具体化を示しません。 Nodeはホストコンピュータにインストールされた1RNICsから成るかもしれません。
Placement - See "Data Placement" in Section 2.3.
プレースメント--セクション2.3で「データプレースメント」を見てください。
Placed - See "Data Placement" in Section 2.3.
置かれました--セクション2.3で「データプレースメント」を見てください。
Recio, et al. Standards Track [Page 9] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[9ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Places - See "Data Placement" in Section 2.3.
場所--セクション2.3で「データプレースメント」を見てください。
Remote Peer - The RDMA/DDP protocol implementation on the opposite
end of the connection. Used to refer to the remote entity when
describing protocol exchanges or other interactions between two
Nodes.
リモートPeer--RDMA/DDPは接続の反対端で実装について議定書の中で述べます。 2Nodesの間のプロトコル交換か他の相互作用について説明するとき、リモート実体について言及するのにおいて、使用されています。
RNIC - RDMA Network Interface Controller. In this context, this
would be a network I/O adapter or embedded controller with iWARP
and Verbs functionality.
RNIC--RDMAはインタフェースコントローラをネットワークでつなぎます。 このような関係においては、これは、iWARPとVerbsの機能性があるネットワーク入出力アダプターか埋め込まれたコントローラでしょう。
RNIC Interface (RI) - The presentation of the RNIC to the Verbs
Consumer as implemented through the combination of the RNIC and
the RNIC driver.
RNIC Interface(ロードアイランド)--RNICとRNICドライバーの組み合わせで実装されるVerbs ConsumerへのRNICのプレゼンテーション。
Termination - See "RDMAP Abortive Termination" in Section 2.4.
終了--セクション2.4で「RDMAPの不成功の終了」を見てください。
Terminated - See "RDMAP Abortive Termination" in Section 2.4.
終えられました--セクション2.4で「RDMAPの不成功の終了」を見てください。
Terminate - See "RDMAP Abortive Termination" in Section 2.4.
終わってください--セクション2.4で「RDMAPの不成功の終了」を見てください。
Terminates - See "RDMAP Abortive Termination" in Section 2.4.
終わり、--セクション2.4で「RDMAPの不成功の終了」を見てください
ULP - Upper Layer Protocol. The protocol layer above the one
currently being referenced. The ULP for RDMA/DDP is expected to
be an OS, Application, adaptation layer, or proprietary device.
The RDMA/DDP documents do not specify a ULP -- they provide a set
of semantics that allow a ULP to be designed to utilize RDMA/DDP.
ULP--上側の層のプロトコル。 現在参照をつけられるものを超えたプロトコル層。 RDMA/DDPのためのULPはOS、Application、適合層、または独占デバイスであると予想されます。 RDMA/DDPドキュメントはULPを指定しません--それらはULPがRDMA/DDPを利用するように設計されているのを許容する1セットの意味論を提供します。
ULP Payload - The ULP data that is contained within a single protocol
segment or packet (e.g., a DDP Segment).
ULP有効搭載量--シングルの中に含まれているULPデータはセグメントかパケット(例えば、DDP Segment)について議定書の中で述べます。
Verbs - An abstract description of the functionality of an RNIC
Interface. The OS may expose some or all of this functionality
via one or more APIs to applications. The OS will also use some
of the functionality to manage the RNIC Interface.
動詞--RNIC Interfaceの機能性の抽象的な記述。 OSはアプリケーションへの1つ以上のAPIを通してこの機能性のいくつかかすべてを暴露するかもしれません。 また、OSは、RNIC Interfaceを管理するのに機能性のいくつかを使用するでしょう。
2.2. LLP
2.2. LLP
LLP - Lower Layer Protocol. The protocol layer beneath the protocol
layer currently being referenced. For example, for DDP, the LLP
is SCTP, MPA, or other transport protocols. For RDMA, the LLP is
DDP.
LLP--層のプロトコルを下ろしてください。 現在参照をつけられるプロトコル層の下のプロトコル層。 例えば、DDPのために、LLPはSCTP、MPA、または他のトランスポート・プロトコルです。 RDMAに関しては、LLPはDDPです。
LLP Connection - Corresponds to an LLP transport-level connection
between the peer LLP layers on two Nodes.
LLP Connection--2Nodesの上の同輩LLP層の間のLLP輸送レベル接続に文通しています。
Recio, et al. Standards Track [Page 10] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[10ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
LLP Stream - Corresponds to a single LLP transport-level Stream
between the peer LLP layers on two Nodes. One or more LLP
Streams may map to a single transport-level LLP connection. For
transport protocols that support multiple Streams per connection
(e.g., SCTP), an LLP Stream corresponds to one transport-level
Stream.
LLP Stream--2Nodesの上の同輩LLP層の間の独身のLLP輸送レベルStreamに対応しています。 LLP Streamsが単独の輸送レベルLLP接続に写像するかもしれない1つか以上。 複数の接続(例えば、SCTP)あたりのStreamsをサポートするトランスポート・プロトコルのために、LLP Streamは1輸送レベルStreamに対応しています。
MULPDU - Maximum ULPDU. The current maximum size of the record that
is acceptable for DDP to pass to the LLP for transmission.
MULPDU--最大のULPDU。 DDPがトランスミッションのためにLLPに終わるのにおいて許容できる記録の現在の最大サイズ。
ULPDU - Upper Layer Protocol Data Unit. The data record defined by
the layer above MPA.
ULPDU--上側の層のプロトコルデータ単位。 MPAの上の層で定義されたデータレコード。
2.3. Direct Data Placement (DDP)
2.3. ダイレクトデータプレースメント(DDP)
Data Placement (Placement, Placed, Places) - For DDP, this term is
specifically used to indicate the process of writing to a data
buffer by a DDP implementation. DDP Segments carry Placement
information, which may be used by the receiving DDP
implementation to perform Data Placement of the DDP Segment ULP
Payload. See "Data Delivery".
DDPのためのデータPlacement(プレースメント、Placed、Places)は今期にDDP実装でデータバッファに書くプロセスを示すのにおいて明確に使用されています。 DDP SegmentsはPlacement情報を運びます。(それは、受信DDP実装によって使用されて、)DDP Segment ULP有効搭載量のData Placementを実行するかもしれません。 「データ配送」を見てください。
DDP Abortive Teardown - The act of closing a DDP Stream without
attempting to Complete in-progress and pending DDP Messages.
DDP Abortive Teardown--進行中のCompleteと未定のDDPにMessagesを試みないでDDP Streamを閉じる行為。
DDP Graceful Teardown - The act of closing a DDP Stream such that all
in-progress and pending DDP Messages are allowed to Complete
successfully.
DDP Graceful Teardown--すべての進行中の、そして、未定のDDP Messagesが首尾よくCompleteに許容されているようにDDP Streamを閉じる行為。
DDP Control Field - A fixed 16-bit field in the DDP Header. The DDP
Control Field contains an 8-bit field whose contents are reserved
for use by the ULP.
DDP Control Field--DDP Headerの固定16ビットの分野。 DDP Control Fieldはコンテンツが使用のためにULPによって予約される8ビットの分野を含んでいます。
DDP Header - The header present in all DDP segments. The DDP Header
contains control and Placement fields that are used to define the
final Placement location for the ULP Payload carried in a DDP
Segment.
DDP Header--すべてのDDPセグメントで出席しているヘッダー。 DDP HeaderはDDP Segmentで運ばれたULP有効搭載量のために最終的なPlacement位置を定義するのに使用されるコントロールとPlacement分野を含んでいます。
DDP Message - A ULP-defined unit of data interchange, which is
subdivided into one or more DDP segments. This segmentation may
occur for a variety of reasons, including segmentation to respect
the maximum segment size of the underlying transport protocol.
DDP Message--データのULPによって定義されたユニット(1つ以上のDDPセグメントに細分される)は交換されます。 この分割はさまざまな理由で起こるかもしれません、基本的なトランスポート・プロトコルの最大のセグメントサイズを尊敬するために分割を含んでいて。
DDP Segment - The smallest unit of data transfer for the DDP
protocol. It includes a DDP Header and ULP Payload (if present).
A DDP Segment should be sized to fit within the underlying
transport protocol MULPDU.
DDP Segment--DDPのためのデータ転送の最小単位は議定書を作ります。 それはDDP HeaderとULP有効搭載量を含んでいます(存在しているなら)。 DDP Segmentは、基本的なトランスポート・プロトコルMULPDUの中で合うように大きさで分けられるべきです。
Recio, et al. Standards Track [Page 11] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[11ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
DDP Stream - A sequence of DDP Messages whose ordering is defined by
the LLP. For SCTP, a DDP Stream maps directly to an SCTP Stream.
For MPA, a DDP Stream maps directly to a TCP connection, and a
single DDP Stream is supported. Note that DDP has no ordering
guarantees between DDP Streams.
DDP Stream--注文がLLPによって定義されるDDP Messagesの系列。 SCTP、Streamが直接SCTP Streamに写像するDDPのために。 MPAに関しては、Streamが直接TCP接続、および独身のDDP Streamに写像するDDPはサポートされます。 DDPがDDP Streamsの間に注文していない保証を持っていることに注意してください。
Direct Data Placement - A mechanism whereby ULP data contained within
DDP Segments may be Placed directly into its final destination in
memory without processing of the ULP. This may occur even when
the DDP Segments arrive out of order. Out-of-order Placement
support may require the Data Sink to implement the LLP and DDP as
one functional block.
ダイレクトData Placement--ULPデータがDDPの中にSegmentsを含んだメカニズムは直接ULPの処理のないメモリの最終的な目的地へのPlacedであるかもしれません。 DDP Segmentsが故障していた状態で到着すると、これは起こるかもしれません。 不適切なPlacementサポートは、Data Sinkが1機能ブロックとしてLLPとDDPを実装するのを必要とするかもしれません。
Direct Data Placement Protocol (DDP) - Also, a wire protocol that
supports Direct Data Placement by associating explicit memory
buffer placement information with the LLP payload units.
Data Placementプロトコル(DDP)を指示してください--顕在記憶バッファプレースメント情報をLLPペイロード単位に関連づけることによってDirect Data Placementをサポートするワイヤプロトコルも。
Message Offset (MO) - For the DDP Untagged Buffer Model, specifies
the offset, in bytes, from the start of a DDP Message.
DDP Untagged Buffer ModelのためのメッセージOffset(MO)はオフセットを指定します、バイトで、DDP Messageの始まりから。
Message Sequence Number (MSN) - For the DDP Untagged Buffer Model,
specifies a sequence number that is increasing with each DDP
Message.
DDP Untagged Buffer ModelのためのメッセージSequence Number(MSN)はそれぞれのDDP Messageと共に増加している一連番号を指定します。
Queue Number (QN) - For the DDP Untagged Buffer Model, identifies a
destination Data Sink queue for a DDP Segment.
DDP Untagged Buffer Modelのための待ち行列Number(QN)はDDP Segmentのために目的地Data Sink待ち行列を特定します。
Steering Tag - An identifier of a Tagged Buffer on a Node, valid as
defined within a protocol specification.
操縦Tag--定義されるとしてプロトコル仕様の中で有効なNodeの上のTagged Bufferに関する識別子。
STag - Steering Tag
雄ジカ--操縦タグ
Tagged Buffer - A buffer that is explicitly Advertised to the Remote
Peer through exchange of an STag, Tagged Offset, and length.
それは明らかにそうです。タグ付けをされたBuffer--、バッファ、STag、Tagged Offset、および長さの交換によるRemote PeerへのAdvertised。
Tagged Buffer Model - A DDP data transfer model used to transfer
Tagged Buffers from the Local Peer to the Remote Peer.
タグ付けをされたBuffer Model--DDPデータ転送モデルは以前はLocal PeerからRemote PeerまでTagged Buffersをよく移していました。
Tagged DDP Message - A DDP Message that targets a Tagged Buffer.
タグ付けをされたDDP Message--Tagged Bufferを狙うDDP Message。
Tagged Offset (TO) - The offset within a Tagged Buffer on a Node.
タグ付けをされたOffset(TO)--Nodeの上のTagged Bufferの中のオフセット。
Untagged Buffer - A buffer that is not explicitly Advertised to the
Remote Peer. Untagged Buffers support one of the two available
data transfer mechanisms called the Untagged Buffer Model. An
Untagged Buffer is used to send asynchronous control messages to
the Remote Peer for RDMA Read, Send, and Terminate requests.
Untagged Buffers handle Untagged DDP Messages.
それは明らかにそうではありません。Untagged Buffer--、バッファ、Remote PeerへのAdvertised。 Untagged BuffersはUntagged Buffer Modelと呼ばれる2つの利用可能なデータ転送メカニズムの1つをサポートします。 Untagged Bufferは、RDMA Read、Send、およびTerminate要求のために非同期なコントロールメッセージをRemote Peerに送るのに使用されます。 Untagged BuffersはUntagged DDP Messagesを扱います。
Recio, et al. Standards Track [Page 12] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[12ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Untagged Buffer Model - A DDP data transfer model used to transfer
Untagged Buffers from the Local Peer to the Remote Peer.
Untagged Buffer Model--DDPデータ転送モデルは以前はLocal PeerからRemote PeerまでUntagged Buffersをよく移していました。
Untagged DDP Message - A DDP Message that targets an Untagged Buffer.
Untagged DDP Message--Untagged Bufferを狙うDDP Message。
2.4. Remote Direct Memory Access (RDMA)
2.4. リモートダイレクトメモリアクセス(RDMA)
Completion Queues (CQs) - Logical components of the RNIC Interface
that conceptually represent how an RNIC notifies the ULP about
the completion of the transmission of data, or the completion of
the reception of data; see [RDMASEC].
完成Queues(CQs)--概念的にRNICがデータの伝達の完成、またはデータのレセプションの完成に関してどうULPに通知するかを表すRNIC Interfaceの論理的な部品。 [RDMASEC]を見てください。
Event - An indication provided by the RDMAP layer to the ULP to
indicate a Completion or other condition requiring immediate
attention.
イベント--Completionか他の状態を示すために一刻を争いながらRDMAP層でULPに提供された指示。
Invalidate STag - A mechanism used to prevent the Remote Peer from
reusing a previous explicitly Advertised STag, until the Local
Peer makes it available through a subsequent explicit
Advertisement. The STag cannot be accessed remotely until it is
explicitly Advertised again.
STagを無効にしてください--メカニズムは以前は明らかによく前であることの状態でaを再利用するのからのRemote Peerを防いでいました。Local Peerがそれをその後の明白なAdvertisementを通して利用可能にするまでのAdvertised STag。 それが明らかにアクセスされるまでSTagに離れてアクセスできない、Advertised、再び。
RDMA Completion (Completion, Completed, Complete, Completes) - For
RDMA, Completion is defined as the process of informing the ULP
that a particular RDMA Operation has performed all functions
specified for the RDMA Operations, including Placement and
Delivery. The Completion semantic of each RDMA Operation is
distinctly defined.
RDMAのためのRDMA Completion(完成、Completed、Complete、Completes)、Completionは特定のRDMA OperationがRDMA Operationsに指定されたすべての機能を実行したことをULPに知らせるプロセスと定義されます、PlacementとDeliveryを含んでいて。 各RDMA Operationにおける意味のCompletionは明瞭に定義されます。
RDMA Message - A data transfer mechanism used to fulfill an RDMA
Operation.
RDMA Message--データ転送メカニズムは以前はRDMA Operationをよく実現させていました。
RDMA Operation - A sequence of RDMA Messages, including control
Messages, to transfer data from a Data Source to a Data Sink.
The following RDMA Operations are defined: RDMA Writes, RDMA
Read, Send, Send with Invalidate, Send with Solicited Event, Send
with Solicited Event and Invalidate, and Terminate.
RDMA Operation--Data SourceからData Sinkまでデータを移すためにコントロールMessagesを含むRDMA Messagesの系列。 以下のRDMA Operationsは定義されます: RDMAが、RDMAが書くと読んで、発信してくださいといって、発信してください、無効にして、請求されたイベントと共に送って、請求されたイベントと共に送って、無効にして、終えます。
RDMA Protocol (RDMAP) - A wire protocol that supports RDMA Operations
to transfer ULP data between a Local Peer and the Remote Peer.
RDMAプロトコル(RDMAP)--Local PeerとRemote Peerの間にULPデータを移すためにRDMA Operationsをサポートするワイヤプロトコル。
RDMAP Abortive Termination (Termination, Terminated, Terminate,
Terminates) - The act of closing an RDMAP Stream without
attempting to Complete in-progress and pending RDMA Operations.
RDMAP Abortive Termination(終了、Terminated、Terminate、Terminates)--進行中の、そして、未定のRDMA OperationsをCompleteに試みないでRDMAP Streamを閉じる行為。
RDMAP Graceful Termination - The act of closing an RDMAP Stream such
that all in-progress and pending RDMA Operations are allowed to
Complete successfully.
RDMAP Graceful Termination--すべての進行中の、そして、未定のRDMA Operationsが首尾よくCompleteに許容されているようにRDMAP Streamを閉じる行為。
Recio, et al. Standards Track [Page 13] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[13ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
RDMA Read - An RDMA Operation used by the Data Sink to transfer the
contents of a source RDMA buffer from the Remote Peer to the
Local Peer. An RDMA Read operation consists of a single RDMA
Read Request Message and a single RDMA Read Response Message.
RDMA Read--Remote PeerからLocal PeerまでソースRDMAバッファのコンテンツを移すのにData Sinkによって使用されたRDMA Operation。 RDMA Read操作は独身のRDMA Read Request Messageと独身のRDMA Read Response Messageから成ります。
RDMA Read Request - An RDMA Message used by the Data Sink to request
the Data Source to transfer the contents of an RDMA buffer. The
RDMA Read Request Message describes both the Data Source and Data
Sink RDMA buffers.
RDMA Read Request--RDMAバッファのコンテンツを移すようData Sourceに要求するのにData Sinkによって使用されたRDMA Message。 RDMA Read Request MessageはData SourceとData Sink RDMAバッファの両方について説明します。
RDMA Read Request Queue - The queue used for processing RDMA Read
Requests. The RDMA Read Request Queue has a DDP Queue Number of
1.
RDMA Read Request Queue--待ち行列は処理にRDMA Read Requestsを使用しました。 RDMA読み出し要求待ち行列で、DDPは1の数を列に並ばせます。
RDMA Read Response - An RDMA Message used by the Data Source to
transfer the contents of an RDMA buffer to the Data Sink, in
response to an RDMA Read Request. The RDMA Read Response Message
only describes the data sink RDMA buffer.
RDMA Read Response--RDMA Read Requestに対応してRDMAバッファのコンテンツをData Sinkに移すのにData Sourceによって使用されたRDMA Message。 RDMA Read Response Messageはデータ受信端末RDMAバッファについて説明するだけです。
RDMAP Stream - An association between a pair of RDMAP
implementations, possibly on different Nodes, which transfer ULP
data using RDMA Operations. There may be multiple RDMAP Streams
on a single Node. An RDMAP Stream maps directly to a single DDP
Stream.
RDMAP Stream--1組のRDMAP実装の間と、そして、ことによると異なったNodesの上の協会。Nodesは、RDMA Operationsを使用することでULPデータを移します。 複数のRDMAP Streamsが独身のNodeにあるかもしれません。 RDMAP Streamは直接ただ一つのDDPにStreamを写像します。
RDMA Write - An RDMA Operation that transfers the contents of a
source RDMA Buffer from the Local Peer to a destination RDMA
Buffer at the Remote Peer using RDMA. The RDMA Write Message
only describes the Data Sink RDMA buffer.
RDMA Write--Remote PeerでRDMAを使用することでLocal Peerから目的地RDMA BufferまでソースRDMA Bufferのコンテンツを移すRDMA Operation。 RDMA Write MessageはData Sink RDMAバッファについて説明するだけです。
Remote Direct Memory Access (RDMA) - A method of accessing memory on
a remote system in which the local system specifies the remote
location of the data to be transferred. Employing an RNIC in the
remote system allows the access to take place without
interrupting the processing of the CPU(s) on the system.
リモートDirect Memory Access(RDMA)--ローカルシステムがデータの離れた場所を指定するリモートシステムの上に関するメモリにアクセスする移されるべきメソッド。 リモートシステムでRNICを使うのに、システムにおけるCPUの処理を中断しないで、アクセスは行われます。
Send - An RDMA Operation that transfers the contents of a ULP Buffer
from the Local Peer to an Untagged Buffer at the Remote Peer.
発信してください--Remote PeerでLocal PeerからUntagged BufferまでULP Bufferのコンテンツを移すRDMA Operation。
Send Message Type - A Send Message, Send with Invalidate Message,
Send with Solicited Event Message, or Send with Solicited Event
and Invalidate Message.
メッセージタイプを送ってください--Aがメッセージを送って、発信してください、メッセージを無効にするか、請求されたイベントメッセージと共に発信するか、請求されたイベントと共に発信してください、そして、またはメッセージを無効にしてください。
Send Operation Type - A Send Operation, Send with Invalidate
Operation, Send with Solicited Event Operation, or Send with
Solicited Event and Invalidate Operation.
操作タイプを送ってください--Aが操作を送って、発信してください、操作を無効にするか、請求されたイベント操作と共に発信するか、請求されたイベントと共に発信してください、そして、または操作を無効にしてください。
Recio, et al. Standards Track [Page 14] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[14ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Solicited Event (SE) - A facility by which an RDMA Operation sender
may cause an Event to be generated at the recipient, if the
recipient is configured to generate such an Event, when a Send
with Solicited Event Message or Send with Solicited Event and
Invalidate Message is received. Note: The Local Peer's ULP can
use the Solicited Event mechanism to ensure that Messages
designated as important to the ULP are handled in an expeditious
manner by the Remote Peer's ULP. The ULP at the Local Peer can
indicate a given Send Message Type is important by using the Send
with Solicited Event Message or Send with Solicited Event and
Invalidate Message. The ULP at the Remote Peer can choose to
only be notified when valid Send with Solicited Event Messages
and/or Send with Solicited Event and Invalidate Messages arrive
and handle other valid incoming Send Messages or Send with
Invalidate Messages at its leisure.
請求されたEvent(SE)--Solicited EventとInvalidate MessageとSolicited Event MessageとSendであるときに、受取人がそのようなEventを生成するために構成されるならRDMA Operation送付者が受取人でEventを生成させるかもしれない施設かSendが受け取られています。 以下に注意してください。 Local PeerのULPは、ULPに重要であるとして指定されたMessagesが迅速な方法でRemote PeerのULPによって扱われるのを保証するのにSolicited Eventメカニズムを使用できます。 Local PeerのULPは、与えられたSend Message TypeがSolicited Event MessageとSendかSolicited EventとInvalidate MessageとSendを使用することによって重要であることを示すことができます。 Remote PeerのULPはSolicited Event Messagesと有効なSend、そして/または、Solicited EventとInvalidate MessagesとSendが到着するとき、通知されるだけであるのを選んで、ゆっくりInvalidate Messagesと他の有効な入って来るSend MessagesかSendを扱うことができます。
Terminate - An RDMA Message used by a Node to pass an error
indication to the peer Node on an RDMAP Stream. This operation
is for RDMAP use only.
終わってください--RDMAP Streamの上の同輩Nodeに誤り表示を通過するのにNodeによって使用されたRDMA Message。 この操作はRDMAP使用だけのためのものです。
ULP Buffer - A buffer owned above the RDMAP layer and Advertised to
the RDMAP layer either as a Tagged Buffer or an Untagged ULP
Buffer.
ULP Buffer--RDMAPへのRDMAP層を超えて所有されていたバッファとAdvertisedはTagged BufferかUntagged ULP Bufferとして層にします。
ULP Message - The ULP data that is handed to a specific protocol
layer for transmission. Data boundaries are preserved as they
are transmitted through iWARP.
ULP Message--特定のプロトコルに手渡されるULPデータはトランスミッションのために層にされます。 それらがiWARPを通して伝えられるようにデータ境界は保持されます。
3. ULP and Transport Attributes
3. ULPと輸送属性
3.1. Transport Requirements and Assumptions
3.1. 輸送要件と仮定
RDMAP MUST be layered on top of the Direct Data Placement Protocol [DDP].
RDMAP MUST、Direct Data Placementプロトコル[DDP]の上で層にされてください。
RDMAP requires the following DDP support:
RDMAPは以下のDDPサポートを必要とします:
* RDMAP uses three queues for Untagged Buffers:
* RDMAPはUntagged Buffersに3つの待ち行列を使用します:
* Queue Number 0 (used by RDMAP for Send, Send with Invalidate,
Send with Solicited Event, and Send with Solicited Event and
Invalidate operations).
* Number0(Send、InvalidateとSend、Solicited EventとSend、およびSolicited EventとInvalidate操作があるSendにRDMAPによって使用されます)を列に並ばせてください。
* Queue Number 1 (used by RDMAP for RDMA Read operations).
* Number1(RDMA Read操作にRDMAPによって使用されます)を列に並ばせてください。
* Queue Number 2 (used by RDMAP for Terminate operations).
* Number2(Terminate操作にRDMAPによって使用されます)を列に並ばせてください。
* DDP maps a single RDMA Message to a single DDP Message.
* DDPは独身のDDP Messageに独身のRDMA Messageを写像します。
Recio, et al. Standards Track [Page 15] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[15ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* DDP uses the STag and Tagged Offset provided by the RDMAP for
Tagged Buffer Messages (i.e., RDMA Write and RDMA Read Response).
* DDPはRDMAPによってTagged Buffer Messages(すなわち、RDMA WriteとRDMA Read Response)に提供されたSTagとTagged Offsetを使用します。
* When the DDP layer Delivers an Untagged DDP Message to the RDMAP
layer, DDP provides the length of the DDP Message. This ensures
that RDMAP does not have to carry a length field in its header.
* デリバーズ、DDP層であることのRDMAP層へのUntagged DDP Message、とDDPはDDP Messageの長さを前提とします。 これは、RDMAPがヘッダーの長さの野原を運ぶ必要はないのを確実にします。
* When the RDMAP layer provides an RDMA Message to the DDP layer,
DDP must insert the RsvdULP field value provided by the RDMAP
layer into the associated DDP Message.
* RDMAP層がDDP層にRDMA Messageを供給するとき、DDPはRDMAP層で関連DDP Messageに提供されたRsvdULP分野価値を挿入しなければなりません。
* When the DDP layer Delivers a DDP Message to the RDMAP layer, DDP
provides the RsvdULP field.
* DDPであるときにはデリバーズ、DDP MessageをRDMAP層に層にしてください、そして、DDPはRsvdULP野原を供給します。
* The RsvdULP field must be 1 octet for DDP Tagged Messages and 5
octets for DDP Untagged Messages.
* RsvdULP分野は、DDP Tagged Messagesのための1つの八重奏とDDP Untagged Messagesのための5つの八重奏でなければなりません。
* DDP propagates to RDMAP all operation or protection errors (used
by RDMAP Terminate) and, when appropriate, the DDP Header fields
of the DDP Segment that encountered the error.
* DDPは誤りに遭遇したDDP Segmentのすべての操作かプロテクション・エラー(RDMAP Terminateによって使用される)と適切でありDDP Header野原をRDMAPに伝播します。
* If an RDMA Operation is aborted by DDP or a lower layer, the
contents of the Data Sink buffers associated with the operation
are considered indeterminate.
* RDMA OperationがDDPか下層によって中止されるなら、操作に関連しているData Sinkバッファの中身は不確定であると考えられます。
* DDP, in conjunction with the lower layers, provides reliable, in-
order Delivery.
* 下層に関連して、DDPは信頼できるコネオーダーDeliveryを提供します。
3.2. RDMAP Interactions with the ULP
3.2. ULPとのRDMAP相互作用
RDMAP provides the ULP with access to the following RDMA Operations as defined in this specification:
RDMAPはこの仕様に基づき定義されるように以下のRDMA OperationsへのアクセスをULPに提供します:
* Send
* 発信してください。
* Send with Solicited Event
* 請求されたイベントと共に発信してください。
* Send with Invalidate
* 発信する、無効にする。
* Send with Solicited Event and Invalidate
* 請求されたイベントと共に送って、無効にします。
* RDMA Write
* RDMAは書きます。
* RDMA Read
* RDMAは読みます。
Recio, et al. Standards Track [Page 16] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[16ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
For Send Operation Types, the following are the interactions between the RDMAP layer and the ULP:
Send Operation Typesに関しては、↓これはRDMAP層とULPとの相互作用です:
* At the Data Source:
* データ送信端末で:
* The ULP passes to the RDMAP layer the following:
* RDMAPへのULPパスは以下を層にします:
* ULP Message Length
* ULPメッセージ長
* ULP Message
* ULPメッセージ
* An indication of the Send Operation Type, where the valid
types are: Send, Send with Solicited Event, Send with
Invalidate, or Send with Solicited Event and Invalidate.
* Send Operation Typeのしるし:(そこでは、有効なタイプがそうです)。 送って、請求されたイベントと共に送って、発信する、無効にするか、請求されたイベントと共に送って、または無効にします。
* An Invalidate STag, if the Send Operation Type was Send with
Invalidate or Send with Solicited Event and Invalidate.
* Solicited EventとInvalidateとInvalidate STag、Invalidateと共にSend Operation TypeはSendであったか、そして、またはSend。
* When the Send Operation Type Completes, an indication of the
Completion results.
* Send Operation Type Completesであるときに、Completionのしるしは結果として生じます。
* At the Data Sink:
* データ受信端末で:
* If the Send Operation Type Completed successfully, the RDMAP
layer passes the following information to the ULP Layer:
* Send Operation Type Completedであるなら、首尾よく、RDMAP層は以下の情報をULP Layerに通過します:
* ULP Message Length
* ULPメッセージ長
* ULP Message
* ULPメッセージ
* An Event, if the Data Sink is configured to generate an
Event.
* Event Data Sinkがイベントを生成するために構成されるなら。
* An Invalidated STag, if the Send Operation Type was Send
with Invalidate or Send with Solicited Event and Invalidate.
* Solicited EventとInvalidateとInvalidated STag、Invalidateと共にSend Operation TypeはSendであったか、そして、またはSend。
* If the Send Operation Type Completed in error, the Data Sink
RDMAP layer will pass up the corresponding error information to
the Data Sink ULP and send a Terminate Message to the Data
Source RDMAP layer. The Data Source RDMAP layer will then pass
up the Terminate Message to the ULP.
* 間違いSend Operation Type Completedであるなら、Data Sink RDMAP層は、対応するエラー情報をData Sink ULPに無視して、Data Source RDMAP層にTerminate Messageを送るでしょう。 そして、Data Source RDMAP層はULPにTerminate Messageを無視するでしょう。
For RDMA Write operations, the following are the interactions between the RDMAP layer and the ULP:
RDMA Write操作のために、↓これはRDMAP層とULPとの相互作用です:
* At the Data Source:
* データ送信端末で:
* The ULP passes to the RDMAP layer the following:
* RDMAPへのULPパスは以下を層にします:
Recio, et al. Standards Track [Page 17] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[17ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* ULP Message Length
* ULPメッセージ長
* ULP Message
* ULPメッセージ
* Data Sink STag
* 男一人でデータ受信端末
* Data Sink Tagged Offset
* データ受信端末のタグ付けをされたオフセット
* When the RDMA Write operation Completes, an indication of
the Completion results.
* RDMA Write操作Completesであるときに、Completionのしるしは結果として生じます。
* At the Data Sink:
* データ受信端末で:
* If the RDMA Write completed successfully, the RDMAP layer does
not Deliver the RDMA Write to the ULP. It does Place the ULP
Message transferred through the RDMA Write Message into the ULP
Buffer.
* RDMA Writeであるなら、首尾よく完成されて、RDMAP層はいずれのDeliver RDMA WriteもULPにしません。 それはRDMA Write Messageを通してULP Bufferに移されたULP MessageをPlaceにします。
* If the RDMA Write completed in error, the Data Sink RDMAP layer
will pass up the corresponding error information to the Data
Sink ULP and send a Terminate Message to the Data Source RDMAP
layer. The Data Source RDMAP layer will then pass up the
Terminate Message to the ULP.
* 誤りで完成したRDMA Writeであるなら、Data Sink RDMAP層は、対応するエラー情報をData Sink ULPに無視して、Data Source RDMAP層にTerminate Messageを送るでしょう。 そして、Data Source RDMAP層はULPにTerminate Messageを無視するでしょう。
For RDMA Read operations, the following are the interactions between the RDMAP layer and the ULP:
RDMA Read操作のために、↓これはRDMAP層とULPとの相互作用です:
* At the Data Sink:
* データ受信端末で:
* The ULP passes to the RDMAP layer the following:
* RDMAPへのULPパスは以下を層にします:
* ULP Message Length
* ULPメッセージ長
* Data Source STag
* 男一人でデータ送信端末
* Data Sink STag
* 男一人でデータ受信端末
* Data Source Tagged Offset
* データ送信端末のタグ付けをされたオフセット
* Data Sink Tagged Offset
* データ受信端末のタグ付けをされたオフセット
* When the RDMA Read operation Completes, an indication of the
Completion results.
* RDMA Read操作Completesであるときに、Completionのしるしは結果として生じます。
* At the Data Source:
* データ送信端末で:
* If no error occurred while processing the RDMA Read Request,
the Data Source will not pass up any information to the ULP.
* 誤りが全くRDMA Read Requestを処理している間、発生しなかったなら、Data Sourceは少しの情報もULPに無視しないでしょう。
Recio, et al. Standards Track [Page 18] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[18ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* If an error occurred while processing the RDMA Read Request,
the Data Source RDMAP layer will pass up the corresponding
error information to the Data Source ULP and send a Terminate
Message to the Data Sink RDMAP layer. The Data Sink RDMAP
layer will then pass up the Terminate Message to the ULP.
* 誤りがRDMA Read Requestを処理している間、発生したなら、Data Source RDMAP層は、対応するエラー情報をData Source ULPに無視して、Data Sink RDMAP層にTerminate Messageを送るでしょう。 そして、Data Sink RDMAP層はULPにTerminate Messageを無視するでしょう。
For STags made available to the RDMAP layer, following are the interactions between the RDMAP layer and the ULP:
RDMAP層が入手したSTagsのために、RDMAP層とULPとの相互作用は以下にあります:
* If the ULP enables an STag, the ULP passes the following to the
RDMAP layer:
* ULPがSTagを有効にするなら、ULPはRDMAP層に以下を通過します:
* STag;
* 雄ジカ。
* range of Tagged Offsets that are associated with a given STag;
* 与えられたSTagに関連しているTagged Offsetsの範囲。
* remote access rights (read, write, or read and write)
associated with a given, valid STag; and
* 遠隔アクセスは与えられて、有効なSTagに関連していた状態でまっすぐになります(読むか、書くか、読んでください、そして、または書いてください)。 そして
* association between a given STag and a given RDMAP Stream.
* 与えられたSTagと与えられたRDMAP Streamとの協会。
* If the ULP disables an STag, the ULP passes to the RDMAP layer the
STag.
* ULPがSTagを無効にするなら、ULPはRDMAP層にSTagを渡します。
If an error occurs at the RDMAP layer, the RDMAP layer may pass back error information (e.g., the content of a Terminate Message) to the ULP.
誤りがRDMAP層に発生するなら、RDMAP層はエラー情報(例えば、Terminate Messageの内容)をULPに戻すかもしれません。
4. Header Format
4. ヘッダー形式
The control information of RDMA Messages is included in DDP protocol-defined header fields, with the following exceptions:
RDMA Messagesに関する制御情報はDDPのプロトコルで定義されたヘッダーフィールドに以下の例外で含まれています:
* The first octet reserved for ULP usage on all DDP Messages in the
DDP Protocol (i.e., the RsvdULP Field) is used by RDMAP to carry
the RDMA Message Opcode and the RDMAP version. This octet is
known as the RDMAP Control Field in this specification. For Send
with Invalidate and Send with Solicited Event and Invalidate,
RDMAP uses the second through fifth octets, provided by DDP on
Untagged DDP Messages, to carry the STag that will be Invalidated.
* ULP用法のためにすべてのDDP MessagesにDDPプロトコル(すなわち、RsvdULP Field)で控えられた最初の八重奏は、RDMA Message OpcodeとRDMAPバージョンを運ぶのにRDMAPによって使用されます。 この八重奏はRDMAP Control Fieldとしてこの仕様で知られています。 InvalidateとSendとSolicited EventとInvalidateとSendに関しては、RDMAPは、InvalidatedになるSTagを運ぶのにUntagged DDP MessagesでDDPによって提供された5番目の八重奏で2番目を使用します。
* The RDMA Message length is passed by the RDMAP layer to the DDP
layer on all outbound transfers.
* RDMA Messageの長さはすべての外国行きの転送のときにRDMAP層のそばでDDP層に通過されます。
* For RDMA Read Request Messages, the RDMA Read Message Size is
included in the RDMA Read Request Header.
* RDMA Read Request Messagesに関しては、RDMA Read Message SizeはRDMA Read Request Headerに含まれています。
Recio, et al. Standards Track [Page 19] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[19ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* The RDMA Message length is passed to the RDMAP layer by the DDP
layer on inbound Untagged Buffer transfers.
* RDMA Messageの長さは本国行きのUntagged Buffer転送のときにDDP層のそばでRDMAP層に通過されます。
* Two RDMA Messages carry additional RDMAP headers. The RDMA Read
Request carries the Data Sink and Data Source buffer descriptions,
including buffer length. The Terminate carries additional
information associated with the error that caused the Terminate.
* 2RDMA Messagesが追加RDMAPヘッダーを運びます。 RDMA Read Requestはバッファ長を含むData SinkとData Sourceバッファ記述を運びます。 TerminateはTerminateを引き起こした誤りに関連している追加情報を運びます。
4.1. RDMAP Control and Invalidate STag Field
4.1. RDMAPは男一人で分野を制御して、無効にします。
The version of RDMAP defined by this specification uses all 8 bits of the RDMAP Control Field. The first octet reserved for ULP use in the DDP Protocol MUST be used by the RDMAP to carry the RDMAP Control Field. The ordering of the bits in the first octet MUST be as defined in Figure 3, "DDP Control, RDMAP Control, and Invalidate STag Fields". For Send with Invalidate and Send with Solicited Event and Invalidate, the second through fifth octets of the DDP RsvdULP field MUST be used by RDMAP to carry the Invalidate STag. Figure 3 depicts the format of the DDP Control and RDMAP Control fields. (Note: In Figure 3, the DDP Header is offset by 16 bits to accommodate the MPA header defined in [MPA]. The MPA header is only present if DDP is layered on top of MPA.)
この仕様で定義されたRDMAPのバージョンはRDMAP Control Fieldのすべての8ビットを使用します。 RDMAPは、RDMAP Control Fieldを運ぶのにDDPプロトコルにおけるULP使用のために控えられた最初の八重奏を使用しなければなりません。 最初の八重奏における、ビットの注文は図3で定義されるような「DDPコントロール、RDMAPが制御します、そして、男一人で分野を無効にしてください」ということであるに違いありません。 InvalidateとSendとSolicited EventとInvalidateとSendに関しては、RDMAPは、Invalidate STagを運ぶのにDDP RsvdULP分野の5番目の八重奏による2番目を使用しなければなりません。 図3はDDP ControlとRDMAP Control分野の書式を表現します。 図3では、DDP Headerは16ビットによって相殺されます。(注意: [MPA]で定義されたMPAヘッダーを収容して、DDPがMPAの上で層にされる場合にだけ、MPAヘッダーは出席しています。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Resrv | DV| RV|Rsv| Opcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L| Resrv| DV| RV|Rsv| Opcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 雄ジカを無効にしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DDP Control, RDMAP Control, and Invalidate STag Fields
図3: DDPが制御されて、RDMAPは男一人で分野を制御して、無効にします。
All RDMA Messages handed by the RDMAP layer to the DDP layer MUST define the value of the Tagged flag in the DDP Header. Figure 4, "RDMA Usage of DDP Fields", MUST be used to define the value of the Tagged flag that is handed to the DDP layer for each RDMA Message.
RDMAP層によってDDP層に手渡されたすべてのRDMA MessagesがDDP HeaderのTagged旗の値を定義しなければなりません。 各RDMA MessageのためにDDP層に手渡されるTagged旗の値を定義するのに、「DDP分野のRDMA用法」という図4を使用しなければなりません。
Figure 4 defines the value of the RDMA Opcode field that MUST be used for each RDMA Message.
図4は各RDMA Messageに使用しなければならないRDMA Opcode分野の値を定義します。
Figure 4 defines when the STag, Queue Number, and Tagged Offset fields MUST be provided for each RDMA Message.
図4は、いつSTag、Queue Number、およびTagged Offset野原を各RDMA Messageに提供しなければならないかを定義します。
Recio, et al. Standards Track [Page 20] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[20ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
For this version of the RDMAP, all RDMA Messages MUST have:
すべてのRDMA Messagesには、RDMAPのこのバージョンのために、以下がなければなりません。
* Bits 24-25; RDMA Version field: 01b for an RNIC that complies with
this RDMA protocol specification. 00b for an RNIC that complies
with the RDMA Consortium's RDMA protocol specification. Both
version numbers are valid. Interoperability is dependent on MPA
protocol version negotiation (e.g., MPA marker and MPA CRC).
* ビット24-25。 RDMAバージョン分野: このRDMAプロトコル仕様に従うRNICのための01b。 RDMA ConsortiumのRDMAプロトコル仕様に従うRNICのための00b。 両方のバージョン番号は有効です。 相互運用性はMPAプロトコルバージョン交渉(例えば、MPAマーカーとMPA CRC)に依存しています。
* Bits 26-27; Reserved. MUST be set to zero by sender, ignored by
the receiver.
* ビット26-27。 予約にされる。 受信機によって無視された送付者はゼロに設定しなければなりません。
* Bits 28-31; OpCode field: see Figure 4.
* ビット28-31。 OpCodeは以下をさばきます。 図4を見てください。
* Bits 32-63; Invalidate STag. However, this field is only valid
for Send with Invalidate and Send with Solicited Event and
Invalidate Messages (see Figure 4).
* ビット32-63。 雄ジカを無効にしてください。 しかしながら、InvalidateとSendとSolicited EventとInvalidate MessagesとSendだけに、この分野は有効です(図4を見てください)。
For Send, Send with Solicited Event, RDMA Read Request, and
Terminate, the Invalidate STag field MUST be set to zero on
transmit and ignored by the receiver.
Send、Solicited EventとSend、RDMA Read Request、およびTerminateに関しては、受信機によって伝わって、無視されて、Invalidate STag分野はゼロにオンなセットであるに違いありません。
Recio, et al. Standards Track [Page 21] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[21ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
-------+-----------+-------+------+-------+-----------+--------------
RDMA | Message | Tagged| STag | Queue | Invalidate| Message
Message| Type | Flag | and | Number| STag | Length
OpCode | | | TO | | | Communicated
| | | | | | between DDP
| | | | | | and RDMAP
-------+-----------+-------+------+-------+-----------+--------------
0000b | RDMA Write| 1 | Valid| N/A | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0001b | RDMA Read | 0 | N/A | 1 | N/A | Yes
| Request | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0010b | RDMA Read | 1 | Valid| N/A | N/A | Yes
| Response | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0011b | Send | 0 | N/A | 0 | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0100b | Send with | 0 | N/A | 0 | Valid | Yes
| Invalidate| | | | |
-------+-----------+-------+------+-------+-----------+--------------
0101b | Send with | 0 | N/A | 0 | N/A | Yes
| SE | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0110b | Send with | 0 | N/A | 0 | Valid | Yes
| SE and | | | | |
| Invalidate| | | | |
-------+-----------+-------+------+-------+-----------+--------------
0111b | Terminate | 0 | N/A | 2 | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
1000b | |
to | Reserved | Not Specified
1111b | |
-------+-----------+-------------------------------------------------
-------+-----------+-------+------+-------+-----------+-------------- RDMA| メッセージ| タグ付けをされます。| 雄ジカ| 待ち行列| 無効にします。| メッセージメッセージ| タイプ| 旗| そして| 数| 雄ジカ| 長さのOpCode| | | to| | | 交信します。| | | | | | DDPの間で| | | | | | そして、RDMAP-------+-----------+-------+------+-------+-----------+-------------- 0000b| RDMAは書きます。| 1 | 有効| なし| なし| はい| | | | | | -------+-----------+-------+------+-------+-----------+-------------- 0001b| RDMAは読みます。| 0 | なし| 1 | なし| はい| 要求| | | | | -------+-----------+-------+------+-------+-----------+-------------- 0010b| RDMAは読みます。| 1 | 有効| なし| なし| はい| 応答| | | | | -------+-----------+-------+------+-------+-----------+-------------- 0011b| 発信してください。| 0 | なし| 0 | なし| はい| | | | | | -------+-----------+-------+------+-------+-----------+-------------- 0100b| 発信します。| 0 | なし| 0 | 有効| はい| 無効にします。| | | | | -------+-----------+-------+------+-------+-----------+-------------- 0101b| 発信します。| 0 | なし| 0 | なし| はい| SE| | | | | -------+-----------+-------+------+-------+-----------+-------------- 0110b| 発信します。| 0 | なし| 0 | 有効| はい| そしてSE。| | | | | | 無効にします。| | | | | -------+-----------+-------+------+-------+-----------+-------------- 0111b| 終わってください。| 0 | なし| 2 | なし| はい| | | | | | -------+-----------+-------+------+-------+-----------+-------------- 1000b| | to| 予約されます。| 指定された1111bでない| | -------+-----------+-------------------------------------------------
Figure 4: RDMA Usage of DDP Fields
図4: DDP分野のRDMA用法
Note: N/A means Not Applicable.
以下に注意してください。 N/AはNot Applicableを意味します。
Recio, et al. Standards Track [Page 22] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[22ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
4.2. RDMA Message Definitions
4.2. RDMAメッセージ定義
The following figure defines which RDMA Headers MUST be used on each RDMA Message and which RDMA Messages are allowed to carry ULP Payload:
以下の図は、どのRDMA Messagesが各RDMA MessageでどのRDMA Headersを使用しなければならないか、そして、ULP有効搭載量を運ぶことができるかを定義します:
-------+-----------+-------------------+-------------------------
RDMA | Message | RDMA Header Used | ULP Message allowed in
Message| Type | | the RDMA Message
OpCode | | |
| | |
-------+-----------+-------------------+-------------------------
0000b | RDMA Write| None | Yes
| | |
-------+-----------+-------------------+-------------------------
0001b | RDMA Read | RDMA Read Request | No
| Request | Header |
-------+-----------+-------------------+-------------------------
0010b | RDMA Read | None | Yes
| Response | |
-------+-----------+-------------------+-------------------------
0011b | Send | None | Yes
| | |
-------+-----------+-------------------+-------------------------
0100b | Send with | None | Yes
| Invalidate| |
-------+-----------+-------------------+-------------------------
0101b | Send with | None | Yes
| SE | |
-------+-----------+-------------------+-------------------------
0110b | Send with | None | Yes
| SE and | |
| Invalidate| |
-------+-----------+-------------------+-------------------------
0111b | Terminate | Terminate Header | No
| | |
-------+-----------+-------------------+-------------------------
1000b | |
to | Reserved | Not Specified
1111b | |
-------+-----------+-------------------+-------------------------
-------+-----------+-------------------+------------------------- RDMA| メッセージ| 使用されるRDMAヘッダー| Messageに許容されたULP Message| タイプ| | RDMAメッセージOpCode| | | | | | -------+-----------+-------------------+------------------------- 0000b| RDMAは書きます。| なし| はい| | | -------+-----------+-------------------+------------------------- 0001b| RDMAは読みます。| RDMA読み出し要求| いいえ| 要求| ヘッダー| -------+-----------+-------------------+------------------------- 0010b| RDMAは読みます。| なし| はい| 応答| | -------+-----------+-------------------+------------------------- 0011b| 発信してください。| なし| はい| | | -------+-----------+-------------------+------------------------- 0100b| 発信します。| なし| はい| 無効にします。| | -------+-----------+-------------------+------------------------- 0101b| 発信します。| なし| はい| SE| | -------+-----------+-------------------+------------------------- 0110b| 発信します。| なし| はい| そしてSE。| | | 無効にします。| | -------+-----------+-------------------+------------------------- 0111b| 終わってください。| ヘッダーを終えてください。| いいえ| | | -------+-----------+-------------------+------------------------- 1000b| | to| 予約されます。| 指定された1111bでない| | -------+-----------+-------------------+-------------------------
Figure 5: RDMA Message Definitions
図5: RDMAメッセージ定義
Recio, et al. Standards Track [Page 23] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[23ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
4.3. RDMA Write Header
4.3. RDMAはヘッダーに書きます。
The RDMA Write Message does not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The RDMA Write Message is fully described by the DDP Headers of the DDP Segments associated with the Message.
RDMA Write MessageはRDMAPヘッダーを含んでいません。 RDMAP層はDDP層にRDMAP Control Fieldを渡します。 RDMA Write MessageはMessageに関連しているDDP SegmentsのDDP Headersによって完全に説明されます。
See Appendix A for a description of the DDP Segment format associated with RDMA Write Messages.
RDMA Write Messagesに関連しているDDP Segment形式の記述に関してAppendix Aを見てください。
4.4. RDMA Read Request Header
4.4. RDMA読み出し要求ヘッダー
The RDMA Read Request Message carries an RDMA Read Request Header that describes the Data Sink and Data Source Buffers used by the RDMA Read operation. The RDMA Read Request Header immediately follows the DDP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The following figure depicts the RDMA Read Request Header that MUST be used for all RDMA Read Request Messages:
RDMA Read Request MessageはData Sinkについて説明するRDMA Read Request HeaderとRDMA Read操作で使用されるData Source Buffersを運びます。 RDMA Read Request Headerはすぐに、DDPヘッダーに続きます。 RDMAP層はDDP層にRDMAP Control Fieldを渡します。 以下の図はすべてのRDMA Read Request Messagesに使用しなければならないRDMA Read Request Headerについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag (SinkSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Sink Tagged Offset (SinkTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Message Size (RDMARDSZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source STag (SrcSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Source Tagged Offset (SrcTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ受信端末雄ジカ(SinkSTag)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タグ付けをされたデータ受信端末は(SinkTO)+を相殺しました。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDMA既読メッセージサイズ(RDMARDSZ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ送信端末雄ジカ(SrcSTag)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タグ付けをされたデータ送信端末は(SrcTO)+を相殺しました。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RDMA Read Request Header Format
図6: RDMA読み出し要求ヘッダー形式
Data Sink Steering Tag: 32 bits.
データ受信端末操縦タグ: 32ビット。
The Data Sink Steering Tag identifies the Data Sink's Tagged
Buffer. This field MUST be copied, without interpretation,
from the RDMA Read Request into the corresponding RDMA Read
Response; this field allows the Data Sink to place the
returning data. The STag is associated with the RDMAP Stream
through a mechanism that is outside the scope of the RDMAP
specification.
Data Sink Steering TagはData SinkのTagged Bufferを特定します。 解釈なしでRDMA Read Requestから対応するRDMA Read Responseにこの分野をコピーしなければなりません。 この分野で、Data Sinkは戻っているデータを置くことができます。 STagはRDMAP仕様の範囲の外にあるメカニズムを通したRDMAP Streamに関連しています。
Recio, et al. Standards Track [Page 24] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[24ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Data Sink Tagged Offset: 64 bits.
データ受信端末のタグ付けをされたオフセット: 64ビット。
The Data Sink Tagged Offset specifies the starting offset, in
octets, from the base of the Data Sink's Tagged Buffer, where
the data is to be written by the Data Source. This field is
copied from the RDMA Read Request into the corresponding RDMA
Read Response and allows the Data Sink to place the returning
data. The Data Sink Tagged Offset MAY start at an arbitrary
offset.
Data Sink Tagged Offsetは始めのオフセットを指定します、八重奏で、Data SinkのTagged Bufferのベースから。(そこでは、データはData Sourceによって書かれていることです)。 この分野は、RDMA Read Requestから対応するRDMA Read Responseにコピーされて、Data Sinkが戻っているデータを置くのを許容します。 Data Sink Tagged Offsetは任意のオフセットのときに始まるかもしれません。
The Data Sink STag and Data Sink Tagged Offset fields
describe the buffer to which the RDMA Read data is written.
Data Sink STagとData Sink Tagged Offset分野はRDMA Readデータが書かれているバッファについて説明します。
Note: the DDP layer protects against a wrap of the Data Sink
Tagged Offset.
以下に注意してください。 DDP層はData Sink Tagged Offsetの包装から守ります。
RDMA Read Message Size: 32 bits.
RDMAはメッセージサイズを読みます: 32ビット。
The RDMA Read Message Size is the amount of data, in octets,
read from the Data Source. A single RDMA Read Request
Message can retrieve from 0 to 2^32-1 data octets from the
Data Source.
RDMA Read Message SizeはData Sourceから読まれた八重奏でデータ量です。 独身のRDMA Read Request MessageはData Sourceから^32-1データ八重奏を0〜2まで検索できます。
Data Source Steering Tag: 32 bits.
データ送信端末操縦タグ: 32ビット。
The Data Source Steering Tag identifies the Data Source's
Tagged Buffer. The STag is associated with the RDMAP Stream
through a mechanism that is outside the scope of the RDMAP
specification.
Data Source Steering TagはData SourceのTagged Bufferを特定します。 STagはRDMAP仕様の範囲の外にあるメカニズムを通したRDMAP Streamに関連しています。
Data Source Tagged Offset: 64 bits.
データ送信端末のタグ付けをされたオフセット: 64ビット。
The Tagged Offset specifies the starting offset, in octets,
that is to be read from the Data Source's Tagged Buffer. The
Data Source Tagged Offset MAY start at an arbitrary offset.
Tagged OffsetはData SourceのTagged Bufferから読まれることになっている八重奏で相殺された始めを指定します。 Data Source Tagged Offsetは任意のオフセットのときに始まるかもしれません。
The Data Source STag and Data Source Tagged Offset fields
describe the buffer from which the RDMA Read data is read.
Data Source STagとData Source Tagged Offset分野はRDMA Readデータが読まれるバッファについて説明します。
See Section 7.2, "Errors Detected at the Remote Peer on Incoming RDMA Messages", for a description of error checking required upon processing of an RDMA Read Request at the Data Source.
セクション7.2、「入って来るRDMAメッセージにリモート同輩に検出された誤り」を見てください、RDMA Read Requestの処理のときにData Sourceで必要であった誤りの照合の記述のために。
Recio, et al. Standards Track [Page 25] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[25ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
4.5. RDMA Read Response Header
4.5. RDMAは応答ヘッダを読みます。
The RDMA Read Response Message does not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The RDMA Read Response Message is fully described by the DDP Headers of the DDP Segments associated with the Message.
RDMA Read Response MessageはRDMAPヘッダーを含んでいません。 RDMAP層はDDP層にRDMAP Control Fieldを渡します。 RDMA Read Response MessageはMessageに関連しているDDP SegmentsのDDP Headersによって完全に説明されます。
See Appendix A for a description of the DDP Segment format associated with RDMA Read Response Messages.
RDMA Read Response Messagesに関連しているDDP Segment形式の記述に関してAppendix Aを見てください。
4.6. Send Header and Send with Solicited Event Header
4.6. ヘッダーを送ってください、そして、請求されたイベントヘッダーと共に発信してください。
The Send and Send with Solicited Event Messages do not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The Send and Send with Solicited Event Messages are fully described by the DDP Headers of the DDP Segments associated with the Messages.
Solicited Event MessagesとSendとSendはRDMAPヘッダーを含んでいません。 RDMAP層はDDP層にRDMAP Control Fieldを渡します。 Solicited Event MessagesとSendとSendはMessagesに関連しているDDP SegmentsのDDP Headersによって完全に説明されます。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
Solicited Event Messagesと共にSendとSendに関連しているDDP Segment形式の記述に関してAppendix Aを見てください。
4.7. Send with Invalidate Header and Send with SE and Invalidate Header
4.7. 発信する、ヘッダーを無効にしてください、そして、SEと共に発信してください、そして、ヘッダーを無効にしてください。
The Send with Invalidate and Send with Solicited Event and Invalidate Messages do not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field and the Invalidate STag field (see section 4.1 RDMAP Control and Invalidate STag Field). The Send with Invalidate and Send with Solicited Event and Invalidate Messages are fully described by the DDP Headers of the DDP Segments associated with the Messages.
InvalidateとSendとSolicited EventとInvalidate MessagesとSendはRDMAPヘッダーを含んでいません。 RDMAP層はRDMAP Control FieldとInvalidate STag野原をDDP層に渡します(セクション4.1のRDMAP ControlとInvalidate STag Fieldを見てください)。 InvalidateとSendとSolicited EventとInvalidate MessagesとSendはMessagesに関連しているDDP SegmentsのDDP Headersによって完全に説明されます。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
Solicited Event Messagesと共にSendとSendに関連しているDDP Segment形式の記述に関してAppendix Aを見てください。
4.8. Terminate Header
4.8. ヘッダーを終えてください。
The Terminate Message carries a Terminate Header that contains additional information associated with the cause of the Terminate. The Terminate Header immediately follows the DDP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The following figure depicts a Terminate Header that MUST be used for the Terminate Message:
Terminate MessageはTerminateの原因に関連している追加情報を含むTerminate Headerを運びます。 Terminate Headerはすぐに、DDPヘッダーに続きます。 RDMAP層はDDP層にRDMAP Control Fieldを渡します。 以下の図はTerminate Messageに使用しなければならないTerminate Headerについて表現します:
Recio, et al. Standards Track [Page 26] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[26ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Terminate Control | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Segment Length (if any) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// //
| Terminated DDP Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
| Terminated RDMA Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールを終えてください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (もしあれば)のDDP Segment Length| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | // // | 終えられたDDP Header(もしあれば)| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // // | 終えられたRDMA Header(もしあれば)| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Terminate Header Format
図7: ヘッダー形式を終えてください。
Terminate Control: 19 bits.
コントロールを終えてください: 19ビット。
The Terminate Control field MUST have the format defined in
Figure 8 below.
Terminate Control分野には、以下の図8で定義された書式がなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Layer | EType | Error Code |HdrCt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 層| EType| エラーコード|HdrCt| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Terminate Control Field
エイト環: 制御フィールドを終えてください。
* Figure 9, "Terminate Control Field Values", defines the valid
values that MUST be used for this field.
* 「制御フィールド値を終えてください」という図9はこの分野に使用しなければならない有効値を定義します。
* Layer: 4 bits.
* 以下を層にしてください。 4ビット。
Identifies the layer that encountered the error.
誤りに遭遇した層を特定します。
* EType (RDMA Error Type): 4 bits.
* EType(RDMA誤りタイプ): 4ビット。
Identifies the type of error that caused the Terminate. When
the error is detected at the RDMAP layer, the RDMAP layer
inserts the Error Type into this field. When the error is
detected at an LLP layer, an LLP layer creates the Error Type
Terminateを引き起こした誤りのタイプを特定します。 誤りがRDMAP層に検出されるとき、RDMAP層はこの分野にError Typeを挿入します。 誤りがLLP層に検出されるとき、LLP層はError Typeを作成します。
Recio, et al. Standards Track [Page 27] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[27ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
and the DDP layer passes it up to the RDMAP layer, and the
RDMAP layer inserts it into this field.
そして、DDP層はそれをRDMAP層まで向かわせます、そして、RDMAP層はこの分野にそれを挿入します。
* Error Code: 8 bits.
* エラーコード: 8ビット。
This field identifies the specific error that caused the
Terminate. When the error is detected at the RDMAP layer, the
RDMAP layer creates the Error Code. When the error is detected
at an LLP layer, the LLP layer creates the Error Code, the DDP
layer passes it up to the RDMAP layer, and the RDMAP layer
inserts it into this field.
この分野はTerminateを引き起こした特定の誤りを特定します。 誤りがRDMAP層に検出されるとき、RDMAP層はError Codeを作成します。 誤りがLLP層に検出されるとき、LLP層はError Codeを作成します、そして、DDP層はそれをRDMAP層まで向かわせます、そして、RDMAP層はこの分野にそれを挿入します。
* HdrCt: 3 bits.
* HdrCt: 3ビット。
Header control bits:
ヘッダ制御ビット:
* M: bit 16. DDP Segment Length valid. See Figure 10 for
when this bit SHOULD be set.
* M: ビット16。 DDP、Segment Length有効です。 これがSHOULDに噛み付いた時の間の図10が設定されるのを見てください。
* D: bit 17. DDP Header Included. See Figure 10 for when
this bit SHOULD be set.
* D: ビット17。 DDPヘッダーを含んでいます。 これがSHOULDに噛み付いた時の間の図10が設定されるのを見てください。
* R: bit 18. RDMAP Header Included. See Figure 10 for when
this bit SHOULD be set.
* R: ビット18。 RDMAPヘッダーを含んでいます。 これがSHOULDに噛み付いた時の間の図10が設定されるのを見てください。
Recio, et al. Standards Track [Page 28] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[28ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
-------+-----------+-------+-------------+------+--------------------
Layer | Layer | Error | Error Type | Error| Error Code Name
| Name | Type | Name | Code |
-------+-----------+-------+-------------+------+--------------------
| | 0000b | Local | None | None - This error
| | | Catastrophic| | type does not have
| | | Error | | an error code. Any
| | | | | value in this field
| | | | | is acceptable.
| +-------+-------------+------+--------------------
| | | | 00X | Invalid STag
| | | +------+--------------------
| | | | 01X | Base or bounds
| | | | | violation
| | | Remote +------+--------------------
| | 0001b | Protection | 02X | Access rights
| | | Error | | violation
| | | +------+--------------------
0000b | RDMA | | | 03X | STag not associated
| | | | | with RDMAP Stream
| | | +------+--------------------
| | | | 04X | TO wrap
| | | +------+--------------------
| | | | 09X | STag cannot be
| | | | | Invalidated
| | | +------+--------------------
| | | | FFX | Unspecified Error
| +-------+-------------+------+--------------------
| | | | 05X | Invalid RDMAP
| | | | | version
| | | +------+--------------------
| | | | 06X | Unexpected OpCode
| | | Remote +------+--------------------
| | 0010b | Operation | 07X | Catastrophic error,
| | | Error | | localized to RDMAP
| | | | | Stream
| | | +------+--------------------
| | | | 08X | Catastrophic error,
| | | | | global
| | | +------+--------------------
| | | | 09X | STag cannot be
| | | | | Invalidated
| | | +------+--------------------
| | | | FFX | Unspecified Error
-------+-----------+-------+-------------+------+-------------------- 層| 層| 誤り| 誤りタイプ| 誤り| エラーコード名| 名前| タイプ| 名前| コード| -------+-----------+-------+-------------+------+-------------------- | | 0000b| ローカル| なし| なにも--この誤り| | | 壊滅的| | タイプは持っていません。| | | 誤り| | エラーコード。 いくらか| | | | | この分野の値| | | | | 許容できる。 | +-------+-------------+------+-------------------- | | | | 00X| 無効の雄ジカ| | | +------+-------------------- | | | | 01X| 基地か領域| | | | | 違反| | | リモート+------+-------------------- | | 0001b| 保護| 02X| アクセス権| | | 誤り| | 違反| | | +------+-------------------- 0000b| RDMA| | | 03X| STagは交際しませんでした。| | | | | RDMAPストリームで| | | +------+-------------------- | | | | 04X| TO包装| | | +------+-------------------- | | | | 09X| STagはそうであるはずがありません。| | | | | 無効にされます。| | | +------+-------------------- | | | | FFX| 不特定の誤り| +-------+-------------+------+-------------------- | | | | 05X| 無効のRDMAP| | | | | バージョン| | | +------+-------------------- | | | | 06X| 予期していなかったOpCode| | | リモート+------+-------------------- | | 0010b| 操作| 07X| 壊滅的な誤り| | | 誤り| | RDMAPにローカライズされます。| | | | | ストリーム| | | +------+-------------------- | | | | 08X| 壊滅的な誤り| | | | | グローバル| | | +------+-------------------- | | | | 09X| STagはそうであるはずがありません。| | | | | 無効にされます。| | | +------+-------------------- | | | | FFX| 不特定の誤り
Recio, et al. Standards Track [Page 29] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[29ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
-------+-----------+-------+-------------+------+--------------------
0001b | DDP | See DDP Specification [DDP] for a description of
| | the values and names.
-------+-----------+-------+-----------------------------------------
0010b | LLP | For MPA, see MPA Specification [MPA] for a
|(e.g., MPA)| description of the values and names.
-------+-----------+-------+-----------------------------------------
-------+-----------+-------+-------------+------+-------------------- 0001b| DDP| 記述のためのDDP Specification[DDP]を見ます。| | 値と名前。 -------+-----------+-------+----------------------------------------- 0010b| LLP| MPAに関しては、aのために、MPA Specification[MPA]を見てください。|(例えば、MPA)| 値と名前の記述。 -------+-----------+-------+-----------------------------------------
Figure 9: Terminate Control Field Values
図9: 制御フィールド値を終えてください。
Reserved: 13 bits. This field MUST be set to zero on transmit,
ignored on receive.
予約される: 13ビット。 この分野が無視されて、ゼロにオンなセットが伝わるということであるに違いない、オンである、受信してください。
DDP Segment Length: 16 bits
DDPセグメントの長さ: 16ビット
The length handed up by the DDP layer when the error was
detected. It MUST be valid if the M bit is set. It MUST be
present when the D bit is set.
誤りが検出されたときDDP層によって手渡された長さ。 Mビットが設定されるなら、有効であるに違いありません。 Dビットが設定されるとき、それは存在していなければなりません。
Terminated DDP Header: 112 bits for Tagged Messages and 144 bits
for Untagged Messages.
終えられたDDPヘッダー: Tagged Messagesのための112ビットとUntagged Messagesのための144ビット。
The DDP Header of the incoming Message that is associated
with the Terminate. The DDP Header is not present if the
Terminate Error Type is a Local Catastrophic Error. It MUST
be present if the D bit is set.
Terminateに関連している入って来るMessageのDDP Header。 DDP HeaderはTerminate Error TypeがLocal Catastrophic Errorであるなら存在していません。 Dビットが設定されるなら、存在していなければなりません。
Terminated RDMA Header: 224 bits.
終えられたRDMAヘッダー: 224ビット。
The Terminated RDMA Header is only sent back if the terminate
is associated with an RDMA Read Request Message. It MUST be
present if the R bit is set.
終わってください。Terminated RDMA Headerが返送されるだけである、RDMA Read Request Messageに関連づけられます。 Rビットが設定されるなら、存在していなければなりません。
If the terminate occurs before the first RDMA Read Request
byte is processed, the original RDMA Read Request Header is
sent back.
終わってください。最初のRDMA Read Requestバイトがことになる処理されています、オリジナルのRDMA Read Request Headerを送るという前に起こり返します。
If the terminate occurs after the first RDMA Read Request
byte is processed, the RDMA Read Request Header is updated to
reflect the current location of the RDMA Read operation that
is in process:
終わり、最初のRDMA Read Requestバイトがことになった処理されています、現在の位置を反映するためにRDMA Read Request Headerをアップデートするという後に中に以下を処理することであるRDMA Read操作は起こります。
* Data Sink STag = Data Sink STag originally sent in the
RDMA Read Request.
* データデータSink STag=Sink STagは元々、RDMA Read Requestを送りました。
Recio, et al. Standards Track [Page 30] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[30ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* Data Sink Tagged Offset = Current offset into the Data
Sink Tagged Buffer. For example, if the RDMA Read
Request was terminated after 2048 octets were sent,
then the Data Sink Tagged Offset = the original Data
Sink Tagged Offset + 2048.
* データSink Tagged OffsetはData Sink Tagged Bufferに相殺された電流と等しいです。 + 例えば、2048年以降RDMA Read Requestを終えたなら、八重奏を送って、オリジナルの次に、Data Sink Tagged Offset=Data Sink Tagged Offsetは2048です。
* Data Message size = Number of bytes left to transfer.
* データMessageサイズは移すのを残っているバイト数と等しいです。
* Data Source STag = Data Source STag in the RDMA Read
Request.
* 男一人でデータ送信端末はRDMA読み出し要求で男一人でデータ送信端末と等しいです。
* Data Source Tagged Offset = Current offset into the
Data Source Tagged Buffer. For example, if the RDMA
Read Request was terminated after 2048 octets were
sent, then the Data Source Tagged Offset = the
original Data Source Tagged Offset + 2048.
* データSource Tagged OffsetはData Source Tagged Bufferに相殺された電流と等しいです。 + 例えば、2048年以降RDMA Read Requestを終えたなら、八重奏を送って、オリジナルの次に、Data Source Tagged Offset=Data Source Tagged Offsetは2048です。
Note: if a given LLP does not define any termination codes for the RDMAP Termination message to use, then none would be used for that LLP.
以下に注意してください。 与えられたLLPが使用するRDMAP Terminationメッセージのために少しの終了コードも定義しないなら、なにもそのLLPに使用されないでしょう。
Figure 10, "Error Type to RDMA Message Mapping", maps layer name and error types to each RDMA Message type:
「RDMAメッセージマッピングへの誤りタイプ」という図10は層の名を写像します、そして、各RDMA Messageへの誤りタイプはタイプします:
Recio, et al. Standards Track [Page 31] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[31ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
---------+-------------+------------+------------+-----------------
Layer | Error Type | Terminate | Terminate | What type of
Name | Name | Includes | Includes | RDMA Message can
| | DDP Header | RDMA Header| cause the error
| | and DDP | |
| | Segment | |
| | Length | |
---------+-------------+------------+------------+-----------------
| Local | No | No | Any
| Catastrophic| | |
| Error | | |
+-------------+------------+------------+-----------------
| Remote | Yes, if | Yes | Only RDMA Read
RDMA | Protection | possible | | Request, Send
| Error | | | with Invalidate,
| | | | and Send with SE
| | | | and Invalidate
+-------------+------------+------------+-----------------
| Remote | Yes, if | No | Any
| Operation | possible | |
| Error | | |
---------+-------------+------------+------------+-----------------
DDP | See DDP Spec| Yes | No | Any
| [DDP] | | |
---------+-------------+------------+------------+-----------------
LLP | See LLP Spec| No | No | Any
| (e.g., MPA) | | |
---------+-------------+------------+------------+----------------- 層| 誤りタイプ| 終わってください。| 終わってください。| Nameの何というタイプ| 名前| インクルード| インクルード| RDMAメッセージはそうすることができます。| | DDPヘッダー| RDMAヘッダー| 誤りを引き起こしてください。| | そして、DDP| | | | セグメント| | | | 長さ| | ---------+-------------+------------+------------+----------------- | ローカル| いいえ| いいえ| いくらか| 壊滅的| | | | 誤り| | | +-------------+------------+------------+----------------- | リモート| はい| はい| RDMAだけがRDMAを読みます。| 保護| 可能| | 発信するよう要求してください。| 誤り| | | 無効にする| | | | そして、SEと共に発信してください。| | | | そして、+を無効にしてください。-------------+------------+------------+----------------- | リモート| はい| いいえ| いくらか| 操作| 可能| | | 誤り| | | ---------+-------------+------------+------------+----------------- DDP| DDP仕様を見てください。| はい| いいえ| いくらか| [DDP]| | | ---------+-------------+------------+------------+----------------- LLP| LLP仕様を見てください。| いいえ| いいえ| いくらか| (例えば、MPA) | | |
Figure 10: Error Type to RDMA Message Mapping
図10: RDMAメッセージマッピングへの誤りタイプ
5. Data Transfer
5. データ転送
5.1. RDMA Write Message
5.1. RDMAはメッセージを書きます。
An RDMA Write is used by the Data Source to transfer data to a previously Advertised Tagged Buffer at the Data Sink. The RDMA Write Message has the following semantics:
RDMA Writeは、以前にデータをaに移すのにData Sourceによって使用されます。Data SinkのAdvertised Tagged Buffer。 RDMA Write Messageには、以下の意味論があります:
* An RDMA Write Message MUST reference a Tagged Buffer. That is,
the Data Source RDMAP layer MUST request that the DDP layer mark
the Message as Tagged.
* RDMA Write MessageはTagged Bufferに参照をつけなければなりません。 すなわち、Data Source RDMAP層は、DDP層がTaggedとしてMessageをマークするよう要求しなければなりません。
* A valid RDMA Write Message MUST NOT be delivered to the Data
Sink's ULP (i.e., it is placed by the DDP layer).
* 有効なRDMA Write MessageをData SinkのULPに提供してはいけません(すなわち、それはDDP層のそばに置かれます)。
* At the Remote Peer, when an invalid RDMA Write Message is
delivered to the Remote Peer's RDMAP layer, an error is surfaced
(see Section 7.1, "RDMAP Error Surfacing").
* 無効のRDMA Write MessageがRemote PeerのRDMAP層に提供されるとき、Remote Peerでは、誤りは表面を仕上げられています(セクション7.1を見てください、「RDMAP誤りは表面化し」て)。
Recio, et al. Standards Track [Page 32] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[32ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* The Tagged Offset of a Tagged Buffer MAY start at a non-zero
value.
* Tagged BufferのTagged Offsetは非ゼロ値で始まるかもしれません。
* An RDMA Write Message MAY target all or part of a previously
Advertised Buffer.
* RDMA Write Messageは以前に、aのすべてか一部を狙うかもしれません。Advertised Buffer。
* The RDMAP does not define how the buffer(s) are used by an
outbound RDMA Write or how they are addressed. For example, an
implementation of RDMA may choose to allow a gather-list of non-
contiguous data blocks to be the source of an RDMA Write. In this
case, the data blocks would be combined by the Data Source and
sent as a single RDMA Write Message to the Data Sink.
* RDMAPは、バッファが外国行きのRDMA Writeによってどのように使用されるか、そして、またはそれらがどのように扱われるかを定義しません。 例えば、RDMAの実装は、リストを集めている非隣接のデータ・ブロックがRDMA Writeの源であることを許容するのを選ぶかもしれません。 この場合、データ・ブロックをData Sourceが結合して、独身のRDMA Write MessageとしてData Sinkに送るでしょう。
* The Data Source RDMAP layer MUST issue RDMA Write Messages to the
DDP layer in the order they were submitted by the ULP.
* ULPによって提出されていた状態で、層がDDPへのRDMA Write Messagesを発行しなければならないData Source RDMAPは中で彼らがオーダーであったのを層にします。
* At the Data Source, a subsequent Send (Send with Invalidate, Send
with Solicited Event, or Send with Solicited Event and Invalidate)
Message MAY be used to signal Delivery of previous RDMA Write
Messages to the Data Sink, if the ULP chooses to signal Delivery
in this fashion.
* Solicited EventとSend、またはSolicited EventとInvalidate) メッセージがあるSendはそうするかもしれません。Data Source、aその後のSend、(Invalidateと共に発信してください、使用されて、前のRDMA Write MessagesのDeliveryにData Sinkに合図してください、ULPが、こんなやり方でDeliveryに合図するのを選ぶなら。
* If the Local Peer wishes to write to multiple Tagged Buffers on
the Remote Peer, the Local Peer MUST use multiple RDMA Write
Messages. That is, a single RDMA Write Message can only write to
one remote Tagged Buffer.
* Local PeerがRemote Peerの上の複数のTagged Buffersに書きたいなら、Local Peerは複数のRDMA Write Messagesを使用しなければなりません。 すなわち、独身のRDMA Write Messageは1リモートTagged Bufferまで書くことができるだけです。
* The Data Source MAY issue a zero-length RDMA Write Message.
* Data Sourceは無の長さのRDMA Write Messageを発行するかもしれません。
5.2. RDMA Read Operation
5.2. RDMAは操作を読みます。
The RDMA Read operation MUST consist of a single RDMA Read Request Message and a single RDMA Read Response Message.
RDMA Read操作は独身のRDMA Read Request Messageと独身のRDMA Read Response Messageから成らなければなりません。
5.2.1. RDMA Read Request Message
5.2.1. RDMAは要求メッセージを読みます。
An RDMA Read Request is used by the Data Sink to transfer data from a previously Advertised Tagged Buffer at the Data Source to a Tagged Buffer at the Data Sink. The RDMA Read Request Message has the following semantics:
RDMA Read Requestがデータを移すのにData Sinkによって使用される、以前に、Advertised Tagged Buffer、Data SinkのTagged BufferへのData Sourceで。 RDMA Read Request Messageには、以下の意味論があります:
* An RDMA Read Request Message MUST reference an Untagged Buffer.
That is, the Local Peer's RDMAP layer MUST request that the DDP
mark the Message as Untagged.
* RDMA Read Request MessageはUntagged Bufferに参照をつけなければなりません。 すなわち、Local PeerのRDMAP層は、DDPがUntaggedとしてMessageをマークするよう要求しなければなりません。
* One RDMA Read Request Message MUST consume one Untagged Buffer.
* 1RDMA Read Request Messageが1Untagged Bufferを消費しなければなりません。
Recio, et al. Standards Track [Page 33] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[33ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* The Remote Peer's RDMAP layer MUST process an RDMA Read Request
Message. A valid RDMA Read Request Message MUST NOT be delivered
to the Data Sink's ULP (i.e., it is processed by the RDMAP layer).
* Remote PeerのRDMAP層はRDMA Read Request Messageを処理しなければなりません。 有効なRDMA Read Request MessageをData SinkのULPに提供してはいけません(すなわち、それはRDMAP層によって処理されます)。
* At the Remote Peer, when an invalid RDMA Read Request Message is
delivered to the Remote Peer's RDMAP layer, an error is surfaced
(see Section 7.1, "RDMAP Error Surfacing").
* 無効のRDMA Read Request MessageがRemote PeerのRDMAP層に提供されるとき、Remote Peerでは、誤りは表面を仕上げられています(セクション7.1を見てください、「RDMAP誤りは表面化し」て)。
* An RDMA Read Request Message MUST reference the RDMA Read Request
Queue. That is, the Local Peer's RDMAP layer MUST request that
the DDP layer set the Queue Number field to one.
* RDMA Read Request MessageはRDMA Read Request Queueに参照をつけなければなりません。 すなわち、Local PeerのRDMAP層は、DDP層がQueue Number分野を1つに設定したよう要求しなければなりません。
* The Local Peer MUST pass to the DDP layer RDMA Read Request
Messages in the order they were submitted by the ULP.
* ULPによって提出されていた状態で、Local Peerは中のDDP RDMA Read Request Messages層に彼らがオーダーであったのに合格しなければなりません。
* The Remote Peer MUST process the RDMA Read Request Messages in the
order they were sent.
* Remote Peerは彼らが送られたオーダーでRDMA Read Request Messagesを処理しなければなりません。
* If the Local Peer wishes to read from multiple Tagged Buffers on
the Remote Peer, the Local Peer MUST use multiple RDMA Read
Request Messages. That is, a single RDMA Read Request Message
MUST only read from one remote Tagged Buffer.
* Local PeerがRemote Peerの上の複数のTagged Buffersから読みたいなら、Local Peerは複数のRDMA Read Request Messagesを使用しなければなりません。 すなわち、独身のRDMA Read Request Messageは1リモートTagged Bufferから読むだけでよいです。
* AN RDMA Read Request Message MAY target all or part of a
previously Advertised Buffer.
* AN RDMA Read Request Messageは以前に、aのすべてか一部を狙うかもしれません。Advertised Buffer。
* If the Data Source receives a valid RDMA Read Request Message, it
MUST respond with a valid RDMA Read Response Message.
* Data Sourceが有効なRDMA Read Request Messageを受けるなら、それは有効なRDMA Read Response Messageと共に応じなければなりません。
* The Data Sink MAY issue a zero-length RDMA Read Request Message by
setting the RDMA Read Message Size field to zero in the RDMA Read
Request Header.
* Data Sinkは、RDMA Read Request HeaderのゼロにRDMA Read Message Size分野を設定することによって、無の長さのRDMA Read Request Messageを発行するかもしれません。
* If the Data Source receives a non-zero-length RDMA Read Message
Size, the Data Source RDMAP MUST validate the Data Source STag and
Data Source Tagged Offset contained in the RDMA Read Request
Header.
* Data Sourceが非ゼロ・レングスRDMA Read Message Sizeを受けるなら、Data Source RDMAPはRDMA Read Request Headerに含まれたData Source STagとData Source Tagged Offsetを有効にしなければなりません。
* If the Data Source receives an RDMA Read Request Header with the
RDMA Read Message Size set to zero, the Data Source RDMAP:
* Data Sourceが受信するなら、RDMA Read Message SizeとRDMA Read Request Headerはゼロにセットしました、Data Source RDMAP:
* MUST NOT validate the Data Source STag and Data Source Tagged
Offset contained in the RDMA Read Request Header, and
* そしてRDMA Read Request Headerに含まれたData Source STagとData Source Tagged Offsetを有効にしてはいけない。
* MUST respond with a zero-length RDMA Read Response Message.
* 無の長さのRDMA Read Response Messageと共に応じなければなりません。
Recio, et al. Standards Track [Page 34] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[34ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
5.2.2. RDMA Read Response Message
5.2.2. RDMAは応答メッセージを読みます。
The RDMA Read Response Message uses the DDP Tagged Buffer Model to Deliver the contents of a previously requested Data Source Tagged Buffer to the Data Sink, without any involvement from the ULP at the Remote Peer. The RDMA Read Response Message has the following semantics:
RDMA Read Response MessageはDDP Tagged Buffer ModelをDeliverに使用します。Remote PeerのULPからの少しもかかわり合いのないData Sinkへの以前に要求されたData Source Tagged Bufferのコンテンツ。 RDMA Read Response Messageには、以下の意味論があります:
* The RDMA Read Response Message for the associated RDMA Read
Request Message travels in the opposite direction.
* 関連RDMA Read Request MessageのためのRDMA Read Response Messageは逆方向に旅行します。
* An RDMA Read Response Message MUST reference a Tagged Buffer.
That is, the Data Source RDMAP layer MUST request that the DDP
mark the Message as Tagged.
* RDMA Read Response MessageはTagged Bufferに参照をつけなければなりません。 すなわち、Data Source RDMAP層は、DDPがTaggedとしてMessageをマークするよう要求しなければなりません。
* The Data Source MUST ensure that a sufficient number of Untagged
Buffers are available on the RDMA Read Request Queue (Queue with
DDP Queue Number 1) to support the maximum number of RDMA Read
Requests negotiated by the ULP.
* Data Sourceは、ULPによって交渉されたRDMA Read Requestsの最大数をサポートするためにUntagged Buffersの十分な数が確実にRDMA Read Request Queue(DDP Queue Number1と共に列に並ばせる)で有効になるようにしなければなりません。
* The RDMAP layer MUST Deliver the RDMA Read Response Message to the
ULP.
* RDMAP層はULPへのDeliver RDMA Read Response Messageがそうしなければなりません。
* At the Remote Peer, when an invalid RDMA Read Response Message is
delivered to the Remote Peer's RDMAP layer, an error is surfaced
(see Section 7.1, "RDMAP Error Surfacing").
* 無効のRDMA Read Response MessageがRemote PeerのRDMAP層に提供されるとき、Remote Peerでは、誤りは表面を仕上げられています(セクション7.1を見てください、「RDMAP誤りは表面化し」て)。
* The Tagged Offset of a Tagged Buffer MAY start at a non-zero
value.
* Tagged BufferのTagged Offsetは非ゼロ値で始まるかもしれません。
* The Data Source RDMAP layer MUST pass RDMA Read Response Messages
to the DDP layer, in the order that the RDMA Read Request Messages
were received by the RDMAP layer, at the Data Source.
* Data Source RDMAP層はDDP層にRDMA Read Response Messagesを渡さなければならなくて、RDMA Read Request Messagesが受け取られたオーダーでは、RDMAPは層にします、Data Sourceで。
* The Data Sink MAY validate that the STag, Tagged Offset, and
length of the RDMA Read Response Message are the same as the STag,
Tagged Offset, and length included in the corresponding RDMA Read
Request Message.
* Data Sinkは有効にするかもしれません。RDMA Read Response MessageのSTag、Tagged Offset、および長さは対応するRDMA Read Request Messageに含まれていたSTag、Tagged Offset、および長さと同じです。
* A single RDMA Read Response Message MUST write to one remote
Tagged Buffer. If the Data Sink wishes to read multiple Tagged
Buffers, the Data Sink can use multiple RDMA Read Request
Messages.
* 独身のRDMA Read Response Messageは1リモートTagged Bufferまで書かなければなりません。 Data Sinkが複数のTagged Buffersを読みたいなら、Data Sinkは複数のRDMA Read Request Messagesを使用できます。
Recio, et al. Standards Track [Page 35] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[35ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
5.3. Send Message Type
5.3. メッセージタイプを送ってください。
The Send Message Type uses the DDP Untagged Buffer Model to transfer data from the Data Source into an Untagged Buffer at the Data Sink.
Send Message Typeは、データをData SourceからData SinkのUntagged Bufferに移すのにDDP Untagged Buffer Modelを使用します。
* A Send Message Type MUST reference an Untagged Buffer. That is,
the Local Peer's RDMAP layer MUST request that the DDP layer mark
the Message as Untagged.
* Send Message TypeはUntagged Bufferに参照をつけなければなりません。 すなわち、Local PeerのRDMAP層は、DDP層がUntaggedとしてMessageをマークするよう要求しなければなりません。
* One Send Message Type MUST consume one Untagged Buffer.
* 1Send Message Typeが1Untagged Bufferを消費しなければなりません。
* The ULP Message sent using a Send Message Type MAY be less than
or equal to the size of the consumed Untagged Buffer. The
RDMAP layer communicates to the ULP the size of the data
written into the Untagged Buffer.
* Send Message Typeが使用させられたULP Messageは消費されたUntagged Bufferの、よりサイズ以下であるかもしれません。 RDMAP層はUntagged Bufferに書かれたデータのサイズをULPに伝えます。
* If the ULP Message sent via Send Message Type is larger than
the Data Sink's Untagged Buffer, it is an error (see Section
9.1, "RDMAP Error Surfacing").
* Send Message Typeを通して送られたULP MessageがData SinkのUntagged Bufferより大きいなら、それは誤り(セクション9.1を見てください、「RDMAP誤りは表面化し」て)です。
* At the Remote Peer, the Send Message Type MUST be Delivered to the
Remote Peer's ULP in the order they were sent.
* Remote Peerでは、Send Message Typeはそれらが送られたオーダーにおけるRemote PeerのULPへのDeliveredであるに違いありません。
* After the Send with Solicited Event or Send with Solicited Event
and Invalidate Message is Delivered to the ULP, the RDMAP MAY
generate an Event, if the Data Sink is configured to generate such
an Event.
* Solicited EventとSendかSolicited EventとInvalidate MessageとSendがDeliveredにULPになった後に、RDMAP MAYはイベントを生成します、Data SinkがそのようなEventを生成するために構成されるなら。
* At the Remote Peer, when an invalid Send Message Type is Delivered
to the Remote Peer's RDMAP layer, an error is surfaced (see
Section 7.1, "RDMAP Error Surfacing").
* 無効のSend Message TypeがRemote PeerのRDMAP層へのDeliveredであるときに、Remote Peerでは、誤りは表面を仕上げられています(セクション7.1を見てください、「RDMAP誤りは表面化し」て)。
* The RDMAP does not specify the structure of the buffer(s) used by
an outbound RDMA Write nor does it specify how the buffer(s) are
addressed. For example, an implementation of RDMA may choose to
allow a gather-list of non-contiguous data blocks to be the source
of a Send Message Type. In this case, the data blocks would be
combined by the Data Source and sent as a single Send Message Type
to the Data Sink.
* RDMAPは外国行きのRDMA Writeによって使用されたバッファの構造を指定しません、そして、それはバッファがどう扱われるかを指定しません。 例えば、RDMAの実装は、リストを集めている非隣接のデータ・ブロックがSend Message Typeの源であることを許容するのを選ぶかもしれません。 この場合、データ・ブロックをData Sourceが結合して、独身のSend Message TypeとしてData Sinkに送るでしょう。
* For a Send Message Type, the Local Peer's RDMAP layer MUST request
that the DDP layer set the Queue Number field to zero.
* Send Message Typeに関しては、Local PeerのRDMAP層は、DDP層がQueue Number分野をゼロに設定したよう要求しなければなりません。
* The Local Peer MUST issue Send Message Type Messages in the order
they were submitted by the ULP.
* Local Peerはオーダーにおける彼らが提出されたSend Message Type MessagesにULPを発行しなければなりません。
Recio, et al. Standards Track [Page 36] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[36ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* The Data Source MAY pass a zero-length Send Message Type. A
zero-length Send Message Type MUST consume an Untagged Buffer at
the Data Sink. A Send with Invalidate or Send with Solicited
Event and Invalidate Message MUST reference an STag. That is, the
Local Peer's RDMAP layer MUST pass the RDMA control field and the
STag that will be Invalidated to the DDP layer.
* Data Sourceは無の長さのSend Message Typeを渡すかもしれません。 無の長さのSend Message TypeはData SinkでUntagged Bufferを消費しなければなりません。 InvalidateとSendかSolicited EventとInvalidate MessageとSendがSTagに参照をつけなければなりません。 すなわち、Local PeerのRDMAP層はRDMA制御フィールドとInvalidatedになるSTagをDDP層に渡さなければなりません。
* When the Send with Invalidate and Send with Solicited Event and
Invalidate Message are Delivered to the Remote Peer's RDMAP layer,
the RDMAP layer MUST:
* InvalidateとSendとSolicited EventとInvalidate MessageとSendがRemote PeerのRDMAP層へのDeliveredであるときに、RDMAP層はDeliveredでなければなりません:
* Verify the STag that is associated with the RDMAP Stream; and
* RDMAP Streamに関連しているSTagについて確かめてください。 そして
* Invalidate the STag if it is associated with the RDMAP Stream;
or issue a Terminate Message with the STag Cannot be
Invalidated Terminate Error Code, if the STag is not associated
with the RDMAP Stream.
* それがRDMAP Streamに関連しているなら、STagを無効にしてください。 または、STag Cannotと共にTerminate Messageを発行してください。Invalidated Terminate Error Codeになってください、STagがRDMAP Streamに関連していないなら。
5.4. Terminate Message
5.4. メッセージを終えてください。
The Terminate Message uses the DDP Untagged Buffer Model to transfer-error-related information from the Data Source into an Untagged Buffer at the Data Sink and then ceases all further communications on the underlying DDP Stream. The Terminate Message has the following semantics:
Terminate MessageはData SinkでUntagged BufferへのData Sourceからの転送誤り関連の情報にDDP Untagged Buffer Modelを使用して、次に、基本的なDDP Streamでさらなるすべてのコミュニケーションをやめます。 Terminate Messageには、以下の意味論があります:
* A Terminate Message MUST reference an Untagged Buffer. That is,
the Local Peer's RDMAP layer MUST request that the DDP layer mark
the Message as Untagged.
* Terminate MessageはUntagged Bufferに参照をつけなければなりません。 すなわち、Local PeerのRDMAP層は、DDP層がUntaggedとしてMessageをマークするよう要求しなければなりません。
* A Terminate Message references the Terminate Queue. That is, the
Local Peer's RDMAP layer MUST request that the DDP layer set the
Queue Number field to two.
* Terminate MessageはTerminate Queueに参照をつけます。 すなわち、Local PeerのRDMAP層は、DDP層がQueue Number分野を2に設定したよう要求しなければなりません。
* One Terminate Message MUST consume one Untagged Buffer.
* 1Terminate Messageが1Untagged Bufferを消費しなければなりません。
* On a single RDMAP Stream, the RDMAP layer MUST guarantee placement
of a single Terminate Message.
* 独身のRDMAP Streamでは、RDMAP層は独身のTerminate Messageのプレースメントを保証しなければなりません。
* A Terminate Message MUST be Delivered to the Remote Peer's RDMAP
layer. The RDMAP layer MUST Deliver the Terminate Message to the
ULP.
* Terminate MessageはRemote PeerのRDMAP層へのDeliveredであるに違いありません。 RDMAP層はULPへのDeliver Terminate Messageがそうしなければなりません。
* At the Remote Peer, when an invalid Terminate Message is delivered
to the Remote Peer's RDMAP layer, an error is surfaced (see
Section 7.1 "RDMAP Error Surfacing").
* 無効のTerminate MessageがRemote PeerのRDMAP層に提供されるとき、Remote Peerでは、誤りは表面を仕上げられています(「RDMAP誤り表面化」というセクション7.1を見てください)。
Recio, et al. Standards Track [Page 37] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[37ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* The RDMAP layer Completes in error all ULP operations that have
not been provided to the DDP layer.
* RDMAPはCompletesを間違って層にします。DDP層に提供されるというわけではなかったすべてのULP操作。
* After sending a Terminate Message on an RDMAP Stream, the Local
Peer MUST NOT send any more Messages on that specific RDMAP
Stream.
* Terminate MessageをRDMAP Streamに送った後に、Local Peerはその特定のRDMAP Streamにそれ以上のMessagesを送ってはいけません。
* After receiving a Terminate Message on an RDMAP Stream, the Remote
Peer MAY stop sending Messages on that specific RDMAP Stream.
* RDMAP Streamの上のTerminate Messageを受けた後に、Remote Peerは、その特定のRDMAP StreamにMessagesを送るのを止めるかもしれません。
5.5. Ordering and Completions
5.5. 注文と落成
It is important to understand the difference between Placement and Delivery ordering since RDMAP provides quite different semantics for the two.
RDMAPが全く異なった意味論を2に提供するのでPlacementとDeliveryの違いが注文されるのを理解しているのは重要です。
Note that many current protocols, both as used in the Internet and elsewhere, assume that data is both Placed and Delivered in order. Taking advantage of this fact allowed applications to take a variety of shortcuts. For RDMAP, many of these shortcuts are no longer safe to use, and could cause application failure.
インターネットとほかの場所でともに使用される多くの現在のプロトコルが、データがオーダーで、PlacedとDeliveredの両方であると仮定することに注意してください。 この事実を利用するのに、アプリケーションはさまざまな近道を取ることができました。 RDMAPに関しては、これらの近道の多くが、使用するためにもう安全でなく、アプリケーション失敗を引き起こす場合がありました。
The following rules apply to implementations of the RDMAP protocol. Note that in these rules, Send includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate:
以下の規則はRDMAPプロトコルの実装に適用されます。 これらの規則では、SendがSendを含んでいるというメモ、InvalidateとSend、Solicited EventとSend、およびSolicited EventとInvalidateとSend:
1. RDMAP does not provide ordering among Messages on different RDMAP
Streams.
1. RDMAPは、異なったRDMAP Streamsの上のMessagesの中で注文しながら、提供しません。
2. RDMAP does not provide ordering between operations that are
generated from the two ends of an RDMAP Stream.
2. RDMAPは、RDMAP Streamの2つの端から生成される操作の間で注文しながら、提供しません。
3. RDMA Messages that use Tagged and Untagged Buffers MAY be Placed
in any order. If an application uses overlapping buffers (points
different Messages or portions of a single Message at the same
buffer), then it is possible that the last incoming write to the
Data Sink buffer will not be the last outgoing data sent from the
Data Source.
3. TaggedとUntagged Buffersを使用するRDMA Messagesは順不同なPlacedであるかもしれません。 アプリケーションが重なっているバッファを使用するなら(同じバッファの独身のMessageのポイントの異なったMessagesか一部)、最後の入来が最終がData Sourceから送られた発信データであるつもりであったならData Sinkバッファに書くのは、可能です。
4. For a Send operation, the contents of an Untagged Buffer at the
Data Sink MAY be indeterminate until the Send is Delivered to the
ULP at the Data Sink.
4. Send操作において、Data SinkのUntagged BufferのコンテンツはSendがData SinkのULPへのDeliveredになるまで不確定であるかもしれません。
5. For an RDMA Write operation, the contents of the Tagged Buffer at
the Data Sink MAY be indeterminate until a subsequent Send is
Delivered to the ULP at the Data Sink.
5. RDMA Write操作において、Data SinkのTagged Bufferのコンテンツはその後のSendがData SinkのULPへのDeliveredになるまで不確定であるかもしれません。
Recio, et al. Standards Track [Page 38] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[38ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
6. For an RDMA Read operation, the contents of the Tagged Buffer at
the Data Sink MAY be indeterminate until the RDMA Read Response
Message has been Delivered at the Local Peer.
6. RDMA Read操作において、Data SinkのTagged BufferのコンテンツはRDMA Read Response MessageがLocal PeerのDeliveredになるまで不確定であるかもしれません。
Statements 4, 5, and 6 imply "no peeking" at the data to see if it is done. It is possible for some data to arrive before logically earlier data does, and peeking may cause unpredictable application failure.
声明4、5、および6は、それが完了しているかどうか確認するためにデータで「覗き見でないの」を含意します。 論理的に以前のデータがそうして、覗き見が予測できないアプリケーション失敗を引き起こすかもしれない前にいくつかのデータが到着するのは、可能です。
7. If the ULP or Application modifies the contents of Tagged or
Untagged Buffers, which are being modified by an RDMA Operation
while the RDMAP is processing the RDMA Operation, the state of
the Buffers is indeterminate.
7. ULPかApplicationがRDMAPがRDMA Operationを処理している間、RDMA Operationによって変更されているTaggedかUntagged Buffersのコンテンツを変更するなら、Buffersの州は不確定です。
8. If the ULP or Application modifies the contents of Tagged or
Untagged Buffers, which are read by an RDMA Operation while the
RDMAP is processing the RDMA Operation, the results of the read
are indeterminate.
8. ULPかApplicationがRDMAPがRDMA Operationを処理している間、RDMA Operationによって読まれるTaggedかUntagged Buffersのコンテンツを変更するなら、読みの結果は不確定です。
9. The Completion of an RDMA Write or Send Operation at the Local
Peer does not guarantee that the ULP Message has yet reached the
Remote Peer ULP Buffer or been examined by the Remote ULP.
9. Local PeerのRDMA WriteかSend OperationのCompletionは、ULP MessageがまだRemote Peer ULP Bufferに達しているか、またはRemote ULPによって調べられたのを保証しません。
10. Send Messages MUST be Delivered to the ULP at the Remote Peer
after they are Delivered to RDMAP by DDP and in the order that
they were Delivered to RDMAP.
10. 彼らがDeliveredにDDPによるRDMAPになった後と注文におけるRemote PeerのULPへの彼らがそうであったDeliveredがRDMAPへのDeliveredであったに違いないならMessagesを送ってください。
Note that DDP ordering rules ensure that this will be the same
order that they were submitted at the Local Peer and that any
prior RDMA Writes have been submitted for ordered Placement at
the Remote Peer. This means that when the ULP sees the Delivery
of the Send, the memory buffers targeted by any preceding RDMA
Writes and Sends are available to be accessed locally or remotely
as authorized. If the ULP overlaps its buffers for different
operations, the data from the RDMA Write or Send may be
overwritten by subsequent RDMA Operations before the ULP receives
and processes the Delivery.
DDP注文規則が、これが同じになるのを確実にするというメモはLocal Peerでそれらを提出して、命令されたPlacementのためにRemote Peerでどんな先のRDMA Writesも提出したよう命令します。 これは、局所的か離れて認可されるようにアクセスされるためにULPがSendのDeliveryを見るとき、どんな前のRDMA WritesとSendsによっても狙われたメモリ・バッファが利用可能であることを意味します。 ULPが異なった操作のためのバッファを重ね合わせるなら、ULPがDeliveryを受けて、処理する前にRDMA WriteかSendからのデータはその後のRDMA Operationsによって上書きされるかもしれません。
11. RDMA Read Response Messages MUST be Delivered to the ULP at the
Remote Peer after they are Delivered to RDMAP by DDP and in the
order that the they were Delivered to RDMAP.
11. RDMA Read Response Messagesが彼らがDeliveredにDDPによるRDMAPになった後と注文におけるRemote PeerのULPへのDeliveredがそれであったならそうしなければならない、彼らはRDMAPへのDeliveredでした。
DDP ordering rules ensure that this will be the same order that
they were submitted at the Local Peer. This means that when the
ULP sees the Delivery of the RDMA Read Response, the memory
buffers targeted by the RDMA Read Response are available to be
accessed locally or remotely as authorized. If the ULP overlaps
DDP注文規則は、それらが同次であったのがLocal Peerで提出されていたならこれがそうするのを確実にします。 これは、局所的か離れて認可されるようにアクセスされるためにULPがRDMA Read ResponseのDeliveryを見るとき、RDMA Read Responseによって狙われたメモリ・バッファが利用可能であることを意味します。 ULPが重なるなら
Recio, et al. Standards Track [Page 39] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[39ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
its buffers for different operations, the data from the RDMA Read
Response may be overwritten by subsequent RDMA Operations before
the ULP receives and processes the Delivery.
異なった操作のためのバッファ、ULPがDeliveryを受けて、処理する前にRDMA Read Responseからのデータはその後のRDMA Operationsによって上書きされるかもしれません。
12. RDMA Read Request Messages, including zero-length RDMA Read
Requests, MUST NOT start processing at the Remote Peer until they
have been Delivered to RDMAP by DDP.
12. ゼロ・レングスRDMA Read Requestsを含むRDMA Read Request Messagesは、DDPでRemote Peerで彼らがDeliveredになるまで処理しRDMAPに始めてはいけません。
Note: the ULP is assured that data written can be read back. For
example, if
以下に注意してください。 ULPは書かれたデータを読み返すことができることが保証されます。 例えば
a) an RDMA Read Request is issued by the local peer,
b) the Request targets the same ULP Buffer as a preceding Send
or RDMA Write (in the same direction as the RDMA Read
Request), and
c) there are no other sources of update for the ULP Buffer,
a) RDMA Read Requestは地元の同輩によって発行されるか、b) Requestは前のSendと同じULP Bufferを狙うか、RDMA Write(RDMA Read Requestと同じ方向への)、およびそこのc)はULP Bufferのためのアップデートの他の源ではありません。
then the Remote Peer will send back the data written by the Send
or RDMA Write. That is, for this example, the ULP Buffer is
Advertised for use on a series of RDMA Messages, is only valid on
the RDMAP Stream for which it is Advertised, and is not locally
updated while the series of RDMAP Messages are performed. For
this example, order rule (12) assures that subsequent local or
remote accesses to the ULP Buffer contain the data written by the
Send or RDMA Write.
そして、Remote PeerはSendかRDMA Writeによって書かれたデータを返送するでしょう。 すなわち、この例に関しては、ULP Bufferを使用のための一連のRDMA Messagesの上のAdvertisedであり、単にそれがAdvertisedであるRDMAP Streamで有効であり、RDMAP Messagesのシリーズを実行しますが、局所的にアップデートしません。 この例に関しては、オーダー規則(12)は、ULP Bufferへのその後の地方の、または、リモートなアクセスがSendかRDMA Writeによって書かれたデータを含むことを保証します。
RDMA Read Response Messages MAY be generated at the Remote Peer
after subsequent RDMA Write Messages or Send Messages have been
Placed or Delivered. Therefore, when an application does an RDMA
Read Request followed by an RDMA Write (or Send) to the same
buffer, it may get the data from the later RDMA Write (or Send)
in the RDMA Read Response Message, even though the operations
completed in order at the Local Peer. If this behavior is not
desired, the Local Peer ULP must Fence the later RDMA write (or
Send) by withholding the RDMA Write Message until all outstanding
RDMA Read Responses have been Delivered.
その後のRDMA Write MessagesかSend MessagesがPlacedかDeliveredになった後にRDMA Read Response MessagesはRemote Peerで生成されるかもしれません。 したがって、アプリケーションがRDMA Write(または、Send)によって同じバッファに続かれたRDMA Read Requestをすると、RDMA Read Response Messageで後のRDMA Write(または、Send)からデータを得るかもしれません、Local Peerのオーダーで完成した操作ですが。 この振舞いが望まれていないなら、Local Peer ULPは後のRDMAがすべての傑出しているRDMA Read ResponsesがDeliveredになるまでRDMA Write Messageを差し控えることによって書く(または、Send)Fenceを望まれていなければなりません。
13. The RDMAP layer MUST submit RDMA Messages to the DDP layer in the
order the RDMA Operations are submitted to the RDMAP layer by the
ULP.
13. RDMAP層はDDP層にRDMA Messagesを提出しなければなりません。オーダーのRDMA OperationsはULPによってRDMAP層に提出されます。
14. A Send or RDMA Write Message MUST NOT be considered Complete at
the Local Peer (Data Source) until it has been successfully
completed at the DDP layer.
14. Local Peer(データSource)のCompleteであるとSendかRDMA Write Messageを首尾よくDDP層に完成するまで考えてはいけません。
15. RDMA Operations MUST be Completed at the Local Peer in the order
that they were submitted by the ULP.
15. RDMA Operationsは彼らが提出されたオーダーにおけるLocal PeerのCompletedがULPであったならそうしなければなりません。
Recio, et al. Standards Track [Page 40] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[40ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
16. At the Data Sink, an incoming Send Message MUST be Delivered to
the ULP only after the DDP Message has been Delivered to the
RDMAP layer by the DDP layer.
16. Data Sinkでは、DDP MessageがRDMAP層ごとにDeliveredになった後にだけ入って来るSend MessageはULPへのDeliveredであるに違いありません。
17. RDMA Read Response Message processing at the Remote Peer (reading
the specified Tagged Buffer) MUST be started only after the RDMA
Read Request Message has been Delivered by the DDP layer (thus,
all previous RDMA Messages have been properly submitted for
ordered Placement).
17. RDMA Read Request MessageがDDP層のそばでDeliveredになった(その結果、命令されたPlacementのために適切に前のすべてのRDMA Messagesを提出しました)後にだけRemote Peer(指定されたTagged Bufferを読む)でのRDMA Read Response Message処理を始めなければなりません。
18. Send Messages MAY be Completed at the Remote Peer (Data Sink)
before prior incoming RDMA Read Request Messages have completed
their response processing.
18. 先の入って来るRDMA Read Request Messagesが彼らの応答処理を終了する前にRemote PeerのCompletedが(データSink)であったかもしれないならMessagesを送ってください。
19. An RDMA Read operation MUST NOT be Completed at the Local Peer
until the DDP layer Delivers the associated incoming RDMA Read
Response Message.
19. RDMA Read操作はDDPまでのLocal PeerのCompletedがデリバーズ、関連入って来るRDMA Read Response Messageを層にするということであるはずがありません。
20. If more than one outstanding RDMA Read Request Messages are
supported by both peers, the RDMA Read Response Messages MUST be
submitted to the DDP layer on the Remote Peer in the order the
RDMA Read Request Messages were Delivered by DDP, but the actual
read of the buffer contents MAY take place in any order at the
Remote Peer.
20. 両方の同輩が1傑出しているRDMA Read Request Messagesをサポートするなら、DeliveredがDDPであったなら、オーダーのRemote Peer RDMA Read Request Messagesの上のDDP層にRDMA Read Response Messagesを提出しなければなりませんが、バッファの内容について読まれた実際はRemote Peerで順不同に行われるかもしれません。
This simplifies Local Peer Completion processing for RDMA Reads
in that a Delivered RDMA Read Response MUST be sufficient to
Complete the RDMA Read operation.
Delivered RDMA Read ResponseがCompleteに十分であるに違いないので、これはRDMA ReadsのためにLocal Peer Completion処理を簡素化します。RDMA Read操作。
6. RDMAP Stream Management
6. RDMAPストリーム管理
RDMAP Stream management consists of RDMAP Stream Initialization and RDMAP Stream Termination.
RDMAP Stream管理はRDMAP Stream初期設定とRDMAP Stream Terminationから成ります。
6.1. Stream Initialization
6.1. ストリーム初期設定
RDMAP Stream initialization occurs after the LLP Stream has been created (e.g., for DDP/MPA over TCP, the first TCP Segment after the SYN, SYN/ACK exchange). The ULP is responsible for transitioning the LLP Stream into RDMA-enabled mode. The switch to RDMA mode typically occurs sometime after LLP Stream setup. Once in RDMA enabled mode, an implementation MUST send only RDMA Messages across the transport Stream until the RDMAP Stream is torn down.
LLP Streamが作成された(例えば、TCPの上のDDP/MPA、SYNの後の最初のTCP SegmentへのSYN/ACK交換)後にRDMAP Stream初期化は起こります。 ULPは移行に責任があります。RDMAによって可能にされたモードへのLLP Stream。 LLP Streamがセットアップしたいつか後にRDMAモードへのスイッチは通常現れます。 RDMAでかつての可能にされたモード、実装は輸送Streamの向こう側にRDMAP Streamを取りこわすまでRDMA Messagesだけを送らなければなりません。
For each direction of an RDMAP Stream:
RDMAP Streamの各方向に:
* For a given RDMAP Stream, the number of outstanding RDMA Read
Requests is limited per RDMAP Stream direction.
* 与えられたRDMAP Streamに関しては、傑出しているRDMA Read Requestsの数はRDMAP Stream方向単位で制限されます。
Recio, et al. Standards Track [Page 41] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[41ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
* It is the ULP's responsibility to set the maximum number of
outstanding, inbound RDMA Read Requests per RDMAP Stream
direction.
* RDMAP Stream方向あたりの傑出していて、本国行きのRDMA Read Requestsの最大数を設定するのは、ULPの責任です。
* The RDMAP layer MUST provide the maximum number of outstanding,
inbound RDMA Read Requests per RDMAP Stream direction that were
negotiated between the ULP and the Local Peer's RDMAP layer. The
negotiation mechanism is outside the scope of this specification.
* RDMAP層はULPとLocal PeerのRDMAP層の間で交渉されたRDMAP Stream方向あたりの傑出していて、本国行きのRDMA Read Requestsの最大数を提供しなければなりません。 この仕様の範囲の外に交渉メカニズムがあります。
* It is the ULP's responsibility to set the maximum number of
outstanding, outbound RDMA Read Requests per RDMAP Stream
direction.
* RDMAP Stream方向あたりの傑出していて、外国行きのRDMA Read Requestsの最大数を設定するのは、ULPの責任です。
* The RDMAP layer MUST provide the maximum number of outstanding,
outbound RDMA Read Requests for the RDMAP Stream direction that
were negotiated between the ULP and the Local Peer's RDMAP layer.
The negotiation mechanism is outside the scope of this
specification.
* RDMAP層はULPとLocal PeerのRDMAP層の間で交渉されたRDMAP Stream方向に傑出していて、外国行きのRDMA Read Requestsの最大数を提供しなければなりません。 この仕様の範囲の外に交渉メカニズムがあります。
* The Local Peer's ULP is responsible for negotiating with the
Remote Peer's ULP the maximum number of outstanding RDMA Read
Requests for the RDMAP Stream direction. It is recommended that
the ULP set the maximum number of outstanding, inbound RDMA Read
Requests equal to the maximum number of outstanding, outbound RDMA
Read Requests for a given RDMAP Stream direction.
* Local PeerのULPはRDMAP Stream方向のために傑出しているRDMA Read Requestsの最大数をRemote PeerのULPと交渉するのに責任があります。 ULPが与えられたRDMAP Stream方向に、傑出していて、外国行きのRDMA Read Requestsの最大数と等しい傑出していて、本国行きのRDMA Read Requestsの最大数を設定するのは、お勧めです。
* For outbound RDMA Read Requests, the RDMAP layer MUST NOT exceed
the maximum number of outstanding, outbound RDMA Read Requests
that were negotiated between the ULP and the Local Peer's RDMAP
layer.
* 外国行きのRDMA Read Requestsに関しては、RDMAP層はULPとLocal PeerのRDMAP層の間で交渉された傑出していて、外国行きのRDMA Read Requestsの最大数を超えてはいけません。
* For inbound RDMA Read Requests, the RDMAP layer MUST NOT exceed
the maximum number of outstanding, inbound RDMA Read Requests that
were negotiated between the ULP and the Local Peer's RDMAP layer.
* 本国行きのRDMA Read Requestsに関しては、RDMAP層はULPとLocal PeerのRDMAP層の間で交渉された傑出していて、本国行きのRDMA Read Requestsの最大数を超えてはいけません。
6.2. Stream Teardown
6.2. ストリーム分解
There are three methods for terminating an RDMAP Stream: ULP Graceful Termination, RDMAP Abortive Termination, and LLP Abortive Termination.
RDMAP Streamを終えるための3つのメソッドがあります: ULPの優雅な終了、RDMAPの不成功の終了、およびLLPの不成功の終了。
The ULP is responsible for performing ULP Graceful Termination. After a ULP Graceful Termination, either side of the Stream can initiate LLP Graceful Termination, using the graceful termination mechanism provided by the LLP.
ULPはULP Graceful Terminationを実行するのに責任があります。 ULP Graceful Terminationの後に、Streamのどちらの側面もLLP Graceful Terminationを開始できます、LLPによって提供された優雅な終了メカニズムを使用して。
Recio, et al. Standards Track [Page 42] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[42ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
RDMAP Abortive Termination allows the RDMAP to issue a Terminate Message describing the reason the RDMAP Stream was terminated. The next section (6.2.1, "RDMAP Abortive Termination") describes the RDMAP Abortive Termination in detail.
RDMAP Abortive TerminationはRDMAPにRDMAP Streamが終えられた理由について説明するTerminate Messageを発行させます。 次のセクション、(6.2 .1 「RDMAPの不成功の終了」) 詳細にRDMAP Abortive Terminationについて説明します。
LLP Abortive Termination results due to an LLP error and causes the RDMAP Stream to be torn down midstream, without an RDMAP Terminate Message. While this last method is highly undesirable, it is possible, and the ULP should take this into consideration.
LLP Abortive TerminationはLLP誤りのためなって、中流の下側までRDMAP Streamを引き裂かせます、RDMAP Terminate Messageなしで。 この最後のメソッドは非常に望ましくないのですが、それは可能です、そして、ULPはこれを考慮に入れるはずです。
6.2.1. RDMAP Abortive Termination
6.2.1. RDMAPの不成功の終了
RDMAP defines a Terminate operation that SHOULD be invoked when either an RDMAP error is encountered or an LLP error is surfaced to the RDMAP layer by the LLP.
RDMAP誤りが遭遇するか、またはLLP誤りがLLPによってRDMAP層に表面を仕上げられているとき、RDMAPは呼び出された状態でSHOULDがあるTerminate操作を定義します。
It is not always possible to send the Terminate Message. For example, certain LLP errors may occur that cause the LLP Stream to be torn down a) before RDMAP is aware of the error, b) before RDMAP is able to send the Terminate Message, or c) after RDMAP has posted the Terminate Message to the LLP, but it has not yet been transmitted by the LLP.
Terminate Messageを送るのはいつも可能であるというわけではありません。 例えば、RDMAPが誤りを意識している前にa)までLLP Streamを引き裂くあるLLP誤りは発生するかもしれませんが、RDMAPがTerminate Message、またはc)をRDMAPの後に送ることができる前にb)はLLPにTerminate Messageを掲示しましたが、それはLLPによってまだ伝えられていません。
Note that an RDMAP Abortive Termination may entail loss of data. In general, when a Terminate Message is received, it is impossible to tell for sure what unacknowledged RDMA Messages were Completed successfully at the Remote Peer. Thus, the state of all outstanding RDMA Messages is indeterminate, and the Messages SHOULD be considered Completed in error.
RDMAP Abortive Terminationがデータの喪失を伴うかもしれないことに注意してください。 Terminate Messageが受け取られているとき、一般に、それは不承認のRDMA Messagesが確実にものであったためにRemote Peerで首尾よくCompletedに言うのが不可能です。 その結果、すべての傑出しているRDMA Messagesの州は、不確定であってMessages SHOULDです。間違いCompletedであると考えられてください。
When a peer sends or receives a Terminate Message, it MAY immediately tear down the LLP Stream. The peer SHOULD perform a graceful LLP teardown to ensure the Terminate Message is successfully Delivered.
同輩がTerminate Messageを送るか、またはすぐに受け取るとき、それはLLP Streamを取りこわすかもしれません。 同輩SHOULDは、Terminate Messageが首尾よくそうであることを保証するために優雅なLLP分解を実行します。Delivered。
See Section 4.8, "Terminate Header", for a description of the Terminate Message and its contents. See Section 5.4, "Terminate Message", for a description of the Terminate Message semantics.
Terminate Messageとそのコンテンツの記述に関して「ヘッダーを終えてください」というセクション4.8を見てください。 Terminate Message意味論の記述に関して「メッセージを終えてください」というセクション5.4を見てください。
7. RDMAP Error Management
7. RDMAP誤り管理
The RDMAP protocol does not have RDMAP- or DDP-layer error recovery operations built in. If everything is working, the LLP guarantees will ensure that the Messages are arriving at the destination.
RDMAPプロトコルで、RDMAPかDDP層のエラー回復操作を造りません。 すべてが働いていると、LLP保証は、Messagesが目的地に到着する予定であるのを確実にするでしょう。
If errors are detected at the RDMAP or DDP layer, then the RDMAP, DDP, and LLP Streams are Abortively Terminated (see Section 4.8, "Terminate Header").
誤りがRDMAPかDDP層に検出されるなら、RDMAP、DDP、およびLLP StreamsはAbortively Terminated(セクション4.8、「ヘッダーを終えてください」を見る)です。
Recio, et al. Standards Track [Page 43] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[43ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
In general, poor implementations or improper ULP programming cause the errors detected at the RDMAP and DDP layers. In these cases, returning a diagnostic termination error Message and closing the RDMAP Stream is far simpler than attempting to maintain the RDMAP Stream, particularly when the cause of the error is not known.
一般に、貧しい実装か不適当なULPプログラミングがRDMAPとDDP層に検出された誤りを引き起こします。 これらの場合では、RDMAP Streamを維持するのを試みるより診断終了誤りにMessageを返して、RDMAP Streamを閉鎖に返すのははるかに簡単です、特に誤りの原因が知られていないと。
If an LLP does not support teardown of a Stream independent of other Streams, and an RDMAP error results in the Termination of a specific Stream, then the LLP MUST label the Stream as an erroneous Stream and MUST NOT allow any further data transfer on that Stream after RDMAP requests the Stream to be torn down.
LLPが他のStreamsの如何にかかわらずStreamの分解をサポートしないで、RDMAP誤りが特定のStreamのTerminationをもたらすなら、RDMAPが、取りこわされるようStreamに要求した後に、LLP MUSTは誤ったStreamとしてStreamをラベルして、そのStreamにどんな詳しいデータも許容してはいけません。
For a specific LLP connection, when all Streams are either gracefully torn down or are labeled as erroneous Streams, the LLP connection MUST be torn down.
すべてのStreamsを優雅に取りこわすか、または誤ったStreamsとしてラベルするとき、特定のLLP接続において、LLP接続を取りこわさなければなりません。
Since errors are detected at the Remote Peer (possibly long) after RDMA Messages are passed to the DDP and the LLP at the Local Peer and after the RDMA Operations conveyed by the Messages are Completed, the sender cannot easily determine which of its Messages have been received. (RDMA Reads are an exception to this rule.)
RDMA MessagesがLocal PeerのDDPとLLPに渡された後とMessagesによって運ばれたRDMA OperationsがCompletedになった後に誤りがRemote Peer(ことによると長い)に検出されるので、送付者は、Messagesのどれが受け取られたかを容易に決心できません。 (RDMA Readsはこの規則への例外です。)
For a list of errors returned to the Remote Peer as a result of an Abortive Termination, see Section 4.8, "Terminate Header".
Abortive Terminationの結果、Remote Peerに返された誤りのリストに関しては、セクション4.8、「ヘッダーを終えてください」を見てください。
7.1. RDMAP Error Surfacing
7.1. RDMAP誤り表面化
If an error occurs at the Local Peer, the RDMAP layer MUST attempt to inform the local ULP that the error has occurred.
誤りがLocal Peerに発生するなら、RDMAP層は、誤りが発生したことを地方のULPに知らせるのを試みなければなりません。
The Local Peer MUST send a Terminate Message for each of the following cases:
Local Peerはそれぞれに関する以下のケースのためにTerminate Messageを送らなければなりません:
1. For errors detected while creating RDMA Write, Send, Send with
Invalidate, Send with Solicited Event, Send with Solicited Event
and Invalidate, or RDMA Read Requests, or other reasons not
directly associated with an incoming Message, the Terminate
Message and Error code are sent instead of the request. In this
case, the Error Type and Error Code fields are included in the
Terminate Message, but the Terminated DDP Header and Terminated
RDMA Header fields are set to zero.
1. RDMA Write、Send、InvalidateとSend、Solicited EventとSend、Solicited EventとInvalidateとSend、RDMA Read Requests、または直接入って来るMessageに関連づけられなかった他の理由を作成している間に検出された誤りにおいて、要求の代わりにTerminate MessageとErrorコードを送ります。 この場合、Error TypeとError Code分野はTerminate Messageに含まれていますが、Terminated DDP HeaderとTerminated RDMA Header分野はゼロに用意ができています。
2. For errors detected on an incoming RDMA Write, Send, Send with
Invalidate, Send with Solicited Event, Send with Solicited Event
and Invalidate, or Read Response Message (after the Message has
been Delivered by DDP), the Terminate Message is sent at the
earliest possible opportunity, preferably in the next outgoing
RDMA Message. In this case, the Error Type, Error Code, ULP PDU
2. 入って来るRDMA Write、Send、InvalidateとSend、Solicited EventとSend、Solicited EventとInvalidateとSend、またはRead Response Message(MessageがDDPでDeliveredになった後に)に検出された誤りにおいてTerminate Messageをできるだけ早く送ります、望ましくは次の出発しているRDMA Messageで。 Error Type、Error Code、この場合ULP PDU
Recio, et al. Standards Track [Page 44] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[44ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Length, and Terminated DDP Header fields are included in the
Terminate Message, but the Terminated RDMA Header field is set to
zero.
Header分野が含まれている長さ、および合わせてくださいTerminate Message、しかし、Terminated RDMA Header分野が設定されるゼロTerminated DDP。
3. For errors detected on an incoming RDMA Read Request Message
(after the Message has been Delivered by DDP), the Terminate
Message is sent at the earliest possible opportunity, preferably
in the next outgoing RDMA Message. In this case, the Error Type,
Error Code, ULP PDU Length, Terminated DDP Header, and Terminated
RDMA Header fields are included in the Terminate Message.
3. 入って来るRDMA Read Request Message(MessageがDDPでDeliveredになった後に)に検出された誤りにおいてTerminate Messageをできるだけ早く送ります、望ましくは次の出発しているRDMA Messageで。 この場合、Error Type、Error Code、ULP PDU Length、Terminated DDP Header、およびTerminated RDMA Header分野はTerminate Messageに含まれています。
4. If more than one error is detected on incoming RDMA Messages,
before the Terminate Message can be sent, then the first RDMA
Message (and its associated DDP Segment) that experienced an
error MUST be captured by the Terminate Message, in accordance
with rules 2 and 3 above.
4. Terminate Messageを送ることができる前に入って来るRDMA Messagesに1つ以上の誤りを検出するなら、規則2と3に従った上のTerminate Messageは誤りを経験した最初のRDMA Message(そして、関連DDP Segment)をキャプチャしなければなりません。
7.2. Errors Detected at the Remote Peer on Incoming RDMA Messages
7.2. 入って来るRDMAメッセージにリモート同輩に検出された誤り
On incoming RDMA Writes, RDMA Read Response, Sends, Send with Invalidate, Send with Solicited Event, Send with Solicited Event and Invalidate, and Terminate Messages, the following must be validated:
入って来るRDMA Writes、RDMA Read Response、Sends、InvalidateとSend、Solicited EventとSend、Solicited EventとInvalidateとSend、およびTerminate Messages、以下の必須の上では、有効にされてください:
1. The DDP layer MUST validate all DDP Segment fields.
1. DDP層はすべてのDDP Segment分野を有効にしなければなりません。
2. The RDMA OpCode MUST be valid.
2. RDMA OpCodeは有効であるに違いありません。
3. The RDMA Version MUST be valid.
3. RDMAバージョンは有効であるに違いありません。
Additionally, on incoming Send with Invalidate and Send with
Solicited Event and Invalidate Messages, the following must also
be validated:
また、さらに、Invalidateと入って来るSendとSolicited EventとInvalidate MessagesとSendでは、以下を有効にしなければなりません:
4. The Invalidate STag MUST be valid.
4. Invalidate STagは有効であるに違いありません。
5. The STag MUST be associated to this RDMAP Stream.
5. このRDMAP StreamにSTagを関連づけなければなりません。
On incoming RDMA Request Messages, the following must be validated:
入って来るRDMA Request Messagesでは、以下を有効にしなければなりません:
1. The DDP layer MUST validate all Untagged DDP Segment fields.
1. DDP層はすべてのUntagged DDP Segment分野を有効にしなければなりません。
2. The RDMA OpCode MUST be valid.
2. RDMA OpCodeは有効であるに違いありません。
3. The RDMA Version MUST be valid.
3. RDMAバージョンは有効であるに違いありません。
4. For non-zero length RDMA Read Request Messages:
4. 非ゼロ・レングスRDMA Read Request Messagesのために:
a. The Data Source STag MUST be valid.
a。 Data Source STagは有効であるに違いありません。
Recio, et al. Standards Track [Page 45] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[45ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
b. The Data Source STag MUST be associated to this RDMAP Stream.
b。 このRDMAP StreamにData Source STagを関連づけなければなりません。
c. The Data Source Tagged Offset MUST fall in the range of legal
offsets associated with the Data Source STag.
c。 Data Source Tagged OffsetはData Source STagに関連している法的なオフセットの範囲に落ちなければなりません。
d. The sum of the Data Source Tagged Offset and the RDMA Read
Message Size MUST fall in the range of legal offsets
associated with the Data Source STag.
d。 Data Source Tagged OffsetとRDMA Read Message Sizeの合計はData Source STagに関連している法的なオフセットの範囲に下がらなければなりません。
e. The sum of the Data Source Tagged Offset and the RDMA Read
Message Size MUST NOT cause the Data Source Tagged Offset to
wrap.
e。 Data Source Tagged OffsetとRDMA Read Message Sizeの合計は包装へのData Source Tagged Offsetを引き起こしてはいけません。
8. Security Considerations
8. セキュリティ問題
This section references the resources that discuss protocol- specific security considerations and implications of using RDMAP with existing security services. A detailed analysis of the security issues around implementation and use of the RDMAP can be found in [RDMASEC].
このセクションはRDMAPを使用するプロトコルの特定のセキュリティ問題と含意について既存のセキュリティー・サービスと議論するリソースに参照をつけます。 [RDMASEC]で実装の周りの安全保障問題の詳細に渡る分析とRDMAPの使用を見つけることができます。
[RDMASEC] introduces the RDMA reference model and discusses how the resources of this model are vulnerable to attacks and the types of attack these vulnerabilities are subject to. It also details the levels of Trust available in this peer-to-peer model and how this defines the nature of resource sharing.
[RDMASEC]は、RDMA規範モデルを紹介して、これらの脆弱性を条件としている攻撃の攻撃とタイプには、このモデルのリソースがどう被害を受け易いかについて議論します。 また、それはこのピアツーピアモデルで利用可能なTrustとこれがどうリソース・シェアリングの本質を定義するかに関するレベルを詳しく述べます。
The IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC 3723 [RFC3723], despite the existence of a newer version of IPsec specified in RFC 4301 [RFC4301] and related RFCs [RFC4303], [RFC4306], [RFC4835]. One of the important early applications of the RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec requirements follow those of IPsec in order to facilitate that usage by allowing a common profile of IPsec to be used with iSCSI and the RDDP protocols. In the future, RFC 3723 may be updated to the newer version of IPsec, and the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RDDPがIPsecのバージョンに基づいているので、IPsec要件は、RFC2401[RFC2401]で指定して、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるようにRFCsを関係づけて、RFCs[RFC4303]を関係づけました、[RFC4306]、[RFC4835。] RDDPプロトコルの重要な早めの応用の1つはiSCSI[iSER]との彼らの使用です。 RDDPのIPsec要件は、IPsecの一般的なプロフィールがiSCSIとRDDPプロトコルと共に使用されるのを許容することによってその用法を容易にするためにIPsecのものに続きます。 将来、IPsecの、より新しいバージョンにRFC3723をアップデートするかもしれません、そして、どんなそのようなものの要件もアップデートするIPsecセキュリティは一様にiSCSIとRDDPプロトコルに申請されるべきです。
8.1. Summary of RDMAP-Specific Security Requirements
8.1. RDMAP特有のセキュリティ要件の概要
[RDMASEC] defines the security requirements for the implementation of the components of the RDMA reference model, namely the RDMA enabled NIC (RNIC) and the Privileged Resource Manager. An RDMAP implementation conforming to this specification MUST conform to these requirements.
[RDMASEC]はRDMA規範モデルの部品の実装のためのセキュリティ要件を定義します、すなわち、RDMAがNIC(RNIC)とPrivileged Resourceマネージャを有効にしました。 この仕様に従うRDMAP実装はこれらの要件に従わなければなりません。
Recio, et al. Standards Track [Page 46] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[46ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
8.1.1. RDMAP (RNIC) Requirements
8.1.1. RDMAP(RNIC)要件
RDMAP provides several countermeasures for all types of attacks as introduced in [RDMASEC]. In the following, this specification lists all security requirements that MUST be implemented by the RNIC. A more detailed discussion of RNIC security requirements can be found in Section 5 of [RDMASEC].
RDMAPは[RDMASEC]で導入するようにすべてのタイプの攻撃のためのいくつかの対策を提供します。 以下では、この仕様はRNICが実装しなければならないすべてのセキュリティ要件をリストアップします。 [RDMASEC]のセクション5でRNICセキュリティ要件の、より詳細な議論を見つけることができます。
1. An RNIC MUST ensure that a specific Stream in a specific
Protection Domain cannot access an STag in a different Protection
Domain.
1. RNIC MUSTは、特定のProtection Domainの特定のStreamが異なったProtection DomainでSTagにアクセスできないのを確実にします。
2. An RNIC MUST ensure that if an STag is limited in scope to a
single Stream, no other Stream can use the STag.
2. RNIC MUSTは、STagが範囲で独身のStreamに制限されるなら、他のどんなStreamもSTagを使用できないのを確実にします。
3. An RNIC MUST ensure that a Remote Peer is not able to access
memory outside of the buffer specified when the STag was enabled
for remote access.
3. RNIC MUSTは、Remote PeerがSTagが遠隔アクセスのために有効にされたときバッファの外部が指定したメモリにアクセスできないのを確実にします。
4. An RNIC MUST provide a mechanism for the ULP to establish and
revoke the association of a ULP Buffer to an STag and TO range.
4. ULPがSTagとTO範囲にULP Bufferの協会を設立して、取り消すように、RNIC MUSTはメカニズムを提供します。
5. An RNIC MUST provide a mechanism for the ULP to establish and
revoke read, write, or read and write access to the ULP Buffer
referenced by an STag.
5. RNIC MUSTはULPが確立するメカニズムと読まれた取消しを提供するか、書くか、またはSTagによって参照をつけられたULP Bufferへのアクセスを読み書きします。
6. An RNIC MUST ensure that the network interface can no longer
modify an Advertised Buffer after the ULP revokes remote access
rights for an STag.
6. RNIC MUSTは、ULPがSTagのためにリモートアクセス権を取り消した後にネットワーク・インターフェースがもうAdvertised Bufferを変更できないのを確実にします。
7. An RNIC MUST ensure that a Remote Peer is not able to invalidate
an STag enabled for remote access, if the STag is shared on
multiple streams.
7. RNIC MUSTは、Remote Peerが遠隔アクセスのために有効にされたSTagを無効にすることができないのを確実にします、STagが複数のストリームで共有されるなら。
8. An RNIC MUST choose the value of STags in a way difficult to
predict. It is RECOMMENDED to sparsely populate them over the
full available range.
8. RNIC MUSTはある意味で予測するのが難しいSTagsの値を選びます。 それは最大限の利用可能な範囲でそれらにまばらに居住するRECOMMENDEDです。
9. An RNIC MUST NOT enable sharing a Completion Queue (CQ) across
ULPs that do not share partial mutual trust.
9. RNIC MUST NOTは、部分的な信頼関係を共有しないULPsの向こう側にCompletion Queue(CQ)を共有しながら、可能にします。
10. An RNIC MUST ensure that if a CQ overflows, any Streams that do
not use the CQ MUST remain unaffected.
10. RNIC MUSTは、CQがあふれるなら、CQ MUSTを使用しないどんなStreamsも影響を受けないままで残っているのを確実にします。
11. An RNIC implementation SHOULD provide a mechanism to cap the
number of outstanding RDMA Read Requests.
11. SHOULDが傑出しているRDMA Read Requestsの数にふたをするためにメカニズムを提供するRNIC実装。
Recio, et al. Standards Track [Page 47] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[47ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
12. An RNIC MUST NOT enable firmware to be loaded on the RNIC
directly from an untrusted Local Peer or Remote Peer, unless the
Peer is properly authenticated*, and the update is done via a
secure protocol, such as IPsec.
12. RNIC MUST NOTは、ファームウェアがRNICで直接信頼されていないLocal PeerかRemote Peerからロードされるのを可能にして、Peerが適切に認証されない場合、*、およびアップデートはそうです。IPsecなどの安全なプロトコルで、します。
* by a mechanism outside the scope of this specification. The
mechanism presumably entails authenticating that the remote ULP
has the right to perform the update.
* この仕様の範囲の外のメカニズムで。 おそらく、メカニズムは、認証するのを伴います。リモートULPは、アップデートを実行するために権利があります。
8.1.2. Privileged Resource Manager Requirements
8.1.2. 特権がある資源管理プログラム要件
With RDMAP, all reservations of local resources are initiated from local ULPs. To protect from local attacks including unfair resource distribution and gaining unauthorized access to RNIC resources, a Privileged Resource Manager (PRM) must be implemented, which manages all local resource allocation. Note that the PRM must not be provided as an independent component, and its functionality can also be implemented as part of the privileged ULP or as part of the RNIC itself.
RDMAPと共に、ローカル資源のすべての予約が地方のULPsから開始されます。 不公平な資金配分を含んで、RNICリソースへの不正アクセスを獲得する地方の攻撃から保護するために、Privileged Resourceマネージャ(PRM)(すべてのローカル資源配分を管理する)を実装しなければなりません。 独立しているコンポーネントとしてPRMを提供してはいけなくて、また、特権があるULPの一部として、または、RNIC自身の一部として機能性を実装することができることに注意してください。
A PRM implementation must meet the following security requirements (a more detailed discussion of PRM security requirements can be found in Section 5 of [RDMASEC]):
PRM実装は以下のセキュリティ必要条件を満たさなければなりません([RDMASEC]のセクション5でPRMセキュリティ要件の、より詳細な議論を見つけることができます):
1. All Non-Privileged ULP interactions with the RNIC Engine that
could affect other ULPs MUST be done using the Resource Manager
as a proxy.
1. プロキシとしてResourceマネージャを使用し他のULPsに影響できたRNIC EngineとのすべてのNon特権があるULP相互作用を終わらなければなりません。
2. All ULP resource allocation requests for scarce resources MUST
also be done using a Privileged Resource Manager.
2. また、Privileged Resourceマネージャを使用し希少資源に関するすべてのULP資源配分要求を終わらなければなりません。
3. The Privileged Resource Manager MUST NOT assume that different
ULPs share Partial Mutual Trust unless there is a mechanism to
ensure that the ULPs do indeed share partial mutual trust.
3. Privileged Resourceマネージャは、本当に、ULPsが部分的な信頼関係を共有するのを保証するためにメカニズムがない場合異なったULPsがPartial Mutual Trustを共有すると仮定してはいけません。
4. If Non-Privileged ULPs are supported, the Privileged Resource
Manager MUST verify that the Non-Privileged ULP has the right to
access a specific Data Buffer before allowing an STag for which
the ULP has access rights to be associated with a specific Data
Buffer.
4. Non特権があるULPsがサポートされるなら、Privileged Resourceマネージャは、ULPにはアクセス権があるSTagが特定のData Bufferに関連しているのを許容する前に特定のData BufferにアクセスするためにNon特権があるULPが権利があることを確かめなければなりません。
5. The Privileged Resource Manager MUST control the allocation of CQ
entries.
5. Privileged ResourceマネージャはCQエントリーの配分を制御しなければなりません。
6. The Privileged Resource Manager SHOULD prevent a Local Peer from
allocating more than its fair share of resources.
6. Privileged ResourceマネージャSHOULDは、Local Peerがリソースの正当な分け前以上を割り当てるのを防ぎます。
Recio, et al. Standards Track [Page 48] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[48ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
7. RDMA Read Request Queue resource consumption MUST be controlled
by the Privileged Resource Manager such that RDMAP/DDP Streams
that do not share Partial Mutual Trust do not share RDMA Read
Request Queue resources.
7. Privileged ResourceマネージャがRDMA Read Request Queueリソース消費を制御しなければならないので、Partial Mutual Trustを共有しないRDMAP/DDP StreamsがRDMA Read Request Queueリソースを共有しません。
8. If an RNIC provides the ability to share receive buffers across
multiple Streams, the combination of the RNIC and the Privileged
Resource Manager MUST be able to detect if the Remote Peer is
attempting to consume more than its fair share of resources so
that the Local Peer can apply countermeasures to detect and
prevent the attack.
8. RNICが複数のStreamsの向こう側に受信バッファを共有する能力を提供するなら、RNICとPrivileged Resourceマネージャの組み合わせは、Remote Peerが、Local Peerが攻撃を検出して、防ぐために対策を適用できるようにリソースの正当な分け前以上を消費するのを試みているかどうか検出できなければなりません。
8.2. Security Services for RDMAP
8.2. RDMAPのためのセキュリティー・サービス
RDMAP is using IP-based network services to control, read, and write data buffers over the network. Therefore, all exchanged control and data packets are vulnerable to spoofing, tampering, and information disclosure attacks.
RDMAPは、ネットワークの上にデータバッファを制御して、読んで、書くのにIP接続を基本にしたネットワークサービスを利用しています。 したがって、すべてがコントロール、パケットが偽造するのに被害を受け易いデータ、改ざん、および情報公開攻撃を交換しました。
RDMAP Streams that are subject to impersonation attacks or Stream hijacking attacks can be authenticated, have their integrity protected, and be protected from replay attacks. Furthermore, confidentiality protection can be used to protect from eavesdropping.
ものまね攻撃かStreamハイジャック攻撃を受けることがあるRDMAP Streamsは認証して、彼らの保全を保護させて、反射攻撃から保護できます。 その上、盗聴から保護するのに秘密性保護を使用できます。
8.2.1. Available Security Services
8.2.1. 利用可能なセキュリティー・サービス
The IPsec protocol suite [RFC2401] defines strong countermeasures to protect an IP stream from those attacks. Several levels of protection can guarantee session confidentiality, per-packet source authentication, per-packet integrity, and correct packet sequencing.
IPsecプロトコル群[RFC2401]は、それらの攻撃からIPストリームを保護するために強硬策を定義します。 いくつかのレベルの保護はセッション秘密性、1パケットあたりのソース認証、1パケットあたりの保全、および正しいパケット順序制御を保証できます。
RDMAP security may also profit from SSL or TLS security services provided for TCP-based ULPs [RFC4346]. Used underneath RDMAP, these security services also provide for stream authentication, data integrity, and confidentiality. As discussed in [RDMASEC], limitations on the maximum packet length to be carried over the network and potentially inefficient out-of-order packet processing at the data sink make SSL and TLS less appropriate for RDMAP than IPsec.
また、RDMAPセキュリティがSSLから利益を得るかもしれませんか、またはTLSセキュリティー・サービスはTCPベースのULPs[RFC4346]に備えました。 RDMAPの下で使用されていて、また、これらのセキュリティー・サービスはストリーム認証、データ保全、および秘密性に備えます。 [RDMASEC]で議論するように、ネットワークの上まで運ばれるべき最大のパケット長における制限とデータ受信端末での潜在的に効率の悪い不適切なパケット処理でSSLとTLSはIPsecほどRDMAPには適切でなくなります。
If SSL is layered on top of RDMAP, SSL does not protect the RDMAP headers. Thus, a man-in-the-middle attack can still occur by modifying the RDMAP header to incorrectly place the data into the wrong buffer, thus effectively corrupting the data stream.
SSLがRDMAPの上で層にされるなら、SSLはRDMAPヘッダーを保護しません。 したがって、介入者攻撃は不当に間違ったバッファの中にデータを置くようにRDMAPヘッダーを変更することによって、まだ起こることができます、その結果、事実上、データ・ストリームを汚します。
By remaining independent of ULP and LLP security protocols, RDMAP will benefit from continuing improvements at those layers. Users are provided flexibility to adapt to their specific security requirements and the ability to adapt to future security challenges. Given this,
ULPとLLPセキュリティプロトコルから独立していたままで残っていることによって、RDMAPはそれらの層で継続的な改善の利益を得るでしょう。 彼らの特定のセキュリティ要件に順応するために柔軟性をユーザに提供します、そして、将来のセキュリティに順応する能力は挑戦します。 これを与えます。
Recio, et al. Standards Track [Page 49] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[49ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
the vulnerabilities of RDMAP to active third-party interference are no greater than any other protocol running over an LLP such as TCP or SCTP.
活発な第三者干渉へのRDMAPの脆弱性はTCPかSCTPなどのLLPをひくよりプロトコル以下ですいかなる他のも。
8.2.2. Requirements for IPsec Services for RDMAP
8.2.2. RDMAPのためのIPsecサービスのための要件
Because IPsec is designed to secure arbitrary IP packet streams, including streams where packets are lost, RDMAP can run on top of IPsec without any change. IPsec packets are processed (e.g., integrity checked and possibly decrypted) in the order they are received, and an RDMAP Data Sink will process the decrypted RDMA Messages contained in these packets in the same manner as RDMA Messages contained in unsecured IP packets.
IPsecがパケットが無くなるところにストリームを含む任意のIPパケットストリームを保証するように設計されているので、RDMAPは少しも変化のないIPsecの上で稼働できます。 IPsecパケットによるオーダーで処理された(例えばチェックされて、ことによると解読された保全)それらが受け取られていて、RDMAP Data Sinkがこれらのパケットに非機密保護しているIPパケットに含まれたRDMA Messagesと同じ方法で含まれた解読されたRDMA Messagesを処理するということです。
The IP Storage working group has defined the normative IPsec requirements for IP Storage [RFC3723]. Portions of this specification are applicable to the RDMAP. In particular, a compliant implementation of IPsec services for RDMAP MUST meet the requirements as outlined in Section 2.3 of [RFC3723]. Without replicating the detailed discussion in [RFC3723], this includes the following requirements:
IP StorageワーキンググループはIP Storage[RFC3723]のための標準のIPsec要件を定義しました。 この仕様の部分はRDMAPに適切です。 特に、RDMAP MUSTのためのサービスが条件を満たすIPsecの対応する実装はセクションに2.3[RFC3723]について概説しました。 [RFC3723]で詳細な論議を模写しないで、これは以下の要件を含んでいます:
1. The implementation MUST support IPsec ESP [RFC2406], as well as
the replay protection mechanisms of IPsec. When ESP is utilized,
per-packet data origin authentication, integrity, and replay
protection MUST be used.
1. 実装はIPsecが超能力[RFC2406]であり、反復操作による保護がIPsecのメカニズムであるとサポートしなければなりません。 超能力が利用されているとき、1パケットあたりのデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
2. It MUST support ESP in tunnel mode and MAY implement ESP in
transport mode.
2. それは、トンネルモードで超能力をサポートしなければならなくて、交通機関で超能力を実装するかもしれません。
3. It MUST support IKE [RFC2409] for peer authentication,
negotiation of security associations, and key management, using
the IPsec DOI [RFC2407].
3. IPsec DOI[RFC2407]を使用して、それは、IKEが同輩認証のための[RFC2409]と、セキュリティ協会の交渉と、かぎ管理であるとサポートしなければなりません。
4. It MUST NOT interpret the receipt of a IKE Phase 2 delete message
as a reason for tearing down the RDMAP stream. Since IPsec
acceleration hardware may only be able to handle a limited number
of active IKE Phase 2 SAs, idle SAs may be dynamically brought
down, and a new SA be brought up again, if activity resumes.
4. それは2がRDMAPストリームを取りこわしながら理由としてのメッセージを削除するIKE Phaseの領収書を解釈してはいけません。 IPsec加速ハードウェアが限られた数のアクティブなIKE Phase2SAsを扱うことができるだけであるかもしれないので、下である、および新しいSAはダイナミックに使用されていないSAsにもたらされるかもしれません。もう一度持って来られてください、活動再開であるなら。
5. It MUST support peer authentication using a pre-shared key, and
MAY support certificate-based peer authentication using digital
signatures. Peer authentication using the public key encryption
methods [RFC2409] SHOULD NOT be used.
5. それは、あらかじめ共有されたキーを使用するのを同輩認証にサポートして、デジタル署名を使用する証明書ベースの同輩認証を5月のサポートにサポートしなければなりません。 同輩認証、公開鍵暗号化メソッド[RFC2409]SHOULD NOTを使用して、使用されてください。
Recio, et al. Standards Track [Page 50] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[50ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
6. It MUST support IKE Main Mode and SHOULD support Aggressive Mode.
IKE Main Mode with pre-shared key authentication SHOULD NOT be
used when either of the peers uses a dynamically assigned IP
address.
6. それはIKE Main ModeとSHOULDサポートAggressive Modeをサポートしなければなりません。 同輩のどちらかであるときに、あらかじめ共有された主要な認証SHOULD NOTが使用されているIKE Main Modeはダイナミックに割り当てられたIPアドレスを使用します。
7. When digital signatures are used to achieve authentication,
either IKE Main Mode or IKE Aggressive Mode MAY be used. In
these cases, an IKE negotiator SHOULD use IKE Certificate Request
Payload(s) to specify the certificate authority (or authorities)
that are trusted in accordance with its local policy. IKE
negotiators SHOULD check the pertinent Certificate Revocation
List (CRL) before accepting a PKI certificate for use in IKE's
authentication procedures.
7. デジタル署名が認証を達成するのに使用されるとき、IKE Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 これらの場合では、IKE交渉者SHOULDは認証局(または、当局)を指定するローカルの方針によると、信じられるIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。
8. Access to locally stored secret information (pre-shared or
private key for digital signing) must be suitably restricted,
since compromise of the secret information nullifies the security
properties of the IKE/IPsec protocols.
8. または、局所的に保存された秘密の情報へのアクセス、(あらかじめ共有される、デジタル署名のための秘密鍵) 秘密の情報の感染がIKE/IPsecプロトコルのセキュリティの特性を無効にするので、適当に制限しなければなりません。
9. It MUST follow the guidelines of Section 2.3.4 of [RFC3723] on
the setting of IKE parameters to achieve a high level of
interoperability without requiring extensive configuration.
9. 大規模な構成を必要としないで高いレベルの相互運用性を達成すると、IKEパラメタの設定の.4セクション2.3[RFC3723]のガイドラインは従われなければなりません。
Furthermore, implementation and deployment of the IPsec services for RDDP should follow the Security Considerations outlined in Section 5 of [RFC3723].
その上、RDDPのためのIPsecサービスの実装と展開は[RFC3723]のセクション5に概説されたSecurity Considerationsに続くべきです。
9. IANA Considerations
9. IANA問題
This document requests no direct action from IANA. The following consideration is listed here as commentary.
このドキュメントはIANAから直接行動を全く要求しません。 以下の考慮は論評としてここに記載されています。
If RDMAP was enabled a priori for a ULP by connecting to a well-known port, this well-known port would be registered for the RDMAP with IANA. The registration of the well-known port will be the responsibility of the ULP specification.
RDMAPがULPのためにウェルノウンポートに接続することによって先験的に有効にされるなら、このウェルノウンポートはRDMAPのためにIANAに登録されるでしょうに。 ウェルノウンポートの登録はULP仕様の責任になるでしょう。
Recio, et al. Standards Track [Page 51] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[51ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
Data Placement over Reliable Transports", RFC 5041, October
2007.
[DDP] 2007年10月のシャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H.,
and P. Thaler, "Internet Small Computer System Interface
(iSCSI) Extensions for Remote Direct Memory Access (RDMA)"
RFC 5046, October 2007.
[iSER]コー、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」RFC5046(2007年10月)。
[MPA] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, October 2007.
[MPA] Culley、P.、Elzur、U.、Recio、R.、べイリー、S.、およびJ.キャリヤー、「マーカーPDUはTCPのために仕様を縁どりながら、並びました」、RFC5044、2007年10月。
[RDMASEC] Pinkerton, J. and E. Deleganes, "Direct Data Placement
Protocol (DDP) / Remote Direct Memory Access Protocol
(RDMAP) Security", RFC 5042, October 2007.
[RDMASEC] ピンカートン、J.、およびE.Deleganesは「データプレースメントプロトコル(DDP)/リモートなダイレクトメモリアクセスプロトコル(RDMAP)セキュリティを指示します」、RFC5042、2007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPの解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", RFC
3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「IPの上でブロックストレージがプロトコルであると機密保護します」、RFC3723(2004年4月)。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[SCTP] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Recio, et al. Standards Track [Page 52] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[52ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
10.2. Informative References
10.2. 有益な参照
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「TLSは2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral、V.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4835、2007年4月。
Recio, et al. Standards Track [Page 53] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[53ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Appendix A. DDP Segment Formats for RDMA Messages
RDMAメッセージのための付録A.DDPセグメント形式
This appendix is for information only and is NOT part of the standard. It simply depicts the DDP Segment format for the various RDMA Messages.
この付録は、情報だけのためにあって、規格の一部ではありません。 それは様々なRDMA Messagesのために単にDDP Segment書式を表現します。
A.1. DDP Segment for RDMA Write
A.1。 RDMAのためのDDPセグメントは書きます。
The following figure depicts an RDMA Write, DDP Segment:
以下の図はRDMA Write、DDP Segmentについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Write ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 男一人でデータ受信端末| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ受信端末のタグ付けをされたオフセット| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDMAはULPに有効搭載量を書きます。| // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: RDMA Write, DDP Segment Format
図11: RDMAは書いて、DDPはセグメント形式です。
Recio, et al. Standards Track [Page 54] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[54ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
A.2. DDP Segment for RDMA Read Request
A.2。 RDMA読み出し要求のためのDDPセグメント
The following figure depicts an RDMA Read Request, DDP Segment:
以下の図はRDMA Read Request、DDP Segmentについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag (SinkSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Sink Tagged Offset (SinkTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Message Size (RDMARDSZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source STag (SrcSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Source Tagged Offset (SrcTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます(使用されません)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(RDMA読み出し要求)待ち行列番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(RDMA読み出し要求)メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(RDMA読み出し要求)メッセージオフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ受信端末雄ジカ(SinkSTag)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タグ付けをされたデータ受信端末は(SinkTO)+を相殺しました。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDMA既読メッセージサイズ(RDMARDSZ)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ送信端末雄ジカ(SrcSTag)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タグ付けをされたデータ送信端末は(SrcTO)+を相殺しました。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: RDMA Read Request, DDP Segment format
図12: RDMA Read Request、DDP Segment形式
Recio, et al. Standards Track [Page 55] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[55ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
A.3. DDP Segment for RDMA Read Response
A.3。 応答が読まれたRDMAのためのDDPセグメント
The following figure depicts an RDMA Read Response, DDP Segment:
以下の図はRDMA Read Response、DDP Segmentについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Response ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 男一人でデータ受信端末| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ受信端末のタグ付けをされたオフセット| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDMAは応答ULP有効搭載量を読みます。| // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: RDMA Read Response, DDP Segment Format
図13: RDMAは応答、DDPセグメント形式を読みます。
A.4. DDP Segment for Send and Send with Solicited Event
A.4。 DDPセグメント、発信してください、そして、請求された出来事と共に発信してください。
The following figure depicts a Send and Send with Solicited Request, DDP Segment:
以下の図はSolicited Request、DDP Segmentと共にSendとSendについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます(使用されません)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) 待ち行列番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) メッセージオフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量をULPに送ってください。| // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Send and Send with Solicited Event, DDP Segment Format
図14: セグメント形式を送って、請求された出来事、DDPと共に送ってください。
Recio, et al. Standards Track [Page 56] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[56ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
A.5. DDP Segment for Send with Invalidate and Send with SE and
Invalidate
A.5。 DDPセグメント、発信する、無効にして、SEと共に送って、無効にする。
The following figure depicts a Send with Invalidate and Send with Solicited and Invalidate Request, DDP Segment:
以下の図はInvalidateとSendと共にSolicitedとInvalidate Request、DDP SegmentでSendについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 雄ジカを無効にしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) 待ち行列番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (発信します) メッセージオフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量をULPに送ってください。| // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Send with Invalidate and Send with SE and Invalidate,
DDP Segment Format
図15: 発信する、無効にして、SEと共に送って、無効にする、DDPセグメント形式
Recio, et al. Standards Track [Page 57] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[57ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
A.6. DDP Segment for Terminate
A.6。 DDPセグメント、終わり
The following figure depicts a Terminate, DDP Segment:
以下の図はTerminate、DDP Segmentについて表現します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Terminate Control | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Segment Length (if any) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Terminated DDP Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
| Terminated RDMA Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDPコントロール| RDMAコントロール| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます(使用されません)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(終える)待ち行列番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(終える)メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP(終える)メッセージオフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールを終えてください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (もしあれば)のDDP Segment Length| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 終えられたDDP Header(もしあれば)| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // // | 終えられたRDMA Header(もしあれば)| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Terminate, DDP Segment Format
図16: 終わってください、そして、DDPは形式を区分します。
Recio, et al. Standards Track [Page 58] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[58ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Appendix B. Ordering and Completion Table
注文と完成が見送る付録B.
The following table summarizes the ordering relationships that are defined in Section 5.5, "Ordering and Completions", from the standpoint of the local peer issuing the two Operations. Note that in the table that follows, Send includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate.
以下のテーブルはセクション5.5と、「注文と落成」で定義される注文関係をまとめます、2Operationsを発行する地元の同輩の見地から。 続くテーブルではSendがSendを含んでいるというメモ、InvalidateとSend、Solicited EventとSend、およびSolicited EventとInvalidateとSend。
------+-------+----------------+----------------+----------------
First | Later | Placement | Placement | Ordering
Op | Op | guarantee at | guarantee at | guarantee at
| | Remote Peer | Local Peer | Remote Peer
| | | |
------+-------+----------------+----------------+----------------
Send | Send | No placement | Not applicable | Completed in
| | guarantee. If | | order.
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
Send | RDMA | No placement | Not applicable | Not applicable
| Write | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
Send | RDMA | No placement | RDMA Read | RDMA Read
| Read | guarantee | Response | Response
| | between Send | Payload will | Message will
| | Payload and | not be placed | not be
| | RDMA Read | at the local | generated until
| | Request Header | peer until the | Send has been
| | | Send Payload is| Completed
| | | placed at the |
| | | Remote Peer |
------+-------+----------------+----------------+----------------
RDMA | Send | No placement | Not applicable | Not applicable
Write | | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+---------------- 1番目| より遅れる| プレースメント| プレースメント| オプアートを注文します。| オプアート| 保証| 保証| 保証| | リモート同輩| 地元の同輩| リモート同輩| | | | ------+-------+----------------+----------------+---------------- 発信してください。| 発信してください。| プレースメントがありません。| 適切でない| 完成| | 保証します。 if| | 注文してください。 | | 保証はそうです。| | | | 必要であることで、見てください。| | | | 1に脚注をつけてください。 | | ------+-------+----------------+----------------+---------------- 発信してください。| RDMA| プレースメントがありません。| 適切でない| 適切でない| 書いてください。| 保証します。 if| | | | 保証はそうです。| | | | 必要であることで、見てください。| | | | 1に脚注をつけてください。 | | ------+-------+----------------+----------------+---------------- 発信してください。| RDMA| プレースメントがありません。| RDMAは読みます。| RDMAは読みます。| 読んでください。| 保証| 応答| 応答| | 間に、発信してください。| 有効搭載量はそうするでしょう。| メッセージはそうするでしょう。| | そして有効搭載量。| 置かれないでください。| ありません。| | RDMAは読みます。| 地方で| 発生| | ヘッダーを要求してください。| 同輩| 発信| | | 発信、有効搭載量はそうです。| 完成されます。| | | 入賞します。| | | | リモート同輩| ------+-------+----------------+----------------+---------------- RDMA| 発信してください。| プレースメントがありません。| 適切でない| 適切なWriteでない| | 保証します。 if| | | | 保証はそうです。| | | | 必要であることで、見てください。| | | | 1に脚注をつけてください。 | |
Recio, et al. Standards Track [Page 59] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[59ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | Not applicable | Not applicable
Write | Write | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | RDMA Read | Not applicable
Write | Read | guarantee | Response |
| | between RDMA | Payload will |
| | Write Payload | not be placed |
| | and RDMA Read | at the local |
| | Request Header | peer until the |
| | | RDMA Write |
| | | Payload is |
| | | placed at the |
| | | Remote Peer |
------+-------+----------------+----------------+----------------
RDMA | Send | No placement | Send Payload | Not applicable
Read | | guarantee | may be placed |
| | between RDMA | at the remote |
| | Read Request | peer before the|
| | Header and Send| RDMA Read |
| | payload | Response is |
| | | generated. |
| | | If guarantee is|
| | | necessary, see |
| | | footnote 2. |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | RDMA Write | Not applicable
Read | Write | guarantee | Payload may be |
| | between RDMA | placed at the |
| | Read Request | Remote Peer |
| | Header and RDMA| before the RDMA|
| | Write payload | Read Response |
| | | is generated. |
| | | If guarantee is|
| | | necessary, see |
| | | footnote 2. |
------+-------+----------------+----------------+---------------- RDMA| RDMA| プレースメントがありません。| 適切でない| 適切なWriteでない| 書いてください。| 保証します。 if| | | | 保証はそうです。| | | | 必要であることで、見てください。| | | | 1に脚注をつけてください。 | | ------+-------+----------------+----------------+---------------- RDMA| RDMA| プレースメントがありません。| RDMAは読みます。| 適切なWriteでない| 読んでください。| 保証| 応答| | | RDMAの間で| 有効搭載量はそうするでしょう。| | | 有効搭載量を書いてください。| 置かれないでください。| | | そして、RDMAは読みます。| 地方で| | | ヘッダーを要求してください。| 同輩| | | | RDMAは書きます。| | | | 有効搭載量はそうです。| | | | 入賞します。| | | | リモート同輩| ------+-------+----------------+----------------+---------------- RDMA| 発信してください。| プレースメントがありません。| 有効搭載量を送ってください。| 適切なReadでない| | 保証| 置かれるかもしれません。| | | RDMAの間で| リモートで| | | 読み出し要求| 以前、じっと見てください。| | | ヘッダー、発信してください。| RDMAは読みます。| | | ペイロード| 応答はそうです。| | | | 発生。 | | | | 保証がそうなら| | | | 必要であることで、見てください。| | | | 2に脚注をつけてください。 | ------+-------+----------------+----------------+---------------- RDMA| RDMA| プレースメントがありません。| RDMAは書きます。| 適切なReadでない| 書いてください。| 保証| 有効搭載量はそうです。| | | RDMAの間で| 入賞します。| | | 読み出し要求| リモート同輩| | | ヘッダーとRDMA| RDMAの前で| | | ペイロードを書いてください。| 応答を読んでください。| | | | 発生します。 | | | | 保証がそうなら| | | | 必要であることで、見てください。| | | | 2に脚注をつけてください。 |
Recio, et al. Standards Track [Page 60] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[60ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | No placement | Second RDMA
Read | Read | guarantee of | guarantee of | Read Response
| | the two RDMA | the two RDMA | will not be
| | Read Request | Read Response | generated until
| | Headers | Payloads. | first RDMA Read
| | Additionally, | | Response is
| | there is no | | generated.
| | guarantee that | |
| | the Tagged | |
| | Buffers | |
| | referenced in | |
| | the RDMA Read | |
| | will be read in| |
| | order | |
------+-------+----------------+----------------+---------------- RDMA| RDMA| プレースメントがありません。| プレースメントがありません。| 第2RDMAは読みます。| 読んでください。| 保証| 保証| 応答を読んでください。| | 2RDMA| 2RDMA| ないでしょう。| | 読み出し要求| 応答を読んでください。| 発生| | ヘッダー| 有効搭載量。 | 最初に、RDMA Read| | さらに| | 応答はそうです。| | いいえがあります。| | 発生。 | | それを保証してください。| | | | タグ付け| | | | バッファ| | | | 中では、参照をつけられます。| | | | RDMAは読みます。| | | | 読まれるでしょう。| | | | オーダー| |
Figure 17: Operation Ordering
図17: 操作注文
Footnote 1: If the guarantee is necessary, a ULP may insert an RDMA Read operation and wait for it to complete to act as a Fence.
脚注1: 保証が必要であるなら、ULPはそれがFenceとして機能するように完了するRDMA Read操作と待ちを挿入するかもしれません。
Footnote 2: If the guarantee is necessary, a ULP may wait for the RDMA Read operation to complete before performing the Send.
脚注2: 保証が必要であるなら、ULPはSendを実行する前に完了するRDMA Read操作を待つかもしれません。
Appendix C. Contributors
付録C.貢献者
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-2769 EMail: dwight.barron@hp.com
ドワイトバロンヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 281-514-2769 メールしてください: dwight.barron@hp.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: 949-926-6383 EMail: caitlinb@broadcom.com
ケイトリンBestler Broadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 949-926-6383 メールしてください: caitlinb@broadcom.com
John Carrier Cray, Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 USA Phone: 206-701-2090 EMail: carrier@cray.com
ジョンキャリヤーザリガニInc.411First Avenue S、Suite600シアトル、ワシントン98104-2860米国は以下に電話をします。 206-701-2090 メールしてください: carrier@cray.com
Recio, et al. Standards Track [Page 61] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[61ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
テッドコンプトンEMC社のリサーチトライアングル公園、NC27709米国電話: 919-248-6075 メールしてください: compton_ted@emc.com
Uri Elzur Broadcom Corporation 16215 Alton Parkway Irvine, California 92619-7013 USA Phone: +1 (949) 585-6432 EMail: Uri@Broadcom.com
ユリElzur Broadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1 (949) 585-6432 メールしてください: Uri@Broadcom.com
Hari Ghadia Gen10 Technology, Inc. 1501 W Shady Grove Road Grand Prairie, TX 75050 Phone: (972) 301 3630 EMail: hghadia@gen10technology.com
ハーリGhadia Gen10技術Inc.1501のW陰になっている木立道路壮大な大草原、テキサス75050電話: (972) 301 3630はメールされます: hghadia@gen10technology.com
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, Arizona 85226 Phone: 480-554-3116 EMail: howard.c.herbert@intel.com
ハワードC.ハーバートインテル社MS CH7-404 5000の西ろうそく屋Blvd. ろうそく屋、アリゾナ85226電話: 480-554-3116 メールしてください: howard.c.herbert@intel.com
Mike Ko IBM 650 Harry Rd. San Jose, CA 95120 Phone: (408) 927-2085 EMail: mako@us.ibm.com
マイクコーIBM650ハリー通り サンノゼ、カリフォルニア 95120は以下に電話をします。 (408) 927-2085 メールしてください: mako@us.ibm.com
Mike Krause Hewlett-Packard Company 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: 408-447-3191 EMail: krause@cup.hp.com
マイククラウジーヒューレット・パッカード43LN社19410はRoadカルパチーノ(カリフォルニア)95014米国電話に入植します: 408-447-3191 メールしてください: krause@cup.hp.com
Recio, et al. Standards Track [Page 62] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[62ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro, Oregon 97124 Phone: 503-712-4106 EMail: dave.b.minturn@intel.com
ヒルズバロ、オレゴン 97124が電話をするデーヴMinturnインテル社MS JF1-210 5200東北イーラムヤング公園道路: 503-712-4106 メールしてください: dave.b.minturn@intel.com
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine, California 92619-7013 USA Phone: +1 (949) 926-7149 EMail: MPenna@Broadcom.com
マイクおおばねBroadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1 (949) 926-7149 メールしてください: MPenna@Broadcom.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com
ワシントン98052レッドモンド(米国)がメールされるジムピンカートンマイクロソフトInc.1マイクロソフト方法: jpink@microsoft.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
血液のシャーBroadcom社5300のカリフォルニアAvenueカリフォルニア92617アーバイン(米国)は以下に電話をします。 +1 (949) 926-6941 メールしてください: hemal@broadcom.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 8836 EMail: allyn@cisco.com
カリフォルニア95134サンノゼ(米国)が電話をするアリンRomanowシスコシステムズの170Wタスマンのドライブ: +1 8836年の408 525メール: allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
トムTalpeyはTrapelo道路#16MA02451ウォルサム(米国)が電話をする器具1601をネットワークでつなぎます: +1 (781) 768-5329 メールしてください: thomas.talpey@netapp.com
Recio, et al. Standards Track [Page 63] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[63ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1-916-570-2707 EMail: pthaler@broadcom.com
パトリシアターレルBroadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1-916-570-2707 メールしてください: pthaler@broadcom.com
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard MS 5668 Roseville, CA 95747-5668 USA Phone: +1 916 785 5198 EMail: jim_wendt@hp.com
5668年のジムウェントヒューレット・パッカード社8000のフットヒルズ並木街MSローズビル、カリフォルニア95747-5668米国電話: +1 5198年の916 785メール: jim_wendt@hp.com
Madeline Vega IBM 11400 Burnet Rd. Bld.45-2L-007 Austin, TX 78758 USA Phone: 512-838-7739 EMail: mvega1@us.ibm.com
マデリーンベガIBM11400Burnet通り Bld.45-2L-007テキサス78758オースチン(米国)は以下に電話をします。 512-838-7739 メールしてください: mvega1@us.ibm.com
Claudia Salzberg IBM 11501 Burnet Rd. Bld.902-5B-014 Austin, TX 78758 USA Phone: 512-838-5156 EMail: salzberg@us.ibm.com
クラウディアSalzberg IBM11501Burnet通り Bld.902-5B-014テキサス78758オースチン(米国)は以下に電話をします。 512-838-5156 メールしてください: salzberg@us.ibm.com
Recio, et al. Standards Track [Page 64] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[64ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Authors' Addresses
作者のアドレス
Renato J. Recio IBM Corp. 11501 Burnett Road Austin, TX 78758 USA Phone: 512-838-3685 EMail: recio@us.ibm.com
レナートJ.Recio IBM社11501のバーネット・Roadテキサス78758オースチン(米国)は以下に電話をします。 512-838-3685 メールしてください: recio@us.ibm.com
Bernard Metzler IBM Research GmbH Zurich Research Laboratory Saeumerstrasse 4 CH-8803 Rueschlikon, Switzerland Phone: +41 44 724 8605 EMail: bmt@zurich.ibm.com
CH-8803 Rueschlikon、Saeumerstrasse4スイスが電話をするバーナードメツラーIBM研究GmbHチューリッヒ研究所: +41 44 724 8605はメールされます: bmt@zurich.ibm.com
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-5543 EMail: paul.culley@hp.com
ポールR.Culleyヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 281-514-5543 メールしてください: paul.culley@hp.com
Jeff Hilland Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-9489 EMail: jeff.hilland@hp.com
ジェフHillandヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 281-514-9489 メールしてください: jeff.hilland@hp.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 USA Phone: +1 (831) 247-4464 Email: Dave.Garcia@StanfordAlumni.org
デーヴガルシア24100Hutchinson通り カリフォルニア95033ロスガトス(米国)は以下に電話をします。 +1 (831) 247-4464 メールしてください: Dave.Garcia@StanfordAlumni.org
Recio, et al. Standards Track [Page 65] RFC 5040 RDMA Protocol Specification October 2007
Recio、他 標準化過程[65ページ]RFC5040RDMAは仕様2007年10月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Recio, et al. Standards Track [Page 66]
Recio、他 標準化過程[66ページ]
一覧
スポンサーリンク
