Skip to main content

Enhanced Remote Direct Memory Access (RDMA) Connection Establishment
draft-ietf-storm-mpa-peer-connect-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    storm mailing list <storm@ietf.org>,
    storm chair <storm-chairs@tools.ietf.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:
http://datatracker.ietf.org/doc/draft-ietf-storm-mpa-peer-connect/


Ballot Text

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 (david.black@emc.com) 
   Responsible Area Director: David Harrington (ietfdbh@comcast.net)

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."




RFC Editor Note