idnits 2.17.1 draft-ietf-storm-rddp-registries-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2012) is 4482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 367, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-storm-rdmap-ext-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Storage Maintenance (storm) Working Group Michael Ko 2 Internet Draft Huawei Symantec 3 Intended status: Proposed Standard David L. Black 4 Expires: July 2012 EMC 5 January 17, 2012 7 IANA Registries for the RDDP 8 (Remote Direct Data Placement) Protocols 9 draft-ietf-storm-rddp-registries-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 21, 2012. 35 Abstract 37 The original RFCs that specified the RDDP protocol suite did not 38 create IANA registries for RDDP error codes, operation codes and 39 function codes. Extensions to the RDDP protocols now require 40 these registries to be created. This memo creates the RDDP 41 registries, populates them with values defined in the original 42 RDDP RFCs, and provides guidance to IANA for future assignment 43 of code points within these registries. 45 Table of Contents 47 1. Introduction ................................................2 48 2. Security Considerations .....................................2 49 3. IANA Considerations .........................................2 50 3.1 RDMAP Errors ................................................3 51 3.2 DDP Errors ..................................................5 52 3.3 MPA Errors ..................................................7 53 3.4 RDMAP Message Operation Codes ...............................8 54 3.5 SCTP Function Codes for DDP Stream Session Control ..........9 55 4. Normative References .......................................10 56 5. Informative References .....................................10 57 6. Acknowledgments ............................................10 59 1. Introduction 61 The original RFCs that specified the RDDP protocol suite 62 [RFC5040][RFC5041][RFC5043][RFC5044] did not create IANA registries. 63 Extensions to the RDDP protocols [MPA-PEER][RDMAP-EXT] now requires 64 creation and use of IANA registries. This memo creates the RDDP- 65 related IANA registries, specifies their initial contents based on 66 the values defined in the original RDDP RFCs, and provides guidance 67 to IANA for future assignments from these registries. In addition, 68 this memo allocates operation code and function code points for 69 experimental use [RFC3692]. 71 2. Security Considerations 73 Since this document is only concerned with creation and IANA 74 management of RDDP registries, it raises no new security issues. 76 However, a few words are necessary about the use of the experimental 77 code points defined in Sections 3.4 and 3.5. Potentially harmful 78 side effects from the use of the experimental values need to be 79 carefully evaluated before deploying any experiment across networks 80 that the owner of the experiment does not entirely control. Guidance 81 given in [RFC3692] about the use of experimental values needs to be 82 followed. 84 3. IANA Considerations 86 Allocation requests for the registries created by this memo may come 87 with a suggested numerical value or values that should be assigned. 88 Such suggestions are useful when early implementations have already 89 chosen particular code points before the final RFC is published. If 90 the allocation request in general is accepted, such suggestions may 91 be honored if the suggested value is still free to be assigned. 93 This memo creates the following RDDP registries for IANA to manage: 95 o RDMAP Errors (Section 3.1) 96 o DDP Errors (Section 3.2) 97 o MPA Errors (Section 3.3) 98 o RDMAP Message Operation Codes (Section 3.4) 99 o SCTP Function Codes for DDP Stream Session Control (Section 3.5) 101 Each of the following sections specifies a registry, its initial 102 contents and the allocation policy in more detail. 104 3.1 RDMAP Errors 106 Name of the registry: "RDMAP Errors" 108 Namespace details: An RDMAP (Remote Direct Memory Access Protocol) 109 error is a 16 bit field divided into three subfields [RFC5040]: 110 o 4-bit Layer, always 0x0 for RDMAP errors 111 o 4-bit Error Type 112 o 8-bit Error Code 113 The Error Code field is optional for this registry, as Error Codes 114 are not used with all RDMAP Error Types. When no numerical Error 115 Code is registered, any 8-bit value may be used as the Error Code, 116 as the Layer and Error Type values are sufficient to specify the 117 error. For this reason, if an RDMAP Error Type is registered 118 without an Error Code, an entry must not be added to this registry 119 with an Error Code for the same Error Type. 121 Information that must be provided to assign a new value: An IESG- 122 approved standards-track specification defining the semantics and 123 interoperability requirements of the proposed new value and the 124 fields to be recorded in the registry. 126 Fields to record in the registry: Layer/Error-Type/Error-Code, 127 Error-Type-Name/Error-Code-Name, RFC Reference. The Error-Code 128 and Error-Code-Name are omitted for Error-Types that do not have 129 Error-Codes. 131 When a specific error code is not registered, the registry entry 132 contains the string "ALL" for the Error Code instead of a numerical 133 value, and the Error Code Name is omitted from the registry entry. 135 Initial registry contents: 137 0x0/0x0/ALL , Local Catastrophic Error, [RFC5040] 139 0x0/0x1/0x00, Remote Protection Error / Invalid Steering Tag, 140 [RFC5040] 142 0x0/0x1/0x01, Remote Protection Error / Base or bounds violation, 143 [RFC5040] 145 0x0/0x1/0x02, Remote Protection Error / Access rights violation, 146 [RFC5040] 148 0x0/0x1/0x03, Remote Protection Error / Steering Tag not associated 149 with RDMAP Stream, [RFC5040] 151 0x0/0x1/0x04, Remote Protection Error / Tagged Offset wrap, 152 [RFC5040] 154 0x0/0x1/0x09, Remote Protection Error / Steering Tag cannot be 155 invalidated, [RFC5040] 157 0x0/0x1/0xff, Remote Protection Error / Unspecified Error, 158 [RFC5040] 160 0x0/0x2/0x05, Remote Operation Error / Invalid RDMAP version, 161 [RFC5040] 163 0x0/0x2/0x06, Remote Operation Error / Unexpected OpCode, 164 [RFC5040] 166 0x0/0x2/0x07, Remote Operation Error / Catastrophic error, 167 localized to RDMAP Stream, [RFC5040] 169 0x0/0x2/0x08, Remote Operation Error / Catastrophic error, global, 170 [RFC5040] 172 0x0/0x2/0x09, Remote Operation Error / Steering Tag cannot be 173 Invalidated, [RFC5040] 175 0x0/0x2/0xff, Remote Operation Error / Unspecified Error, [RFC5040] 177 All combinations not listed above that combine 0x0 as the Layer with 178 an Error Type and Error Code are Unassigned and available to IANA 179 for assignment. 181 Allocation Policy: Standards Action ([RFC5226]) 183 3.2 DDP Errors 185 Name of the registry: "DDP Errors" 187 Namespace details: A DDP (Direct Data Placement) error is a 16 bit 188 field divided into three subfields [RFC5041]: 189 o 4-bit Layer, always 0x1 for DDP errors 190 o 4-bit Error Type 191 o 8-bit Error Code 192 The Error Code field is required for this registry, except for the 193 registry entry that reserves a set of errors for use by the Lower 194 Layer Protocol. When no numerical Error Code is registered, any 195 8-bit value may be used as the Error Code, as the Layer and Error 196 Type values are sufficient to specify the error. For this reason, 197 if a DDP Error Type is registered without an Error Code, an entry 198 must not be added to this registry with an Error Code for the same 199 Error Type. 201 Information that must be provided to assign a new value: An IESG- 202 approved standards-track specification defining the semantics and 203 interoperability requirements of the proposed new value and the 204 fields to be recorded in the registry. 206 Fields to record in the registry: Layer/Error-Type/Error-Code, 207 Error-Type-Name/Error-Code-Name, RFC Reference. 209 The last registry entry in the initial registry contents below 210 reserves a set of errors for use by the Lower Layer Protocol. 211 That entry uses "ALL" for the Error Code and omits the Error Code 212 Name. The use of "ALL" is unique to that entry; all other entries 213 in this registry are required to contain a numeric Error Code and 214 an Error Code Name. 216 Initial registry contents: 218 0x1/0x0/0x00, Local Catastrophic, [RFC5041] 220 0x1/0x1/0x00, Tagged Buffer Error / Invalid Steering Tag, [RFC5041] 222 0x1/0x1/0x01, Tagged Buffer Error / Base or bounds violation, 223 [RFC5041] 225 0x1/0x1/0x02, Tagged Buffer Error / Steering Tag not associated with 226 DDP Stream, [RFC5041] 228 0x1/0x1/0x03, Tagged Buffer Error / Tagged Offset wrap, [RFC5041] 229 0x1/0x1/0x04, Tagged Buffer Error / Invalid DDP version, [RFC5041] 231 0x1/0x2/0x01, Untagged Buffer Error / Invalid Queue Number, 232 [RFC5041] 234 0x1/0x2/0x02, Untagged Buffer Error / Invalid Message Sequence 235 Number - no buffer available, [RFC5041] 237 0x1/0x2/0x03, Untagged Buffer Error / Invalid Message Sequence 238 Number - Message Sequence Number range is not valid, [RFC5041] 240 0x1/0x2/0x04, Untagged Buffer Error / Invalid Message Offset, 241 [RFC5041] 243 0x1/0x2/0x05, Untagged Buffer Error / DDP Message too long for 244 available buffer, [RFC5041] 246 0x1/0x2/0x06, Untagged Buffer Error / Invalid DDP version, 247 [RFC5041] 249 0x1/0x3/ALL , Reserved for use by Lower Layer Protocol, [RFC5041] 251 All combinations not listed above that combine 0x1 as the Layer with 252 an Error Type and Error Code are Unassigned and available to IANA 253 for assignment. 255 Allocation Policy: Standards Action ([RFC5226]) 257 3.3 MPA Errors 259 Name of the registry: "MPA Errors" 261 Namespace details: An MPA (Marker PDU Aligned Framing for TCP) error 262 is a 16 bit field divided into three subfields [RFC5044]: 263 o 4-bit Layer, always 0x2 for MPA errors 264 o 4-bit Error Type 265 o 8-bit Error Code 266 The Error Code field is required for this registry. 268 Information that must be provided to assign a new value: An IESG- 269 approved standards-track specification defining the semantics and 270 interoperability requirements of the proposed new value and the 271 fields to be recorded in the registry. 273 Fields to record in the registry: Layer/Error-Type/Error-Code, 274 Error-Type-Name/Error-Code-Name, RFC Reference. 276 The string "ALL" is not used for the Error Code in this registry; 277 every entry is required to contain a numeric Error Code and an 278 Error Code Name. 280 Initial registry contents: 282 0x2/0x0/0x01, MPA Error / TCP connection closed, terminated, or 283 lost, [RFC5044] 285 0x2/0x0/0x02, MPA Error / MPA CRC Error, [RFC5044] 287 0x2/0x0/0x03, MPA Error / MPA Marker and ULPDU Length field 288 mismatch, [RFC5044] 290 0x2/0x0/0x04, MPA Error / Invalid MPA Request Frame or MPA 291 Response Frame, [RFC5044] 293 All combinations not listed above that combine 0x2 as the Layer with 294 an Error Type and Error Code are Unassigned and available to IANA 295 for assignment. 297 Allocation Policy: Standards Action ([RFC5226]) 299 3.4 RDMAP Message Operation Codes 301 Name of the registry: "RDMAP Message Operation Codes" 303 Namespace details: RDMAP Operation Codes are 4-bit values [RFC5040]. 305 Information that must be provided to assign a new value: An IESG- 306 approved standards-track specification defining the semantics and 307 interoperability requirements of the proposed new value and the 308 fields to be recorded in the registry. 310 Fields to record in the registry: RDMAP Message Operation Code, 311 Message Type, RFC Reference 313 Initial registry contents: 315 0x0, RDMA Write, [RFC5040] 317 0x1, RDMA Read Request, [RFC5040] 319 0x2, RDMA Read Response, [RFC5040] 321 0x3, Send, [RFC5040] 323 0x4, Send with Invalidate, [RFC5040] 325 0x5, Send with Solicited Event, [RFC5040] 327 0x6, Send with Solicited Event and Invalidate, [RFC5040] 329 0x7, Terminate, [RFC5040] 331 0xF, Reserved (Experimental) [RFCXXXX] 333 RFC Editor: Please replace [RFCXXXX] in the above line with the RFC 334 number assigned to this document. 336 All other values are Unassigned and available to IANA for assignment. 338 Allocation Policy: Standards Action ([RFC5226]) 340 3.5 SCTP Function Codes for DDP Stream Session Control 342 Name of the registry: "SCTP Function Codes for DDP Session Control" 344 Namespace details: SCTP (Stream Control Transmission Protocol) 345 function codes for DDP session control are 16-bit values [RFC5043]. 347 Information that must be provided to assign a new value: An IESG- 348 approved standards-track specification defining the semantics and 349 interoperability requirements of the proposed new value and the 350 fields to be recorded in the registry. 352 Fields to record in the registry: SCTP Function Code, SCTP 353 Function Name, RFC Reference 355 Initial registry contents: 357 0x0001, DDP Stream Session Initiate, [RFC5043] 359 0x0002, DDP Stream Session Accept, [RFC5043] 361 0x0003, DDP Stream Session Reject, [RFC5043] 363 0x0004, DDP Stream Session Terminate, [RFC5043] 365 0xFFFF, Reserved (Experimental) [RFCXXXX] 367 RFC Editor: Please replace [RFCXXXX] in the above line with the RFC 368 number assigned to this document. 370 All other values are Unassigned and available to IANA for assignment. 372 Allocation Policy: Standards Action ([RFC5226]) 374 4. Normative References 376 [RFC5040] R. Recio et al., "An RDMA Protocol Specification", 377 RFC 5040, October 2007. 379 [RFC5041] H. Shah et al., "Direct Data Placement over Reliable 380 Transports", RFC 5041, October 2007. 382 [RFC5043] C. Bestler et al., "Stream Control Transmission Protocol 383 (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, 384 October 2007. 386 [RFC5044] P. Culley et al., "Marker PDU Aligned Framing for TCP 387 Specification", RFC 5044, October 2007. 389 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing 390 an IANA Considerations Section in RFCs", RFC 5226, BCP 26, 391 May 2008. 393 5. Informative References 395 [MPA-PEER] A. Kanevsky, et al., "Enhanced RDMA Connection 396 Establishment", draft-ietf-storm-mpa-peer-connect-09, work 397 in progress, December 2011. 399 [RDMAP-EXT] H. Shah, et al., "RDMA Protocol Extensions", 400 draft-ietf-storm-rdmap-ext-02, work in progress, January 2012. 402 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 403 Considered Useful", BCP 82, RFC 3692, January 2004. 405 6. Acknowledgments 407 IANA's review of a draft version of this document indicated 408 the need for some corrections; the authors thank IANA for 409 that review. The authors would also like to thank Pete Resnick 410 and Jari Arkko for their helpful comments from IESG review. 412 Author's Address 414 Michael Ko 415 Huawei Symantec 416 20245 Stevens Creek Blvd. 417 Cupertino, CA 95014, USA 418 Phone: +1-408-510-7465 419 Email: michael@huaweisymantec.com 421 David L. Black 422 EMC Corporation 423 176 South St. 424 Hopkinton, MA 01748, USA 425 Phone: +1-508-293-7953 426 Email: david.black@emc.com 428 Copyright Notice 430 Copyright (c) 2012 IETF Trust and the persons identified as the 431 document authors. All rights reserved. 433 This document is subject to BCP 78 and the IETF Trust's Legal 434 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 435 license-info) in effect on the date of publication of this document. 436 Please review these documents carefully, as they describe your 437 rights and restrictions with respect to this document. Code 438 Components extracted from this document must include Simplified 439 BSD License text as described in Section 4.e of the Trust Legal 440 Provisions and are provided without warranty as described in the 441 Simplified BSD License.