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