draft-ietf-rddp-applicability-07.txt   draft-ietf-rddp-applicability-08.txt 
Remote Direct Data Placement C. Bestler Remote Direct Data Placement C. Bestler
Working group Broadcom Corporation Working group Broadcom Corporation
Internet-Draft L. Coene Internet-Draft L. Coene
Expires: December 1, 2006 Siemens Expires: December 23, 2006 Siemens
May 30, 2006 June 21, 2006
Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct
Data Placement (DDP) Data Placement (DDP)
draft-ietf-rddp-applicability-07.txt draft-ietf-rddp-applicability-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2006. This Internet-Draft will expire on December 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the applicability of Remote Direct Memory This document describes the applicability of Remote Direct Memory
Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).
It compares and contrasts the different transport options over IP It compares and contrasts the different transport options over IP
skipping to change at page 5, line 45 skipping to change at page 5, line 45
message sender. The message receiver is given no independent message sender. The message receiver is given no independent
indication that a tagged message has been received. indication that a tagged message has been received.
Untagged Message A DDP message that is directed to a ULP specified Untagged Message A DDP message that is directed to a ULP specified
buffer based upon a Message Sequence Number being matched with a buffer based upon a Message Sequence Number being matched with a
receiver supplied buffer. The destination buffer is specified by receiver supplied buffer. The destination buffer is specified by
the message receiver. The message receiver is notified by some the message receiver. The message receiver is notified by some
mechanism that an untagged message has been received. mechanism that an untagged message has been received.
Upper Layer Protocol (ULP) The direct user of RDMAP/DDP services. In Upper Layer Protocol (ULP) The direct user of RDMAP/DDP services. In
addition to protocols such as iSER [8] and NFSv4 over RDMA [9], addition to protocols such as iSER [7] and NFSv4 over RDMA [8],
the ULP may be embedded in an application, or a middleware layer the ULP may be embedded in an application, or a middleware layer
as is often the case for the Sockets Direct Protocol (SDP) and as is often the case for the Sockets Direct Protocol (SDP) and
Remote Procedure Call (RPC) protocols. Remote Procedure Call (RPC) protocols.
3. Direct Placement 3. Direct Placement
Direct Data Placement optimizes the placement of ULP payload into the Direct Data Placement optimizes the placement of ULP payload into the
correct destination buffers, typically eliminating intermediate correct destination buffers, typically eliminating intermediate
copying. Placement is enabled without regard to order of arrival, copying. Placement is enabled without regard to order of arrival,
order of transmission or requiring per-placement interaction with the order of transmission or requiring per-placement interaction with the
skipping to change at page 16, line 35 skipping to change at page 16, line 35
A ULP that requires a greater degree of protection may add it own. A ULP that requires a greater degree of protection may add it own.
However, DDP and RDMAP headers will only be guaranteed to have the However, DDP and RDMAP headers will only be guaranteed to have the
equivalent of end-to-end CRC32c protection. A ULP that requires data equivalent of end-to-end CRC32c protection. A ULP that requires data
integrity checking more thorough than an end-to-end CRC32c should integrity checking more thorough than an end-to-end CRC32c should
first invalidate all STags that reference a buffer before applying first invalidate all STags that reference a buffer before applying
their own integrity check. their own integrity check.
CRC32c only provides protection against random corruption. To CRC32c only provides protection against random corruption. To
protect against unauthorized alteration or forging of data packets protect against unauthorized alteration or forging of data packets
security methods must be applied. The security draft [RDMA-Security] security methods must be applied. The security draft [RDMA-Security]
[7] specifies usage of RFC2406 [2] for both adaptation layers. [6] specifies usage of RFC2406 [1] for both adaptation layers.
6.6.1. MPA/TCP Specifics 6.6.1. MPA/TCP Specifics
It is mandatory for MPA/TCP implementations to implement CRC32c, but It is mandatory for MPA/TCP implementations to implement CRC32c, but
it is NOT mandatory to use the CRC32c during an RDMA connection. The it is NOT mandatory to use the CRC32c during an RDMA connection. The
activating or deactivating of the CRC in MPA/TCP is an administrative activating or deactivating of the CRC in MPA/TCP is an administrative
configuration operation at the local and remote end. The configuration operation at the local and remote end. The
administration of the CRC(ON/OFF) is invisible to the ULP. administration of the CRC(ON/OFF) is invisible to the ULP.
Applications SHOULD trust that this administrative option will only Applications SHOULD trust that this administrative option will only
skipping to change at page 23, line 7 skipping to change at page 23, line 7
Sockets Direct Protocol (SDP) can allow applications to keep their Sockets Direct Protocol (SDP) can allow applications to keep their
traditional byte-stream or message-stream interface and still enjoy traditional byte-stream or message-stream interface and still enjoy
many of the benefits of the optimized wire level protocols. many of the benefits of the optimized wire level protocols.
8. IANA Considerations 8. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
9. Security considerations 9. Security considerations
RDMA security considerations are discussed in [RDMA-SEC] [7]. This RDMA security considerations are discussed in [RDMA-SEC] [6]. This
document will only deal with the more usage oriented aspects, and document will only deal with the more usage oriented aspects, and
where there are implications in the choice of underlying transport. where there are implications in the choice of underlying transport.
9.1. Connection/Association Setup 9.1. Connection/Association Setup
Both the SCTP and TCP adaptations allow for existing procedures to be Both the SCTP and TCP adaptations allow for existing procedures to be
followed for the establishment of the SCTP association or TCP followed for the establishment of the SCTP association or TCP
connection. Use of DDP does not impair the use of any security connection. Use of DDP does not impair the use of any security
measures to filter, validate and/or log the remote end of an measures to filter, validate and/or log the remote end of an
association/connection. association/connection.
skipping to change at page 23, line 44 skipping to change at page 23, line 44
Unless the ULP peers have an adequate basis for mutual trust, the Unless the ULP peers have an adequate basis for mutual trust, the
receiving ULP might be well advised to use a distinct STag for each receiving ULP might be well advised to use a distinct STag for each
interaction, and to invalidate it after each use or to require its interaction, and to invalidate it after each use or to require its
peer to use the RDMAP option to invalidate the STag with its peer to use the RDMAP option to invalidate the STag with its
responding untagged message. responding untagged message.
9.3. Impact of Encrypted Transports 9.3. Impact of Encrypted Transports
While DDP is cleanly layered over the LLP, its maximum benefit may be While DDP is cleanly layered over the LLP, its maximum benefit may be
limited when the LLP Stream is secured with a streaming cypher, such limited when the LLP Stream is secured with a streaming cypher, such
as Transport Layer Security (TLS) RFC2246 [1]. If the LLP must as Transport Layer Security (TLS) RFC4346 [9]. If the LLP must
decrypt in order, it cannot provide out-of-order DDP Segments to the decrypt in order, it cannot provide out-of-order DDP Segments to the
DDP layer for placement purposes. IPsec RFC2406 [2]. tunnel mode DDP layer for placement purposes. IPsec RFC2406 [1]. tunnel mode
encrypts entire IP Datagrams. IPsec transport mode encrypts TCP encrypts entire IP Datagrams. IPsec transport mode encrypts TCP
Segments or SCTP packets. In neither case should IPsec preclude Segments or SCTP packets, as does use of DTLS RFC4347 [10] over UDP
beneath TCP or SCTP. Neither IPsec nor this use of DTLS preclude
providing out-of-order DDP Segments to the DDP layer for placement. providing out-of-order DDP Segments to the DDP layer for placement.
Note that end-to-end use of IPsec cryptographic integrity protection Note that end-to-end use of cryptographic integrity protection may
may allow suppression of MPA CRC generation and checking under allow suppression of MPA CRC generation and checking under certain
certain circumstances. This is one example where the LLP may be circumstances. This is one example where the LLP may be judged to
judged to have "or equivalent" protection to an end-to-end CRC32c. have "or equivalent" protection to an end-to-end CRC32c.
10. References 10. References
10.1. Normative references 10.1. Normative references
[1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [1] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
RFC 2246, January 1999.
[2] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[3] Recio, R., "An RDMA Protocol Specification", [2] Recio, R., "An RDMA Protocol Specification",
draft-ietf-rddp-rdmap-05 (work in progress), July 2005. draft-ietf-rddp-rdmap-05 (work in progress), July 2005.
[4] Shah, H., "Direct Data Placement over Reliable Transports", [3] Shah, H., "Direct Data Placement over Reliable Transports",
draft-ietf-rddp-ddp-05 (work in progress), July 2005. draft-ietf-rddp-ddp-05 (work in progress), July 2005.
[5] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote [4] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote
Direct Memory Access (RDMA) Direct Data Placement (DDP) Direct Memory Access (RDMA) Direct Data Placement (DDP)
Adaptation", draft-ietf-rddp-sctp-02 (work in progress), Adaptation", draft-ietf-rddp-sctp-03 (work in progress),
August 2005. June 2006.
[6] Culley, P., "Marker PDU Aligned Framing for TCP Specification", [5] Culley, P., "Marker PDU Aligned Framing for TCP Specification",
draft-ietf-rddp-mpa-03 (work in progress), October 2005. draft-ietf-rddp-mpa-04 (work in progress), May 2006.
[7] Pinkerton, J., "DDP/RDMAP Security", draft-ietf-rddp-security-09 [6] Pinkerton, J., "DDP/RDMAP Security", draft-ietf-rddp-security-09
(work in progress), May 2006. (work in progress), May 2006.
10.2. Informative References 10.2. Informative References
[8] Ko, M., "iSCSI Extensions for RDMA Specification", October 2005. [7] Ko, M., "iSCSI Extensions for RDMA Specification",
draft-ietf-ips-iser-05 (work in progress), October 2005.
[9] Callaghan, B. and T. Talpey, "NFS Direct Data Placemetn", [8] Callaghan, B. and T. Talpey, "NFS Direct Data Placement",
draft-ietf-nfsv4-nfsdirect-02 (work in progress), October 2005. draft-ietf-nfsv4-nfsdirect-02 (work in progress), October 2005.
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[10] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
Authors' Addresses Authors' Addresses
Caitlin Bestler Caitlin Bestler
Broadcom Corporation Broadcom Corporation
16215 Alton Parkway 16215 Alton Parkway
P.O. Box 57013 P.O. Box 57013
Irvine, CA 92619-7013 Irvine, CA 92619-7013
USA USA
Phone: 949-926-6383 Phone: 949-926-6383
 End of changes. 20 change blocks. 
28 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/