From: The IESG <firstname.lastname@example.org>
To: IETF-Announce <email@example.com>
Cc: RFC Editor <firstname.lastname@example.org>,
storm mailing list <email@example.com>,
storm chair <firstname.lastname@example.org>
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:
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.
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.
Document Shepherd: David L. Black (email@example.com)
Responsible Area Director: David Harrington (firstname.lastname@example.org)
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."