idnits 2.17.1 draft-ietf-rddp-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DAFS' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'FIBRE' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'IB' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'MYR' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'SDP' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'SRVNET' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'VI' is defined on line 737, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DAFS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIBRE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB' -- Possible downref: Non-RFC (?) normative reference: ref. 'MYR' -- Possible downref: Non-RFC (?) normative reference: ref. 'RDDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROM' ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRVNET' -- Possible downref: Non-RFC (?) normative reference: ref. 'VI' Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Stephen Bailey (Sandburst) 3 Expires: August 2003 Tom Talpey (NetApp) 5 The Architecture of Direct Data Placement (DDP) 6 And Remote Direct Memory Access (RDMA) 7 On Internet Protocols 8 draft-ietf-rddp-arch-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines an abstract architecture for Direct Data 39 Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to 40 run on Internet Protocol-suite transports. This architecture does 41 not necessarily reflect the proper way to implement such protocols, 42 but is, rather, a descriptive tool for defining and understanding 43 the protocols. 45 Table Of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Architecture . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Direct Data Placement (DDP) Protocol Architecture . . . 3 50 2.1.1. Transport Operations . . . . . . . . . . . . . . . . . . 5 51 2.1.2. DDP Operations . . . . . . . . . . . . . . . . . . . . . 6 52 2.1.3. Transport Characteristics in DDP . . . . . . . . . . . . 9 53 2.2. Remote Direct Memory Access Protocol Architecture . . . 11 54 2.2.1. RDMA Operations . . . . . . . . . . . . . . . . . . . . 12 55 2.2.2. Transport Characteristics in RDMA . . . . . . . . . . . 14 56 3. Security Considerations . . . . . . . . . . . . . . . . 15 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . 15 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 15 59 References . . . . . . . . . . . . . . . . . . . . . . . 16 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . 16 61 Full Copyright Statement . . . . . . . . . . . . . . . . 17 63 1. Introduction 65 This document defines an abstract architecture for Direct Data 66 Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to 67 run on Internet Protocol-suite transports [RDDP, ROM]. This 68 architecture does not necessarily reflect the proper way to 69 implement such protocols, but is, rather, a descriptive tool for 70 defining and understanding the protocols. 72 The first part of the document describes the architecture of DDP 73 protocols, including what assumptions are made about the transports 74 on which DDP is built. The second part describes the architecture 75 of RDMA protocols layered on top of DDP. 77 Before introducing the protocols, three definitions will be useful 78 to guide discussion: 80 o Placement - writing to a data buffer. 82 o Delivery - informing the Upper Layer Protocol (ULP) (e.g. 83 RDMA) that a particular message is available for use. 84 Delivery therefore may be viewed as the "control" signal 85 associated with a unit of data. Note that the order of 86 delivery is defined more strictly than it is for placement. 88 o Completion - informing the ULP or application that a 89 particular RDMA operation has finished. A completion, for 90 instance, may require the delivery of several messages, or it 91 may also reflect that some local processing has finished. 93 The goal of the DDP protocol is to allow the efficient placement of 94 data into buffers designated by Upper Layer Protocols (e.g. RDMA). 95 This is described in detail in [ROM]. Efficiency may be 96 characterized by the minimization of the number of transfers of the 97 data over the receiver's system buses. 99 The goal of the RDMA protocol is to provide the semantics to enable 100 Remote Direct Memory Access between peers in a way consistent with 101 application requirements. The RDMA protocol provides facilities 102 immediately useful to existing and future networking, storage, and 103 other application protocols. [DAFS, FIBRE, IB, MYR, SDP, SRVNET, 104 VI] 106 The DDP and RDMA protocols work together to achieve their 107 respective goals. RDMA provides facilities to a ULP for 108 identifying buffers, controlling the transfer of data between ULP 109 peers, and providing completion notifications to the ULP. RDMA 110 uses the features of DDP to steer payloads to specific buffers at 111 the Data Sink. ULPs that do not require the features of RDMA may 112 be layered directly on top of DDP. 114 The DDP and RDMA protocols are transport independent. The 115 following figure shows the relationship between RDMA, DDP, Upper 116 Layer Protocols and Transport. 118 +---------------------------------------------------+ 119 | ULP | 120 +---------+------------+----------------------------+ 121 | | | RDMA | 122 | | +----------------------------+ 123 | | DDP | 124 | +-----------------------------------------+ 125 | Transport | 126 +---------------------------------------------------+ 128 2. Architecture 130 The Architecture section is presented in two parts: Direct Data 131 Placement Protocol architecture and Remote Direct Memory Access 132 Protocol architecture. 134 2.1. Direct Data Placement (DDP) Protocol Architecture 136 The central idea of general-purpose DDP is that a data sender will 137 supplement the data it sends with placement information that allows 138 the receiver's network interface to place the data directly at its 139 final destination without any copying. DDP can be used to steer 140 received data to its final destination, without requiring layer- 141 specific behavior for each different layer. Data sent with such 142 DDP information is said to be `tagged'. 144 The central component of the DDP architecture is the `buffer', 145 which is an object with beginning and ending addresses, and a 146 method (set()) to set the value of an octet at an address. In many 147 cases, a buffer corresponds directly to a portion of host user 148 memory. However, DDP does not depend on this---a buffer could be a 149 disk file, or anything else that can be viewed as an addressable 150 collection of octets. Abstractly, a buffer provides the interface: 152 typedef struct { 153 const address_t start; 154 const address_t end; 155 void set(address_t a, data_t v); 156 } ddp_buffer_t; 158 address_t 160 a reference to local memory 162 data_t 164 an octet data value. 166 The protocol layering and in-line data flow of DDP is: 168 Client Protocol 169 (e.g. ULP or RDMA) 170 | ^ 171 untagged messages | | untagged message delivery 172 tagged messages | | tagged message delivery 173 v | 174 DDP+---> data placement 175 ^ 176 | transport messages 177 v 178 Transport 179 (e.g. SCTP, DCP, framed TCP) 180 ^ 181 | IP datagrams 182 v 183 . . . 185 In addition to in-line data flow, the client protocol registers 186 buffers with DDP, and DDP performs buffer update (set()) operations 187 as a result of receiving tagged messages. 189 DDP messages may be split into multiple, smaller DDP messages, each 190 in a separate transport message. However, if the transport is 191 unreliable or unordered, messages split across transport messages 192 may or may not provide useful behavior, in the same way as 193 splitting arbitrary upper layer messages across unreliable or 194 unordered transport messages may or may not provide useful 195 behavior. In other words, the same considerations apply to 196 building client protocols on different types of transports with or 197 without the use of DDP. 199 A DDP message split across transport messages looks like: 201 DDP message: Transport messages: 203 stag=s, offset=o, message 1: 204 notify=y, id=i |type=ddp | 205 message= |stag=s | 206 |aabbccddee|-------. |offset=o | 207 ~ ... ~----. \ |notify=n | 208 |vvwwxxyyzz|-. \ \ |id=? | 209 | \ `--->|aabbccddee| 210 | \ ~ ... ~ 211 | +----->|iijjkkllmm| 212 | | 213 + | message 2: 214 \ | |type=ddp | 215 \ | |stag=s | 216 \ + |offset=o+n| 217 \ \ |notify=y | 218 \ \ |id=i | 219 \ `-->|nnooppqqrr| 220 \ ~ ... ~ 221 `---->|vvwwxxyyzz| 223 Although this picture suggests that DDP information is carried in- 224 line with the message payload, components of the DDP information 225 may also be in transport-specific fields, or derived from 226 transport-specific control information if the transport permits. 228 2.1.1. Transport Operations 230 For the purposes of this architecture, the transport provides: 232 void xpt_send(socket_t s, message_t m); 233 message_t xpt_recv(socket_t s); 234 msize_t xpt_max_msize(socket_t s); 236 socket_t 238 a transport address, including IP addresses, ports and other 239 transport-specific identifiers. 241 message_t 243 a string of octets. 245 msize_t (scalar) 247 a message size. 249 xpt_send(socket_t s, message_t m) 251 send a transport message. 253 xpt_recv(socket_t s) 255 receive a transport message. 257 xpt_max_msize(socket_t s) 259 get the current maximum transport message size. Corresponds, 260 roughly, to the current path Maximum Transfer Unit (PMTU), 261 adjusted by underlying protocol overheads. 263 Real implementations of xpt_send() and xpt_recv() typically return 264 error indications, but that is not relevant to this architecture. 266 2.1.2. DDP Operations 268 The DDP layer provides: 270 void ddp_send(socket_t s, message_t m); 271 void ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d, 272 ddp_notify_t n); 273 void ddp_post_recv(socket_t s, bdesc_t b); 274 ddp_ind_t ddp_recv(socket_t s); 275 bdesc_t ddp_register(socket_t s, ddp_buffer_t b); 276 void ddp_deregister(bhand_t bh); 277 msizes_t ddp_max_msizes(socket_t s); 279 ddp_addr_t 281 the buffer address portion of a tagged message: 283 typedef struct { 284 stag_t stag; 285 address_t offset; 286 } ddp_addr_t; 288 stag_t (scalar) 290 a Steering Tag. A stag_t identifies the destination buffer 291 for tagged messages. stag_ts are generated when the buffer is 292 registered, communicated to the sender by some client protocol 293 convention and inserted in DDP messages. stag_t values in 294 this DDP architecture are assumed to be completely opaque to 295 the client protocol, and implementation-dependent. However, 296 particular implementations, such as DDP on a multicast 297 transport (see below), may provide the buffer holder some 298 control in selecting stag_ts. 300 ddp_notify_t 302 the notification portion of a DDP message, used to signal that 303 the message represents the final fragment of a multi-segmented 304 DDP message: 306 typedef struct { 307 boolean_t notify; 308 ddp_msg_id_t i; 309 } ddp_notify_t; 311 ddp_msg_id_t (scalar) 313 a DDP message identifier. msg_id_ts are chosen by the DDP 314 message receiver (buffer holder), communicated to the sender 315 by some client protocol convention and inserted in DDP 316 messages. Whether a message reception indication is requested 317 for a DDP message is a matter of client protocol convention. 318 Unlike stag_ts, the structure of msg_id_ts is opaque to DDP, 319 and therefore, completely in the hands of the client protocol. 321 bdesc_t 323 a description of a registered buffer: 325 typedef struct { 326 bhand_t bh; 327 ddp_addr_t a; 328 } bdesc_t; 330 `a.offset' is the starting offset of the registered buffer, 331 which may have no relationship to the `start' or `end' 332 addresses of that buffer. However, particular 333 implementations, such as DDP on a multicast transport (see 334 below), may allow some client protocol control over the 335 starting offset. 337 bhand_t 339 an opaque buffer handle used to deregister a buffer. 341 recv_message_t 343 a description of a completed untagged receive buffer: 345 typedef struct { 346 bdesc_t b; 347 length l; 348 } recv_message_t; 350 ddp_ind_t 352 an untagged message, a tagged message reception indication, or 353 a tagged message reception error: 355 typedef union { 356 recv_message_t m; 357 ddp_msg_id_t i; 358 ddp_err_t e; 359 } ddp_ind_t; 361 ddp_err_t 363 indicates an error while receiving a tagged message, typically 364 `offset' out of bounds, or `stag' is not registered to the 365 socket. 367 msizes_t 368 The maximum untagged and tagged messages that fit in a single 369 transport message: 371 typedef struct { 372 msize_t max_untagged; 373 msize_t max_tagged; 374 } msizes_t; 376 ddp_send(socket_t s, message_t m) 378 send an untagged message. 380 ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d, ddp_notify_t n) 382 send a tagged message to remote buffer address d. 384 ddp_post_recv(socket_t s, bdesc_t b) 386 post a registered buffer to accept received untagged messages. 388 ddp_recv(socket_t s) 390 get the next received untagged message, tagged message 391 reception indication, or tagged message error. 393 ddp_register(socket_t s, ddp_buffer_t b) 395 register a buffer for DDP on a socket. The same buffer may be 396 registered multiple times on the same or different sockets. 397 The same buffer registered on different sockets may result in 398 a common registration. Different buffers may also refer to 399 portions of the same underlying addressable object (buffer 400 aliasing). 402 ddp_deregister(bhand_t bh) 404 remove a registration from a buffer. 406 ddp_max_msizes(socket_t s) 408 get the current maximum untagged and tagged message sizes that 409 will fit in a single transport message. 411 2.1.3. Transport Characteristics In DDP 413 Certain characteristics of the transport on which DDP is mapped 414 determine the nature of the service provided to client protocols. 416 Specifically, transports are: 418 o reliable or unreliable, 420 o ordered or unordered, 422 o single source or multisource, 424 o single destination or multidestination (multicast or anycast). 426 Some transports support several combinations of these 427 characteristics. For example, SCTP [SCTP] is reliable, single 428 source, single destination (point-to-point) and supports both 429 ordered and unordered modes. 431 In general, these transport characteristics equally affect 432 transport and DDP message delivery. However, there are several 433 issues specific to DDP messages. 435 DDP messages carried by transport are framed for processing by the 436 receiver, and may be further protected for integrity or privacy in 437 accordance with the transport capabilities. DDP does not provide 438 such functions. 440 A key component of DDP is how the following operations on the 441 receiving side are ordered among themselves, and how they relate to 442 corresponding operations on the sending side: 444 o set()s, 446 o untagged message reception indications, and 448 o tagged message reception indications. 450 These relationships depend upon the characteristics of the 451 underlying transport in a way which is defined by the DDP protocol. 452 For example, if the transport is unreliable and unordered, the DDP 453 protocol might specify that the client protocol is subject to the 454 consequences of transport messages being lost or duplicated, rather 455 requiring different characteristics be presented to the client 456 protocol. 458 Multidestination data delivery is the other transport 459 characteristic which may require specific consideration in a DDP 460 protocol. As mentioned above, the basic DDP model assumes that 461 buffer address values returned by ddp_register() are opaque to the 462 client protocol, and can be implementation dependent. The most 463 natural way to map DDP to a multidestination transport is to 464 require all receivers produce the same buffer address when 465 registering a multidestination destination buffer. Restriction of 466 the DDP model to accommodate multiple destinations involves 467 engineering tradeoffs comparable to those of providing non-DDP 468 multidestination transport capability. 470 2.2. Remote Direct Memory Access (RDMA) Protocol Architecture 472 Remote Direct Memory Access (RDMA) extends the capabilities of DDP 473 with the ability to read from buffers registered to a socket (RDMA 474 Read). This allows a client protocol to perform arbitrary, 475 bidirectional data movement without involving the remote client. 476 When RDMA is implemented in hardware, arbitrary data movement can 477 be performed without involving the remote host CPU at all. 479 In addition, RDMA protocols usually specify a transport-independent 480 untagged message service (Send) with characteristics which are both 481 very efficient to implement in hardware, and convenient for client 482 protocols. 484 The RDMA architecture is patterned after the traditional model for 485 device programming, where the client requests an operation using 486 Send-like actions (programmed I/O), the server performs the 487 necessary data transfers for the operation (DMA reads and writes), 488 and notifies the client of completion. The programmed I/O+DMA 489 model efficiently supports a high degree of concurrency and 490 flexibility for both the client and server, even when operations 491 have a wide range of intrinsic latencies. 493 RDMA is layered as a client protocol on top of DDP: 495 Client Protocol 496 | ^ 497 Sends | | Send reception indications 498 RDMA Read Requests | | RDMA Read Completion indications 499 RDMA Writes | | RDMA Write Completion indications 500 v | 501 RDMA 502 | ^ 503 untagged messages | | untagged message delivery 504 tagged messages | | tagged message delivery 505 v | 506 DDP+---> data placement 507 ^ 508 | transport messages 509 v 510 . . . 512 In addition to in-line data flow, read (get()) and update (set()) 513 operations are performed on buffers registered with RDMA as a 514 result of RDMA Read Requests and RDMA Writes, respectively. 516 An RDMA `buffer' extends a DDP buffer with a get() operation that 517 retrieves the value of the octet at address `a': 519 typedef struct { 520 const address_t start; 521 const address_t end; 522 void set(address_t a, data_t v); 523 data_t get(address_t a); 524 } rdma_buffer_t; 526 2.2.1. RDMA Operations 528 The RDMA layer provides: 530 void rdma_send(socket_t s, message_t m); 531 void rdma_write(socket_t s, message_t m, ddp_addr_t d, 532 rdma_notify_t n); 533 void rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d); 534 void rdma_post_recv(socket_t s, bdesc_t b); 535 rdma_ind_t rdma_recv(socket_t s); 536 bdesc_t rdma_register(socket_t s, rdma_buffer_t b, 537 bmode_t mode); 538 void rdma_deregister(bhand_t bh); 539 msizes_t rdma_max_msizes(socket_t s); 541 Although, for clarity, these data transfer interfaces are 542 synchronous, rdma_read() and possibly rdma_send() (in the presence 543 of Send flow control), can require an arbitrary amount of time to 544 complete. To express the full concurrency and interleaving of RDMA 545 data transfer, these interfaces should also be reentrant. For 546 example, a client protocol may perform an rdma_send(), while an 547 rdma_read() operation is in progress. 549 rdma_notify_t 551 RDMA Write notification information, used to signal that the 552 message represents the final fragment of a multi-segmented 553 RDMA message: 555 typedef struct { 556 boolean_t notify; 557 rdma_write_id_t i; 558 } rdma_notify_t; 560 identical in function to ddp_notify_t, except that the type 561 rdma_write_id_t may not be equivalent to ddp_msg_id_t. 563 rdma_write_id_t (scalar) 565 an RDMA Write identifier. 567 rdma_ind_t 569 a Send message, or an RDMA error: 571 typedef union { 572 recv_message_t m; 573 rdma_err_t e; 574 } rdma_ind_t; 576 rdma_err_t 578 an RDMA protocol error indication. RDMA errors include buffer 579 addressing errors corresponding to ddp_err_ts, and buffer 580 protection violations (e.g. RDMA Writing a buffer only 581 registered for reading). 583 bmode_t 585 buffer registration mode (permissions). Any combination of 586 permitting RDMA Read (BMODE_READ) and RDMA Write (BMODE_WRITE) 587 operations. 589 rdma_send(socket_t s, message_t m) 591 send a message, delivering it to the next untagged RDMA buffer 592 at the remote peer. 594 rdma_write(socket_t s, message_t m, ddp_addr_t d, rdma_notify_t n) 596 RDMA Write to remote buffer address d. 598 rdma_read(socket_t s, ddp_addr_t s, length l, ddp_addr_t d) 600 RDMA Read l octets from remote buffer address s to local 601 buffer address d. 603 rdma_post_recv(socket_t s, bdesc_t b) 605 post a registered buffer to accept received Send messages. 607 rdma_recv(socket_t s); 609 get the next received Send message, RDMA Write completion 610 identifier, or RDMA error. 612 rdma_register(socket_t s, rdma_buffer_t b, bmode_t mode) 614 register a buffer for RDMA on a socket (for read access, write 615 access or both). As with DDP, the same buffer may be 616 registered multiple times on the same or different sockets, 617 and different buffers may refer to portions of the same 618 underlying addressable object. 620 rdma_deregister(bhand_t bh) 622 remove a registration from a buffer. 624 rdma_max_msizes(socket_t s) 626 get the current maximum Send (max_untagged) and RDMA Read or 627 Write (max_tagged) operations that will fit in a single 628 transport message. The values returned by rdma_max_msizes() 629 are closely related to the values returned by 630 ddp_max_msizes(), but may not be equal. 632 2.2.2. Transport Characteristics In RDMA 634 As with DDP, RDMA can be used on transports with a variety of 635 different characteristics that manifest themselves directly in the 636 service provided by RDMA. 638 Like DDP, an RDMA protocol must specify how: 640 o set()s, 642 o get()s, 644 o Send messages, and 646 o RDMA Read completions 648 are ordered among themselves and how they relate to corresponding 649 operations on the remote peer(s). These relationships are likely 650 to be a function of the underlying transport characteristics. 652 There are some additional characteristics of RDMA which may 653 translate poorly to unreliable or multipoint transports due to 654 attendant complexities in managing endpoint state: 656 o Send flow control 658 o RDMA Read 660 These difficulties can be overcome by placing restrictions on the 661 service provided by RDMA. However, many RDMA clients, especially 662 those that separate data transfer and application logic concerns, 663 are likely to depend upon capabilities only provided by RDMA on a 664 point-to-point, reliable transport. 666 3. Security Considerations 668 System integrity must be maintained in any RDMA solution. 669 Mechanisms must be specified to prevent RDMA or DDP operations from 670 impairing system integrity. For example, the threat caused by 671 potential buffer overflow needs full examination, and prevention 672 mechanisms must be spelled out. 674 Because a Steering Tag exports access to a memory region, one 675 critical aspect of security is the scope of this access. It must 676 be possible to individually control specific attributes of the 677 access provided by a Steering Tag, including remote read access, 678 remote write access, and others that might be identified. A 679 specification must provide both implementation requirements 680 relevant to this issue, and guidelines to assist implementors in 681 making the appropriate design decisions. 683 Resource issues leading to denial-of-service attacks, overwrites 684 and other concurrent operations, the ordering of completions as 685 required by the RDMA protocol, and the granularity of transfer are 686 all within the required scope of any security analysis of RDMA and 687 DDP. 689 4. IANA Considerations 691 IANA considerations are not addressed in by this document. Any 692 IANA considerations resulting from the use of DDP or RDMA must be 693 addressed in the relevant standards. 695 5. Acknowledgements 697 The authors wish to acknowledge the valuable contributions of David 698 Black, Jeff Mogul and Allyn Romanow. 700 6. References 702 [DAFS] 703 Direct Access File System http://www.dafscollaborative.org 704 http://www.ietf.org/internet-drafts/draft-wittle-dafs-00.txt 706 [FIBRE] 707 Fibre Channel Standard 708 http://www.fibrechannel.com/technology/index.master.html 710 [IB] InfiniBand Architecture Specification, Volumes 1 and 2, 711 Release 1.0.a. http://www.infinibandta.org 713 [MYR] 714 Myrinet, http://www.myricom.com 716 [RDDP] 717 Remote Direct Data Placement Working Group charter, 718 http://www.ietf.org/html.charters/rddp-charter.html 720 [ROM] 721 A. Romanow, J. Mogul, T. Talpey, S. Bailey, "RDMA over IP 722 Problem Statement", http://www.ietf.org/internet-drafts/draft- 723 ietf-rddp-problem-statement-01.txt, Work in Progress, February 724 2003 726 [SCTP] 727 R. Stewart et al., "Stream Transmission Control Protocol", 728 Standards Track RFC, http://www.ietf.org/rfc/rfc2960.txt 730 [SDP] 731 Sockets Direct Protocol v1.0 733 [SRVNET] 734 Compaq Servernet, 735 http://nonstop.compaq.com/view.asp?PAGE=ServerNet 737 [VI] Virtual Interface Architecture Specification Version 1.0. 738 http://www.vidf.org/info/04standards.html 740 Authors' Addresses 741 Stephen Bailey 742 Sandburst Corporation 743 600 Federal Street 744 Andover, MA 01810 USA 745 USA 747 Phone: +1 978 689 1614 748 Email: steph@sandburst.com 750 Tom Talpey 751 Network Appliance 752 375 Totten Pond Road 753 Waltham, MA 02451 USA 755 Phone: +1 781 768 5329 756 Email: thomas.talpey@netapp.com 758 Full Copyright Statement 760 Copyright (C) The Internet Society (2003). All Rights Reserved. 762 This document and translations of it may be copied and furnished to 763 others, and derivative works that comment on or otherwise explain 764 it or assist in its implementation may be prepared, copied, 765 published and distributed, in whole or in part, without restriction 766 of any kind, provided that the above copyright notice and this 767 paragraph are included on all such copies and derivative works. 768 However, this document itself may not be modified in any way, such 769 as by removing the copyright notice or references to the Internet 770 Society or other Internet organizations, except as needed for the 771 purpose of developing Internet standards in which case the 772 procedures for copyrights defined in the Internet Standards process 773 must be followed, or as required to translate it into languages 774 other than English. 776 The limited permissions granted above are perpetual and will not be 777 revoked by the Internet Society or its successors or assigns. 779 This document and the information contained herein is provided on 780 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 781 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 782 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 783 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 784 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.