Internet DRAFT - draft-ietf-storm-rddp-registries
draft-ietf-storm-rddp-registries
Storage Maintenance (storm) Working Group Michael Ko
Internet Draft Huawei Symantec
Intended status: Proposed Standard David L. Black
Expires: July 2012 EMC
January 17, 2012
IANA Registries for the RDDP
(Remote Direct Data Placement) Protocols
draft-ietf-storm-rddp-registries-02.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 July 2012 [Page 1]
Internet-Draft IANA Considerations for RDDP October 2011
Table of Contents
1. Introduction ................................................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. In addition,
this memo allocates operation code and function code points for
experimental use [RFC3692].
2. Security Considerations
Since this document is only concerned with creation and IANA
management of RDDP registries, it raises no new security issues.
However, a few words are necessary about the use of the experimental
code points defined in Sections 3.4 and 3.5. Potentially harmful
side effects from the use of the experimental values need to be
carefully evaluated before deploying any experiment across networks
that the owner of the experiment does not entirely control. Guidance
given in [RFC3692] about the use of experimental values needs to be
followed.
3. IANA Considerations
Allocation requests for the registries created by this memo may come
with a suggested numerical value or values that should be assigned.
Such suggestions are useful when early implementations have already
chosen particular code points before the final RFC is published. If
Ko and Black Expires July 2012 [Page 2]
Internet-Draft IANA Considerations for RDDP October 2011
the allocation request in general is accepted, such suggestions may
be honored if the suggested value is still free to be assigned.
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)
Each of the following sections specifies a registry, its initial
contents and the allocation 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, always 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, an entry must not be added 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.
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:
Ko and Black Expires July 2012 [Page 3]
Internet-Draft IANA Considerations for RDDP October 2011
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]
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 July 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, always 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. 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 a DDP Error Type is registered without an Error Code, an entry
must not be added 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.
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. The use of "ALL" is unique to that entry; all other entries
in this registry are required to contain a numeric Error Code and
an Error Code Name.
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]
Ko and Black Expires July 2012 [Page 5]
Internet-Draft IANA Considerations for RDDP October 2011
0x1/0x1/0x04, Tagged Buffer Error / Invalid DDP version, [RFC5041]
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 July 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, always 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.
Fields to record in the registry: Layer/Error-Type/Error-Code,
Error-Type-Name/Error-Code-Name, RFC Reference.
The string "ALL" is not used for the Error Code in this registry;
every entry is required to contain a numeric Error Code and an
Error Code Name.
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 July 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.
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]
0xF, Reserved (Experimental) [RFCXXXX]
RFC Editor: Please replace [RFCXXXX] in the above line with the RFC
number assigned to this document.
All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action ([RFC5226])
Ko and Black Expires July 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.
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]
0xFFFF, Reserved (Experimental) [RFCXXXX]
RFC Editor: Please replace [RFCXXXX] in the above line with the RFC
number assigned to this document.
All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action ([RFC5226])
Ko and Black Expires July 2012 [Page 9]
Internet-Draft IANA Considerations for RDDP October 2011
4. Normative References
[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-02, work in progress, January 2012.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
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. The authors would also like to thank Pete Resnick
and Jari Arkko for their helpful comments from IESG review.
Ko and Black Expires July 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) 2012 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 July 2012 [Page 11]
