Network Working Group                                          S. Bailey
Request for Comments: 4296                                     Sandburst
Category: Informational                                        T. Talpey
                                                                  NetApp
                                                           December 2005
        
Network Working Group                                          S. Bailey
Request for Comments: 4296                                     Sandburst
Category: Informational                                        T. Talpey
                                                                  NetApp
                                                           December 2005
        

The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols

Internet协议上的直接数据放置(DDP)和远程直接内存访问(RDMA)体系结构

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(2005年)。

Abstract

摘要

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.

本文档定义了在Internet协议套件传输上运行的直接数据放置(DDP)和远程直接内存访问(RDMA)协议的抽象体系结构。该体系结构不一定反映实现此类协议的正确方式,而是定义和理解协议的描述性工具。DDP允许将数据有效地放置到上层协议(如RDMA)指定的缓冲区中。RDMA提供了语义,以便能够以符合应用程序需求的方式在对等方之间进行远程直接内存访问。

Table of Contents

目录

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
      1.2. DDP and RDMA Protocols .....................................3
   2. Architecture ....................................................4
      2.1. Direct Data Placement (DDP) Protocol Architecture ..........4
           2.1.1. Transport Operations ................................6
           2.1.2. DDP Operations ......................................7
           2.1.3. Transport Characteristics in DDP ...................10
      2.2. Remote Direct Memory Access (RDMA) Protocol Architecture ..12
           2.2.1. RDMA Operations ....................................14
           2.2.2. Transport Characteristics in RDMA ..................16
   3. Security Considerations ........................................17
      3.1. Security Services .........................................18
      3.2. Error Considerations ......................................19
   4. Acknowledgements ...............................................19
   5. Informative References .........................................20
        
   1. Introduction ....................................................2
      1.1. Terminology ................................................2
      1.2. DDP and RDMA Protocols .....................................3
   2. Architecture ....................................................4
      2.1. Direct Data Placement (DDP) Protocol Architecture ..........4
           2.1.1. Transport Operations ................................6
           2.1.2. DDP Operations ......................................7
           2.1.3. Transport Characteristics in DDP ...................10
      2.2. Remote Direct Memory Access (RDMA) Protocol Architecture ..12
           2.2.1. RDMA Operations ....................................14
           2.2.2. Transport Characteristics in RDMA ..................16
   3. Security Considerations ........................................17
      3.1. Security Services .........................................18
      3.2. Error Considerations ......................................19
   4. Acknowledgements ...............................................19
   5. Informative References .........................................20
        
1. Introduction
1. 介绍

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. This document uses C language notation as a shorthand to describe the architectural elements of DDP and RDMA protocols. The choice of C notation is not intended to describe concrete protocols or programming interfaces.

本文档定义了在Internet协议套件传输上运行的直接数据放置(DDP)和远程直接内存访问(RDMA)协议的抽象体系结构。该体系结构不一定反映实现此类协议的正确方式,而是定义和理解协议的描述性工具。本文档使用C语言符号作为简写来描述DDP和RDMA协议的体系结构元素。选择C表示法并不是为了描述具体的协议或编程接口。

The first part of the document describes the architecture of DDP protocols, including what assumptions are made about the transports on which DDP is built. The second part describes the architecture of RDMA protocols layered on top of DDP.

本文档的第一部分描述了DDP协议的体系结构,包括对构建DDP的传输所做的假设。第二部分描述了在DDP之上分层的RDMA协议的体系结构。

1.1. Terminology
1.1. 术语

Before introducing the protocols, certain definitions will be useful to guide discussion:

在介绍协议之前,某些定义将有助于指导讨论:

o Placement - writing to a data buffer.

o 位置-写入数据缓冲区。

o Operation - a protocol message, or sequence of messages, which provide an architectural semantic, such as reading or writing of a data buffer.

o 操作-协议消息或消息序列,提供架构语义,如读取或写入数据缓冲区。

o Delivery - informing any Upper Layer or application that a particular message is available for use. Therefore, delivery may be viewed as the "control" signal associated with a unit of data. Note that the order of delivery is defined more strictly than it is for placement.

o 传递-通知任何上层或应用程序特定消息可供使用。因此,传送可被视为与数据单元相关联的“控制”信号。请注意,交货顺序的定义比放置顺序的定义更严格。

o Completion - informing any Upper Layer or application that a particular operation has finished. A completion, for instance, may require the delivery of several messages, or it may also reflect that some local processing has finished.

o 完成-通知任何上层或应用程序特定操作已完成。例如,完成可能需要传递多条消息,也可能反映某些本地处理已完成。

o Data Sink - the peer on which any placement occurs.

o 数据接收器-进行任何放置的对等方。

o Data Source - the peer from which the placed data originates.

o 数据源-放置数据的源节点。

o Steering Tag - a "handle" used to identify the buffer that is the target of placement. A "tagged" message is one that references such a handle.

o 转向标签-用于识别作为放置目标的缓冲器的“手柄”。“标记”消息是指引用此类句柄的消息。

o RDMA Write - an Operation that places data from a local data buffer to a remote data buffer specified by a Steering Tag.

o RDMA写入-将数据从本地数据缓冲区放入由转向标记指定的远程数据缓冲区的操作。

o RDMA Read - an Operation that places data to a local data buffer specified by a Steering Tag from a remote data buffer specified by another Steering Tag.

o RDMA Read—将数据从另一个转向标记指定的远程数据缓冲区放入转向标记指定的本地数据缓冲区的操作。

o Send - an Operation that places data from a local data buffer to a remote data buffer of the data sink's choice. Therefore, sends are "untagged".

o 发送-将数据从本地数据缓冲区放置到数据接收器选择的远程数据缓冲区的操作。因此,发送是“未标记的”。

1.2. DDP and RDMA Protocols
1.2. DDP和RDMA协议

The goal of the DDP protocol is to allow the efficient placement of data into buffers designated by protocols layered above DDP (e.g., RDMA). This is described in detail in [ROM]. Efficiency may be characterized by the minimization of the number of transfers of the data over the receiver's system buses.

DDP协议的目标是允许有效地将数据放置到DDP之上分层协议(如RDMA)指定的缓冲区中。这在[ROM]中有详细描述。效率可以通过最小化通过接收器系统总线的数据传输的次数来表征。

The goal of the RDMA protocol is to provide the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. The RDMA protocol provides facilities immediately useful to existing and future networking, storage, and other application protocols. [FCVI, IB, MYR, SDP, SRVNET, VI]

RDMA协议的目标是提供语义,以便以符合应用程序要求的方式在对等方之间实现远程直接内存访问。RDMA协议为现有和未来的网络、存储和其他应用程序协议提供了立即有用的功能。[FCVI、IB、MYR、SDP、SRVNET、VI]

The DDP and RDMA protocols work together to achieve their respective goals. DDP provides facilities to safely steer payloads to specific buffers at the Data Sink. RDMA provides facilities to Upper Layers for identifying these buffers, controlling the transfer of data

DDP和RDMA协议共同实现各自的目标。DDP提供了将有效负载安全引导到数据接收器的特定缓冲区的设施。RDMA为上层提供了识别这些缓冲区、控制数据传输的工具

between peers' buffers, supporting authorized bidirectional transfer between buffers, and signalling completion. Upper Layer Protocols that do not require the features of RDMA may be layered directly on top of DDP.

在对等方的缓冲区之间,支持缓冲区之间的授权双向传输,以及信令完成。不需要RDMA特性的上层协议可以直接分层在DDP之上。

The DDP and RDMA protocols are transport independent. The following figure shows the relationship between RDMA, DDP, Upper Layer Protocols, and Transport.

DDP和RDMA协议是独立于传输的。下图显示了RDMA、DDP、上层协议和传输之间的关系。

          +--------------------------------------------------+
          |               Upper Layer Protocol               |
          +---------+------------+---------------------------+
          |         |            |           RDMA            |
          |         |            +---------------------------+
          |         |                   DDP                  |
          |         +----------------------------------------+
          |                    Transport                     |
          +--------------------------------------------------+
        
          +--------------------------------------------------+
          |               Upper Layer Protocol               |
          +---------+------------+---------------------------+
          |         |            |           RDMA            |
          |         |            +---------------------------+
          |         |                   DDP                  |
          |         +----------------------------------------+
          |                    Transport                     |
          +--------------------------------------------------+
        
2. Architecture
2. 建筑学

The Architecture section is presented in two parts: Direct Data Placement Protocol architecture and Remote Direct Memory Access Protocol architecture.

体系结构部分分为两部分:直接数据放置协议体系结构和远程直接内存访问协议体系结构。

2.1. Direct Data Placement (DDP) Protocol Architecture
2.1. 直接数据放置(DDP)协议体系结构

The central idea of general-purpose DDP is that a data sender will supplement the data it sends with placement information that allows the receiver's network interface to place the data directly at its final destination without any copying. DDP can be used to steer received data to its final destination, without requiring layer-specific behavior for each different layer. Data sent with such DDP information is said to be `tagged'.

通用DDP的中心思想是,数据发送方将使用放置信息补充其发送的数据,该信息允许接收方的网络接口将数据直接放置在其最终目的地,而无需任何复制。DDP可以用于将接收到的数据引导到其最终目的地,而不需要每个不同层的特定层行为。与DDP信息一起发送的数据称为“标记”。

The central components of the DDP architecture are the `buffer', which is an object with beginning and ending addresses, and a method (set()), which sets the value of an octet at an address. In many cases, a buffer corresponds directly to a portion of host user memory. However, DDP does not depend on this; a buffer could be a disk file, or anything else that can be viewed as an addressable collection of octets. Abstractly, a buffer provides the interface:

DDP体系结构的核心组件是“缓冲区”,它是一个具有起始地址和结束地址的对象,以及一个方法(set()),该方法在地址处设置八位字节的值。在许多情况下,缓冲区直接对应于主机用户内存的一部分。然而,DDP并不依赖于此;缓冲区可以是一个磁盘文件,也可以是任何可以被视为八位字节可寻址集合的东西。抽象地说,缓冲区提供了接口:

        typedef struct {
          const address_t start;
          const address_t end;
          void            set(address_t a, data_t v);
        } ddp_buffer_t;
        
        typedef struct {
          const address_t start;
          const address_t end;
          void            set(address_t a, data_t v);
        } ddp_buffer_t;
        

address_t

地址

a reference to local memory

对本地内存的引用

data_t

数据

an octet data value.

八位字节数据值。

The protocol layering and in-line data flow of DDP is:

DDP的协议分层和在线数据流为:

                         DDP Client Protocol
                  (e.g., RDMA or Upper Layer Protocol)
                                |  ^
              untagged messages |  | untagged message delivery
                tagged messages |  | tagged message delivery
                                v  |
                                DDP+---> data placement
                                 ^
                                 | transport messages
                                 v
                             Transport
                    (e.g., SCTP, DCCP, framed TCP)
                                 ^
                                 | IP datagrams
                                 v
                               . . .
        
                         DDP Client Protocol
                  (e.g., RDMA or Upper Layer Protocol)
                                |  ^
              untagged messages |  | untagged message delivery
                tagged messages |  | tagged message delivery
                                v  |
                                DDP+---> data placement
                                 ^
                                 | transport messages
                                 v
                             Transport
                    (e.g., SCTP, DCCP, framed TCP)
                                 ^
                                 | IP datagrams
                                 v
                               . . .
        

In addition to in-line data flow, the client protocol registers buffers with DDP, and DDP performs buffer update (set()) operations as a result of receiving tagged messages.

除了在线数据流之外,客户机协议还向DDP注册缓冲区,DDP在接收标记消息后执行缓冲区更新(set())操作。

DDP messages may be split into multiple, smaller DDP messages, each in a separate transport message. However, if the transport is unreliable or unordered, messages split across transport messages may or may not provide useful behavior, in the same way as splitting arbitrary Upper Layer messages across unreliable or unordered transport messages may or may not provide useful behavior. In other words, the same considerations apply to building client protocols on different types of transports with or without the use of DDP.

DDP消息可以分为多个较小的DDP消息,每个消息位于单独的传输消息中。但是,如果传输不可靠或无序,则跨传输消息拆分的消息可能会或可能不会提供有用的行为,就像跨不可靠或无序传输消息拆分任意上层消息可能会或可能不会提供有用的行为一样。换句话说,在使用或不使用DDP的情况下,在不同类型的传输上构建客户机协议也需要考虑同样的问题。

A DDP message split across transport messages looks like:

跨传输消息拆分的DDP消息如下所示:

DDP message: Transport messages:

DDP消息:传输消息:

     stag=s, offset=o,          message 1:
     notify=y, id=i               |type=ddp  |
     message=                     |stag=s    |
       |aabbccddee|-------.       |offset=o  |
       ~   ...    ~----.   \      |notify=n  |
       |vvwwxxyyzz|-.   \   \     |id=?      |
                    |    \   `--->|aabbccddee|
                    |     \       ~    ...   ~
                    |      +----->|iijjkkllmm|
                    |      |
                    +      |    message 2:
                     \     |      |type=ddp  |
                      \    |      |stag=s    |
                       \   +      |offset=o+n|
                        \   \     |notify=y  |
                         \   \    |id=i      |
                          \   `-->|nnooppqqrr|
                           \      ~    ...   ~
                            `---->|vvwwxxyyzz|
        
     stag=s, offset=o,          message 1:
     notify=y, id=i               |type=ddp  |
     message=                     |stag=s    |
       |aabbccddee|-------.       |offset=o  |
       ~   ...    ~----.   \      |notify=n  |
       |vvwwxxyyzz|-.   \   \     |id=?      |
                    |    \   `--->|aabbccddee|
                    |     \       ~    ...   ~
                    |      +----->|iijjkkllmm|
                    |      |
                    +      |    message 2:
                     \     |      |type=ddp  |
                      \    |      |stag=s    |
                       \   +      |offset=o+n|
                        \   \     |notify=y  |
                         \   \    |id=i      |
                          \   `-->|nnooppqqrr|
                           \      ~    ...   ~
                            `---->|vvwwxxyyzz|
        

Although this picture suggests that DDP information is carried in-line with the message payload, components of the DDP information may also be in transport-specific fields, or derived from transport-specific control information if the transport permits.

尽管这幅图片表明DDP信息与消息有效载荷一起携带,但DDP信息的组成部分也可能位于特定于传输的字段中,或者在传输允许的情况下从特定于传输的控制信息派生而来。

2.1.1. Transport Operations
2.1.1. 运输业务

For the purposes of this architecture, the transport provides:

出于此体系结构的目的,传输提供:

        void      xpt_send(socket_t s, message_t m);
        message_t xpt_recv(socket_t s);
        msize_t   xpt_max_msize(socket_t s);
        
        void      xpt_send(socket_t s, message_t m);
        message_t xpt_recv(socket_t s);
        msize_t   xpt_max_msize(socket_t s);
        

socket_t

插座

a transport address, including IP addresses, ports and other transport-specific identifiers.

传输地址,包括IP地址、端口和其他传输特定标识符。

message_t

信息

a string of octets.

一串八位组。

msize_t (scalar)

msize_t(标量)

a message size.

消息大小。

xpt_send(socket_t s, message_t m)

xpt发送(套接字、消息)

send a transport message.

发送传输消息。

xpt_recv(socket_t s)

xpt_recv(插座)

receive a transport message.

接收传输消息。

xpt_max_msize(socket_t s)

xpt_max_msize(插座)

get the current maximum transport message size. Corresponds, roughly, to the current path Maximum Transfer Unit (PMTU), adjusted by underlying protocol overheads.

获取当前最大传输消息大小。大致对应于当前路径最大传输单元(PMTU),由底层协议开销调整。

Real implementations of xpt_send() and xpt_recv() typically return error indications, but that is not relevant to this architecture.

xpt_send()和xpt_recv()的实际实现通常会返回错误指示,但这与此体系结构无关。

2.1.2. DDP Operations
2.1.2. DDP业务

The DDP layer provides:

DDP层提供:

        void       ddp_send(socket_t s, message_t m);
        void       ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d,
                                ddp_notify_t n);
        void       ddp_post_recv(socket_t s, bdesc_t b);
        ddp_ind_t  ddp_recv(socket_t s);
        bdesc_t    ddp_register(socket_t s, ddp_buffer_t b);
        void       ddp_deregister(bhand_t bh);
        msizes_t   ddp_max_msizes(socket_t s);
        
        void       ddp_send(socket_t s, message_t m);
        void       ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d,
                                ddp_notify_t n);
        void       ddp_post_recv(socket_t s, bdesc_t b);
        ddp_ind_t  ddp_recv(socket_t s);
        bdesc_t    ddp_register(socket_t s, ddp_buffer_t b);
        void       ddp_deregister(bhand_t bh);
        msizes_t   ddp_max_msizes(socket_t s);
        

ddp_addr_t

ddp地址

the buffer address portion of a tagged message:

标记消息的缓冲区地址部分:

                typedef struct {
                  stag_t stag;
                  address_t offset;
                } ddp_addr_t;
        
                typedef struct {
                  stag_t stag;
                  address_t offset;
                } ddp_addr_t;
        

stag_t (scalar)

阶段(标量)

a Steering Tag. A stag_t identifies the destination buffer for tagged messages. stag_ts are generated when the buffer is registered, communicated to the sender by some client protocol

转向标签。stag_\t标识标记消息的目标缓冲区。在注册缓冲区时生成stag_t,并通过一些客户端协议将其传送给发送方

convention and inserted in DDP messages. stag_t values in this DDP architecture are assumed to be completely opaque to the client protocol, and implementation-dependent. However, particular implementations, such as DDP on a multicast transport (see below), may provide the buffer holder some control in selecting stag_ts.

约定并插入DDP消息中。此DDP体系结构中的stag_t值被假定为对客户端协议完全不透明,并且依赖于实现。然而,特定的实现,例如多播传输上的DDP(见下文),可以为缓冲区持有者提供选择stag\t的一些控制。

ddp_notify_t

ddp\u通知

the notification portion of a DDP message, used to signal that the message represents the final fragment of a multi-segmented DDP message:

DDP报文的通知部分,用于表示该报文代表多段DDP报文的最后一段:

                typedef struct {
                  boolean_t notify;
                  ddp_msg_id_t i;
                } ddp_notify_t;
        
                typedef struct {
                  boolean_t notify;
                  ddp_msg_id_t i;
                } ddp_notify_t;
        

ddp_msg_id_t (scalar)

ddp\u msg\u id\t(标量)

a DDP message identifier. msg_id_ts are chosen by the DDP message receiver (buffer holder), communicated to the sender by some client protocol convention and inserted in DDP messages. Whether a message reception indication is requested for a DDP message is a matter of client protocol convention. Unlike stag_ts, the structure of msg_id_ts is opaque to DDP, and therefore, it is completely in the hands of the client protocol.

DDP消息标识符。msg_id_ts由DDP消息接收器(缓冲区持有者)选择,通过某些客户端协议约定与发送方通信,并插入DDP消息中。是否为DDP消息请求消息接收指示取决于客户端协议约定。与stag_ts不同,msg_id_ts的结构对DDP是不透明的,因此,它完全掌握在客户机协议手中。

bdesc_t

BDESCUT

a description of a registered buffer:

已注册缓冲区的描述:

                typedef struct {
                  bhand_t bh;
                  ddp_addr_t a;
                } bdesc_t;
        
                typedef struct {
                  bhand_t bh;
                  ddp_addr_t a;
                } bdesc_t;
        

`a.offset' is the starting offset of the registered buffer, which may have no relationship to the `start' or `end' addresses of that buffer. However, particular implementations, such as DDP on a multicast transport (see below), may allow some client protocol control over the starting offset.

`a、 “偏移量”是已注册缓冲区的起始偏移量,它可能与该缓冲区的“开始”或“结束”地址没有关系。然而,特定的实现,例如多播传输上的DDP(见下文),可能允许一些客户端协议控制起始偏移量。

bhand_t

班杜特

an opaque buffer handle used to deregister a buffer.

用于取消缓冲区注册的不透明缓冲区句柄。

recv_message_t

接收信息

a description of a completed untagged receive buffer:

已完成的未标记接收缓冲区的说明:

                typedef struct {
                  bdesc_t b;
                  length_t l;
                } recv_message_t;
        
                typedef struct {
                  bdesc_t b;
                  length_t l;
                } recv_message_t;
        

ddp_ind_t

ddp_____t

an untagged message, a tagged message reception indication, or a tagged message reception error:

未标记消息、标记消息接收指示或标记消息接收错误:

                typedef union {
                  recv_message_t m;
                  ddp_msg_id_t i;
                  ddp_err_t e;
                } ddp_ind_t;
        
                typedef union {
                  recv_message_t m;
                  ddp_msg_id_t i;
                  ddp_err_t e;
                } ddp_ind_t;
        

ddp_err_t

ddp\u错误

indicates an error while receiving a tagged message, typically `offset' out of bounds, or `stag' is not registered to the socket.

指示接收带标记消息时出错,通常“偏移量”超出范围,或者“stag”未注册到套接字。

msizes_t

微星

The maximum untagged and tagged messages that fit in a single transport message:

适合单个传输邮件的最大未标记和已标记邮件数:

                typedef struct {
                  msize_t max_untagged;
                  msize_t max_tagged;
                } msizes_t;
        
                typedef struct {
                  msize_t max_untagged;
                  msize_t max_tagged;
                } msizes_t;
        

ddp_send(socket_t s, message_t m)

ddp发送(套接字、消息)

send an untagged message.

发送未标记的消息。

ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d, ddp_notify_t n)

ddp发送ddp(套接字、消息、ddp地址、ddp通知)

send a tagged message to remote buffer address d.

将带标记的消息发送到远程缓冲区地址d。

ddp_post_recv(socket_t s, bdesc_t b)

ddp_post_recv(插座、bdesc_t b)

post a registered buffer to accept a single received untagged message. Each buffer is returned to the caller in a ddp_recv() untagged message reception indication, in the order in which it was posted. The same buffer may be enabled on multiple sockets; receipt of an untagged message into the buffer from any of these sockets unposts the buffer from all sockets.

发布已注册的缓冲区以接受单个已接收的未标记消息。每个缓冲区以ddp_recv()未标记消息接收指示的形式返回给调用者,其顺序与发布的顺序相同。可以在多个套接字上启用相同的缓冲区;从这些套接字中的任何一个将未标记的消息接收到缓冲区中,将从所有套接字中取消缓冲区。

ddp_recv(socket_t s)

ddp_recv(插座)

get the next received untagged message, tagged message reception indication, or tagged message error.

获取下一条接收到的未标记消息、标记消息接收指示或标记消息错误。

ddp_register(socket_t s, ddp_buffer_t b)

ddp_寄存器(套接字、ddp_缓冲区)

register a buffer for DDP on a socket. The same buffer may be registered multiple times on the same or different sockets. The same buffer registered on different sockets may result in a common registration. Different buffers may also refer to portions of the same underlying addressable object (buffer aliasing).

在套接字上注册DDP缓冲区。同一缓冲区可以在相同或不同的套接字上注册多次。在不同套接字上注册的相同缓冲区可能会导致公共注册。不同的缓冲区也可能引用同一底层可寻址对象的部分(缓冲区别名)。

ddp_deregister(bhand_t bh)

ddp_注销登记员(bhand_t bh)

remove a registration from a buffer.

从缓冲区中删除注册。

ddp_max_msizes(socket_t s)

ddp_max_msizes(插座)

get the current maximum untagged and tagged message sizes that will fit in a single transport message.

获取适合单个传输邮件的当前最大未标记和标记邮件大小。

2.1.3. Transport Characteristics in DDP
2.1.3. DDP中的传输特性

Certain characteristics of the transport on which DDP is mapped determine the nature of the service provided to client protocols. Fundamentally, the characteristics of the transport will not be changed by the presence of DDP. The choice of transport is therefore driven not by DDP, but by the requirements of the Upper Layer, and employing the DDP service.

DDP映射到的传输的某些特征决定了提供给客户端协议的服务的性质。从根本上说,DDP的存在不会改变运输的特点。因此,传输的选择不是由DDP驱动的,而是由上层的需求和使用DDP服务驱动的。

Specifically, transports are:

具体而言,运输是:

o reliable or unreliable,

o 可靠或不可靠,

o ordered or unordered,

o 有序或无序,

o single source or multisource,

o 单源或多源,

o single destination or multidestination (multicast or anycast).

o 单目的地或多目的地(多播或选播)。

Some transports support several combinations of these characteristics. For example, SCTP [SCTP] is reliable, single source, single destination (point-to-point) and supports both ordered and unordered modes.

一些传输支持这些特性的多种组合。例如,SCTP[SCTP]是可靠的、单源的、单目的地的(点对点),并且支持有序和无序模式。

DDP messages carried by transport are framed for processing by the receiver, and may be further protected for integrity or privacy in accordance with the transport capabilities. DDP does not provide such functions.

传输所承载的DDP消息被帧化以供接收器处理,并且可以根据传输能力进一步保护完整性或隐私。DDP不提供此类功能。

In general, transport characteristics equally affect transport and DDP message delivery. However, there are several issues specific to DDP messages.

一般来说,传输特性同样影响传输和DDP消息传递。但是,DDP消息有几个特定的问题。

A key component of DDP is how the following operations on the receiving side are ordered among themselves, and how they relate to corresponding operations on the sending side:

DDP的一个关键组成部分是接收端的以下操作如何在它们之间排序,以及它们如何与发送端的相应操作相关:

o set()s,

o set()s,

o untagged message reception indications, and

o 未标记的信息接收指示,以及

o tagged message reception indications.

o 标记消息接收指示。

These relationships depend upon the characteristics of the underlying transport in a way that is defined by the DDP protocol. For example, if the transport is unreliable and unordered, the DDP protocol might specify that the client protocol is subject to the consequences of transport messages being lost or duplicated, rather than requiring that different characteristics be presented to the client protocol.

这些关系以DDP协议定义的方式取决于底层传输的特性。例如,如果传输不可靠且无序,则DDP协议可以指定客户端协议受到传输消息丢失或复制的后果的影响,而不是要求向客户端协议呈现不同的特征。

Buffer access must be implemented consistently across endpoint IP addresses on transports allowing multiple IP addresses per endpoint, for example, SCTP. In particular, the Steering Tag must be consistently scoped and must address the same buffer across all IP address associations belonging to the endpoint. Additionally, operation ordering relationships across IP addresses within an association (set(), get(), etc.) depend on the underlying transport. If the above consistency relationships cannot be maintained by a transport endpoint, then the endpoint is unsuitable for a DDP connection.

必须在传输上跨端点IP地址一致地实现缓冲区访问,允许每个端点有多个IP地址,例如SCTP。特别是,转向标记的作用域必须一致,并且必须跨属于端点的所有IP地址关联寻址相同的缓冲区。此外,关联(set()、get()等)中IP地址之间的操作顺序关系取决于底层传输。如果传输端点无法维护上述一致性关系,则该端点不适合DDP连接。

Multidestination data delivery is a transport characteristic that may require specific consideration in a DDP protocol. As mentioned above, the basic DDP model assumes that buffer address values returned by ddp_register() are opaque to the client protocol, and can

多目的地数据传输是DDP协议中可能需要特别考虑的传输特性。如上所述,基本DDP模型假设DDP_register()返回的缓冲区地址值对客户端协议是不透明的,并且可以

be implementation dependent. The most natural way to map DDP to a multidestination transport is to require that all receivers produce the same buffer address when registering a multidestination destination buffer. Restriction of the DDP model to accommodate multiple destinations involves engineering tradeoffs comparable to those of providing non-DDP multidestination transport capability.

必须依赖于实现。将DDP映射到多目的地传输的最自然的方法是要求所有接收器在注册多目的地缓冲区时产生相同的缓冲区地址。限制DDP模型以容纳多个目的地涉及到与提供非DDP多目的地运输能力的工程权衡。

A registered buffer is identified within DDP by its stag_t, which in turn is associated with a socket. Therefore, this registration grants a capability to the DDP peer, and the socket (using the underlying properties of its chosen transport and possible security) identifies the peer and authenticates the stag_t.

注册的缓冲区通过其stag_t在DDP中标识,而stag_t又与套接字相关联。因此,此注册向DDP对等方授予一种能力,套接字(使用其所选传输的底层属性和可能的安全性)识别对等方并对stag\t进行身份验证。

The same buffer may be enabled by ddp_post_recv() on multiple sockets. In this case any ddp_recv() untagged message reception indication may be provided on a different socket from that on which the buffer was posted. Such indications are not ordered among multiple DDP sockets.

ddp_post_recv()可以在多个套接字上启用相同的缓冲区。在这种情况下,任何ddp_recv()未标记的消息接收指示都可以在不同的套接字上提供,而不是在其上发布缓冲区。此类指示不在多个DDP插座之间排序。

When multiple sockets reference an untagged message reception buffer, local interfaces are responsible for managing the mechanisms of allocating posted buffers to received untagged messages, the handling of received untagged messages when no buffer is available, and of resource management among multiple sockets. Where underprovisioning of buffers on multiple sockets is allowed, mechanisms should be provided to manage buffer consumption on a per-socket or group of related sockets basis.

当多个套接字引用未标记的消息接收缓冲区时,本地接口负责管理将已发布的缓冲区分配给已接收的未标记消息的机制、在没有可用缓冲区时处理已接收的未标记消息的机制以及多个套接字之间的资源管理机制。如果允许在多个套接字上提供不足的缓冲区,则应提供机制来管理每个套接字或相关套接字组的缓冲区消耗。

Architecturally, therefore, DDP is a flexible and general paradigm that may be applied to any variety of transports. Implementations of DDP may, however, adapt themselves to these differences in ways appropriate to each transport. In all cases, the layering of DDP must continue to express the transport's underlying characteristics.

因此,在体系结构上,DDP是一种灵活且通用的范例,可应用于任何种类的传输。然而,DDP的实现可能会以适合于每种传输的方式适应这些差异。在所有情况下,DDP的分层必须继续表达运输的基本特征。

2.2. Remote Direct Memory Access (RDMA) Protocol Architecture
2.2. 远程直接内存访问(RDMA)协议体系结构

Remote Direct Memory Access (RDMA) extends the capabilities of DDP with two primary functions.

远程直接内存访问(RDMA)通过两个主要功能扩展了DDP的功能。

First, it adds the ability to read from buffers registered to a socket (RDMA Read). This allows a client protocol to perform arbitrary, bidirectional data movement without involving the remote client. When RDMA is implemented in hardware, arbitrary data movement can be performed without involving the remote host CPU at all.

首先,它增加了从注册到套接字的缓冲区读取的能力(RDMA读取)。这允许客户端协议在不涉及远程客户端的情况下执行任意、双向的数据移动。在硬件中实现RDMA时,可以执行任意数据移动,而无需涉及远程主机CPU。

In addition, RDMA specifies a transport-independent untagged message service (Send) with characteristics that are both very efficient to implement in hardware, and convenient for client protocols.

此外,RDMA还指定了一个独立于传输的未标记消息服务(Send),该服务具有在硬件中实现非常高效和方便客户端协议的特点。

The RDMA architecture is patterned after the traditional model for device programming, where the client requests an operation using Send-like actions (programmed I/O), the server performs the necessary data transfers for the operation (DMA reads and writes), and notifies the client of completion. The programmed I/O+DMA model efficiently supports a high degree of concurrency and flexibility for both the client and server, even when operations have a wide range of intrinsic latencies.

RDMA体系结构仿效传统的设备编程模式,其中客户端使用类似发送的操作(编程I/O)请求操作,服务器执行操作所需的数据传输(DMA读写),并通知客户端完成。编程I/O+DMA模型有效地支持客户机和服务器的高度并发性和灵活性,即使操作具有广泛的内在延迟。

RDMA is layered as a client protocol on top of DDP:

RDMA作为DDP之上的客户端协议分层:

                      Client Protocol
                           |  ^
                     Sends |  | Send reception indications
        RDMA Read Requests |  | RDMA Read Completion indications
               RDMA Writes |  | RDMA Write Completion indications
                           v  |
                           RDMA
                           |  ^
         untagged messages |  | untagged message delivery
           tagged messages |  | tagged message delivery
                           v  |
                           DDP+---> data placement
                            ^
                            | transport messages
                            v
                          . . .
        
                      Client Protocol
                           |  ^
                     Sends |  | Send reception indications
        RDMA Read Requests |  | RDMA Read Completion indications
               RDMA Writes |  | RDMA Write Completion indications
                           v  |
                           RDMA
                           |  ^
         untagged messages |  | untagged message delivery
           tagged messages |  | tagged message delivery
                           v  |
                           DDP+---> data placement
                            ^
                            | transport messages
                            v
                          . . .
        

In addition to in-line data flow, read (get()) and update (set()) operations are performed on buffers registered with RDMA as a result of RDMA Read Requests and RDMA Writes, respectively.

除了在线数据流之外,读取(get())和更新(set())操作分别在RDMA注册的缓冲区上执行,这是RDMA读取请求和RDMA写入的结果。

An RDMA `buffer' extends a DDP buffer with a get() operation that retrieves the value of the octet at address `a':

RDMA“buffer”使用get()操作扩展DDP缓冲区,该操作检索地址“a”处的八位字节值:

           typedef struct {
             const address_t start;
             const address_t end;
             void            set(address_t a, data_t v);
             data_t          get(address_t a);
           } rdma_buffer_t;
        
           typedef struct {
             const address_t start;
             const address_t end;
             void            set(address_t a, data_t v);
             data_t          get(address_t a);
           } rdma_buffer_t;
        
2.2.1. RDMA Operations
2.2.1. RDMA操作

The RDMA layer provides:

RDMA层提供:

        void        rdma_send(socket_t s, message_t m);
        void        rdma_write(socket_t s, message_t m, ddp_addr_t d,
                               rdma_notify_t n);
        void        rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d);
        void        rdma_post_recv(socket_t s, bdesc_t b);
        rdma_ind_t  rdma_recv(socket_t s);
        bdesc_t     rdma_register(socket_t s, rdma_buffer_t b,
                               bmode_t mode);
        void        rdma_deregister(bhand_t bh);
        msizes_t    rdma_max_msizes(socket_t s);
        
        void        rdma_send(socket_t s, message_t m);
        void        rdma_write(socket_t s, message_t m, ddp_addr_t d,
                               rdma_notify_t n);
        void        rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d);
        void        rdma_post_recv(socket_t s, bdesc_t b);
        rdma_ind_t  rdma_recv(socket_t s);
        bdesc_t     rdma_register(socket_t s, rdma_buffer_t b,
                               bmode_t mode);
        void        rdma_deregister(bhand_t bh);
        msizes_t    rdma_max_msizes(socket_t s);
        

Although, for clarity, these data transfer interfaces are synchronous, rdma_read() and possibly rdma_send() (in the presence of Send flow control) can require an arbitrary amount of time to complete. To express the full concurrency and interleaving of RDMA data transfer, these interfaces should also be reentrant. For example, a client protocol may perform an rdma_send(), while an rdma_read() operation is in progress.

尽管为了清楚起见,这些数据传输接口是同步的,但rdma_read()和可能的rdma_send()(在存在发送流控制的情况下)可能需要任意时间才能完成。为了表示RDMA数据传输的完全并发和交错,这些接口也应该是可重入的。例如,当rdma_read()操作正在进行时,客户端协议可能会执行rdma_send()。

rdma_notify_t

通知

RDMA Write notification information, used to signal that the message represents the final fragment of a multi-segmented RDMA message:

RDMA写入通知信息,用于表示消息表示多段RDMA消息的最终片段:

                typedef struct {
                  boolean_t notify;
                  rdma_write_id_t i;
                } rdma_notify_t;
        
                typedef struct {
                  boolean_t notify;
                  rdma_write_id_t i;
                } rdma_notify_t;
        

identical in function to ddp_notify_t, except that the type rdma_write_id_t may not be equivalent to ddp_msg_id_t.

功能与ddp_notify_t相同,只是rdma_write_id_t类型可能与ddp_msg_id_t不同。

rdma_write_id_t (scalar)

rdma_write_id_t(标量)

an RDMA Write identifier.

RDMA写入标识符。

rdma_ind_t

rdma____t

a Send message, or an RDMA error:

发送消息或RDMA错误:

                typedef union {
                  recv_message_t m;
                  rdma_err_t e;
                } rdma_ind_t;
        
                typedef union {
                  recv_message_t m;
                  rdma_err_t e;
                } rdma_ind_t;
        

rdma_err_t

rdma___t

an RDMA protocol error indication. RDMA errors include buffer addressing errors corresponding to ddp_err_ts, and buffer protection violations (e.g., RDMA Writing a buffer only registered for reading).

RDMA协议错误指示。RDMA错误包括与ddp错误相对应的缓冲区寻址错误和缓冲区保护冲突(例如,RDMA写入仅注册用于读取的缓冲区)。

bmode_t

b模式

buffer registration mode (permissions). Any combination of permitting RDMA Read (BMODE_READ) and RDMA Write (BMODE_WRITE) operations.

缓冲区注册模式(权限)。允许RDMA读取(BMODE_读取)和RDMA写入(BMODE_写入)操作的任意组合。

rdma_send(socket_t s, message_t m)

rdma发送(套接字、消息)

send a message, delivering it to the next untagged RDMA buffer at the remote peer.

发送一条消息,将其传递到远程对等方的下一个未标记RDMA缓冲区。

rdma_write(socket_t s, message_t m, ddp_addr_t d, rdma_notify_t n)

rdma_写入(套接字、消息、ddp地址、rdma_通知)

RDMA Write to remote buffer address d.

RDMA写入远程缓冲区地址d。

rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)

rdma读取(插座、ddp地址、长度、ddp地址)

RDMA Read l octets from remote buffer address s to local buffer address d.

RDMA从远程缓冲区地址s读取l个八位字节到本地缓冲区地址d。

rdma_post_recv(socket_t s, bdesc_t b)

rdma_post_recv(插座、bdesc_t b)

post a registered buffer to accept a single Send message, to be filled and returned in-order to a subsequent caller of rdma_recv(). As with DDP, buffers may be enabled on multiple sockets, in which case ordering guarantees are relaxed. Also as with DDP, local interfaces must manage the mechanisms of allocation and management of buffers posted to multiple sockets.

post一个已注册的缓冲区以接受单个发送消息,该消息将被填充并返回给rdma_recv()的后续调用方。与DDP一样,可以在多个套接字上启用缓冲区,在这种情况下,订购保证将放宽。与DDP一样,本地接口必须管理分配和管理发送到多个套接字的缓冲区的机制。

rdma_recv(socket_t s);

rdma_recv(插座);

get the next received Send message, RDMA Write completion identifier, or RDMA error.

获取下一个接收到的发送消息、RDMA写入完成标识符或RDMA错误。

rdma_register(socket_t s, rdma_buffer_t b, bmode_t mode)

rdma_寄存器(套接字、rdma_缓冲区、b模式)

register a buffer for RDMA on a socket (for read access, write access or both). As with DDP, the same buffer may be registered multiple times on the same or different sockets, and different buffers may refer to portions of the same underlying addressable object.

在套接字上为RDMA注册缓冲区(用于读访问、写访问或两者)。与DDP一样,相同的缓冲区可以在相同或不同的套接字上多次注册,不同的缓冲区可以引用相同底层可寻址对象的部分。

rdma_deregister(bhand_t bh)

rdma_注销登记员(bhand_t bh)

remove a registration from a buffer.

从缓冲区中删除注册。

rdma_max_msizes(socket_t s)

rdma_max_msizes(插座)

get the current maximum Send (max_untagged) and RDMA Read or Write (max_tagged) operations that will fit in a single transport message. The values returned by rdma_max_msizes() are closely related to the values returned by ddp_max_msizes(), but may not be equal.

获取当前最大发送(最大未标记)和RDMA读取或写入(最大已标记)操作,这些操作将适合单个传输消息。rdma_max_msizes()返回的值与ddp_max_msizes()返回的值密切相关,但可能不相等。

2.2.2. Transport Characteristics in RDMA
2.2.2. RDMA中的传输特性

As with DDP, RDMA can be used on transports with a variety of different characteristics that manifest themselves directly in the service provided by RDMA. Also, as with DDP, the fundamental characteristics of the transport will not be changed by the presence of RDMA.

与DDP一样,RDMA可以用于具有各种不同特性的传输,这些特性直接体现在RDMA提供的服务中。此外,与DDP一样,RDMA的存在不会改变传输的基本特性。

Like DDP, an RDMA protocol must specify how:

与DDP一样,RDMA协议必须指定如何:

o set()s,

o set()s,

o get()s,

o 得到()s,

o Send messages, and

o 发送消息,以及

o RDMA Read completions

o RDMA读取完成

are ordered among themselves and how they relate to corresponding operations on the remote peer(s). These relationships are likely to be a function of the underlying transport characteristics.

它们之间的顺序以及它们与远程对等上的相应操作的关系。这些关系可能是潜在运输特征的函数。

There are some additional characteristics of RDMA that may translate poorly to unreliable or multipoint transports due to attendant complexities in managing endpoint state:

由于管理端点状态的复杂性,RDMA的一些附加特性可能很难转化为不可靠或多点传输:

o Send flow control

o 发送流控制

o RDMA Read

o RDMA读取

These difficulties can be overcome by placing restrictions on the service provided by RDMA. However, many RDMA clients, especially those that separate data transfer and application logic concerns, are likely to depend upon capabilities only provided by RDMA on a point-to-point, reliable transport. In other words, many potential Upper Layers, which might avail themselves of RDMA services, are naturally already biased toward these transport classes.

这些困难可以通过限制RDMA提供的服务来克服。然而,许多RDMA客户机,特别是那些分离数据传输和应用程序逻辑关注点的客户机,可能只依赖RDMA在点对点可靠传输上提供的功能。换句话说,许多可能利用RDMA服务的潜在上层自然已经偏向于这些传输类。

3. Security Considerations
3. 安全考虑

Fundamentally, the DDP and RDMA protocols themselves should not introduce additional vulnerabilities. They are intermediate protocols and so should not perform or require functions such as authorization, which are the domain of Upper Layers. However, the DDP and RDMA protocols should allow mapping by strict Upper Layers that are not permissive of new vulnerabilities; DDP and RDMAP implementations should be prohibited from `cutting corners' that create new vulnerabilities. Implementations must ensure that only `supplied' resources (i.e., buffers) can be manipulated by DDP or RDMAP messages.

从根本上说,DDP和RDMA协议本身不应引入额外的漏洞。它们是中间协议,因此不应执行或需要授权等功能,这是上层的领域。但是,DDP和RDMA协议应允许严格的上层映射,不允许出现新的漏洞;应禁止DDP和RDMAP实现“偷工减料”,以免产生新的漏洞。实现必须确保DDP或RDMAP消息只能操作“提供的”资源(即缓冲区)。

System integrity must be maintained in any RDMA solution. Mechanisms must be specified to prevent RDMA or DDP operations from impairing system integrity. For example, threats can include potential buffer reuse or buffer overflow, and are not merely a security issue. Even trusted peers must not be allowed to damage local integrity. Any DDP and RDMA protocol must address the issue of giving end-systems and applications the capabilities to offer protection from such compromises.

任何RDMA解决方案都必须保持系统完整性。必须指定防止RDMA或DDP操作损害系统完整性的机制。例如,威胁可能包括潜在的缓冲区重用或缓冲区溢出,而不仅仅是安全问题。即使是受信任的对等方也不能破坏本地完整性。任何DDP和RDMA协议都必须解决这样一个问题,即为终端系统和应用程序提供保护,使其免受此类损害。

Because a Steering Tag exports access to a buffer, one critical aspect of security is the scope of this access. It must be possible to individually control specific attributes of the access provided by a Steering Tag on the endpoint (socket) on which it was registered, including remote read access, remote write access, and others that might be identified. DDP and RDMA specifications must provide both implementation requirements relevant to this issue, and guidelines to assist implementors in making the appropriate design decisions.

由于转向标记将访问导出到缓冲区,因此安全性的一个关键方面是此访问的范围。必须能够单独控制在其上注册的端点(套接字)上的指导标记提供的访问的特定属性,包括远程读访问、远程写访问和其他可能识别的访问。DDP和RDMA规范必须提供与此问题相关的实施要求,以及帮助实施者做出适当设计决策的指南。

For example, it must not be possible for DDP to enable evasion of buffer consistency checks at the recipient. The DDP and RDMA specifications must allow the recipient to rely on its consistent buffer contents by explicitly controlling peer access to buffer regions at appropriate times.

例如,DDP不能在收件人处规避缓冲区一致性检查。DDP和RDMA规范必须允许接收方通过在适当的时间显式控制对等方对缓冲区的访问来依赖其一致的缓冲区内容。

The use of DDP and RDMA on a transport connection may interact with any security mechanism, and vice-versa. For example, if the security mechanism is implemented above the transport layer, the DDP and RDMA headers may not be protected. Therefore, such a layering may be inappropriate, depending on requirements.

在传输连接上使用DDP和RDMA可能与任何安全机制交互,反之亦然。例如,如果安全机制是在传输层之上实现的,则DDP和RDMA头可能不受保护。因此,根据需求,这种分层可能不合适。

3.1. Security Services
3.1. 安全服务

The following end-to-end security services protect DDP and RDMAP operation streams:

以下端到端安全服务保护DDP和RDMAP操作流:

o Authentication of the data source, to protect against peer impersonation, stream hijacking, and man-in-the-middle attacks exploiting capabilities offered by the RDMA implementation.

o 对数据源进行身份验证,以防止利用RDMA实现提供的功能进行对等模拟、流劫持和中间人攻击。

Peer connections that do not pass authentication and authorization checks must not be permitted to begin processing in RDMA mode with an inappropriate endpoint. Once associated, peer accesses to buffer regions must be authenticated and made subject to authorization checks in the context of the association and endpoint (socket) on which they are to be performed, prior to any transfer operation or data being accessed. The RDMA protocols must ensure that these region protections be under strict application control.

不允许未通过身份验证和授权检查的对等连接在RDMA模式下使用不适当的端点开始处理。一旦关联,对缓冲区的对等访问必须经过身份验证,并在访问任何传输操作或数据之前,在关联和端点(套接字)的上下文中进行授权检查。RDMA协议必须确保这些区域保护受到严格的应用程序控制。

o Integrity, to protect against modification of the control content and buffer content.

o 完整性,以防止控件内容和缓冲区内容的修改。

While integrity is of concern to any transport, it is important for the DDP and RDMAP protocols that the RDMA control information carried in each operation be protected, in order to direct the payloads appropriately.

虽然完整性对任何传输都很重要,但对于DDP和RDMAP协议来说,保护每个操作中携带的RDMA控制信息非常重要,以便正确引导有效负载。

o Sequencing, to protect against replay attacks (a special case of the above modifications).

o 排序,以防止重播攻击(上述修改的特例)。

o Confidentiality, to protect the stream from eavesdropping.

o 机密性,以保护流不被窃听。

IPsec, operating to secure the connection on a packet-by-packet basis, is a natural fit to securing RDMA placement, which operates in conjunction with transport. Because RDMA enables an implementation to avoid buffering, it is preferable to perform all applicable

IPsec以分组为基础保护连接,它自然适合于保护RDMA位置,RDMA位置与传输一起工作。因为RDMA使实现能够避免缓冲,所以最好执行所有适用的操作

security protection prior to processing of each segment by the transport and RDMA layers. Such a layering enables the most efficient secure RDMA implementation.

传输层和RDMA层处理每个段之前的安全保护。这样的分层实现了最高效的安全RDMA实现。

The TLS record protocol, on the other hand, is layered on top of reliable transports and cannot provide such security assurance until an entire record is available, which may require the buffering and/or assembly of several distinct messages prior to TLS processing. This defers RDMA processing and introduces overheads that RDMA is designed to avoid. In addition, TLS length restrictions on records themselves impose additional buffering and processing for long operations that must span multiple records. TLS therefore is viewed as potentially a less natural fit for protecting the RDMA protocols.

另一方面,TLS记录协议是在可靠传输之上分层的,在整个记录可用之前无法提供此类安全保证,这可能需要在TLS处理之前缓冲和/或组装几个不同的消息。这延迟了RDMA处理,并引入了RDMA旨在避免的开销。此外,对记录本身的TLS长度限制对必须跨越多个记录的长操作施加了额外的缓冲和处理。因此,TLS被视为可能不太适合保护RDMA协议。

Any DDP and RDMAP specification must provide the means to satisfy the above security service requirements.

任何DDP和RDMAP规范都必须提供满足上述安全服务要求的方法。

IPsec is sufficient to provide the required security services to the DDP and RDMAP protocols, while enabling efficient implementations.

IPsec足以为DDP和RDMAP协议提供所需的安全服务,同时支持高效的实现。

3.2. Error Considerations
3.2. 错误注意事项

Resource issues leading to denial-of-service attacks, overwrites and other concurrent operations, the ordering of completions as required by the RDMA protocol, and the granularity of transfer are all within the required scope of any security analysis of RDMA and DDP.

导致拒绝服务攻击、覆盖和其他并发操作的资源问题、RDMA协议要求的完成顺序以及传输粒度都在RDMA和DDP安全分析的要求范围内。

The RDMA operations require checking of what is essentially user information, explicitly including addressing information and operation type (read or write), and implicitly including protection and attributes. The semantics associated with each class of error resulting from possible failure of such checks must be clearly defined, and the expected action to be taken by the protocols in each case must be specified.

RDMA操作需要检查本质上是用户信息的内容,显式地包括寻址信息和操作类型(读或写),隐式地包括保护和属性。必须明确定义与此类检查可能失败导致的每类错误相关的语义,并且必须指定协议在每种情况下采取的预期操作。

In some cases, this will result in a catastrophic error on the RDMA association; however, in others, a local or remote error may be signalled. Certain of these errors may require consideration of abstract local semantics. The result of the error on the RDMA association must be carefully specified so as to provide useful behavior, while not constraining the implementation.

在某些情况下,这将导致RDMA关联上的灾难性错误;然而,在其他情况下,可能会发出本地或远程错误信号。某些错误可能需要考虑抽象的局部语义。必须仔细指定RDMA关联的错误结果,以便在不限制实现的情况下提供有用的行为。

4. Acknowledgements
4. 致谢

The authors wish to acknowledge the valuable contributions of Caitlin Bestler, David Black, Jeff Mogul, and Allyn Romanow.

作者希望感谢凯特琳·贝斯勒、大卫·布莱克、杰夫·莫格尔和艾琳·罗曼诺的宝贵贡献。

5. Informative References
5. 资料性引用

[FCVI] ANSI Technical Committee T11, "Fibre Channel Standard Virtual Interface Architecture Mapping", ANSI/NCITS 357- 2001, March 2001, available from http://www.t11.org/t11/stat.nsf/fcproj.

[FCVI]ANSI技术委员会T11,“光纤通道标准虚拟接口体系结构映射”,ANSI/NCITS 357-2001,2001年3月,可从http://www.t11.org/t11/stat.nsf/fcproj.

[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification Volumes 1 and 2", Release 1.1, November 2002, available from http://www.infinibandta.org/specs.

[IB]InfiniBand贸易协会,“InfiniBand体系结构规范第1卷和第2卷”,1.12002年11月发布,可从http://www.infinibandta.org/specs.

[MYR] VMEbus International Trade Association, "Myrinet on VME Protocol Specification", ANSI/VITA 26-1998, August 1998, available from http://www.myri.com/open-specs.

[MYR]VMEbus国际贸易协会,“关于VME协议规范的Myrinet”,ANSI/VITA 26-1998,1998年8月,可从http://www.myri.com/open-specs.

[ROM] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005.

[ROM]Romanow,A.,Mogul,J.,Talpey,T.,和S.Bailey,“IP上的远程直接内存访问(RDMA)问题陈述”,RFC 42972005年12月。

[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.

[SCTP]Stewart,R.,Xie,Q.,Morneault,K.,Sharp,C.,Schwarzbauer,H.,Taylor,T.,Rytina,I.,Kalla,M.,Zhang,L.,和V.Paxson,“流控制传输协议”,RFC 29602000年10月。

[SDP] InfiniBand Trade Association, "Sockets Direct Protocol v1.0", Annex A of InfiniBand Architecture Specification Volume 1, Release 1.1, November 2002, available from http://www.infinibandta.org/specs.

[SDP]InfiniBand贸易协会,“Sockets Direct Protocol v1.0”,InfiniBand体系结构规范第1卷附件A,1.1版,2002年11月,可从http://www.infinibandta.org/specs.

[SRVNET] R. Horst, "TNet: A reliable system area network", IEEE Micro, pp. 37-45, February 1995.

[SRVNET]R.Horst,“TNet:可靠的系统区域网络”,IEEE Micro,第37-45页,1995年2月。

[VI] D. Cameron and G. Regnier, "The Virtual Interface Architecture", ISBN 0971288704, Intel Press, April 2002, more info at http://www.intel.com/intelpress/via/.

[六] D.Cameron和G.Regnier,“虚拟接口体系结构”,ISBN 0971288704,英特尔出版社,2002年4月,更多信息请访问http://www.intel.com/intelpress/via/.

Authors' Addresses

作者地址

Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA USA

Stephen Bailey Sandburst Corporation美国马萨诸塞州安多弗联邦街600号01810

   Phone: +1 978 689 1614
   EMail: steph@sandburst.com
        
   Phone: +1 978 689 1614
   EMail: steph@sandburst.com
        

Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA

美国马萨诸塞州沃尔瑟姆特拉佩罗路1601号汤姆·塔尔佩网络设备公司02451

   Phone: +1 781 768 5329
   EMail: thomas.talpey@netapp.com
        
   Phone: +1 781 768 5329
   EMail: thomas.talpey@netapp.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(2005年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。