draft-ietf-storm-rddp-registries-01.txt   draft-ietf-storm-rddp-registries-02.txt 
Storage Maintenance (storm) Working Group Michael Ko Storage Maintenance (storm) Working Group Michael Ko
Internet Draft Huawei Symantec Internet Draft Huawei Symantec
Intended status: Proposed Standard David L. Black Intended status: Proposed Standard David L. Black
Expires: June 2012 EMC Expires: July 2012 EMC
December 21, 2011 January 17, 2012
IANA Registries for the RDDP IANA Registries for the RDDP
(Remote Direct Data Placement) Protocols (Remote Direct Data Placement) Protocols
draft-ietf-storm-rddp-registries-01.txt draft-ietf-storm-rddp-registries-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
create IANA registries for RDDP error codes, operation codes and create IANA registries for RDDP error codes, operation codes and
function codes. Extensions to the RDDP protocols now require function codes. Extensions to the RDDP protocols now require
these registries to be created. This memo creates the RDDP these registries to be created. This memo creates the RDDP
registries, populates them with values defined in the original registries, populates them with values defined in the original
RDDP RFCs, and provides guidance to IANA for future assignment RDDP RFCs, and provides guidance to IANA for future assignment
of code points within these registries. of code points within these registries.
Table of Contents Table of Contents
1. Introduction ................................................2 1. Introduction ................................................2
1.1 Conventions .................................................2
2. Security Considerations .....................................2 2. Security Considerations .....................................2
3. IANA Considerations .........................................2 3. IANA Considerations .........................................2
3.1 RDMAP Errors ................................................3 3.1 RDMAP Errors ................................................3
3.2 DDP Errors ..................................................5 3.2 DDP Errors ..................................................5
3.3 MPA Errors ..................................................7 3.3 MPA Errors ..................................................7
3.4 RDMAP Message Operation Codes ...............................8 3.4 RDMAP Message Operation Codes ...............................8
3.5 SCTP Function Codes for DDP Stream Session Control ..........9 3.5 SCTP Function Codes for DDP Stream Session Control ..........9
4. Normative References .......................................10 4. Normative References .......................................10
5. Informative References .....................................10 5. Informative References .....................................10
6. Acknowledgments ............................................10 6. Acknowledgments ............................................10
1. Introduction 1. Introduction
The original RFCs that specified the RDDP protocol suite The original RFCs that specified the RDDP protocol suite
[RFC5040][RFC5041][RFC5043][RFC5044] did not create IANA registries. [RFC5040][RFC5041][RFC5043][RFC5044] did not create IANA registries.
Extensions to the RDDP protocols [MPA-PEER][RDMAP-EXT] now requires Extensions to the RDDP protocols [MPA-PEER][RDMAP-EXT] now requires
creation and use of IANA registries. This memo creates the RDDP- creation and use of IANA registries. This memo creates the RDDP-
related IANA registries, specifies their initial contents based on related IANA registries, specifies their initial contents based on
the values defined in the original RDDP RFCs, and provides guidance the values defined in the original RDDP RFCs, and provides guidance
to IANA for future assignments from these registries. to IANA for future assignments from these registries. In addition,
this memo allocates operation code and function code points for
1.1 Conventions experimental use [RFC3692].
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 2. Security Considerations
Since this document is only concerned with creation and IANA Since this document is only concerned with creation and IANA
management of RDDP registries, it raises no new security issues. 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 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
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: This memo creates the following RDDP registries for IANA to manage:
o RDMAP Errors (Section 3.1) o RDMAP Errors (Section 3.1)
o DDP Errors (Section 3.2) o DDP Errors (Section 3.2)
o MPA Errors (Section 3.3) o MPA Errors (Section 3.3)
o RDMAP Message Operation Codes (Section 3.4) o RDMAP Message Operation Codes (Section 3.4)
o SCTP Function Codes for DDP Stream Session Control (Section 3.5) o SCTP Function Codes for DDP Stream Session Control (Section 3.5)
Each of the following sections specifies a registry, its initial Each of the following sections specifies a registry, its initial
contents and the administration policy in more detail. contents and the allocation policy in more detail.
3.1 RDMAP Errors 3.1 RDMAP Errors
Name of the registry: "RDMAP Errors" Name of the registry: "RDMAP Errors"
Namespace details: An RDMAP (Remote Direct Memory Access Protocol) Namespace details: An RDMAP (Remote Direct Memory Access Protocol)
error is a 16 bit field divided into three subfields [RFC5040]: error is a 16 bit field divided into three subfields [RFC5040]:
o 4-bit Layer, MUST be 0x0 for RDMAP errors o 4-bit Layer, always 0x0 for RDMAP errors
o 4-bit Error Type o 4-bit Error Type
o 8-bit Error Code o 8-bit Error Code
The Error Code field is OPTIONAL for this registry, as Error Codes The Error Code field is optional for this registry, as Error Codes
are not used with all RDMAP Error Types. When no numerical Error 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, 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 as the Layer and Error Type values are sufficient to specify the
error. For this reason, if an RDMAP Error Type is registered error. For this reason, if an RDMAP Error Type is registered
without an Error Code, IANA MUST NOT add an entry to this registry without an Error Code, an entry must not be added to this registry
with an Error Code for the same Error Type. with an Error Code for the same Error Type.
Information that must be provided to assign a new value: An IESG- Information that must be provided to assign a new value: An IESG-
approved standards-track specification defining the semantics and approved standards-track specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry. 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, Fields to record in the registry: Layer/Error-Type/Error-Code,
Error-Type-Name/Error-Code-Name, RFC Reference. The 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 and Error-Code-Name are omitted for Error-Types that do not have
Error-Codes. Error-Codes.
When a specific error code is not registered, the registry entry When a specific error code is not registered, the registry entry
contains the string "ALL" for the Error Code instead of a numerical contains the string "ALL" for the Error Code instead of a numerical
value, and the Error Code Name is omitted from the registry entry. value, and the Error Code Name is omitted from the registry entry.
Initial registry contents: Initial registry contents:
skipping to change at page 5, line 11 skipping to change at page 5, line 11
for assignment. for assignment.
Allocation Policy: Standards Action ([RFC5226]) Allocation Policy: Standards Action ([RFC5226])
3.2 DDP Errors 3.2 DDP Errors
Name of the registry: "DDP Errors" Name of the registry: "DDP Errors"
Namespace details: A DDP (Direct Data Placement) error is a 16 bit Namespace details: A DDP (Direct Data Placement) error is a 16 bit
field divided into three subfields [RFC5041]: field divided into three subfields [RFC5041]:
o 4-bit Layer, MUST be 0x1 for DDP errors o 4-bit Layer, always 0x1 for DDP errors
o 4-bit Error Type o 4-bit Error Type
o 8-bit Error Code o 8-bit Error Code
The Error Code field is REQUIRED for this registry, except for the 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 registry entry that reserves a set of errors for use by the Lower
Layer Protocol. 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- Information that must be provided to assign a new value: An IESG-
approved standards-track specification defining the semantics and approved standards-track specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry. 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, Fields to record in the registry: Layer/Error-Type/Error-Code,
Error-Type-Name/Error-Code-Name, RFC Reference. Error-Type-Name/Error-Code-Name, RFC Reference.
The last registry entry in the initial registry contents below The last registry entry in the initial registry contents below
reserves a set of errors for use by the Lower Layer Protocol. 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 That entry uses "ALL" for the Error Code and omits the Error Code
Name. For all other entries in this registry, the string "ALL" Name. The use of "ALL" is unique to that entry; all other entries
MUST NOT be used for the Error Code, and an Error Code Name MUST in this registry are required to contain a numeric Error Code and
be part of the registry entry. an Error Code Name.
Initial registry contents: Initial registry contents:
0x1/0x0/0x00, Local Catastrophic, [RFC5041] 0x1/0x0/0x00, Local Catastrophic, [RFC5041]
0x1/0x1/0x00, Tagged Buffer Error / Invalid Steering Tag, [RFC5041] 0x1/0x1/0x00, Tagged Buffer Error / Invalid Steering Tag, [RFC5041]
0x1/0x1/0x01, Tagged Buffer Error / Base or bounds violation, 0x1/0x1/0x01, Tagged Buffer Error / Base or bounds violation,
[RFC5041] [RFC5041]
skipping to change at page 7, line 11 skipping to change at page 7, line 11
for assignment. for assignment.
Allocation Policy: Standards Action ([RFC5226]) Allocation Policy: Standards Action ([RFC5226])
3.3 MPA Errors 3.3 MPA Errors
Name of the registry: "MPA Errors" Name of the registry: "MPA Errors"
Namespace details: An MPA (Marker PDU Aligned Framing for TCP) error Namespace details: An MPA (Marker PDU Aligned Framing for TCP) error
is a 16 bit field divided into three subfields [RFC5044]: is a 16 bit field divided into three subfields [RFC5044]:
o 4-bit Layer, MUST be 0x2 for MPA errors o 4-bit Layer, always 0x2 for MPA errors
o 4-bit Error Type o 4-bit Error Type
o 8-bit Error Code o 8-bit Error Code
The Error Code field is REQUIRED for this registry. The Error Code field is required for this registry.
Information that must be provided to assign a new value: An IESG- Information that must be provided to assign a new value: An IESG-
approved standards-track specification defining the semantics and approved standards-track specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry. 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, Fields to record in the registry: Layer/Error-Type/Error-Code,
Error-Type-Name/Error-Code-Name, RFC Reference. Error-Type-Name/Error-Code-Name, RFC Reference.
The string "ALL" MUST NOT be used for the Error Code in this The string "ALL" is not used for the Error Code in this registry;
registry, and an Error Code Name is REQUIRED in every entry in every entry is required to contain a numeric Error Code and an
this registry. Error Code Name.
Initial registry contents: Initial registry contents:
0x2/0x0/0x01, MPA Error / TCP connection closed, terminated, or 0x2/0x0/0x01, MPA Error / TCP connection closed, terminated, or
lost, [RFC5044] lost, [RFC5044]
0x2/0x0/0x02, MPA Error / MPA CRC Error, [RFC5044] 0x2/0x0/0x02, MPA Error / MPA CRC Error, [RFC5044]
0x2/0x0/0x03, MPA Error / MPA Marker and ULPDU Length field 0x2/0x0/0x03, MPA Error / MPA Marker and ULPDU Length field
mismatch, [RFC5044] mismatch, [RFC5044]
skipping to change at page 8, line 16 skipping to change at page 8, line 16
Name of the registry: "RDMAP Message Operation Codes" Name of the registry: "RDMAP Message Operation Codes"
Namespace details: RDMAP Operation Codes are 4-bit values [RFC5040]. Namespace details: RDMAP Operation Codes are 4-bit values [RFC5040].
Information that must be provided to assign a new value: An IESG- Information that must be provided to assign a new value: An IESG-
approved standards-track specification defining the semantics and approved standards-track specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry. 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, Fields to record in the registry: RDMAP Message Operation Code,
Message Type, RFC Reference Message Type, RFC Reference
Initial registry contents: Initial registry contents:
0x0, RDMA Write, [RFC5040] 0x0, RDMA Write, [RFC5040]
0x1, RDMA Read Request, [RFC5040] 0x1, RDMA Read Request, [RFC5040]
0x2, RDMA Read Response, [RFC5040] 0x2, RDMA Read Response, [RFC5040]
skipping to change at page 8, line 40 skipping to change at page 8, line 37
0x3, Send, [RFC5040] 0x3, Send, [RFC5040]
0x4, Send with Invalidate, [RFC5040] 0x4, Send with Invalidate, [RFC5040]
0x5, Send with Solicited Event, [RFC5040] 0x5, Send with Solicited Event, [RFC5040]
0x6, Send with Solicited Event and Invalidate, [RFC5040] 0x6, Send with Solicited Event and Invalidate, [RFC5040]
0x7, Terminate, [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. All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action ([RFC5226]) Allocation Policy: Standards Action ([RFC5226])
3.5 SCTP Function Codes for DDP Stream Session Control 3.5 SCTP Function Codes for DDP Stream Session Control
Name of the registry: "SCTP Function Codes for DDP Session Control" Name of the registry: "SCTP Function Codes for DDP Session Control"
Namespace details: SCTP (Stream Control Transmission Protocol) Namespace details: SCTP (Stream Control Transmission Protocol)
function codes for DDP session control are 16-bit values [RFC5043]. function codes for DDP session control are 16-bit values [RFC5043].
Information that must be provided to assign a new value: An IESG- Information that must be provided to assign a new value: An IESG-
approved standards-track specification defining the semantics and approved standards-track specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry. 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 Fields to record in the registry: SCTP Function Code, SCTP
Function Name, RFC Reference Function Name, RFC Reference
Initial registry contents: Initial registry contents:
0x0001, DDP Stream Session Initiate, [RFC5043] 0x0001, DDP Stream Session Initiate, [RFC5043]
0x0002, DDP Stream Session Accept, [RFC5043] 0x0002, DDP Stream Session Accept, [RFC5043]
0x0003, DDP Stream Session Reject, [RFC5043] 0x0003, DDP Stream Session Reject, [RFC5043]
0x0004, DDP Stream Session Terminate, [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. All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action ([RFC5226]) Allocation Policy: Standards Action ([RFC5226])
4. Normative References 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", [RFC5040] R. Recio et al., "An RDMA Protocol Specification",
RFC 5040, October 2007. RFC 5040, October 2007.
[RFC5041] H. Shah et al., "Direct Data Placement over Reliable [RFC5041] H. Shah et al., "Direct Data Placement over Reliable
Transports", RFC 5041, October 2007. Transports", RFC 5041, October 2007.
[RFC5043] C. Bestler et al., "Stream Control Transmission Protocol [RFC5043] C. Bestler et al., "Stream Control Transmission Protocol
(SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043,
October 2007. October 2007.
skipping to change at page 10, line 34 skipping to change at page 10, line 31
an IANA Considerations Section in RFCs", RFC 5226, BCP 26, an IANA Considerations Section in RFCs", RFC 5226, BCP 26,
May 2008. May 2008.
5. Informative References 5. Informative References
[MPA-PEER] A. Kanevsky, et al., "Enhanced RDMA Connection [MPA-PEER] A. Kanevsky, et al., "Enhanced RDMA Connection
Establishment", draft-ietf-storm-mpa-peer-connect-09, work Establishment", draft-ietf-storm-mpa-peer-connect-09, work
in progress, December 2011. in progress, December 2011.
[RDMAP-EXT] H. Shah, et al., "RDMA Protocol Extensions", [RDMAP-EXT] H. Shah, et al., "RDMA Protocol Extensions",
draft-ietf-storm-rdmap-ext-01, work in progress, July 2011. 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 6. Acknowledgments
IANA's review of a draft version of this document indicated IANA's review of a draft version of this document indicated
the need for some corrections; the authors thank IANA for the need for some corrections; the authors thank IANA for
that review. that review. The authors would also like to thank Pete Resnick
and Jari Arkko for their helpful comments from IESG review.
Author's Address Author's Address
Michael Ko Michael Ko
Huawei Symantec Huawei Symantec
20245 Stevens Creek Blvd. 20245 Stevens Creek Blvd.
Cupertino, CA 95014, USA Cupertino, CA 95014, USA
Phone: +1-408-510-7465 Phone: +1-408-510-7465
Email: michael@huaweisymantec.com Email: michael@huaweisymantec.com
David L. Black David L. Black
EMC Corporation EMC Corporation
176 South St. 176 South St.
Hopkinton, MA 01748, USA Hopkinton, MA 01748, USA
Phone: +1-508-293-7953 Phone: +1-508-293-7953
Email: david.black@emc.com Email: david.black@emc.com
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. Code rights and restrictions with respect to this document. Code
Components extracted from this document must include Simplified Components extracted from this document must include Simplified
BSD License text as described in Section 4.e of the Trust Legal BSD License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the Provisions and are provided without warranty as described in the
 End of changes. 29 change blocks. 
48 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/