Enhanced Remote Direct Memory Access (RDMA) Connection Establishment
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, storm mailing list <firstname.lastname@example.org>, storm chair <email@example.com> Subject: Protocol Action: 'Enhanced RDMA Connection Establishment' to Proposed Standard (draft-ietf-storm-mpa-peer-connect-09.txt) The IESG has approved the following document: - 'Enhanced RDMA Connection Establishment' (draft-ietf-storm-mpa-peer-connect-09.txt) as a Proposed Standard This document is the product of the STORage Maintenance Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-storm-mpa-peer-connect/
Technical Summary This document extends iWARP (rddp) RDMA connection establishment with two functions that apply to the adaptation layer between RDMA functionality and the transport protocol. The first extension broadens MPA (adaptation to TCP) to enable connection establishment without initial data to send in support of applications structured as a collection of peers. The second extension improves connection setup for both MPA/TCP and the SCTP adaptation by adding support for standardized exchange of resource availability (queue depth) information. Working Group Summary This document makes small additions to existing protocols. There has been clear WG recognition that this functionality is needed to match the usage of these protocols by an important class of applications, and no significant WG dissent from the design in this document. Document Quality There are multiple existing implementations of the iWARP (rddp) RDMA protocols that have plans to add the functionality specified in this document. Hemal Shah reviewed the near-final version of this draft and found some important corrections that needed to be made. Personnel Document Shepherd: David L. Black (firstname.lastname@example.org) Responsible Area Director: David Harrington (email@example.com) RFC Editor Note please add this text at the end of section 1.1 "RTR indications are optional, and are carried by existing RDMA message types, specifically a zero length FULPDU Send message, a zero length RDMA Read message or a zero length RDMA write message. The presence vs. absence of the RTR indication and the type of RDMA message to use are negotiated by control flags in Enhanced RDMA Connection Establishment Data specified by this document (see Section 9). RDMA implementations are often tightly integrated with application libraries and hardware, hence the flexibility to use more than one type of RDMA message enables implementations to choose message types that are less disruptive to the implementation structure. When an RTR indication is used, and MPA connection setup negotiation indicates support for multiple RDMA message types as RTR indications by both the initiator and responder, the initiator selects one of the supported RDMA message types as the RTR indication at the initiator’s sole discretion."