Storage Maintenance (storm) Working Group                    Michael Ko
Internet Draft                                          Huawei Symantec
Intended status: Proposed Standard                       David L. Black
Expires: June 2012                                                  EMC
                                                      December 21, 2011



                         IANA Registries for the RDDP
                   (Remote Direct Data Placement) Protocols
                   draft-ietf-storm-rddp-registries-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 21, 2012.

Abstract

   The original RFCs that specified the RDDP protocol suite did not
   create IANA registries for RDDP error codes, operation codes and
   function codes.  Extensions to the RDDP protocols now require
   these registries to be created.  This memo creates the RDDP
   registries, populates them with values defined in the original
   RDDP RFCs, and provides guidance to IANA for future assignment
   of code points within these registries.






Ko and Black              Expires June 2012                  [Page 1]


Internet-Draft       IANA Considerations for RDDP        October 2011

   Table of Contents

   1.   Introduction ................................................2
   1.1  Conventions .................................................2
   2.   Security Considerations .....................................2
   3.   IANA Considerations .........................................2
   3.1  RDMAP Errors ................................................3
   3.2  DDP Errors ..................................................5
   3.3  MPA Errors ..................................................7
   3.4  RDMAP Message Operation Codes ...............................8
   3.5  SCTP Function Codes for DDP Stream Session Control ..........9
   4.   Normative References .......................................10
   5.   Informative References .....................................10
   6.   Acknowledgments ............................................10


1. Introduction

   The original RFCs that specified the RDDP protocol suite
   [RFC5040][RFC5041][RFC5043][RFC5044] did not create IANA registries.
   Extensions to the RDDP protocols [MPA-PEER][RDMAP-EXT] now requires
   creation and use of IANA registries.  This memo creates the RDDP-
   related IANA registries, specifies their initial contents based on
   the values defined in the original RDDP RFCs, and provides guidance
   to IANA for future assignments from these registries.

1.1  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2. Security Considerations

   Since this document is only concerned with creation and IANA
   management of RDDP registries, it raises no new security issues.

3. IANA Considerations

   This memo creates the following RDDP registries for IANA to manage:

     o RDMAP Errors (Section 3.1)
     o DDP Errors (Section 3.2)
     o MPA Errors (Section 3.3)
     o RDMAP Message Operation Codes (Section 3.4)
     o SCTP Function Codes for DDP Stream Session Control (Section 3.5)



Ko and Black              Expires June 2012                  [Page 2]


Internet-Draft       IANA Considerations for RDDP        October 2011

   Each of the following sections specifies a registry, its initial
   contents and the administration policy in more detail.

3.1  RDMAP Errors

   Name of the registry: "RDMAP Errors"

   Namespace details: An RDMAP (Remote Direct Memory Access Protocol)
   error is a 16 bit field divided into three subfields [RFC5040]:
      o 4-bit Layer, MUST be 0x0 for RDMAP errors
      o 4-bit Error Type
      o 8-bit Error Code
   The Error Code field is OPTIONAL for this registry, as Error Codes
   are not used with all RDMAP Error Types.  When no numerical Error
   Code is registered, any 8-bit value MAY be used as the Error Code,
   as the Layer and Error Type values are sufficient to specify the
   error.  For this reason, if an RDMAP Error Type is registered
   without an Error Code, IANA MUST NOT add an entry to this registry
   with an Error Code for the same Error Type.

   Information that must be provided to assign a new value: An IESG-
   approved standards-track specification defining the semantics and
   interoperability requirements of the proposed new value and the
   fields to be recorded in the registry.

   Assignment policy: If the requested value is not already assigned,
   it may be assigned to the requester.

   Fields to record in the registry: Layer/Error-Type/Error-Code,
   Error-Type-Name/Error-Code-Name, RFC Reference.  The Error-Code
   and Error-Code-Name are omitted for Error-Types that do not have
   Error-Codes.

   When a specific error code is not registered, the registry entry
   contains the string "ALL" for the Error Code instead of a numerical
   value, and the Error Code Name is omitted from the registry entry.

   Initial registry contents:

   0x0/0x0/ALL , Local Catastrophic Error, [RFC5040]

   0x0/0x1/0x00, Remote Protection Error / Invalid Steering Tag,
   [RFC5040]

   0x0/0x1/0x01, Remote Protection Error / Base or bounds violation,
   [RFC5040]



Ko and Black              Expires June 2012                  [Page 3]


Internet-Draft       IANA Considerations for RDDP        October 2011

   0x0/0x1/0x02, Remote Protection Error / Access rights violation,
   [RFC5040]

   0x0/0x1/0x03, Remote Protection Error / Steering Tag not associated
   with RDMAP Stream, [RFC5040]

   0x0/0x1/0x04, Remote Protection Error / Tagged Offset wrap,
   [RFC5040]

   0x0/0x1/0x09, Remote Protection Error / Steering Tag cannot be
   invalidated, [RFC5040]

   0x0/0x1/0xff, Remote Protection Error / Unspecified Error,
   [RFC5040]

   0x0/0x2/0x05, Remote Operation Error / Invalid RDMAP version,
   [RFC5040]

   0x0/0x2/0x06, Remote Operation Error / Unexpected OpCode,
   [RFC5040]

   0x0/0x2/0x07, Remote Operation Error / Catastrophic error,
   localized to RDMAP Stream, [RFC5040]

   0x0/0x2/0x08, Remote Operation Error / Catastrophic error, global,
   [RFC5040]

   0x0/0x2/0x09, Remote Operation Error / Steering Tag cannot be
   Invalidated, [RFC5040]

   0x0/0x2/0xff, Remote Operation Error / Unspecified Error, [RFC5040]

   All combinations not listed above that combine 0x0 as the Layer with
   an Error Type and Error Code are Unassigned and available to IANA
   for assignment.

   Allocation Policy: Standards Action ([RFC5226])












Ko and Black              Expires June 2012                  [Page 4]


Internet-Draft       IANA Considerations for RDDP        October 2011

3.2  DDP Errors

   Name of the registry: "DDP Errors"

   Namespace details: A DDP (Direct Data Placement) error is a 16 bit
   field divided into three subfields [RFC5041]:
      o 4-bit Layer, MUST be 0x1 for DDP errors
      o 4-bit Error Type
      o 8-bit Error Code
   The Error Code field is REQUIRED for this registry, except for the
   registry entry that reserves a set of errors for use by the Lower
   Layer Protocol.

   Information that must be provided to assign a new value: An IESG-
   approved standards-track specification defining the semantics and
   interoperability requirements of the proposed new value and the
   fields to be recorded in the registry.

   Assignment policy: If the requested value is not already assigned,
   it may be assigned to the requester.

   Fields to record in the registry: Layer/Error-Type/Error-Code,
   Error-Type-Name/Error-Code-Name, RFC Reference.

   The last registry entry in the initial registry contents below
   reserves a set of errors for use by the Lower Layer Protocol.
   That entry uses "ALL" for the Error Code and omits the Error Code
   Name.  For all other entries in this registry, the string "ALL"
   MUST NOT be used for the Error Code, and an Error Code Name MUST
   be part of the registry entry.

   Initial registry contents:

   0x1/0x0/0x00, Local Catastrophic, [RFC5041]

   0x1/0x1/0x00, Tagged Buffer Error / Invalid Steering Tag, [RFC5041]

   0x1/0x1/0x01, Tagged Buffer Error / Base or bounds violation,
   [RFC5041]

   0x1/0x1/0x02, Tagged Buffer Error / Steering Tag not associated with
   DDP Stream, [RFC5041]

   0x1/0x1/0x03, Tagged Buffer Error / Tagged Offset wrap, [RFC5041]

   0x1/0x1/0x04, Tagged Buffer Error / Invalid DDP version, [RFC5041]



Ko and Black              Expires June 2012                  [Page 5]


Internet-Draft       IANA Considerations for RDDP        October 2011

   0x1/0x2/0x01, Untagged Buffer Error / Invalid Queue Number,
   [RFC5041]

   0x1/0x2/0x02, Untagged Buffer Error / Invalid Message Sequence
   Number - no buffer available, [RFC5041]

   0x1/0x2/0x03, Untagged Buffer Error / Invalid Message Sequence
   Number - Message Sequence Number range is not valid, [RFC5041]

   0x1/0x2/0x04, Untagged Buffer Error / Invalid Message Offset,
   [RFC5041]

   0x1/0x2/0x05, Untagged Buffer Error / DDP Message too long for
   available buffer, [RFC5041]

   0x1/0x2/0x06, Untagged Buffer Error / Invalid DDP version,
   [RFC5041]

   0x1/0x3/ALL , Reserved for use by Lower Layer Protocol, [RFC5041]

   All combinations not listed above that combine 0x1 as the Layer with
   an Error Type and Error Code are Unassigned and available to IANA
   for assignment.

   Allocation Policy: Standards Action ([RFC5226])
























Ko and Black              Expires June 2012                  [Page 6]


Internet-Draft       IANA Considerations for RDDP        October 2011

3.3  MPA Errors

   Name of the registry: "MPA Errors"

   Namespace details: An MPA (Marker PDU Aligned Framing for TCP) error
   is a 16 bit field divided into three subfields [RFC5044]:
      o 4-bit Layer, MUST be 0x2 for MPA errors
      o 4-bit Error Type
      o 8-bit Error Code
   The Error Code field is REQUIRED for this registry.

   Information that must be provided to assign a new value: An IESG-
   approved standards-track specification defining the semantics and
   interoperability requirements of the proposed new value and the
   fields to be recorded in the registry.

   Assignment policy: If the requested value is not already assigned,
   it may be assigned to the requester.

   Fields to record in the registry: Layer/Error-Type/Error-Code,
   Error-Type-Name/Error-Code-Name, RFC Reference.

   The string "ALL" MUST NOT be used for the Error Code in this
   registry, and an Error Code Name is REQUIRED in every entry in
   this registry.

   Initial registry contents:

   0x2/0x0/0x01, MPA Error / TCP connection closed, terminated, or
   lost, [RFC5044]

   0x2/0x0/0x02, MPA Error / MPA CRC Error, [RFC5044]

   0x2/0x0/0x03, MPA Error / MPA Marker and ULPDU Length field
   mismatch, [RFC5044]

   0x2/0x0/0x04, MPA Error / Invalid MPA Request Frame or MPA
   Response Frame, [RFC5044]

   All combinations not listed above that combine 0x2 as the Layer with
   an Error Type and Error Code are Unassigned and available to IANA
   for assignment.

   Allocation Policy: Standards Action ([RFC5226])





Ko and Black              Expires June 2012                  [Page 7]


Internet-Draft       IANA Considerations for RDDP        October 2011

3.4  RDMAP Message Operation Codes

   Name of the registry: "RDMAP Message Operation Codes"

   Namespace details: RDMAP Operation Codes are 4-bit values [RFC5040].

   Information that must be provided to assign a new value: An IESG-
   approved standards-track specification defining the semantics and
   interoperability requirements of the proposed new value and the
   fields to be recorded in the registry.

   Assignment policy: If the requested value is not already assigned,
   it may be assigned to the requester.

   Fields to record in the registry: RDMAP Message Operation Code,
   Message Type, RFC Reference

   Initial registry contents:

   0x0, RDMA Write, [RFC5040]

   0x1, RDMA Read Request, [RFC5040]

   0x2, RDMA Read Response, [RFC5040]

   0x3, Send, [RFC5040]

   0x4, Send with Invalidate, [RFC5040]

   0x5, Send with Solicited Event, [RFC5040]

   0x6, Send with Solicited Event and Invalidate, [RFC5040]

   0x7, Terminate, [RFC5040]

   All other values are Unassigned and available to IANA for assignment.

   Allocation Policy: Standards Action ([RFC5226])











Ko and Black              Expires June 2012                  [Page 8]


Internet-Draft       IANA Considerations for RDDP        October 2011

3.5  SCTP Function Codes for DDP Stream Session Control

   Name of the registry: "SCTP Function Codes for DDP Session Control"

   Namespace details: SCTP (Stream Control Transmission Protocol)
   function codes for DDP session control are 16-bit values [RFC5043].

   Information that must be provided to assign a new value: An IESG-
   approved standards-track specification defining the semantics and
   interoperability requirements of the proposed new value and the
   fields to be recorded in the registry.

   Assignment policy: If the requested value is not already assigned,
   it may be assigned to the requester.

   Fields to record in the registry: SCTP Function Code, SCTP
   Function Name, RFC Reference

   Initial registry contents:

   0x0001, DDP Stream Session Initiate, [RFC5043]

   0x0002, DDP Stream Session Accept, [RFC5043]

   0x0003, DDP Stream Session Reject, [RFC5043]

   0x0004, DDP Stream Session Terminate, [RFC5043]

   All other values are Unassigned and available to IANA for assignment.

   Allocation Policy: Standards Action ([RFC5226])


















Ko and Black              Expires June 2012                  [Page 9]


Internet-Draft       IANA Considerations for RDDP        October 2011

4. Normative References

   [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5040] R. Recio et al., "An RDMA Protocol Specification",
       RFC 5040, October 2007.

   [RFC5041] H. Shah et al., "Direct Data Placement over Reliable
       Transports", RFC 5041, October 2007.

   [RFC5043] C. Bestler et al., "Stream Control Transmission Protocol
       (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043,
       October 2007.

   [RFC5044] P. Culley et al., "Marker PDU Aligned Framing for TCP
       Specification", RFC 5044, October 2007.

   [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing
       an IANA Considerations Section in RFCs", RFC 5226, BCP 26,
       May 2008.

5. Informative References

   [MPA-PEER] A. Kanevsky, et al., "Enhanced RDMA Connection
       Establishment", draft-ietf-storm-mpa-peer-connect-09, work
       in progress, December 2011.

   [RDMAP-EXT] H. Shah, et al., "RDMA Protocol Extensions",
       draft-ietf-storm-rdmap-ext-01, work in progress, July 2011.


6. Acknowledgments

   IANA's review of a draft version of this document indicated
   the need for some corrections; the authors thank IANA for
   that review.












Ko and Black              Expires June 2012                 [Page 10]


Internet-Draft       IANA Considerations for RDDP        October 2011

Author's Address

   Michael Ko
   Huawei Symantec
   20245 Stevens Creek Blvd.
   Cupertino, CA 95014, USA
   Phone: +1-408-510-7465
   Email: michael@huaweisymantec.com

   David L. Black
   EMC Corporation
   176 South St.
   Hopkinton, MA  01748, USA
   Phone: +1-508-293-7953
   Email: david.black@emc.com


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.  Code
   Components extracted from this document must include Simplified
   BSD License text as described in Section 4.e of the Trust Legal
   Provisions and are provided without warranty as described in the
   Simplified BSD License.


















Ko and Black              Expires June 2012                 [Page 11]