RFC5041 日本語訳
5041 Direct Data Placement over Reliable Transports. H. Shah, J.Pinkerton, R. Recio, P. Culley. October 2007. (Format: TXT=84642 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Shah
Request for Comments: 5041 Broadcom Corporation
Category: Standards Track J. Pinkerton
Microsoft Corporation
R. Recio
IBM Corporation
P. Culley
Hewlett-Packard Company
October 2007
コメントを求めるワーキンググループH.シャー要求をネットワークでつないでください: 5041年のBroadcom社のカテゴリ: 標準化過程J.ピンカートンマイクロソフト社R.Recio IBM社のP.Culleyヒューレット・パッカード会社2007年10月
Direct Data Placement over Reliable Transports
信頼できる輸送の上のダイレクトデータプレースメント
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
要約
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers.
Direct Data Placementプロトコルは直接上側のプロトコルの層のものへの受信データが中間的バッファなしでバッファを受け取るというPlaceへの情報を提供します。 これは中間的バッファを通してデータを移すと関連している余分なCPUとメモリ使用量を取り外します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Architectural Goals ........................................3
1.2. Protocol Overview ..........................................4
1.3. DDP Layering ...............................................6
2. Glossary ........................................................7
2.1. General ....................................................7
2.2. LLP ........................................................9
2.3. Direct Data Placement (DDP) ................................9
3. Reliable Delivery LLP Requirements .............................12
4. Header Format ..................................................13
4.1. DDP Control Field .........................................13
4.2. DDP Tagged Buffer Model Header ............................14
4.3. DDP Untagged Buffer Model Header ..........................16
4.4. DDP Segment Format ........................................17
5. Data Transfer ..................................................18
5.1. DDP Tagged or Untagged Buffer Models ......................18
5.1.1. Tagged Buffer Model ................................18
1. 序論…3 1.1. 建築目標…3 1.2. 概要について議定書の中で述べてください…4 1.3. DDPレイヤリング…6 2. 用語集…7 2.1. 一般…7 2.2. LLP…9 2.3. データプレースメント(DDP)を指示してください…9 3. 信頼できる配信LLP要件…12 4. ヘッダー形式…13 4.1. DDP制御フィールド…13 4.2. DDPはバッファモデルヘッダーにタグ付けをしました…14 4.3. DDP Untaggedはモデルヘッダーをバッファリングします…16 4.4. DDPセグメント形式…17 5. データ転送…18 5.1. タグ付けをされたDDPかUntaggedがモデルをバッファリングします…18 5.1.1. バッファモデルにタグ付けをします…18
Shah, et al. Standards Track [Page 1] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[1ページ]。
5.1.2. Untagged Buffer Model ..............................18
5.2. Segmentation and Reassembly of a DDP Message ..............19
5.3. Ordering Among DDP Messages ...............................21
5.4. DDP Message Completion and Delivery .......................21
6. DDP Stream Setup and Teardown ..................................22
6.1. DDP Stream Setup ..........................................22
6.2. DDP Stream Teardown .......................................22
6.2.1. DDP Graceful Teardown ..............................22
6.2.2. DDP Abortive Teardown ..............................23
7. Error Semantics ................................................24
7.1. Errors Detected at the Data Sink ..........................24
7.2. DDP Error Numbers .........................................25
8. Security Considerations ........................................26
8.1. Protocol-Specific Security Considerations .................26
8.2. Association of an STag and a DDP Stream ...................26
8.3. Security Requirements .....................................27
8.3.1. RNIC Requirements ..................................28
8.3.2. Privileged Resources Manager Requirement ...........29
8.4. Security Services for DDP .................................30
8.4.1. Available Security Services ........................30
8.4.2. Requirements for IPsec Services for DDP ............30
9. IANA Considerations ............................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Receive Window Sizing ................................34
Appendix B. Contributors .........................................34
5.1.2. バッファモデルをUntaggedしました…18 5.2. DDPメッセージの分割とReassembly…19 5.3. DDPメッセージの中で注文します…21 5.4. DDPメッセージ完成と配送…21 6. DDPストリームセットアップと分解…22 6.1. DDPストリームセットアップ…22 6.2. DDPストリーム分解…22 6.2.1. DDPの優雅な分解…22 6.2.2. DDPの不成功の分解…23 7. 誤り意味論…24 7.1. データ受信端末に検出された誤り…24 7.2. DDPエラー番号…25 8. セキュリティ問題…26 8.1. プロトコル特有のセキュリティ問題…26 8.2. 雄ジカの群集とDDPは流れます…26 8.3. セキュリティ要件…27 8.3.1. RNIC要件…28 8.3.2. 特権があるリソースマネージャ要件…29 8.4. DDPのためのセキュリティサービス…30 8.4.1. 利用可能なセキュリティー・サービス…30 8.4.2. DDPのためのIPsecサービスのための要件…30 9. IANA問題…31 10. 参照…32 10.1. 標準の参照…32 10.2. 有益な参照…33付録A.はウィンドウサイズ処理を受けます…34 付録B.貢献者…34
Table of Figures
数値表
Figure 1: DDP Layering ............................................6
Figure 2: MPA, DDP, and RDMAP Header Alignment ....................7
Figure 3: DDP Control Field ......................................13
Figure 4: Tagged Buffer DDP Header ...............................15
Figure 5: Untagged Buffer DDP Header .............................16
Figure 6: DDP Segment Format .....................................17
図1: DDPレイヤリング…6 図2: MPA、DDP、およびRDMAPヘッダー整列…7 図3: DDP制御フィールド…13 図4: バッファDDPヘッダーにタグ付けをします…15 図5: バッファDDPヘッダーをUntaggedしました…16 図6: DDPセグメント形式…17
Shah, et al. Standards Track [Page 2] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[2ページ]。
1. Introduction
1. 序論
Note: The capitalization of certain words in this document indicates they are being used with the specific meaning given in the glossary (Section 2).
以下に注意してください。 ある単語の資源化は、それらが用語集(セクション2)で与える特定の意味と共に使用されているのを本書では示します。
Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol (ULP) to send data to a Data Sink without requiring the Data Sink to Place the data in an intermediate buffer - thus, when the data arrives at the Data Sink, the network interface can Place the data directly into the ULP's buffer. This can enable the Data Sink to consume substantially less memory bandwidth than a buffered model because the Data Sink is not required to move the data from the intermediate buffer to the final destination. Additionally, this can enable the network protocol to consume substantially fewer CPU cycles than if the CPU was used to move the data, and this can remove the bandwidth limitation of only being able to move data as fast as the CPU can copy the data.
ダイレクトData Placementプロトコル(DDP)は、Upper Layerプロトコル(ULP)がData Sinkへの中間的バッファのPlaceへのData Sinkを必要とすることのないデータをデータに送るのを可能にします--その結果、データがData Sinkに到着すると、ネットワーク・インターフェースが到着できる、Place、ULPのバッファの直接中へのデータ。 Data Sinkが中間的バッファから最終的な目的地までデータを動かす必要はないので、これは、Data Sinkが実質的にバッファリングされたモデルより少ないメモリ帯域幅を消費するのを可能にすることができます。 さらに、これは、CPUがデータを動かすのに使用されたか、そして、これが可能にすることができるよりネットワーク・プロトコルが実質的にさらに少ないCPUサイクルを費やすのを可能にすることができます。CPUがデータをコピーできるのと同じくらい速くデータを動かすことができるだけの帯域幅制限を取り除いてください。
DDP preserves ULP record boundaries (messages) while providing a variety of data transfer mechanisms and completion mechanisms to be used to transfer ULP messages.
DDPはULPメッセージを移すのに使用されるためにさまざまなデータ転送メカニズムと完成メカニズムを提供している間、ULP境界の記録(メッセージ)を保存します。
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. 建築目標
DDP has been designed with the following high-level architectural goals:
DDPは以下のハイレベルの建築目標で設計されています:
* Provide a buffer model that enables the Local Peer to Advertise
a named buffer (i.e., a Tag for a buffer) to the Remote Peer,
such that across the network the Remote Peer can Place data into
the buffer at Remote-Peer-specified locations. This is referred
to as the Tagged Buffer Model.
* Local Peerを広告、バッファ(すなわち、バッファのためのTag)というaに有効にするバッファモデルをRemote Peerに供給してください、ネットワークの向こう側に、Remote PeerはRemote同輩が指定している位置のバッファの中へのPlaceデータをそうすることができるようなもの これはTagged Buffer Modelと呼ばれます。
* Provide a second receive buffer model that preserves ULP message
boundaries from the Remote Peer and keeps the Local Peer's
buffers anonymous (i.e., Untagged). This is referred to as the
Untagged Buffer Model.
* Remote PeerからULPメッセージ限界を保持して、Local Peerのバッファを匿名に保つ受信バッファモデル(すなわち、Untagged)を1秒に提供してください。 これはUntagged Buffer Modelと呼ばれます。
* Provide reliable, in-order Delivery semantics for both Tagged
and Untagged Buffer Models.
* 信頼できて、注文しているDelivery意味論をTaggedとUntagged Buffer Modelsの両方に供給してください。
* Provide segmentation and reassembly of ULP messages.
* ULPメッセージの分割と再アセンブリを提供してください。
Shah, et al. Standards Track [Page 3] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[3ページ]。
* Enable the ULP Buffer to be used as a reassembly buffer, without
a need for a copy, even if incoming DDP Segments arrive out of
order. This requires the protocol to separate Data Placement of
ULP Payload contained in an incoming DDP Segment from Data
Delivery of completed ULP Messages.
* ULP Bufferが再アセンブリバッファとして使用されるのを可能にしてください、コピーの必要性なしで、入って来るDDP Segmentsが故障していた状態で到着しても。 これは、完成したULP MessagesのData Deliveryと入って来るDDP Segmentに含まれたULP有効搭載量のData Placementを切り離すためにプロトコルを必要とします。
* If the Lower Layer Protocol (LLP) supports multiple LLP Streams
within an LLP Connection, provide the above capabilities
independently on each LLP Stream and enable the capability to be
exported on a per-LLP-Stream basis to the ULP.
* Lower Layerプロトコル(LLP)がLLP Connectionの中の複数のLLP Streamsをサポートするなら、各LLP Streamで独自に上の能力を提供してください、そして、LLP単位で流れるベースでULPにエクスポートするべき能力を可能にしてください。
1.2. Protocol Overview
1.2. プロトコル概要
DDP supports two basic data transfer models - a Tagged Buffer data transfer model and an Untagged Buffer data transfer model.
DDPは、2つの基礎データが転送モデルであるとサポートします--Tagged Bufferデータ転送モデルとUntagged Bufferデータ転送モデル。
The Tagged Buffer data transfer model requires the Data Sink to send the Data Source an identifier for the ULP Buffer, referred to as a Steering Tag (STag). The STag is transferred to the Data Source using a ULP-defined method. Once the Data Source ULP has an STag for a destination ULP Buffer, it can request that DDP send the ULP data to the destination ULP Buffer by specifying the STag to DDP. Note that the Tagged Buffer does not have to be filled starting at the beginning of the ULP Buffer. The ULP Data Source can provide an arbitrary offset into the ULP Buffer.
Tagged Bufferデータ転送モデルは、Data SinkがSteering Tag(STag)と呼ばれたULP Bufferのための識別子をData Sourceに送るのを必要とします。 ULPによって定義されたメソッドを使用することでSTagをData Sourceに移します。 Data Source ULPに目的地ULP BufferへのSTagがいったんあると、それは、DDPがDDPにSTagを指定することによってULPデータを目的地ULP Bufferに送るよう要求できます。 Tagged BufferがULP Bufferの始めからいっぱいにされる必要はないことに注意してください。 ULP Data Sourceは任意のオフセットをULP Bufferに供給できます。
The Untagged Buffer data transfer model enables data transfer to occur without requiring the Data Sink to Advertise a ULP Buffer to the Data Source. The Data Sink can queue up a series of receive ULP Buffers. An Untagged DDP Message from the Data Source consumes an Untagged Buffer at the Data Sink. Because DDP is message oriented, even if the Data Source sends a DDP Message payload smaller than the receive ULP Buffer, the partially filled receive ULP Buffer is delivered to the ULP anyway. If the Data Source sends a DDP Message payload larger than the receive ULP Buffer, it results in an error.
Untagged Bufferデータ転送モデルは、データ転送が広告、ULP BufferにData Sinkを必要としないでData Sourceに起こるのを可能にします。 待ち行列がシリーズを上げるData Sink缶はULP Buffersを受けます。 Data SourceからのUntagged DDP MessageはData SinkでUntagged Bufferを消費します。 ULP Bufferを受けてください、そして、部分的にいっぱいにされるのはULP Bufferを受けます。DDPがData Sourceが、より小さくDDP Messageペイロードを送っても適応するメッセージである、とにかくULPに提供されます。 Data Sourceが、より大きい状態でDDP Messageペイロードを送る、ULP Bufferを受けてください、そして、それは誤りをもたらします。
There are several key differences between the Tagged and Untagged Buffer Model:
TaggedとUntagged Buffer Modelの間には、いくつかの主要な違いがあります:
* For the Tagged Buffer Model, the Data Source specifies which
received Tagged Buffer will be used for a specific Tagged DDP
Message (sender-based ULP Buffer management). For the Untagged
Buffer Model, the Data Sink specifies the order in which
Untagged Buffers will be consumed as Untagged DDP Messages are
received (receiver-based ULP Buffer management).
* Tagged Buffer Modelとして、Data Sourceは、どの容認されたTagged Bufferが特定のTagged DDP Message(送付者を拠点とするULP Buffer管理)に使用されるかを指定します。 Untagged Buffer Modelとして、Data SinkはUntagged DDP Messagesが受け取られているときUntagged Buffersが消費されるオーダー(受信機を拠点とするULP Buffer管理)を指定します。
* For the Tagged Buffer Model, the ULP at the Data Sink must
Advertise the ULP Buffer to the Data Source through a ULP
* タグ付けをされたバッファモデルのために、データ受信端末のULPはULPを通してULPバッファのデータ送信端末に広告を出さなければなりません。
Shah, et al. Standards Track [Page 4] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[4ページ]。
specific mechanism before data transfer can occur. For the
Untagged Buffer Model, data transfer can occur without an end-
to-end explicit ULP Buffer Advertisement. Note, however, that
the ULP needs to address flow control issues.
データ転送の前の特定のメカニズムは現れることができます。 Untagged Buffer Modelに関しては、データ転送は終わりまでの終わりの明白なULP Buffer Advertisementなしで起こることができます。 しかしながら、ULPが、フロー制御問題を扱う必要に注意してください。
* For the Tagged Buffer Model, a DDP Message can start at an
arbitrary offset within the Tagged Buffer. For the Untagged
Buffer Model, a DDP Message can only start at offset 0.
* Tagged Buffer Modelに関しては、DDP MessageはTagged Bufferの中の任意のオフセットのときに始まることができます。 Untagged Buffer Modelに関しては、DDP Messageはオフセット0時に始まることができるだけです。
* The Tagged Buffer Model allows multiple DDP Messages targeted to
a Tagged Buffer with a single ULP Buffer Advertisement. The
Untagged Buffer Model requires associating a receive ULP Buffer
for each DDP Message targeted to an Untagged Buffer.
* Tagged Buffer Modelは独身のULP Buffer Advertisementと共にTagged Bufferに狙う複数のDDP Messagesを許容します。 Untagged Buffer Modelは、交際するのを必要とします。aはUntagged Bufferに狙うそれぞれのDDP MessageのためにULP Bufferを受けます。
Either data transfer model Places a ULP Message into a DDP Message. Each DDP Message is then sliced into DDP Segments that are intended to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer Protocol Data Unit (MULPDU). Thus, the ULP can post arbitrarily sized ULP Messages, containing up to 2^32 - 1 octets of ULP Payload, and DDP slices the ULP message into DDP Segments, which are reassembled transparently at the Data Sink.
DDP Messageへのデータ転送モデルPlaces a ULP Message。 そして、それぞれのDDP Messageは下位層プロトコル(LLP)の最大のUpper LayerプロトコルData Unitの中で合うことを意図するDDP Segmentsに切られます(MULPDU)。 したがって、ULPは任意に大きさで分けられたULP Messages、ULP有効搭載量について1最大2^32--八重奏を含むのを掲示できます、そして、DDPはDDP SegmentsにULPメッセージを切ります。(Segmentsは透過的にData Sinkで組み立て直されます)。
DDP provides in-order delivery for the ULP. However, DDP differentiates between Data Delivery and Data Placement. DDP provides enough information in each DDP Segment to allow the ULP Payload in each inbound DDP Segment payloads to be directly Placed into the correct ULP Buffer, even when the DDP Segments arrive out- of-order. Thus, DDP enables the reassembly of ULP Payload contained in DDP Segments of a DDP Message into a ULP Message to occur within the ULP Buffer, therefore eliminating the traditional copy out of the reassembly buffer into the ULP Buffer.
DDPはオーダーにおける配送をULPに供給します。 しかしながら、DDPはData DeliveryとData Placementを区別します。 DDPはそれぞれのDDP SegmentのDDP Segmentsであるときに、直接、正しいULP Bufferで、同等へのPlacedが到着するということになるようにそれぞれの本国行きのDDP SegmentのULP有効搭載量にペイロードを許容できるくらいの情報をオーダーの外に提供します。 したがって、DDPは、DDP MessageのDDP SegmentsにULP Messageに含まれたULP有効搭載量の再アセンブリがULP Bufferの中に現れるのを可能にします、したがって、伝統的なコピーを再アセンブリバッファからULP Bufferに排除します。
A DDP Message's payload is Delivered to the ULP when:
DDP MessageのペイロードがULPへのDeliveredである、いつ:
* all DDP Segments of a DDP Message have been completely received,
and the payload of the DDP Message has been Placed into the
associated ULP Buffer,
* DDP MessageのすべてのDDP Segmentsを完全に受け取りました、そして、DDP Messageのペイロードは関連ULP BufferへのPlacedです。
* all prior DDP Messages have been Placed, and
* そしてすべての先のDDP MessagesがPlacedである。
* all prior DDP Message Deliveries have been performed.
* すべての先のDDP Message Deliveriesが実行されました。
The LLP under DDP may support a single LLP Stream of data per connection (e.g., TCP [TCP]) or multiple LLP Streams of data per connection (e.g., SCTP [SCTP]). But in either case, DDP is specified such that each DDP Stream is independent and maps to a single LLP Stream. Within a specific DDP Stream, the LLP Stream is required to
DDPの下におけるLLPは1接続あたりのデータの独身のLLP Stream(例えば、TCP[TCP])か1接続あたりのデータの複数のLLP Streams(例えば、SCTP[SCTP])をサポートするかもしれません。 しかし、どちらの場合ではも、DDPが指定されるので、それぞれのDDP Streamは独立していて、LLP Streamをシングルに写像します。 特定のDDP Streamの中では、LLP Streamが必要です。
Shah, et al. Standards Track [Page 5] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[5ページ]。
provide in-order, reliable Delivery. Note that DDP has no ordering guarantees between DDP Streams.
注文していて、信頼できるDeliveryを提供してください。 DDPがDDP Streamsの間に注文していない保証を持っていることに注意してください。
A DDP protocol could potentially run over reliable Delivery LLPs or unreliable Delivery LLPs. This specification requires reliable, in order Delivery LLPs.
DDPプロトコルは潜在的に信頼できるDelivery LLPsか頼り無いDelivery LLPsをひくかもしれません。 この仕様が必要である、オーダーDelivery LLPsでは、信頼できます。
1.3. DDP Layering
1.3. DDPレイヤリング
DDP is intended to be LLP independent, subject to the requirements defined in section 3. However, DDP was specifically defined to be part of a family of protocols that were created to work well together, as shown in Figure 1, DDP Layering. For LLP protocol definitions of each LLP, see Marker PDU Aligned Framing for TCP Specification [MPA] and Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation [SCTPDDP].
DDPはセクション3で定義された要件を条件としてLLP独立者であることを意図します。 しかしながら、DDPは一緒にうまくいくために作成されたプロトコルのファミリーの一部になるように明確に定義されました、図1に示されるように、DDP Layering。 それぞれのLLPのLLPプロトコル定義に関しては、TCP Specification[MPA]とStream Control Transmissionプロトコル(SCTP)のダイレクトData Placement(DDP)適合[SCTPDDP]に関してMarker PDU Aligned Framingを見てください。
DDP enables direct data Placement capability for any ULP, but it has been specifically designed to work well with Remote Direct Memory Access Protocol (RDMAP) (see [RDMAP]), and is part of the iWARP protocol suite.
DDPがどんなULPのためにもダイレクトデータPlacement能力を可能にしますが、それは、Remote Direct Memory Accessプロトコル(RDMAP)([RDMAP]を見る)で明確に仕事によく設計されていて、iWARPプロトコル群の一部です。
+-------------------+
| |
| RDMA ULP |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| ULP | RDMAP |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DDP protocol |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MPA | |
| | |
| | |
+-+-+-+-+-+-+-+-+-+ SCTP |
| | |
| TCP | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------+ | | | RDMA ULP| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ULP| RDMAP| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DDPプロトコル| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | MPA| | | | | | | | ++++++++++SCTP| | | | | TCP| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DDP Layering
図1: DDPレイヤリング
Shah, et al. Standards Track [Page 6] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[6ページ]。
If DDP is layered below RDMAP and on top of MPA and TCP, then the respective headers and payload are arranged as follows (Note: For clarity, MPA header and CRC are included, but framing markers are not shown.):
DDPがRDMAPの下と、そして、MPAとTCPの上で層にされるなら、それぞれのヘッダーとペイロードは以下の通りアレンジされます(注意: 明快において、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 Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// DDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// RDMAP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
// RDMAP ULP Payload //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ヘッダー//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //RDMAPヘッダー//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //////RDMAP ULP有効搭載量//////| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPA, DDP, and RDMAP Header Alignment
図2: MPA、DDP、および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,
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, 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メッセージに埋め込むだろうことです。
Shah, et al. Standards Track [Page 7] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[7ページ]。
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".
データDelivery(配送、Delivered、デリバーズ)--配送は特定のメッセージが使用に利用可能であることをULPか消費者に知らせるプロセスと定義されます。 これは一般に、順不同に起こるかもしれない「プレースメント」と明確に異なっています、厳密に「配送」の注文を定義しますが。 「データプレースメント」を見てください。
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を送って、受け取ることができなければならないことに注意してください。
Delivery (Delivered, Delivers) - See Data Delivery in Section 2.1.
配送(提供された、デリバーズ)--セクション2.1でデータ配送を見てください。
iWARP - A suite of wire protocols comprised of RDMAP [RDMAP], DDP
(this specification), and Marker PDU Aligned Framing for TCP
(MPA) [MPA]. The iWARP protocol suite may be layered above TCP,
SCTP, or other transport protocols.
iWARP--ひとそろいのワイヤプロトコルはTCPのためにRDMAPで[RDMAP]、DDP(この仕様)、およびMarker PDU Aligned Framingを包括しました(MPA)[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 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 RDMA Enabled Network Interface Controllers
(RNICs) installed in a host computer.
ノード--コンピュータ・デバイスはネットワークの1個以上のリンクに付きました。 Nodeは、コンピュータで動きながら、このような関係においては特定のアプリケーションかプロトコル具体化を示しません。 Nodeはホストコンピュータにインストールされた1RDMA Enabled Network Interface Controllers(RNICs)から成るかもしれません。
Placement (Placed, 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 Enabled Network Interface Controller. In this context,
this would be a network I/O adapter or embedded controller with
iWARP functionality.
RNIC--RDMAはネットワーク・インターフェースコントローラを可能にしました。 このような関係においては、これは、iWARPの機能性があるネットワーク入出力アダプターか埋め込まれたコントローラでしょう。
ULP - Upper Layer Protocol. The protocol layer above the protocol
layer currently being referenced. The ULP for RDMA/DDP is
expected to be an Operating System (OS), application, adaptation
layer, or proprietary device. The RDMA/DDP documents do not
ULP--上側の層のプロトコル。 現在参照をつけられるプロトコル層の上のプロトコル層。 RDMA/DDPのためのULPはOperating System(OS)、アプリケーション、適合層、または独占デバイスであると予想されます。 RDMA/DDPドキュメントはそうしません。
Shah, et al. Standards Track [Page 8] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[8ページ]。
specify a ULP -- they provide a set of semantics that allow a ULP
to be designed to utilize RDMA/DDP.
ULPを指定してください--彼らはULPがRDMA/DDPを利用するように設計されているのを許容する1セットの意味論を提供します。
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を通して伝えられるようにデータ境界は保持されます。
ULP Payload - The ULP data that is contained within a single protocol
segment or packet (e.g., a DDP Segment).
ULP有効搭載量--シングルの中に含まれているULPデータはセグメントかパケット(例えば、DDP Segment)について議定書の中で述べます。
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 DDP Adaptation, MPA, or other transport protocols. For
RDMA, the LLP is DDP.
LLP--層のプロトコルを下ろしてください。 現在参照をつけられるプロトコル層の下のプロトコル層。 例えば、DDPのために、LLPはSCTP DDP Adaptation、MPA、または他のトランスポート・プロトコルです。 RDMAに関しては、LLPはDDPです。
LLP Connection - Corresponds to an LLP transport-level connection
between the peer LLP layers on two nodes.
LLP Connection--2つのノードの上の同輩LLP層の間のLLP輸送レベル接続に文通しています。
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輸送レベルストリームに対応しています。 LLP Streamsが独身の輸送レベルLLP Connectionに写像するかもしれない1つか以上。 複数の接続(例えば、SCTP)あたりのストリームをサポートするトランスポート・プロトコルのために、LLP Streamは1つの輸送レベルストリームに対応しています。
MULPDU - Maximum Upper Layer Protocol Data Unit (MULPDU). The
current maximum size of the record that is acceptable for DDP to
pass to the LLP for transmission.
MULPDU--最大の上側の層のプロトコルデータ単位(MULPDU)。 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" and "Direct Data Placement".
DDPのためのデータPlacement(プレースメント、Placed、Places)は今期にDDP実装でData Bufferに書くプロセスを示すのにおいて明確に使用されています。 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--進行中の、そして、未定のDDP Messagesを完成するのを試みないDDP Streamを閉じる行為。
Shah, et al. Standards Track [Page 9] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[9ページ]。
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 Streamを閉じて、Messagesが首尾よく完成できるDDPまで行為。
DDP Control Field - A fixed 8-bit field in the DDP Header.
DDP Control Field--DDP Headerの固定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 Segmentsに出席しているヘッダー。 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によって定義されたユニット(1DDP Segmentsに細分される)は交換されます。 この分割はさまざまな理由で起こるかもしれません、基本的なトランスポート・プロトコルの最大のセグメントサイズを尊敬するために分割を含んでいて。
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 Lower Layer
Protocol MULPDU.
DDP Segment--DDPのためのデータ転送の最小単位は議定書を作ります。 それはDDP HeaderとULP有効搭載量を含んでいます(存在しているなら)。 DDP Segmentは、Lower LayerプロトコルMULPDUの中で合うように大きさで分けられるべきです。
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メッセージの系列。 SCTP、Streamが直接SCTPに写像するDDPには、流れてください。 MPAに関しては、Streamが直接TCP接続、および独身のDDP Streamに写像するDDPはサポートされます。 DDPがDDP Streamsの間に注文していない保証を持っていることに注意してください。
DDP Stream Identifier (ID) - An identifier for a DDP Stream.
DDP Stream Identifier(ID)--DDP Streamのための識別子。
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 octets, 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と共に増加している一連番号を指定します。
Shah, et al. Standards Track [Page 10] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[10ページ]。
Protection Domain (PD) - A mechanism used to associate a DDP Stream
and an STag. Under this mechanism, the use of an STag is valid
on a DDP Stream if the STag has the same Protection Domain
Identifier (PD ID) as the DDP Stream.
保護Domain(PD)--メカニズムは以前はよくDDP StreamとSTagを関連づけていました。 このメカニズムの下では、STagにDDP Streamと同じProtection Domain Identifier(PD ID)があるなら、STagの使用はDDP Streamで有効です。
Protection Domain Identifier (PD ID) - An identifier for the
Protection Domain.
保護Domain Identifier(PD ID)--Protection Domainのための識別子。
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の中のオフセット。
ULP Buffer - A buffer owned above the DDP layer and Advertised to the
DDP layer either as a Tagged Buffer or an Untagged ULP Buffer.
ULP Buffer--DDPへのDDP層を超えて所有されていたバッファとAdvertisedはTagged BufferかUntagged ULP Bufferとして層にします。
ULP Message Length - The total length, in octets, of the ULP Payload
contained in a DDP Message.
ULP Message Length--DDP Messageに含まれたULP有効搭載量の八重奏における全長。
Untagged Buffer - A buffer that is not explicitly Advertised to the
Remote Peer.
それは明らかにそうではありません。Untagged Buffer--、バッファ、Remote PeerへのAdvertised。
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。
Shah, et al. Standards Track [Page 11] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[11ページ]。
3. Reliable Delivery LLP Requirements
3. 信頼できる配信LLP要件
Any protocol that can serve as an LLP to DDP MUST meet the following requirements.
LLPとしてDDPに機能できるどんなプロトコルも以下の必要条件を満たさなければなりません。
1. LLPs MUST expose MULPDU and MULPDU changes. This is required so
that the DDP layer can perform segmentation aligned with the
MULPDU and can adapt as MULPDU changes come about. The corner
case of how to handle outstanding requests during a MULPDU change
is covered by the requirements below.
1. LLPsは、MULPDUとMULPDUが変化であると暴露しなければなりません。 これが、DDP層がMULPDUに並べられた分割は実行できて、MULPDU変化が生じるとき適合できるくらい必要です。 MULPDU変化の間どう傑出している要求を扱うかに関する角のケースは以下の要件でカバーされています。
2. In the event of a MULPDU change, DDP MUST NOT be required by the
LLP to re-segment DDP Segments that have been previously posted
to the LLP. Note that under pathological conditions the LLP may
change the Advertised MULPDU more frequently than the queue of
previously posted DDP Segment transmit requests is flushed.
Under this pathological condition, the LLP transmit queue can
contain DDP Messages for which multiple updates to the
corresponding MULPDU have occurred subsequent to posting of the
messages. Thus, there may be no correlation between the queued
DDP Segment(s) and the LLP's current value of MULPDU.
2. MULPDU変化の場合、DDPはLLPによって以前にLLPに掲示された再セグメントDDP Segmentsに必要とされてはいけません。 LLPが以前にの待ち行列がDDPを掲示したより頻繁にAdvertised MULPDUを変えるかもしれないという病的状態の下で、Segmentが要求を伝えるというメモは紅潮しています。 この病的状態の下では、LLPは缶がDDP Messagesを入れてある対応するMULPDUへのそれの複数のアップデートがメッセージの任命にその後で起こった待ち行列を伝えます。 したがって、列に並ばせられたDDP Segment(s)とLLPの現行価値の間には、MULPDUに相関関係が全くないかもしれません。
3. The LLP MUST ensure that, if it accepts a DDP Segment, it will
transfer it reliably to the receiver or return with an error
stating that the transfer failed to complete.
3. LLP MUSTは、DDP Segmentを受け入れると、完全な状態でそれを受信機に確かに移すか、または転送がそうしなかったと述べる誤りとともに帰るのを確実にします。
4. The LLP MUST preserve DDP Segment and Message boundaries at the
Data Sink.
4. LLP MUSTはData SinkにDDP SegmentとMessage境界を保持します。
5. The LLP MAY provide the incoming segments out of order for
Placement, but if it does, it MUST also provide information that
specifies what the sender-specified order was.
5. そうするなら、LLP MAYはPlacementに、不適切な入って来るセグメントを提供しますが、また、それは送付者によって指定されたオーダーが何であったかを指定する情報を提供しなければなりません。
6. LLP MUST provide a strong digest (at least equivalent to CRC32-C)
to cover at least the DDP Segment. It is believed that some of
the existing data integrity digests are not sufficient, and that
direct memory transfer semantics requires a stronger digest than,
for example, a simple checksum.
6. LLP MUSTは、少なくともDDP Segmentをカバーするために、強いダイジェスト(CRC32-Cに少なくとも同等な)を提供します。 既存のデータ保全ダイジェストのいくつかが十分でなく、ダイレクト転記意味論が例えば、簡単なチェックサムより強いダイジェストを必要とすると信じられています。
7. On receive, the LLP MUST provide the length of the DDP Segment
received. This ensures that DDP does not have to carry a length
field in its header.
7. オンである、受信してください、そして、LLP MUSTはSegmentが受けたDDPの長さを提供します。 これは、DDPがヘッダーの長さの野原を運ぶ必要はないのを確実にします。
8. If an LLP does not support teardown of an LLP Stream independent
of other LLP Streams, and a DDP error occurs on a specific DDP
Stream, then the LLP MUST label the associated LLP Stream as an
erroneous LLP Stream and MUST NOT allow any further data transfer
8. LLPが他のLLP Streamsの如何にかかわらずLLP Streamの分解をサポートしないで、DDP誤りが特定のDDP Streamに発生するなら、LLP MUSTは誤ったLLP Streamとして関連LLP Streamをラベルして、どんな詳しいデータも許容してはいけません。
Shah, et al. Standards Track [Page 12] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[12ページ]。
on that LLP Stream after DDP requests the associated DDP Stream
to be torn down.
そのLLP Streamでは、DDPが、引き裂かれるよう関連DDP Streamに要求した後にダウンしてください。
9. For a specific LLP Stream, the LLP MUST provide a mechanism to
indicate that the LLP Stream has been gracefully torn down. For
a specific LLP Connection, the LLP MUST provide a mechanism to
indicate that the LLP Connection has been gracefully torn down.
9. 特定のLLP Streamのために、LLP MUSTはLLP Streamが優雅に取りこわされたのを示すメカニズムを提供します。 特定のLLP Connectionのために、LLP MUSTはLLP Connectionが優雅に取りこわされたのを示すメカニズムを提供します。
Note that, if the LLP does not allow an LLP Stream to be torn
down independently of the LLP Connection, the above requirements
allow the LLP to notify DDP of both events at the same time.
LLPが、LLP StreamがLLP Connectionの如何にかかわらず取りこわされるのを許容しないならLLPが同時に上記の要件で両方のイベントのDDPに通知できることに注意してください。
10. For a specific LLP Connection, when all LLP Streams are either
gracefully torn down or are labeled as erroneous LLP Streams, the
LLP Connection MUST be torn down.
10. すべてのLLP Streamsを優雅に取りこわすか、または誤ったLLP Streamsとしてラベルするとき、特定のLLP Connectionに関しては、LLP Connectionを取りこわさなければなりません。
11. The LLP MUST NOT pass a duplicate DDP Segment to the DDP layer
after it has passed all the previous DDP Segments to the DDP
layer and the associated ordering information for the previous
DDP Segments and the current DDP Segment.
11. 前のDDP Segmentsと現在のDDP Segmentのために前のすべてのDDP SegmentsをDDP層と関連注文情報に渡した後にLLP MUST NOTは写しDDP SegmentをDDP層に渡します。
4. Header Format
4. ヘッダー形式
DDP has two different header formats: one for Data Placement into Tagged Buffers, and the other for Data Placement into Untagged Buffers. See Section 5.1 for a description of the two models.
DDPには、2つの異なったヘッダー形式があります: Data PlacementのためのTagged Buffersへの1つ、およびData PlacementのためのUntagged Buffersへのもう片方。 2つのモデルの記述に関してセクション5.1を見てください。
4.1. DDP Control Field
4.1. DDPコントロール分野
The first 8 bits of the DDP Header carry a DDP Control Field that is common between the two formats. It is shown below in Figure 3, 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.
DDP Headerの最初の8ビットは2つの形式の間で一般的なDDP Control Fieldを運びます。 それは16ビットによって相殺された、[MPA]で定義されたMPAヘッダーを収容した図3に以下に示されます。 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| Rsvd |DV |
+-+-+-+-+-+-+-+-+
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| Rsvd|DV| +-+-+-+-+-+-+-+-+
Figure 3: DDP Control Field
図3: DDPコントロール分野
T - Tagged flag: 1 bit.
T--タグ付けをされた旗: 1ビット。
Specifies the Tagged or Untagged Buffer Model. If set to one,
the ULP Payload carried in this DDP Segment MUST be Placed into a
Tagged Buffer.
タグ付けされるかUntaggedバッファモデルを指定します。 1つに設定されるなら、このDDP Segmentで運ばれたULP有効搭載量はTagged BufferへのPlacedであるに違いありません。
Shah, et al. Standards Track [Page 13] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[13ページ]。
If set to zero, the ULP Payload carried in this DDP Segment MUST
be Placed into an Untagged Buffer.
ゼロに設定されるなら、このDDP Segmentで運ばれたULP有効搭載量はUntagged BufferへのPlacedであるに違いありません。
L - Last flag: 1 bit.
L--最後に、弛んでください: 1ビット。
Specifies whether the DDP Segment is the last segment of a DDP
Message. It MUST be set to one on the last DDP Segment of every
DDP Message. It MUST NOT be set to one on any other DDP Segment.
DDP SegmentがDDP Messageの最後のセグメントであるかどうか指定します。 それはあらゆるDDP Messageの最後のDDP Segmentの上の1つへのセットであるに違いありません。 それはいかなる他のDDP Segmentの上の1つへのセットであるはずがありません。
The DDP Segment with the L bit set to 1 MUST be posted to the LLP
after all other DDP Segments of the associated DDP Message have
been posted to the LLP. For an Untagged DDP Message, the DDP
Segment with the L bit set to 1 MUST carry the highest MO.
関連DDP Messageの他のすべてのDDP SegmentsがLLPに掲示された後に1に設定されたLビットがあるDDP SegmentをLLPに掲示しなければなりません。 Untagged DDP Messageに関しては、1に設定されたLビットがあるDDP Segmentは最も高いMOを運ばなければなりません。
If the Last flag is set to one, the DDP Message payload MUST be
Delivered to the ULP after:
Last旗が1つに設定されるなら、DDP MessageペイロードはULPへの以下の後のDeliveredであるに違いありません。
o Placement of all DDP Segments of this DDP Message and all
prior DDP Messages, and
o そしてこのDDP Messageとすべての先のDDP MessagesのすべてのDDP Segmentsのプレースメント。
o Delivery of each prior DDP Message.
o それぞれの先のDDP Messageの配送。
If the Last flag is set to zero, the DDP Segment is an
intermediate DDP Segment.
Last旗がゼロに設定されるなら、DDP Segmentは中間的DDP Segmentです。
Rsvd - Reserved: 4 bits.
Rsvd--予約される: 4ビット。
Reserved for future use by the DDP protocol. This field MUST be
set to zero on transmit, and not checked on receive.
今後の使用のために、DDPプロトコルで、予約されます。 この分野はゼロにオンなセットが伝わるということであるに違いありません、そして、検査されないで、受信してください。
DV - Direct Data Placement Protocol Version: 2 bits.
DV--データプレースメントプロトコルバージョンを指示してください: 2ビット。
The version of the DDP Protocol in use. This field MUST be set
to one to indicate the version of the specification described in
this document. The value of DV MUST be the same for all the DDP
Segments transmitted or received on a DDP Stream.
使用中のDDPプロトコルのバージョン。 この分野を本書では説明された仕様のバージョンを示すように1つに設定しなければなりません。 DV MUSTの値は、Segmentsが伝えたすべてのDDPに同じであるか、またはa DDP Streamで受信しました。
4.2. DDP Tagged Buffer Model Header
4.2. DDPのタグ付けをされたバッファモデルヘッダー
Figure 4 shows the DDP Header format that MUST be used in all DDP Segments that target Tagged Buffers. It includes the DDP Control Field previously defined in Section 4.1. (Note: In Figure 4, 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.)
図4はTagged Buffersを狙うすべてのDDP Segmentsで使用しなければならないDDP Header書式を示しています。 それは以前にセクション4.1で定義されたDDP Control Fieldを含んでいます。 図4では、DDP Headerは16ビットによって相殺されます。(注意: [MPA]で定義されたMPAヘッダーを収容して、DDPがMPAの上で層にされる場合にだけ、MPAヘッダーは出席しています。)
Shah, et al. Standards Track [Page 14] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[14ページ]。
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| Rsvd | DV| RsvdULP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TO +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Rsvd| DV| RsvdULP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 雄ジカ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +に| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Tagged Buffer DDP Header
図4: タグ付けをされたバッファDDPヘッダー
T is set to one.
Tは1つに設定されます。
RsvdULP - Reserved for use by the ULP: 8 bits.
RsvdULP--使用のために、ULPによって予約されます: 8ビット。
The RsvdULP field is opaque to the DDP protocol and can be
structured in any way by the ULP. At the Data Source, DDP MUST
set RsvdULP Field to the value specified by the ULP. It is
transferred unmodified from the Data Source to the Data Sink. At
the Data Sink, DDP MUST provide the RsvdULP field to the ULP when
the DDP Message is delivered. Each DDP Segment within a specific
DDP Message MUST contain the same value for this field. The Data
Source MUST ensure that each DDP Segment within a specific DDP
Message contains the same value for this field.
RsvdULP分野を、DDPプロトコルに不透明であり、ULPは何らかの方法で構造化できます。 Data Sourceでは、DDPはULPによって指定された値にRsvdULP Fieldを設定しなければなりません。 Data SourceからData Sinkまで変更されていなくそれを移します。 DDP Messageが提供されるとき、Data Sinkでは、DDPはRsvdULP野原をULPに供給しなければなりません。 特定のDDP Messageの中のそれぞれのDDP Segmentはこの分野への同じ値を含まなければなりません。 Data Sourceは、特定のDDP Messageの中のそれぞれのDDP Segmentがこの分野への同じ値を含むのを確実にしなければなりません。
STag - Steering Tag: 32 bits.
雄ジカ--操縦タグ: 32ビット。
The Steering Tag identifies the Data Sink's Tagged Buffer. The
STag MUST be valid for this DDP Stream. The STag is associated
with the DDP Stream through a mechanism that is outside the scope
of the DDP Protocol specification. At the Data Source, DDP MUST
set the STag field to the value specified by the ULP. At the
Data Sink, the DDP MUST provide the STag field when the ULP
Message is delivered. Each DDP Segment within a specific DDP
Message MUST contain the same value for this field and MUST be
the value supplied by the ULP. The Data Source MUST ensure that
each DDP Segment within a specific DDP Message contains the same
value for this field.
Steering TagはData SinkのTagged Bufferを特定します。 このDDP Streamに、STagは有効であるに違いありません。 STagはDDPプロトコル仕様の範囲の外にあるメカニズムを通したDDP Streamに関連しています。 Data Sourceでは、DDPはULPによって指定された値にSTag分野を設定しなければなりません。 ULP Messageが提供されるとき、Data Sinkでは、DDPはSTag野原を供給しなければなりません。 特定のDDP Messageの中のそれぞれのDDP Segmentはこの分野への同じ値を含まなければならなくて、ULPによって供給された値であるに違いありません。 Data Sourceは、特定のDDP Messageの中のそれぞれのDDP Segmentがこの分野への同じ値を含むのを確実にしなければなりません。
TO - Tagged Offset: 64 bits.
--タグ付けをされたオフセット: 64ビット。
The Tagged Offset specifies the offset, in octets, within the
Data Sink's Tagged Buffer, where the Placement of ULP Payload
contained in the DDP Segment starts. A DDP Message MAY start at
an arbitrary TO within a Tagged Buffer.
Tagged Offsetはオフセットを指定します、八重奏で、Data SinkのTagged Bufferで中DDP Segmentに含まれたULP有効搭載量のPlacementが始めである。 DDP MessageはTagged Bufferの中の任意のTOで始まるかもしれません。
Shah, et al. Standards Track [Page 15] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[15ページ]。
4.3. DDP Untagged Buffer Model Header
4.3. DDP Untaggedバッファモデルヘッダー
Figure 5 shows the DDP Header format that MUST be used in all DDP Segments that target Untagged Buffers. It includes the DDP Control Field previously defined in Section 4.1. (Note: In Figure 5, 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.)
図5はUntagged Buffersを狙うすべてのDDP Segmentsで使用しなければならないDDP Header書式を示しています。 それは以前にセクション4.1で定義されたDDP Control Fieldを含んでいます。 図5では、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| Rsvd | DV| RsvdULP[0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsvdULP[8:39] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MO |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Rsvd| DV| RsvdULP[0:7]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RsvdULP[8:39]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MO| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Untagged Buffer DDP Header
図5: バッファDDPヘッダーをUntaggedしました。
T is set to zero.
Tはゼロに設定されます。
RsvdULP - Reserved for use by the ULP: 40 bits.
RsvdULP--使用のために、ULPによって予約されます: 40ビット。
The RsvdULP field is opaque to the DDP protocol and can be
structured in any way by the ULP. At the Data Source, DDP MUST
set RsvdULP Field to the value specified by the ULP. It is
transferred unmodified from the Data Source to the Data Sink. At
the Data Sink, DDP MUST provide RsvdULP field to the ULP when the
ULP Message is Delivered. Each DDP Segment within a specific DDP
Message MUST contain the same value for the RsvdULP field. At
the Data Sink, the DDP implementation is NOT REQUIRED to verify
that the same value is present in the RsvdULP field of each DDP
Segment within a specific DDP Message and MAY provide the value
from any one of the received DDP Segment to the ULP when the ULP
Message is Delivered.
RsvdULP分野を、DDPプロトコルに不透明であり、ULPは何らかの方法で構造化できます。 Data Sourceでは、DDPはULPによって指定された値にRsvdULP Fieldを設定しなければなりません。 Data SourceからData Sinkまで変更されていなくそれを移します。 ULP MessageがDeliveredであるときに、Data Sinkでは、DDPはRsvdULP野原をULPに供給しなければなりません。 特定のDDP Messageの中のそれぞれのDDP SegmentはRsvdULP分野への同じ値を含まなければなりません。 Data Sinkでは、DDP実装は、同じ値が特定のDDP Messageの中のそれぞれのDDP SegmentのRsvdULP分野に存在していることを確かめるNOT REQUIREDであり、ULP MessageがDeliveredであるときに、容認されたDDP SegmentのどれかからULPまで値を提供するかもしれません。
Shah, et al. Standards Track [Page 16] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[16ページ]。
QN - Queue Number: 32 bits.
QN--数を列に並ばせてください: 32ビット。
The Queue Number identifies the Data Sink's Untagged Buffer queue
referenced by this header. Each DDP segment within a specific
DDP message MUST contain the same value for this field and MUST
be the value supplied by the ULP at the Data Source. The Data
Source MUST ensure that each DDP Segment within a specific DDP
Message contains the same value for this field.
Queue Numberはこのヘッダーによって参照をつけられたData SinkのUntagged Buffer待ち行列を特定します。 特定のDDPメッセージの中のそれぞれのDDPセグメントは、この分野に同じ値を含まなければならなくて、Data SourceのULPによって供給された値であるに違いありません。 Data Sourceは、特定のDDP Messageの中のそれぞれのDDP Segmentがこの分野への同じ値を含むのを確実にしなければなりません。
MSN - Message Sequence Number: 32 bits.
MSN--、メッセージ通番: 32ビット。
The Message Sequence Number specifies a sequence number that MUST
be increased by one (modulo 2^32) with each DDP Message targeting
the specific Queue Number on the DDP Stream associated with this
DDP Segment. The initial value for MSN MUST be one. The MSN
value MUST wrap to 0 after a value of 0xFFFFFFFF. Each DDP
segment within a specific DDP message MUST contain the same value
for this field. The Data Source MUST ensure that each DDP
Segment within a specific DDP Message contains the same value for
this field.
Message Sequence NumberはそれぞれのDDP MessageがこのDDP Segmentに関連しているDDP Streamの上の特定のQueue Numberを狙っていて1つ(法2^32)増強しなければならない一連番号を指定します。 MSN MUSTのための初期の値は1にそうです。 値が0xFFFFFFFFの値の後に0に包装しなければならないMSN。 特定のDDPメッセージの中のそれぞれのDDPセグメントはこの分野への同じ値を含まなければなりません。 Data Sourceは、特定のDDP Messageの中のそれぞれのDDP Segmentがこの分野への同じ値を含むのを確実にしなければなりません。
MO - Message Offset: 32 bits.
MO--メッセージは相殺されました: 32ビット。
The Message Offset specifies the offset, in octets, from the
start of the DDP Message represented by the MSN and Queue Number
on the DDP Stream associated with this DDP Segment. The MO
referencing the first octet of the DDP Message MUST be set to
zero by the DDP layer.
Message Offsetはオフセットを指定します、八重奏で、このDDP Segmentに関連しているDDP Streamの上のMSNとQueue Numberによって表されたDDP Messageの始まりから。 DDP層でDDP Messageの最初の八重奏に参照をつけるMOをゼロに設定しなければなりません。
4.4. DDP Segment Format
4.4. DDPセグメント形式
Each DDP Segment MUST contain a DDP Header. Each DDP Segment may also contain ULP Payload. Following is the DDP Segment format:
それぞれのDDP SegmentはDDP Headerを含まなければなりません。 また、それぞれのDDP SegmentはULP有効搭載量を含むかもしれません。 以下に、DDP Segment形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP | |
| Header| ULP Payload (if any) |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDP| | | ヘッダー| (もしあれば)のULP有効搭載量| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DDP Segment Format
図6: DDPセグメント形式
Shah, et al. Standards Track [Page 17] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[17ページ]。
5. Data Transfer
5. データ転送
DDP supports multi-segment DDP Messages. Each DDP Message is composed of one or more DDP Segments. Each DDP Segment contains a DDP Header. The DDP Header contains the information required by the receiver to Place any ULP Payload included in the DDP Segment.
DDPはマルチセグメントDDP Messagesをサポートします。 それぞれのDDP Messageは1DDP Segmentsで構成されます。 それぞれのDDP SegmentはDDP Headerを含んでいます。 DDP HeaderはDDP SegmentにどんなULP有効搭載量も含んでいて、受信機によってPlaceに必要とされた情報を含んでいます。
5.1. DDP Tagged or Untagged Buffer Models
5.1. タグ付けをされたDDPかUntaggedバッファモデル
DDP uses two basic buffer models for the Placement of the ULP Payload: Tagged Buffer Model and Untagged Buffer Model.
DDPはULP有効搭載量のPlacementに2つの基本的なバッファモデルを使用します: タグ付けをされたバッファモデルとUntaggedバッファはモデル化されます。
5.1.1. Tagged Buffer Model
5.1.1. タグ付けをされたバッファモデル
The Tagged Buffer Model is used by the Data Source to transfer a DDP Message into a Tagged Buffer at the Data Sink that has been previously Advertised to the Data Source. An STag identifies a Tagged Buffer. For the Placement of a DDP Message using the Tagged Buffer Model, the STag is used to identify the buffer, and the TO is used to identify the offset within the Tagged Buffer into which the ULP Payload is transferred. The protocol used to Advertise the Tagged Buffer is outside the scope of this specification (i.e., ULP specific). A DDP Message can start at an arbitrary TO within a Tagged Buffer.
Tagged Buffer Modelは、Data Sinkの以前にそうであるTagged BufferにDDP Messageを移すのにData Sourceによって使用されます。Data SourceへのAdvertised。 STagはTagged Bufferを特定します。 Tagged Buffer Modelを使用するDDP MessageのPlacementに関しては、STagはバッファを特定するのに使用されます、そして、TOは、ULP有効搭載量がわたっているTagged Bufferの中でオフセットを特定するのに使用されます。 この仕様(すなわち、ULP特有の)の範囲の外に広告、Tagged Bufferに使用されるプロトコルがあります。 DDP MessageはTagged Bufferの中の任意のTOで始まることができます。
Additionally, a Tagged Buffer can potentially be written multiple times. This might be done for error recovery or because a buffer is being re-used after some ULP specific synchronization mechanism.
さらに、潜在的に複数の回にTagged Bufferを書くことができます。 これはエラー回復のためにするか、または何らかのULPの特定の同期メカニズムの後にバッファを再使用しているからです。
5.1.2. Untagged Buffer Model
5.1.2. Untaggedバッファモデル
The Untagged Buffer Model is used by the Data Source to transfer a DDP Message to the Data Sink into a queued buffer.
Untagged Buffer Modelは、列に並ばせられたバッファの中へのData SinkにDDP Messageを移すのにData Sourceによって使用されます。
The DDP Queue Number is used by the ULP to separate ULP messages into different queues of receive buffers. For example, if two queues were supported, the ULP could use one queue to post buffers handed to it by the application above the ULP, and it could use the other queue for buffers that are only consumed by ULP-specific control messages. This enables the separation of ULP control messages from opaque ULP Payload when using Untagged Buffers.
DDP Queue Numberは、受信バッファの異なった待ち行列にULPメッセージを切り離すのにULPによって使用されます。 例えば、2つの待ち行列がサポートされるなら、ULPはULPの上のアプリケーションでそれに手渡されたバッファを掲示するのに1つの待ち行列を使用できるでしょうに、そして、それはULP特有のコントロールメッセージによって消費されるだけであるバッファにもう片方の待ち行列を使用するかもしれません。 Untagged Buffersを使用するとき、これは不透明なULP有効搭載量からのULPコントロールメッセージの分離を可能にします。
The DDP Message Sequence Number can be used by the Data Sink to identify the specific Untagged Buffer. The protocol used to communicate how many buffers have been queued is outside the scope of this specification. Similarly, the exact implementation of the buffer queue is outside the scope of this specification.
Data Sinkは、特定のUntagged Bufferを特定するのにDDP Message Sequence Numberを使用できます。 この仕様の範囲の外にいくつのバッファが列に並ばせられたかを伝えるのに使用されるプロトコルがあります。 同様に、この仕様の範囲の外にバッファ待ち行列の正確な実装があります。
Shah, et al. Standards Track [Page 18] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[18ページ]。
5.2. Segmentation and Reassembly of a DDP Message
5.2. DDPメッセージの分割とReassembly
At the Data Source, the DDP layer MUST segment the data contained in a ULP message into a series of DDP Segments, where each DDP Segment contains a DDP Header and ULP Payload, and MUST be no larger than the MULPDU value Advertised by the LLP. The ULP Message Length MUST be less than 2^32. At the Data Source, the DDP layer MUST send all the data contained in the ULP message. At the Data Sink, the DDP layer MUST Place the ULP Payload contained in all valid incoming DDP Segments associated with a DDP Message into the ULP Buffer.
Data Sourceでは、DDP層はデータがULPメッセージに一連のDDP Segmentsに含んだセグメントがそうしなければなりません。そこでは、それぞれのDDP SegmentはDDP HeaderとULP有効搭載量を含んでいて、MULPDU値のAdvertisedよりLLPで大きいはずがありません。 ULP Message Lengthは2未満^32であるに違いない。 Data Sourceに、DDP層はULPメッセージに含まれたすべてのデータを送らなければなりません。 Data Sinkでは、DDP層はDDP Messageに関連しているすべての有効な入って来るDDP SegmentsにULP Bufferに含まれたPlace ULP有効搭載量がそうしなければなりません。
DDP Message segmentation at the Data Source is accomplished by identifying a DDP Message (which corresponds one-to-one with a ULP Message) uniquely and then, for each associated DDP Segment of a DDP Message, by specifying an octet offset for the portion of the ULP Message contained in the DDP Segment.
Data SourceのDDP Message分割は唯一、DDP Message(1〜1にULP Messageに対応する)を特定して、次に、DDP Messageのそれぞれの関連DDP Segmentのために達成されます、DDP Segmentに含まれたULP Messageの一部に相殺された八重奏を指定することによって。
For an Untagged DDP Message, the combination of the QN and MSN uniquely identifies a DDP Message. The octet offset for each DDP Segment of a Untagged DDP Message is the MO field. For each DDP Segment of a Untagged DDP Message, the MO MUST be set to the octet offset from the first octet in the associated ULP Message (which is defined to be zero) to the first octet in the ULP Payload contained in the DDP Segment.
Untagged DDP Messageに関しては、QNとMSNの組み合わせは唯一DDP Messageを特定します。 Untagged DDP MessageのそれぞれのDDP Segmentのために相殺された八重奏はMO分野です。 Untagged DDP MessageのそれぞれのDDP Segmentにおいて、関連ULP Message(ゼロになるように定義される)における最初の八重奏から最初のDDP Segmentに含まれたULP有効搭載量における八重奏まで相殺された八重奏にMOを設定しなければなりません。
For example, if the ULP Untagged Message was 2048 octets, and the MULPDU was 1500 octets, the Data Source would generate two DDP Segments, one with MO = 0, containing 1482 octets of ULP Payload, and a second with MO = 1482, containing 566 octets of ULP Payload. In this example, the amount of ULP Payload for the first DDP Segment was calculated as:
例えば、Data SourceはULP Untagged Messageが2048の八重奏であり、MULPDUが1500の八重奏であるなら、2DDP Segmentsを生成するでしょうに、MO=0がある1、ULP有効搭載量の1482の八重奏、およびMO=1482がある1秒を含んでいて、ULP有効搭載量の566の八重奏を含んでいて。 この例では、最初のDDP SegmentのためのULP有効搭載量の量は以下として計算されました。
1482 = 1500 (MULPDU) - 18 (for the DDP Header)
1482 = 1500(MULPDU)--18(DDPヘッダーのための)
For a Tagged DDP Message, the STag and TO, combined with the in-order delivery characteristics of the LLP, are used to segment and reassemble the ULP Message. Because the initial octet offset (the TO field) can be non-zero, recovery of the original ULP Message boundary cannot be done in the general case without an additional ULP Message.
Tagged DDP Messageに関しては、オーダーにおける、LLPの配送の特性に結合したSTagとTOはセグメントに使用されて、ULP Messageを組み立て直します。 初期の八重奏オフセット(TO分野)が非ゼロであるかもしれないので、追加ULP Messageなしで一般的な場合で元のULP Message境界の回復ができません。
Implementers' note: One implementation, valid for some ULPs such
as RDMAP, is to not directly support recovery of the ULP Message
boundary for a Tagged DDP Message. For example, the ULP may wish
to have the Local Peer use small buffers at the Data Source even
when the ULP at the Data Sink has Advertised a single large
Tagged Buffer for this data transfer. In this case, the ULP may
choose to use the same STag for multiple consecutive ULP
Messages. Thus, a non-zero initial TO and re-use of the STag
Implementersの注意: RDMAPなどのいくつかのULPsに、有効な1つの実装はTagged DDP Messageのために直接ULP Message境界の回復をサポートしないことです。 例えば、ULPは、小さくLocal Peer使用を持っているのがData SinkのULPにAdvertisedがあると同等のData Sourceでこのデータ転送のための独身の大きいTagged Bufferをバッファリングすることを願うかもしれません。 この場合、ULPは、複数の連続したULP Messagesに同じSTagを使用するのを選ぶかもしれません。 その結果、STagの非ゼロの初期のTOと再使用
Shah, et al. Standards Track [Page 19] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[19ページ]。
effectively enable the ULP to implement segmentation and
reassembly due to ULP-specific constraints. See [RDMAP] for
details of how this is done.
事実上、ULPがULP特有の規制のため分割を実装して、再アセンブリするのを可能にしてください。 これがどう完了しているかに関する詳細に関して[RDMAP]を見てください。
A different implementation of a ULP could use an Untagged DDP
Message (sent after the Tagged DDP Message) that details the
initial TO for the STag that was used in the Tagged DDP Message.
And finally, another implementation of a ULP could choose to
always use an initial TO of zero such that no additional message
is required to convey the initial TO used in a Tagged DDP
Message.
ULPの異なった実装はTagged DDP Messageで使用されたSTagのために初期のTOについて詳述するUntagged DDP Message(Tagged DDP Messageの後に発信する)を使用するかもしれません。 そして、最終的に、ULPの別の実装が、いつもゼロの初期のTOを使用するのを選ぶかもしれないので、どんな追加メッセージもTagged DDP Messageで使用される初期のTOを運ぶのに必要ではありません。
Regardless of whether the ULP chooses to recover the original ULP Message boundary at the Data Sink for a Tagged DDP Message, DDP supports segmentation and reassembly of the Tagged DDP Message. The STag is used to identify the ULP Buffer at the Data Sink, and the TO is used to identify the octet-offset within the ULP Buffer referenced by the STag. The ULP at the Data Source MUST specify the STag and the initial TO when the ULP Message is handed to DDP.
ULPが、Tagged DDP MessageのためにData Sinkで元のULP Message境界を回復するのを選ぶかどうかにかかわらず、DDPはTagged DDP Messageの分割と再アセンブリをサポートします。 STagはData SinkでULP Bufferを特定するのに使用されます、そして、TOは、STagによって参照をつけられたULP Bufferの中で八重奏オフセットを特定するのに使用されます。 ULP MessageがDDPに手渡されるとき、Data SourceのULPはSTagと初期のTOを指定しなければなりません。
For each DDP Segment of a Tagged DDP Message, the TO MUST be set to the octet offset from the first octet in the associated ULP Message to the first octet in the ULP Payload contained in the DDP Segment, plus the TO assigned to the first octet in the associated ULP Message.
Tagged DDP MessageのそれぞれのDDP Segmentに関しては、TO MUSTが関連ULP Messageにおける最初の八重奏から最初のDDP Segmentに含まれたULP有効搭載量における八重奏まで相殺された八重奏に用意ができていて、そのうえ、TOは関連で最初の八重奏にULP Messageを割り当てました。
For example, if the ULP Tagged Message was 2048 octets with an initial TO of 16384, and the MULPDU was 1500 octets, the Data Source would generate two DDP Segments: one with TO = 16384, containing the first 1486 octets of ULP payload, and a second with TO = 17870, containing 562 octets of ULP payload. In this example, the amount of ULP payload for the first DDP Segment was calculated as:
例えば、ULP Tagged Messageが16384の初期のTOとの2048の八重奏であり、MULPDUが1500の八重奏であるなら、Data Sourceは2DDP Segmentsを生成するでしょうに: ULPペイロードの562の八重奏を含んでいて、TO=17870で最初の1486年のULPペイロード、および1秒の八重奏を含むTO=16384がある1。 この例では、最初のDDP SegmentのためのULPペイロードの量は以下として計算されました。
1486 = 1500 (MULPDU) - 14 (for the DDP Header)
1486 = 1500(MULPDU)--14(DDPヘッダーのための)
A zero-length DDP Message is allowed and MUST consume exactly one DDP Segment. Only the DDP Control and RsvdULP Fields MUST be valid for a zero-length Tagged DDP Segment. The STag and TO fields MUST NOT be checked for a zero-length Tagged DDP Message.
無の長さのDDP Messageは許容されていて、ちょうど1DDP Segmentを消費しなければなりません。 無の長さのTagged DDP Segmentに、DDP ControlとRsvdULPフィールズだけが有効であるに違いありません。 無の長さのTagged DDP MessageがないかどうかSTagとTO分野をチェックしてはいけません。
For either Untagged or Tagged DDP Messages, the Data Sink is not required to verify that the entire ULP Message has been received.
UntaggedかTagged DDP Messagesのどちらかに関しては、Data Sinkは、全体のULP Messageが受け取られたことを確かめる必要はありません。
Shah, et al. Standards Track [Page 20] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[20ページ]。
5.3. Ordering Among DDP Messages
5.3. DDPメッセージの中で注文します。
Messages passed through the DDP MUST conform to the ordering rules defined in this section.
DDPを通り抜けるメッセージは規則がこのセクションで定義した注文に従わなければなりません。
At the Data Source, DDP:
データ送信端末、DDPで:
* MUST transmit DDP Messages in the order they were submitted to
the DDP layer,
* オーダーでDDP Messagesを伝えてください。DDP層に彼らを提出しなければなりませんでした。
* SHOULD transmit DDP Segments within a DDP Message in increasing
MO order for Untagged DDP Messages, and in increasing TO order
for Tagged DDP Messages.
* SHOULDはUntagged DDP Messagesの増加するMO注文、およびTagged DDP Messagesの増加するTO注文におけるDDP Messageの中でDDP Segmentsを伝えます。
At the Data Sink, DDP (Note: The following rules are motivated by LLP implementations that separate Placement and Delivery.):
Data Sink、DDP(注意: 以下の規則はLLP実装のその別々のPlacementとDeliveryによって動機づけられています。)で:
* MAY perform Placement of DDP Segments out of order,
* 故障していた状態でDDP SegmentsのPlacementを実行するかもしれません。
* MAY perform Placement of a DDP Segment more than once,
* 一度より多くのDDP SegmentのPlacementを実行するかもしれません。
* MUST Deliver a DDP Message to the ULP at most once,
* 高々ULPへのDeliver a DDP Message、一度でなければならない。
* MUST Deliver DDP Messages to the ULP in the order they were sent
by the Data Source.
* 彼らがData Sourceによって送られたオーダーにおけるULPへのDeliver DDP Messagesはそうしなければなりません。
5.4. DDP Message Completion and Delivery
5.4. DDPメッセージ完成と配送
At the Data Source, DDP Message transfer is considered completed when the reliable, in-order transport LLP has indicated that the transfer will occur reliably. Note that this in no way restricts the LLP from buffering the data at either the Data Source or Data Sink. Thus, at the Data Source, completion of a DDP Message does not necessarily mean that the Data Sink has received the message.
信頼できて、注文している輸送LLPが、転送が確かに起こるのを示したとき、Data Sourceでは、DDP Message転送は完成していると考えられます。 これがData SourceかData SinkのどちらかでデータをバッファリングするのでLLPを決して制限しないことに注意してください。 したがって、Data Sourceでは、DDP Messageの完成は、必ずData Sinkがメッセージを受け取ったことを意味するというわけではありません。
At the Data Sink, DDP MUST Deliver a DDP Message if and only if all of the following are true:
そして、Data Sinkでは、DDPがそうしなければならない、Deliver a DDP Message、以下のすべてが本当である場合にだけ:
* the last DDP Segment of the DDP Message had its Last flag set,
* DDP Messageの最後のDDP SegmentはLast旗を設定させました。
* all of the DDP Segments of the DDP Message have been Placed,
* DDP MessageのDDP SegmentsのすべてがPlacedです。
* all preceding DDP Messages have been Placed, and
* そしてすべての前のDDP MessagesがPlacedである。
* each preceding DDP Message has been Delivered to the ULP.
* それぞれの前のDDP MessageはULPへのDeliveredです。
Shah, et al. Standards Track [Page 21] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[21ページ]。
At the Data Sink, DDP MUST provide the ULP Message Length to the ULP when an Untagged DDP Message is Delivered. The ULP Message Length may be calculated by adding the MO and the ULP Payload length in the last DDP Segment (with the Last flag set) of an Untagged DDP Message.
Untagged DDP MessageがDeliveredであるときに、Data Sinkでは、DDPはULP Message LengthをULPに供給しなければなりません。 ULP Message Lengthは、Untagged DDP Messageの最後のDDP Segment(Last旗のセットがある)でMOとULP有効搭載量の長さを加えることによって、計算されるかもしれません。
At the Data Sink, DDP MUST provide the RsvdULP Field of the DDP Message to the ULP when the DDP Message is delivered.
DDP Messageが提供されるとき、Data Sinkでは、DDPはDDP MessageのRsvdULP FieldをULPに供給しなければなりません。
6. DDP Stream Setup and Teardown
6. DDPストリームセットアップと分解
This section describes LLP independent issues related to DDP Stream setup and teardown.
このセクションはDDP Streamセットアップと分解に関連するLLPの独立している問題について説明します。
6.1. DDP Stream Setup
6.1. DDPストリームセットアップ
It is expected that the ULP will use a mechanism outside the scope of this specification to establish an LLP Connection, and that the LLP Connection will support one or more LLP Streams (e.g., MPA/TCP or SCTP). After the LLP sets up the LLP Stream, it will enable a DDP Stream on a specific LLP Stream at an appropriate point.
ULPがLLP Connectionを証明するのにこの仕様の範囲の外でメカニズムを使用して、LLP Connectionが、1LLP Streamsが(例えば、MPA/TCPかSCTP)であるとサポートすると予想されます。 LLPがLLP Streamをセットアップした後に、それは適切なポイントの特定のLLP Streamの上のDDP Streamを有効にするでしょう。
The ULP is required to enable both endpoints of an LLP Stream for DDP data transfer at the same time, in both directions; this is necessary so that the Data Sink can properly recognize the DDP Segments.
ULPは同時にDDPデータ転送のためにLLP Streamの両方の終点を可能にしなければなりません、両方の方向に。 これが、Data Sinkが適切にDDP Segmentsを認識できるくらい必要です。
6.2. DDP Stream Teardown
6.2. DDPストリーム分解
DDP MUST NOT independently initiate Stream Teardown. DDP either responds to a stream being torn down by the LLP or processes a request from the ULP to tear down a stream. DDP Stream teardown disables DDP capabilities on both endpoints. For connection-oriented LLPs, DDP Stream teardown MAY result in underlying LLP Connection teardown.
DDPは独自にStream Teardownを開始してはいけません。 DDPは、LLPによって取りこわされるストリームに応じるか、またはストリームを取りこわすためにULPから要求を処理します。 DDP Stream分解は、両方の終点でDDPが能力であると無効にします。 接続指向のLLPsに関しては、DDP Stream分解は基本的なLLP Connection分解をもたらすかもしれません。
6.2.1. DDP Graceful Teardown
6.2.1. DDPの優雅な分解
It is up to the ULP to ensure that DDP teardown happens on both endpoints of the DDP Stream at the same time; this is necessary so that the Data Sink stops trying to interpret the DDP Segments.
DDP分解が同時にDDP Streamの両方の終点で起こるのを保証するのは、ULP次第です。 これが必要であるので、Data Sinkは、DDP Segmentsを解釈しようとするのを止めます。
If the Local Peer ULP indicates graceful teardown, the DDP layer on the Local Peer SHOULD ensure that all ULP data would be transferred before the underlying LLP Stream and Connection are torn down, and any further data transfer requests by the Local Peer ULP MUST return an error.
Local Peer ULPが、優雅な分解、Local Peer SHOULDの上のDDP層が、すべてのULPデータが以前移されるのを確実にするのを示すなら、基本的なLLP StreamとConnectionを取りこわします、そして、Local Peer ULPによるどんな詳しいデータ要求も誤りを返さなければなりません。
Shah, et al. Standards Track [Page 22] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[22ページ]。
If the DDP layer on the Local Peer receives a graceful teardown request from the LLP, any further data received after the request is considered an error and MUST cause the DDP Stream to be abortively torn down.
Local Peerの上のDDP層がLLPから優雅な分解要求を受け取るなら、どんな詳しいデータでも、要求が誤りであると考えられた後に受信して、DDP Streamを不成功に取りこわさなければなりません。
If the Local Peer LLP supports a half-closed LLP Stream, on the receipt of an LLP graceful teardown request of the DDP Stream, DDP SHOULD indicate the half-closed state to the ULP, and continue to process outbound data transfer requests normally. Following this event, when the Local Peer ULP requests graceful teardown, DDP MUST indicate to the LLP that it SHOULD perform a graceful close of the other half of the LLP Stream.
Local Peer LLPが半開きなLLP Streamをサポートするなら、DDP SHOULDは、DDP StreamのLLPの優雅な分解要求の領収書の上では、半開きな状態をULPに示して、通常、アウトバウンドデータ転送要求を処理し続けています。 Local Peer ULPが優雅な分解を要求するとき、このイベントに続いて、DDPがそれをLLPに示さなければならない、それ、SHOULDはLLP Streamのもう片方の半分の優雅な閉鎖を実行します。
If the Local Peer LLP supports a half-closed LLP Stream, on the receipt of a ULP graceful half-closed teardown request of the DDP Stream, DDP SHOULD keep data reception enabled on the other half of the LLP Stream.
Local Peer LLPが半開きなLLP Streamをサポートするなら、DDP StreamのULPの優雅な半開きな分解要求の領収書では、DDP SHOULDは、LLP Streamのもう片方の半分でデータ受信を可能にし続けます。
6.2.2. DDP Abortive Teardown
6.2.2. DDPの不成功の分解
As previously mentioned, DDP does not independently terminate a DDP Stream. Thus, any of the following fatal errors on a DDP Stream MUST cause DDP to indicate to the ULP that a fatal error has occurred:
以前に言及されるように、DDPは独自にDDP Streamを終えません。 したがって、DDP Streamにおける以下の致命的な誤りのどれかはDDPに致命的な誤りが発生したのをULPに示させなければなりません:
* Underlying LLP Connection or LLP Stream is lost.
* 基本的なLLP ConnectionかLLP Streamが無くなっています。
* Underlying LLP reports a fatal error.
* 基本的なLLPは致命的な誤りを報告します。
* DDP Header has one or more invalid fields.
* DDP Headerには、1つ以上の無効の分野があります。
If the LLP indicates to the ULP that a fatal error has occurred, the DDP layer SHOULD report the error to the ULP (see Section 7.2, DDP Error Numbers) and complete all outstanding ULP requests with an error. If the underlying LLP Stream is still intact, DDP SHOULD continue to allow the ULP to transfer additional DDP Messages on the outgoing half connection after the fatal error was indicated to the ULP. This enables the ULP to transfer an error syndrome to the Remote Peer. After indicating to the ULP a fatal error has occurred, the DDP Stream MUST NOT be terminated until the Local Peer ULP indicates to the DDP layer that the DDP Stream should be abortively torn down.
LLPが、致命的な誤りが発生したのをULPに示すなら、DDP層のSHOULDはULP(セクション7.2を見てください、DDP Error民数記)に誤りを報告して、誤りですべての傑出しているULP要求を終了します。 基本的なLLP Streamがまだ完全であるなら、致命的な誤りがULPに示された後にDDP SHOULDはULPに外向的な半分接続のときに追加DDP Messagesをずっと移させます。 これは、ULPが誤りシンドロームをRemote Peerに移すのを可能にします。 Local Peer ULPが、致命的な誤りが発生したのをDDP Streamが不成功に取りこわされるべきであるのをULPにDDP層に示すまで、次々とDDP Streamを終えてはいけません。
Shah, et al. Standards Track [Page 23] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[23ページ]。
7. Error Semantics
7. 誤り意味論
All LLP errors reported to DDP SHOULD be passed up to the ULP.
すべてのLLP誤りが、ULPまで通過されるようにDDP SHOULDに報告しました。
7.1. Errors Detected at the Data Sink
7.1. データ受信端末に検出された誤り
For non-zero-length Untagged DDP Segments, the DDP Segment MUST be validated before Placement by verifying:
非ゼロ・レングスUntagged DDP Segmentsに関しては、Placementの前で以下について確かめることによって、DDP Segmentを有効にしなければなりません。
1. The QN is valid for this stream.
1. このストリームに、QNは有効です。
2. The QN and MSN have an associated buffer that allows Placement of
the payload.
2. QNとMSNには、ペイロードのPlacementを許容する関連バッファがあります。
Implementers' note: DDP implementations SHOULD consider lack of
an associated buffer as a system fault. DDP implementations MAY
try to recover from the system fault using LLP means in a ULP-
transparent way. DDP implementations SHOULD NOT permit system
faults to occur repeatedly or frequently. If there is not an
associated buffer, DDP implementations MAY choose to disable the
stream for the reception and report an error to the ULP at the
Data Sink.
Implementersの注意: DDP実装SHOULDは、関連バッファの不足がシステム欠点であるとみなします。 DDP実装は、システム欠点からULPの見え透いた方法でLLP手段を使用することで回復しようとするかもしれません。 DDP実装SHOULD NOTは、システム欠点が反復か頻繁に起こるのを可能にします。 関連バッファがなければ、DDP実装は、レセプションとレポートのためのストリームが誤りであるとData SinkのULPに無効にするのを選ぶかもしれません。
3. The MO falls in the range of legal offsets associated with the
Untagged Buffer.
3. MOはUntagged Bufferに関連している法的なオフセットの範囲で低下します。
4. The sum of the DDP Segment payload length and the MO falls in the
range of legal offsets associated with the Untagged Buffer.
4. DDP Segmentペイロード長とMOの合計はUntagged Bufferに関連している法的なオフセットの範囲に下がります。
5. The Message Sequence Number falls in the range of legal Message
Sequence Numbers, for the queue defined by the QN. The legal
range is defined as being between the MSN value assigned to the
first available buffer for a specific QN and the MSN value
assigned to the last available buffer for a specific QN.
5. Message Sequence NumberはQNによって定義された待ち行列のために法的なMessage Sequence民数記の範囲に落ちます。 法的な範囲は特定のQNのための最初の利用可能なバッファに割り当てられたMSN値と特定のQNのために最後の利用可能なバッファに割り当てられたMSN値の間には、あると定義されます。
Implementers' note: for a typical Queue Number, the lower limit
of the Message Sequence Number is defined by whatever DDP
Messages have already been completed. The upper limit is defined
by however many message buffers are currently available for that
queue. Both numbers change dynamically as new DDP Messages are
received and completed, and new buffers are added. It is up to
the ULP to ensure that sufficient buffers are available to handle
the incoming DDP Segments.
Implementersの注意: 典型的なQueue Numberに関しては、Message Sequence Numberの下限は既に完成したどんなDDP Messagesによっても定義されます。 多くのメッセージ・バッファが現在どのようにその待ち行列に利用可能であっても、上限は定義されます。 新しいDDP Messagesが受け取られて、完成して、新しいバッファが加えられるとき、両方の数はダイナミックに変化します。 十分なバッファが入って来るDDP Segmentsを扱うために利用可能であることを保証するのは、ULP次第です。
For non-zero-length Tagged DDP Segments, the segment MUST be validated before Placement by verifying:
非ゼロ・レングスTagged DDP Segmentsに関しては、Placementの前で以下について確かめることによって、セグメントを有効にしなければなりません。
1. The STag is valid for this stream.
1. このストリームに、STagは有効です。
Shah, et al. Standards Track [Page 24] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[24ページ]。
2. The STag has an associated buffer that allows Placement of the
payload.
2. STagには、ペイロードのPlacementを許容する関連バッファがあります。
3. The TO falls in the range of legal offsets registered for the
STag.
3. TOはSTagのために登録された法的なオフセットの範囲に落ちます。
4. The sum of the DDP Segment payload length and the TO falls in the
range of legal offsets registered for the STag.
4. DDP Segmentペイロード長とTOの合計はSTagのために登録された法的なオフセットの範囲に下がります。
5. A 64-bit unsigned sum of the DDP Segment payload length and the
TO does not wrap.
5. 包装ではなく、Segmentペイロード長とTOがそうするDDPの64ビットの未署名の合計。
If the DDP layer detects any of the receive errors listed in this section, it MUST cease placing the remainder of the DDP Segment and report the error(s) to the ULP. The DDP layer SHOULD include in the error report the DDP Header, the type of error, and the length of the DDP segment, if available. DDP MUST silently drop any subsequent incoming DDP Segments. Since each of these errors represents a failure of the sending ULP or protocol, DDP SHOULD enable the ULP to send one additional DDP Message before terminating the DDP Stream.
層がいずれも検出するDDPである、このセクションで記載された誤りを受けてください、それは、DDP Segmentの残りを置くのをやめて、誤りをULPに報告しなければなりません。 DDP層のSHOULDはエラー・レポートにDDP Header、誤りのタイプ、およびDDPセグメントの長さを含んでいます、利用可能であるなら。 DDPは静かにどんなその後の入って来るDDP Segmentsも下げなければなりません。 それぞれのこれらの誤りが送付ULPかプロトコルの失敗を表すので、DDP SHOULDは、DDP Streamを終える前にULPが1追加DDP Messageを送るのを可能にします。
7.2. DDP Error Numbers
7.2. DDPエラー番号
The following error numbers MUST be used when reporting errors to the ULP. They correspond to the checks enumerated in section 7.1. Each error is subdivided into a 4-bit Error Type and an 8-bit Error Code.
誤りをULPに報告するとき、以下のエラー番号を使用しなければなりません。 彼らはセクション7.1で列挙されたチェックに対応します。 各誤りは4ビットのError Typeと8ビットのError Codeに細分されます。
Error Error Type Code Description ---------------------------------------------------------- 0x0 0x00 Local Catastrophic
誤り誤りタイプコード記述---------------------------------------------------------- 0×0、0×00ローカル壊滅的
0x1 Tagged Buffer Error
0x00 Invalid STag
0x01 Base or bounds violation
0x02 STag not associated with DDP Stream
0x03 TO wrap
0x04 Invalid DDP version
0×1 タグ付けをされたBuffer Error0x00Invalid STag0x01基地か違反0x02STagがDDP Stream0x03TOに関連づけなかった領域が0×04Invalid DDPバージョンを包装します。
0x2 Untagged Buffer Error
0x01 Invalid QN
0x02 Invalid MSN - no buffer available
0x03 Invalid MSN - MSN range is not valid
0x04 Invalid MO
0x05 DDP Message too long for available buffer
0x06 Invalid DDP version
0×2 Untagged Buffer Error0x01Invalid QN0×02Invalid MSN--いいえ、バッファ利用可能な0x03Invalid MSN--MSN範囲は長い間利用可能なバッファ0x06Invalid DDPバージョンのための有効な0×04Invalid MO0x05DDP Messageであり過ぎるというわけではありません。
0x3 Rsvd Reserved for the use by the LLP
0×3 LLPによる使用のためにRsvd Reserved
Shah, et al. Standards Track [Page 25] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[25ページ]。
8. Security Considerations
8. セキュリティ問題
This section discusses both protocol-specific considerations and the implications of using DDP with existing security mechanisms. The security requirements for the DDP implementation are provided at the end of the section. A more detailed analysis of the security issues around the implementation and the use of the DDP can be found in [RDMASEC].
このセクションはプロトコル特有の問題と使用DDPの含意の両方について既存のセキュリティー対策に論じます。セクションの端でDDP実装のためのセキュリティ要件を提供します。 [RDMASEC]で実装の周りの安全保障問題の、より詳細な分析とDDPの使用を見つけることができます。
The IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [IPSEC] 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]. 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; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RDDPがIPsecのバージョンに基づいているので、IPsec要件は、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるように、RFC2401[IPSEC]で指定して、RFCsを関係づけて、RFCs[RFC4303][RFC4306]を関係づけました。 RDDPプロトコルの重要な早めの応用の1つはiSCSI[iSER]との彼らの使用です。 RDDPのIPsec要件は、IPsecの一般的なプロフィールがiSCSIとRDDPプロトコルと共に使用されるのを許容することによってその用法を容易にするためにIPsecのものに続きます。 将来、IPsecの、より新しいバージョンにRFC3723をアップデートするかもしれません。 どんなそのようなものの要件もアップデートするIPsecセキュリティは一様にiSCSIとRDDPプロトコルに申請されるべきです。
8.1. Protocol-Specific Security Considerations
8.1. プロトコル特有のセキュリティ問題
The vulnerabilities of DDP to active third-party interference are no greater than any other protocol running over transport protocols such as TCP and SCTP over IP. A third party, by injecting spoofed packets into the network that are Delivered to a DDP Data Sink, could launch a variety of attacks that exploit DDP-specific behavior. Since DDP directly or indirectly exposes memory addresses on the wire, the Placement information carried in each DDP Segment must be validated, including invalid STag and octet-level granularity base and bounds check, before any data is Placed. For example, a third-party adversary could inject random packets that appear to be valid DDP Segments and corrupt the memory on a DDP Data Sink. Since DDP is IP transport protocol independent, communication security mechanisms such as IPsec [IPSEC] may be used to prevent such attacks.
活発な第三者干渉へのDDPの脆弱性はIPの上でTCPやSCTPなどのトランスポート・プロトコルをひくよりプロトコル以下ですいかなる他のも。 ネットワークへのDeliveredである偽造しているパケットをDDP Data Sinkに注入することによって、第三者はDDP特異的行動を利用するさまざまな攻撃に着手できるでしょう。 DDPがワイヤの上に直接か間接的にメモリアドレスを暴露するので、無効のSTagを含んでいて、それぞれのDDP Segmentで運ばれたPlacement情報を有効にしなければなりません、そして、八重奏レベル粒状ベースと領域はチェックします、どんなデータもPlacedになる前に。 例えば、第三者敵は、有効なDDP Segmentsであるように見える無作為のパケットを注入して、DDP Data Sinkに関するメモリを崩壊させることができました。 DDPがIPトランスポート・プロトコル独立者であるので、IPsec[IPSEC]などのコミュニケーションセキュリティー対策はそのような攻撃を防ぐのに使用されるかもしれません。
8.2. Association of an STag and a DDP Stream
8.2. 雄ジカとDDPストリームの協会
There are several mechanisms for associating an STag and a DDP Stream. Two required mechanisms for this association are a Protection Domain (PD) association and a DDP Stream association.
STagとDDP Streamを関連づけるための数個のメカニズムがあります。 2つのこの協会に、必要なメカニズムが、Protection Domain(PD)協会とDDP Stream協会です。
Under the Protection Domain (PD) association, a unique Protection Domain Identifier (PD ID) is created and used locally to associate an STag with a set of DDP Streams. Under this mechanism, the use of the STag is only permitted on the DDP Streams that have the same PD ID as the STag. For an incoming DDP Segment of a Tagged DDP Message on a
Protection Domain(PD)協会の下では、ユニークなProtection Domain Identifier(PD ID)は、DDP Streamsの1セットにSTagを関連づけるのに局所的に作成されて、使用されます。このメカニズムの下では、STagの使用はSTagと同じPD IDを持っているDDP Streamsで受入れられるだけです。 aのTagged DDP Messageの入って来るDDP Segmentのために
Shah, et al. Standards Track [Page 26] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[26ページ]。
DDP Stream, if the PD ID of the DDP Stream is not the same as the PD ID of the STag targeted by the Tagged DDP Message, then the DDP Segment is not Placed, and the DDP layer MUST surface a local error to the ULP. Note that the PD ID is locally defined and cannot be directly manipulated by the Remote Peer.
DDP Stream、DDP StreamのPD IDがTagged DDP Messageによって狙われたSTagのPD IDと同じでないなら、DDP SegmentはPlacedでなく、DDP層は地方の誤りのULPに表面を仕上げなければなりません。 PD IDを局所的に定義して、Remote Peerが直接操作できないことに注意してください。
Under the DDP Stream association, a DDP Stream is identified locally by a unique DDP Stream identifier (ID). An STag is associated with a DDP Stream by using a DDP Stream ID. In this case, for an incoming DDP Segment of a Tagged DDP Message on a DDP Stream, if the DDP Stream ID of the DDP Stream is not the same as the DDP Stream ID of the STag targeted by the Tagged DDP Message, then the DDP Segment is not Placed and the DDP layer MUST surface a local error to the ULP. Note that the DDP Stream ID is locally defined and cannot be directly manipulated by the Remote Peer.
DDP Stream協会の下では、ユニークなDDP Stream識別子(ID)によってDDP Streamは局所的に特定されます。 STagは、DDP Stream IDを使用することによって、DDP Streamに関連しています。 この場合、DDP StreamのDDP Stream IDがTagged DDP Messageによって狙われたSTagのDDP Stream IDと同じでないなら、DDP Streamの上のTagged DDP Messageの入って来るDDP Segmentに関して、DDP SegmentはPlacedではありません、そして、DDP層は地方の誤りのULPに表面を仕上げなければなりません。 DDP Stream IDを局所的に定義して、Remote Peerが直接操ることができないことに注意してください。
A ULP SHOULD associate an STag with at least one DDP Stream. DDP MUST support Protection Domain association and DDP Stream association mechanisms for associating an STag and a DDP Stream.
ULP SHOULDは少なくとも1DDP StreamにSTagを関連づけます。 DDPは、STagとDDP Streamを関連づけるためにProtection Domain協会とDDP Streamが連合機能であるとサポートしなければなりません。
8.3. Security Requirements
8.3. セキュリティ要件
[RDMASEC] defines the security model and general assumptions for RDMAP/DDP. This subsection provides the security requirements for the DDP implementation. For more details on the type of attacks, type of attackers, trust models, and resource sharing for the DDP implementation, the reader is referred to [RDMASEC].
[RDMASEC]はRDMAP/DDPのための機密保護モデルと一般的な仮定を定義します。 この小区分はDDP実装のためのセキュリティ要件を提供します。 DDP実装のための攻撃のタイプ、攻撃者のタイプ、信頼モデル、およびリソース・シェアリングに関するその他の詳細について、読者は言及されます[RDMASEC]。
DDP has several mechanisms that deal with a number of attacks. These attacks include, but are not limited to:
DDPには、多くの攻撃に対処する数個のメカニズムがあります。 含んでいますが、これらの攻撃は制限されません:
1. Connection to/from an unauthorized or unauthenticated endpoint.
2. Hijacking of a DDP Stream.
3. Attempts to read or write from unauthorized memory regions.
4. Injection of RDMA Messages within a stream on a multi-user
operating system by another application.
1. 権限のないか非認証された終点からの/との接続。 2. DDPストリームのハイジャック。 3. 権限のないメモリ領域から読むか、または書くのを試みます。 4. 別のアプリケーションによるマルチユーザオペレーティングシステムに関するストリームの中のRDMA Messagesの注射。
DDP relies on the LLP to establish the LLP Stream over which DDP Messages will be carried. DDP itself does nothing to authenticate the validity of the LLP Stream of either of the endpoints. It is the responsibility of the ULP to validate the LLP Stream. This is highly desirable due to the nature of DDP.
DDPは、DDP Messagesが運ばれるLLP Streamを証明するためにLLPを当てにします。 DDP自体は終点のどちらかのLLP Streamの正当性を認証するようなことを何もしません。 LLP Streamを有効にするのは、ULPの責任です。 これはDDPの本質のために非常に望ましいです。
Shah, et al. Standards Track [Page 27] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[27ページ]。
Hijacking of an DDP Stream would require that the underlying LLP Stream is hijacked. This would require knowledge of Advertised Buffers in order to directly Place data into a user buffer. Therefore, this is constrained by the same techniques mentioned to guard against attempts to read or write from unauthorized memory regions.
DDP Streamのハイジャックは、基本的なLLP Streamがハイジャックされるのを必要とするでしょう。 これがAdvertised Buffersに関する知識を必要とするだろう、直接、ユーザバッファの中へのPlaceデータ。 したがって、これは権限のないメモリ領域から読むか、または書く試みに用心するために言及された同じテクニックで抑制されます。
DDP does not require a node to open its buffers to arbitrary attacks over the DDP Stream. It may access ULP memory only to the extent that the ULP has enabled and authorized it to do so. The STag access control model is defined in [RDMASEC]. Specific security operations include:
DDPは、DDP Streamの上の任意の攻撃にバッファを開くためにノードを必要としません。 それはULPが、それがそうするのを可能にして、認可したという範囲だけにULPメモリにアクセスするかもしれません。 STagアクセス制御モデルは[RDMASEC]で定義されます。 特定のセキュリティ操作は:
1. STags are only valid over the exact byte range established by the
ULP. DDP MUST provide a mechanism for the ULP to establish and
revoke the TO range associated with the ULP Buffer referenced by
the STag.
2. STags are only valid for the duration established by the ULP.
The ULP may revoke them at any time, in accordance with its own
upper layer protocol requirements. DDP MUST provide a mechanism
for the ULP to establish and revoke STag validity.
3. DDP MUST provide a mechanism for the ULP to communicate the
association between a STag and a specific DDP Stream.
4. A ULP may only expose memory to remote access to the extent that
it already had access to that memory itself.
5. If an STag is not valid on a DDP Stream, DDP MUST pass the
invalid access attempt to the ULP. The ULP may provide a
mechanism for terminating the DDP Stream.
1. STagsはULPによって確立された正確なバイト範囲だけで有効です。 ULPがSTagによって参照をつけられるULP Bufferに関連しているTO範囲を設立して、取り消すように、DDPはメカニズムを提供しなければなりません。 2. ULPによって確立された持続時間だけに、STagsは有効です。 それ自身の上側の層のプロトコル要件に従って、ULPはいつでも、それらを取り消すかもしれません。 ULPがSTagの正当性を設立して、取り消すように、DDPはメカニズムを提供しなければなりません。 3. ULPがSTagと特定のDDP Streamとの協会を伝えるように、DDPはメカニズムを提供しなければなりません。 4. ULPは既にそのメモリ自体に近づく手段を持ったという範囲への遠隔アクセスにメモリを暴露するだけであるかもしれません。 5. STagがDDP Streamで有効でないなら、DDPは無効のアクセス試みをULPに通過しなければなりません。 ULPはDDP Streamを終えるのにメカニズムを提供するかもしれません。
Further, DDP provides a mechanism that directly Places incoming payloads in user-mode ULP Buffers. This avoids the risks of prior solutions that relied upon exposing system buffers for incoming payloads.
さらに、DDPはその直接Places入って来るペイロードのメカニズムをユーザ・モードULP Buffersに供給します。 これは入って来るペイロードのためのシステムバッファを暴露するそれが当てにした先のソリューションの危険を避けます。
For the DDP implementation, two components MUST be provided: an RDMA-enabled NIC (RNIC) and a Privileged Resource Manager (PRM).
DDP実装において、2つのコンポーネントを提供しなければなりません: RDMAによって可能にされたNIC(RNIC)と特権がある資源管理プログラム(PRM)。
8.3.1. RNIC Requirements
8.3.1. RNIC要件
The RNIC MUST implement the DDP wire Protocol and perform the security semantics described below.
RNIC MUSTはDDPがワイヤプロトコルであると実装して、以下で説明されたセキュリティ意味論を実行します。
1. An RNIC MUST ensure that a specific DDP Stream in a specific
Protection Domain cannot access an STag in a different Protection
Domain.
1. RNIC MUSTは、特定のProtection Domainの特定のDDP Streamが異なったProtection DomainでSTagにアクセスできないのを確実にします。
2. An RNIC MUST ensure that if an STag is limited in scope to a
single DDP Stream, no other DDP Stream can use the STag.
2. RNIC MUSTは、STagが範囲で独身のDDP Streamに制限されるなら、他のどんなDDP StreamもSTagを使用できないのを確実にします。
Shah, et al. Standards Track [Page 28] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[28ページ]。
3. An RNIC MUST ensure that a Remote Peer is not able to access
memory outside 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 NOT enable firmware to be loaded on the RNIC
directly from an untrusted Local Peer or Remote Peer, unless the
Peer is properly authenticated (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), and the update is done via a secure protocol, such as
IPsec.
7. RNIC MUST NOTは、ファームウェアがRNICで直接信頼されていないLocal PeerかRemote Peerからロードされるのを可能にします、Peerが適切に認証されない場合(この仕様の範囲の外のメカニズムで。 メカニズム、おそらく、リモートULPは権利がある限嗣相続認証がアップデートを実行します。), そして、IPsecなどの安全なプロトコルで、アップデートします。
8.3.2. Privileged Resources Manager Requirement
8.3.2. 特権があるリソースマネージャ要件
The PRM MUST implement the security semantics described below.
PRM MUSTは、セキュリティが以下で説明された意味論であると実装します。
1. All Non-Privileged ULP interactions with the RNIC Engine that
could affect other ULPs MUST be done using the Privileged
Resource Manager as a proxy.
1. プロキシとしてPrivileged 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 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 SHOULD prevent a Local Peer from
allocating more than its fair share of resources. If an RNIC
provides the ability to share receive buffers across multiple DDP
Streams, the combination of the RNIC and the Privileged Resource
5. Privileged ResourceマネージャSHOULDは、Local Peerがリソースの正当な分け前以上を割り当てるのを防ぎます。 RNICが複数のDDP Streamsの向こう側に受信バッファを共有する能力、RNICの組み合わせ、およびPrivileged Resourceを提供するなら
Shah, et al. Standards Track [Page 29] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[29ページ]。
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.
マネージャは、Remote Peerが、Local Peerが攻撃を検出して、防ぐために対策を適用できるようにリソースの正当な分け前以上を消費するのを試みているかどうか検出できなければなりません。
8.4. Security Services for DDP
8.4. DDPのためのセキュリティー・サービス
DDP uses IP-based network services; therefore, all exchanged DDP Segments are vulnerable to spoofing, tampering and information disclosure attacks. If a DDP Stream may be subject to impersonation attacks, or stream hijacking attacks, it is highly RECOMMENDED that the DDP Stream be authenticated, integrity protected, and protected from replay attacks. It MAY use confidentiality protection to protect from eavesdropping.
DDPはIP接続を基本にしたネットワークサービスを利用します。 したがって、すべてがSegmentsが偽造するのに被害を受け易いDDP、改ざん、および情報公開攻撃を交換しました。 DDP Streamはものまね攻撃、またはストリームハイジャック攻撃を受けることがあるかもしれないなら、DDP StreamがあるRECOMMENDEDが認証されて、保全が反射攻撃から非常に、保護して、保護されたということです。 それは、盗聴から保護するのに秘密性保護を使用するかもしれません。
8.4.1. Available Security Services
8.4.1. 利用可能なセキュリティー・サービス
IPsec can be used to protect against the packet injection attacks outlined above. Because IPsec is designed to secure arbitrary IP packet streams, including streams where packets are lost, DDP can run on top of IPsec without any change.
上に概説されたパケット注射攻撃から守るのにIPsecを使用できます。 IPsecがパケットが無くなるところにストリームを含む任意のIPパケットストリームを保証するように設計されているので、DDPは少しも変化のないIPsecの上で稼働できます。
DDP security may also profit from SSL or TLS security services provided for TCP or SCTP based ULPs [TLS] as well as from DTLS [DTLS] security services provided beneath the transport protocol. See [RDMASEC] for further discussion of these approaches and the rationale for selection of IPsec security services for the RDDP protocols.
また、DDPセキュリティがSSLから利益を得るかもしれませんか、TLSセキュリティー・サービスはTCPに備えたか、またはSCTPがトランスポート・プロトコルの下で提供されたDTLS[DTLS]セキュリティー・サービスの時点で、また、ULPs[TLS]を基礎づけました。 これらのアプローチと原理のさらなる議論に関してRDDPプロトコルのためのIPsecセキュリティー・サービスの品揃えに関して[RDMASEC]を見てください。
8.4.2. Requirements for IPsec Services for DDP
8.4.2. DDPのためのIPsecサービスのための要件
IPsec packets are processed (e.g., integrity checked and possibly decrypted) in the order they are received, and a DDP Data Sink will process the decrypted DDP Segments contained in these packets in the same manner as DDP Segments contained in unsecured IP packets.
IPsecパケットによるオーダーで処理された(例えばチェックされて、ことによると解読された保全)それらが受け取られていて、DDP Data SinkがDDP Segmentsが非機密保護しているIPにパケットを含んだときSegmentsがこれらのパケットに同じ方法で含んだ解読されたDDPを処理するということです。
The IP Storage working group has defined the normative IPsec requirements for IP Storage [RFC3723]. Portions of this specification are applicable to the DDP. In particular, a compliant implementation of IPsec services 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要件を定義しました。 この仕様の部分はDDPに適切です。 特に、対応するIPsecサービスの実装は[RFC3723]のセクション2.3に概説されているように条件を満たさなければなりません。 [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パケットあたりのデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
Shah, et al. Standards Track [Page 30] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[30ページ]。
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 an IKE delete message as a
reason for tearing down the DDP stream. Since IPsec acceleration
hardware may only be able to handle a limited number of active
IPsec Security Associations (SAs), idle SAs may be dynamically
brought down and a new SA be brought up again, if activity
resumes.
4. それは領収書を解釈してはいけません。IKEでは、DDPストリームを取りこわす理由としてメッセージを削除してください。 IPsec加速ハードウェアが限られた数のアクティブなIPsec Security Associations(SAs)を扱うことができるだけであるかもしれないので、使用されていないSAsは扱うことができます。下であるのと新しいSAがダイナミックにもたらされて、もう一度持って来られてください、活動再開であるなら。
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を使用して、使用されてください。
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. 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.
7. または、局所的に保存された秘密の情報へのアクセス、(あらかじめ共有される、デジタル署名のための秘密鍵) 秘密の情報の感染がIKE/IPsecプロトコルのセキュリティの特性を無効にするので、適当に制限しなければなりません。
8. 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.
8. 大規模な構成を必要としないで高いレベルの相互運用性を達成すると、IKEパラメタの設定の.4セクション2.3[RFC3723]のガイドラインは従われなければなりません。
Furthermore, implementation and deployment of the IPsec services for DDP should follow the Security Considerations outlined in Section 5 of [RFC3723].
その上、DDPのための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 DDP were enabled a priori for a ULP by connecting to a well-known port, this well-known port would be registered for the DDP with IANA. The registration of the well-known port would be the responsibility of the ULP specification.
DDPがULPのためにウェルノウンポートに接続することによって先験的に可能にされるなら、このウェルノウンポートはDDPのためにIANAに登録されるでしょうに。 ウェルノウンポートの登録はULP仕様の責任でしょう。
Shah, et al. Standards Track [Page 31] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[31ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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 Atkinson, R., "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 Carrel, D., "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., Travostino,
F., "Securing Block Storage Protocols over IP", RFC 3723,
April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan対RFC3723、Travostino、F.が「IPの上でブロックストレージがプロトコルであると機密保護する」2004年4月
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[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月。
[RDMAP] Recio, R., Culley, P., Garcia, D., and J. Hilland, "A
Remote Direct Memory Access Protocol Specification", RFC
5040, October 2007.
[RDMAP]RecioとR.とCulleyとP.とガルシア、D.とJ.Hilland、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(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月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[SCTP] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[SCTPDDP] Bestler, C. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Direct Data Placement (DDP) Adaptation",
RFC 5043, October 2007.
[SCTPDDP]BestlerとC.とR.スチュワート、「ストリーム制御伝動プロトコル(SCTP)ダイレクトデータプレースメント(DDP)適合」、RFC5043、2007年10月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Shah, et al. Standards Track [Page 32] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[32ページ]。
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月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[DTLS]レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、2006年4月のRFC4347。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[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月)。
Shah, et al. Standards Track [Page 33] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[33ページ]。
Appendix A. Receive Window Sizing
付録A.はウィンドウサイズ処理を受けます。
This appendix provides guidance to LLP implementers.
この付録は指導をLLP implementersに供給します。
Reliable, sequenced, LLPs include a mechanism to Advertise the amount of receive buffer space a sender may consume. This is generally called a "receive window".
広告、受信バッファ宇宙a送付者の量はそうするかもしれません。信頼できて、配列されたLLPsがメカニズムを含んでいる、消費します。 これによる「窓を受けてください」という一般に、aと呼ばれて、ことです。
DDP allows data to be transferred directly to predefined buffers at the Data Sink. Accordingly, the LLP receive window size need not be affected by the reception of a DDP Segment, if that segment is placed before additional segments arrive.
DDPは、データが直接Data Sinkの事前に定義されたバッファに移されるのを許容します。 それに従って、レシーブ・ウィンドウ・サイズがそうしなければならないLLPがDDP Segmentのレセプションで影響を受けないで、そのセグメントが以前置かれるなら、追加セグメントは到着します。
The LLP implementation SHOULD maintain an Advertised receive window large enough to enable a reasonable number of segments to be outstanding at one time. The amount to Advertise depends on the desired data rate, and the expected or actual round-trip delay between endpoints.
LLP実装SHOULDは、Advertisedが相当な数のセグメントがひところ傑出しているのを可能にすることができるくらい大きい窓を受けると主張します。 達する、広告、終点の間で必要なデータ信号速度、および予想されたか実際の往復の遅れによります。
The amount of actual buffers maintained to "back up" the receive window is left up to the implementation. This amount will depend on the rate that DDP Segments can be retired; there may be some cases where segment processing cannot keep up with the incoming packet rate. If this occurs, one reasonable way to slow the incoming packet rate is to reduce the receive window.
維持された「支援する」実際のバッファの量、実装に上がった状態で残っている窓を受けてください。 DDP Segmentsがレートであるかもしれませんが、引退して、意志が依存するこの量。 いくつかのケースがセグメント処理が入って来るパケットレートについて行くことができないところにあるかもしれません。 これが起こるなら、入って来るパケットレートを遅くする1つの合理的な方法が減少することになっている、窓を受けてください。
Note that the LLP should take care to comply with the applicable RFCs; for instance, for TCP, receivers are highly discouraged from "shrinking" the receive window (reducing the right edge of the window after it has been Advertised).
LLPが適切なRFCsに従うために注意するはずであることに注意してください。 例えば、TCPに関して、受信機が「縮小すること」から非常にがっかりしている、窓を受けてください(Advertisedになった後に窓の正しい縁を減少させて)。
Appendix B. Contributors
付録B.貢献者
Many thanks to the following individuals for their contributions.
彼らの貢献のために以下の個人をありがとうございます。
John Carrier Cray Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 Phone: 206-701-2090 EMail: carrier@cray.com
ジョンキャリヤーザリガニ株式会社411のFirst Avenue S、Suite600シアトル、ワシントン98104-2860Phone: 206-701-2090 メールしてください: carrier@cray.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
Shah, et al. Standards Track [Page 34] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[34ページ]。
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-6383 EMail: caitlinb@Broadcom.com
ケイトリンBestler Broadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1 (949) 926-6383 メールしてください: caitlinb@Broadcom.com
Uri Elzur Broadcom Corporation 5300 California Avenue Irvine, CA 92617, USA Phone: 949.926.6432 EMail: uri@broadcom.com
Avenueアーバイン、カリフォルニア 92617、ユリElzur Broadcom社5300のカリフォルニア米国は以下に電話をします。 949.926.6432 メールしてください: uri@broadcom.com
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-7149 EMail: MPenna@Broadcom.com
マイクおおばねBroadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1 (949) 926-7149 メールしてください: MPenna@Broadcom.com
Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-8635 EMail: pthaler@broadcom.com
パトリシアターレルBroadcom社16215のオールトンParkwayカリフォルニア92619-7013アーバイン(米国)は以下に電話をします。 +1 (949) 926-8635 メールしてください: pthaler@broadcom.com
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: +1 (919) 248-6075 EMail: compton_ted@emc.com
テッドコンプトンEMC社のリサーチトライアングル公園、NC27709米国電話: +1 (919) 248-6075 メールしてください: compton_ted@emc.com
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard Roseville, CA 95747-5668 USA Phone: +1 (916) 785-5198 EMail: jim_wendt@hp.com
ジムウェントヒューレット・パッカード社8000のフットヒルズBoulevardカリフォルニア95747-5668ローズビル(米国)は以下に電話をします。 +1 (916) 785-5198 メールしてください: jim_wendt@hp.com
Mike Krause Hewlett-Packard Company, 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: +1 (408) 447-3191 EMail: krause@cup.hp.com
マイククラウジーヒューレット・パッカード社、43LN19410はRoadカルパチーノ(カリフォルニア)95014米国電話に入植します: +1 (408) 447-3191 メールしてください: krause@cup.hp.com
Shah, et al. Standards Track [Page 35] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[35ページ]。
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro, OR 97124 USA Phone: +1 (503) 712-4106 EMail: dave.b.minturn@intel.com
デーヴMinturnインテル社MS JF1-210 5200東北イーラム・ヤング・Parkwayヒースボロー、または97124米国電話: +1 (503) 712-4106 メールしてください: dave.b.minturn@intel.com
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, AZ 85226 USA Phone: +1 (480) 554-3116 EMail: howard.c.herbert@intel.com
ハワードC.ハーバートインテル社MS CH7-404 5000の西ろうそく屋Blvd. ろうそく屋、アリゾナ85226米国電話: +1 (480) 554-3116 メールしてください: howard.c.herbert@intel.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
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-2769 EMail: Dwight.Barron@Hp.com
ドワイトバロンヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 +1 (281) 514-2769 メールしてください: Dwight.Barron@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
Jeff Hilland Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-9489 EMail: jeff.hilland@hp.com
ジェフHillandヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 +1 (281) 514-9489 メールしてください: jeff.hilland@hp.com
Barry Reinhold Lamprey Networks Durham, NH 03824 USA Phone: +1 (603) 868-8411 EMail: bbr@LampreyNetworks.com
ニューハンプシャー03824ダラム(米国)が電話をするバリトンサックスラインホルトヤツメウナギネットワーク: +1 (603) 868-8411 メールしてください: bbr@LampreyNetworks.com
Shah, et al. Standards Track [Page 36] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[36ページ]。
Authors' Addresses
作者のアドレス
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
James Pinkerton Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 (425) 705-5442 EMail: jpink@microsoft.com
ワシントン98052レッドモンド(米国)が電話をするジェームスピンカートンマイクロソフト社1マイクロソフト道: +1 (425) 705-5442 メールしてください: jpink@microsoft.com
Renato Recio IBM Corporation 11501 Burnett Road Austin, TX 78758 USA Phone: +1 (512) 838-1365 EMail: recio@us.ibm.com
レナートRecio IBM社11501のバーネット・Roadテキサス78758オースチン(米国)は以下に電話をします。 +1 (512) 838-1365 メールしてください: recio@us.ibm.com
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-5543 EMail: paul.culley@hp.com
ポールR.Culleyヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 +1 (281) 514-5543 メールしてください: paul.culley@hp.com
Shah, et al. Standards Track [Page 37] RFC 5041 DDP Protocol Specification October 2007
シャー、他 規格はDDPプロトコル仕様2007年10月にRFC5041を追跡します[37ページ]。
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に情報を扱ってください。
Shah, et al. Standards Track [Page 38]
シャー、他 標準化過程[38ページ]
一覧
スポンサーリンク
