RFC 6580

IANA Registries for the Remote Direct Data Placement (RDDP) Protocols

📅 published April 2012, from ietf

RFC 6580: IANA Registries for the Remote Direct Data Placement (RDDP) Protocols 🎀

  • Number: RFC 6580
  • Series: Internet Engineering Task Force (IETF) 🌸
  • Authors: M. Ko (Consultant) and D. Black (EMC) 💜
  • Category: Standards Track ✨
  • Date: April 2012 📅
  • ISSN: 2070-1721
  • Obsoletes / Updates: none listed 🦋

Abstract ✨

okay so the original RDDP RFCs never made IANA registries for RDDP error codes, operation codes, or function codes 🙈 extensions to RDDP now need those registries, so this memo finally makes them! it creates the RDDP registries, fills them with the values from the original RDDP RFCs, and gives IANA guidance on assigning new code points later 💅

Status of This Memo 🌈

this is an Internet Standards Track document 💖

it's a product of the Internet Engineering Task Force (IETF), so it represents IETF community consensus. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more on Internet Standards is in Section 2 of RFC 5741 📚

for the current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6580 🔍

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) as in effect on the date of publication. please read those carefully because they spell out your rights and restrictions for this document 📝 any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 ✨

okay the original RDDP RFCs [RFC5040] [RFC5041] [RFC5043] [RFC5044] didn't create IANA registries 😭 but extensions to RDDP [RFC6581] [RMP-EXT] now need them! so this memo creates the RDDP-related IANA registries, sets their starting contents based on the values in the original RDDP RFCs, and explains how IANA should handle future assignments from them 🦋 it also allocates operation code and function code points for experimental use [RFC3692] 🧪

2. Security Considerations 💀

honestly this document is only about creating and managing the RDDP registries with IANA, so it doesn't raise any new security issues 🫶

BUT (and this is a big but) we need to talk about the experimental code points in Sections 3.4 and 3.5 🚨 potentially harmful side effects from experimental values need to be carefully evaluated before anyone deploys an experiment across networks the experiment's owner doesn't entirely control 😱 the guidance about experimental values in [RFC3692] needs to be followed, no exceptions 🙅‍♀️

3. IANA Considerations 👑

allocation requests for these registries may come with a suggested numerical value or values to assign 💡 those suggestions are super useful when early implementations have already picked certain code points before the final RFC is published 🧁 if the allocation request as a whole is accepted, the suggestions may be honored as long as the suggested value is still free 🍓

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

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

each of the following sections specifies a registry, its initial contents, and its 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 split into three subfields [RFC5040]:

  • 4-bit Layer, always 0x0 for RDMAP errors
  • 4-bit Error Type
  • 8-bit Error Code

the Error Code field is optional for this registry, since Error Codes aren't used with every RDMAP Error Type 🤷‍♀️ when no numerical Error Code is registered, any 8-bit value may be used as the Error Code, because the Layer and Error Type values are enough to specify the error ✨ for that 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 that defines the semantics and interoperability requirements of the proposed new value, plus 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 don't have Error-Codes 🙃

when a specific Error Code isn't registered, the registry entry contains the string "ALL" for the Error Code instead of a numerical value, and the Error Code Name is left out of the 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]

any combinations not listed above that pair 0x0 as the Layer with an Error Type and Error Code are Unassigned and available for IANA to assign 🎀

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 split into three subfields [RFC5041]:

  • 4-bit Layer, always 0x1 for DDP errors
  • 4-bit Error Type
  • 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 the Lower Layer Protocol 🧐 when no numerical Error Code is registered, any 8-bit value may be used as the Error Code, since the Layer and Error Type values are enough to specify the error ✨ so, 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 that defines the semantics and interoperability requirements of the proposed new value, plus 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 entry in the initial registry contents below reserves a set of errors for the Lower Layer Protocol 🔐 that entry uses "ALL" for the Error Code and leaves out the Error Code Name. the use of "ALL" is unique to that entry; every other entry in this registry is 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]

any combinations not listed above that pair 0x1 as the Layer with an Error Type and Error Code are Unassigned and available for IANA to assign 🌸

Allocation Policy: Standards Action [RFC5226] ✨

3.3. MPA Errors ✨

Name of the registry: "MPA Errors" 🎀

okay so an MPA (Marker PDU Aligned Framing) error is a 16-bit field that's split into three bits 💅 [RFC5044]:

  • 4-bit Layer, always 0x2 for MPA errors
  • 4-bit Error Type
  • 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 has to include a numeric Error Code and an Error Code Name, no exceptions 🙈

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]

Any combination that uses 0x2 as the Layer with an Error Type and Error Code and isn't listed above is Unassigned, and IANA can hand it out later 🌸

Allocation Policy: Standards Action [RFC5226] 👑

3.4. RDMAP Message Operation Codes

Name of the registry: "RDMAP Message Operation Codes" 💜

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]

Every other value is 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" 🌈

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 reviewed a draft of this document and flagged a few things that needed fixing, so the authors are thanking IANA for that review 🙏 The authors also want to thank Pete Resnick and Jari Arkko for their helpful comments during 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
📦 where this page comes from