[storm] Protocol Action: 'Enhanced RDMA Connection Establishment' to Proposed Standard (draft-ietf-storm-mpa-peer-connect-09.txt)

The IESG <iesg-secretary@ietf.org> Fri, 03 February 2012 18:06 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292421F8591; Fri, 3 Feb 2012 10:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NijMmfk1AnRJ; Fri, 3 Feb 2012 10:06:39 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10C521F858E; Fri, 3 Feb 2012 10:06:39 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20120203180639.6647.5449.idtracker@ietfa.amsl.com>
Date: Fri, 03 Feb 2012 10:06:39 -0800
Cc: storm mailing list <storm@ietf.org>, storm chair <storm-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [storm] Protocol Action: 'Enhanced RDMA Connection Establishment' to Proposed Standard (draft-ietf-storm-mpa-peer-connect-09.txt)
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 18:06:40 -0000

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