RDDP IANA Registries: IANA Registries for the Remote Direct Data Placement (RDDP) Protocols
Official code registries for Remote Direct Data Placement protocol extensions
Ko, M. and D. Black, "IANA Registries for the Remote Direct Data Placement (RDDP) Protocols", RFC 6580, DOI 10.17487/RFC6580, April 2012, <https://www.rfc-editor.org/info/rfc6580>.
@misc{rfc6580,
series = {Request for Comments},
number = 6580,
howpublished = {RFC 6580},
publisher = {RFC Editor},
doi = {10.17487/RFC6580},
url = {https://www.rfc-editor.org/info/rfc6580},
author = {M. Ko and D. Black},
title = {{IANA Registries for the Remote Direct Data Placement (RDDP) Protocols}},
pagetotal = 10,
year = 2012,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Ko
Request for Comments: 6580 Consultant
Category: Standards Track D. Black
ISSN: 2070-1721 EMC
April 2012
IANA Registries for the Remote Direct Data Placement (RDDP) Protocols
Abstract
The original RFCs that specified the Remote Direct Data Placement
(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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6580.
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.
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 .................................................6
3.4. RDMAP Message Operation Codes ..............................7
3.5. SCTP Function Codes for DDP Stream Session Control .........8
4. Normative References ............................................9
5. Informative References ..........................................9
6. Acknowledgments .................................................9
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 [RFC6581] [RMP-EXT] now require
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
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:
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]
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]
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]
3.3 MPA Errors
Name of the registry: "MPA Errors"
Namespace details: An MPA (Marker PDU Aligned Framing) 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]
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) [RFC6580]
All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action [RFC5226]
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) [RFC6580]
All other values are Unassigned and available to IANA for assignment.
Allocation Policy: Standards Action [RFC5226]
4. Normative References
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, October 2007.
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
Data Placement over Reliable Transports", RFC 5041, October
2007.
[RFC5043] Bestler, C., Ed., and R. Stewart, Ed., "Stream Control
Transmission Protocol (SCTP) Direct Data Placement (DDP)
Adaptation", RFC 5043, October 2007.
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, October 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
5. Informative References
[RMP-EXT] Shah, H., Marti, F., Noureddine, W., Eiriksson, A., and R.
Sharp, "RDMA Protocol Extensions", Work in Progress,
January 2012.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC6581] Kanevsky, A., Ed., Bestler, C., Ed., Sharp, R., and S.
Wise, "Enhanced Remote Direct Memory Access (RDMA)
Connection Establishment", RFC 6581, April 2012.
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.
Authors' Address
Michael Ko
EMail: mkosjc@gmail.com
David L. Black
EMC Corporation
176 South St.
Hopkinton, MA 01748, USA
Phone: +1-508-293-7953
EMail: david.black@emc.com
AI ELI5
On this page
§1The Need for RDDP Code Registries
Remote Direct Data Placement (RDDP) is a suite of protocols that allow computers to transfer data directly to remote memory without involving the CPU of the receiving machine. The original RFCs (5040, 5041, 5043, 5044) defined the protocols but did not create IANA registries for code points.
As RDDP protocols are extended (such as in RFC 6581 and other upcoming specifications), new error codes, operation codes, and function codes need to be assigned in an organized way. This RFC creates the necessary IANA registries, populates them with values from the original specifications, and provides allocation policy guidance.
RDDP lets computers send data directly to memory without the computer thinking about it. When things go wrong or new features are added, you need numbered codes. This RFC creates the official list and says how to add new codes.
§2The RDDP Protocol Stack
The RDDP suite consists of multiple layers, each producing error codes:
RDMAP (Remote Direct Memory Access Protocol) operates at Layer 0 and produces 16-bit error codes divided into three subfields: a 4-bit Layer field (always 0x0), a 4-bit Error Type, and an 8-bit Error Code. Error codes are optional; when an Error Type alone is sufficient to specify the error, no Error Code is registered.
DDP (Direct Data Placement) operates at Layer 1 and uses the same 16-bit structure with Layer = 0x1. DDP distinguishes between Tagged Buffer errors and Untagged Buffer errors, plus a special entry reserving codes for the lower layer protocol.
MPA (Marker PDU Aligned Framing) operates at Layer 2 (0x2) and produces 16-bit error codes with a single Error Type and always requires a numeric Error Code.
RDDP has three layers, each producing different kinds of error codes. Each layer is numbered (0, 1, 2) and has its own set of error types and specific error codes nested inside them.
- RDMAPRemote Direct Memory Access Protocol, Layer 0
- DDPDirect Data Placement, Layer 1
- MPAMarker PDU Aligned Framing, Layer 2
- TransportTCP, SCTP, or other lower-layer protocol
§3Message Operations and Function Codes
RDMAP Message Operation Codes are 4-bit values specifying what kind of message is being sent. The original RFCs define codes 0x0 through 0x7 for operations such as RDMA Write, RDMA Read Request, RDMA Read Response, Send, Send with Invalidate, Send with Solicited Event, and Terminate. Code 0xF is reserved for experimental use.
SCTP Function Codes for DDP Stream Session Control are 16-bit values used when DDP runs over SCTP (Stream Control Transmission Protocol). The original specification defines codes 0x0001 through 0x0004 for operations like DDP Stream Session Initiate, Accept, Reject, and Terminate. Code 0xFFFF is reserved for experimental use.
Both registries allow any unassigned values to be allocated by future Standards-Track specifications.
When RDDP sends a message, the first few bits say what kind of message it is (read, write, etc.). This RFC lists all those message types and how to add new ones in the future.
- 0x0RDMA Write — Write data to remote memory.
- 0x1RDMA Read Request — Request data from remote memory.
- 0x2RDMA Read Response — Return requested data.
- 0x3Send — Send a message to the remote ULP.
- 0x4Send with Invalidate — Send and invalidate a Steering Tag.
- 0x5Send with Solicited Event — Send and trigger a solicited event.
- 0x6Send with Solicited Event and Invalidate — Send, invalidate, and trigger event.
- 0x7Terminate — Terminate the connection.
- 0xFReserved (Experimental) — Reserved for experimental use.
§4Code Point Allocation Policy
All five registries use the same allocation policy: Standards Action. This means new code points can only be assigned through an IESG-approved Standards-Track RFC. Allocation requests should include a specification that defines the semantics and interoperability requirements of the proposed new code point.
When suggesting specific numerical values, allocation requests can note codes that early implementations have already chosen. If the IANA allocation request is accepted, such suggestions may be honored if the value is still available.
The RFC reserves specific experimental code points for use in research and prototyping. Code 0xF is reserved as experimental for RDMAP Message Operation Codes (allowing 4-bit experiments), and code 0xFFFF is reserved for SCTP Function Codes.
Want to add a new code? You need to write a proper RFC that explains what the code does and why it's needed. This keeps the system organized and prevents random additions.
§5Initial Registry Contents and Examples
The RDMAP Errors registry begins with entries like 0x0/0x0/ALL (Local Catastrophic Error) and 0x0/0x1/0x00 (Remote Protection Error / Invalid Steering Tag). The registry distinguishes between Error Types that require specific Error Codes (such as Remote Protection Error) and those that use a wildcard 'ALL' value for the Error Code field when no specific codes are registered.
The DDP Errors registry includes Tagged Buffer errors (Layer 1, Type 0x1), Untagged Buffer errors (Layer 1, Type 0x2), and notably reserves Layer 1, Type 0x3 entirely for use by the lower layer protocol with the special entry 0x1/0x3/ALL.
The MPA Errors registry is simpler, with four defined error types covering TCP connection issues, CRC errors, marker mismatches, and invalid frame formats.
All registries note that combinations not listed are Unassigned and available for IANA assignment by future Standards-Track specifications.
Each registry lists the specific error codes and operation codes defined in the original RDDP RFCs. New codes can be added later by anyone who writes a proper standard.