draft-ietf-rddp-applicability-03.txt   draft-ietf-rddp-applicability-04.txt 
Remote Direct Data Placement C. Bestler Remote Direct Data Placement C. Bestler
Working group Broadcom Working group Broadcom
Internet-Draft L. Coene Internet-Draft L. Coene
Expires: March 30, 2006 Siemens Expires: April 14, 2006 Siemens
September 26, 2005 October 11, 2005
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-03.txt draft-ietf-rddp-applicability-04.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 March 30, 2006. This Internet-Draft will expire on April 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 comparese and contrasts the different transport options over IP It comparese and contrasts the different transport options over IP
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6.6. Data Integrity Implications . . . . . . . . . . . . . . . 15 6.6. Data Integrity Implications . . . . . . . . . . . . . . . 15
6.6.1. MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 15 6.6.1. MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 15
6.6.2. SCTP Specifics . . . . . . . . . . . . . . . . . . . . 16 6.6.2. SCTP Specifics . . . . . . . . . . . . . . . . . . . . 16
6.7. Non-IP Transports . . . . . . . . . . . . . . . . . . . . 16 6.7. Non-IP Transports . . . . . . . . . . . . . . . . . . . . 16
6.7.1. No RDMA Layer Ack . . . . . . . . . . . . . . . . . . 16 6.7.1. No RDMA Layer Ack . . . . . . . . . . . . . . . . . . 16
6.8. Other IP Transports . . . . . . . . . . . . . . . . . . . 17 6.8. Other IP Transports . . . . . . . . . . . . . . . . . . . 17
6.9. LLP Independent Session Establishment . . . . . . . . . . 17 6.9. LLP Independent Session Establishment . . . . . . . . . . 17
6.9.1. RDMA-only Session Establishment . . . . . . . . . . . 18 6.9.1. RDMA-only Session Establishment . . . . . . . . . . . 18
6.9.2. RDMA-Conditional Session Establishment . . . . . . . . 18 6.9.2. RDMA-Conditional Session Establishment . . . . . . . . 18
7. Local Interface Implications . . . . . . . . . . . . . . . . . 20 7. Local Interface Implications . . . . . . . . . . . . . . . . . 20
8. Security considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Connection/Association Setup . . . . . . . . . . . . . . . 21 9. Security considerations . . . . . . . . . . . . . . . . . . . 22
8.2. Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 21 9.1. Connection/Association Setup . . . . . . . . . . . . . . . 22
8.3. Impact of Encrypted Transports . . . . . . . . . . . . . . 21 9.2. Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. Impact of Encrypted Transports . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Normative references . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
Remote Direct Memory Access Protocol (RDMAP) and Direct Data Remote Direct Memory Access Protocol (RDMAP) and Direct Data
Placement (DDP) work together to provide application independent Placement (DDP) work together to provide application independent
efficient placement of application payload directly into buffers efficient placement of application payload directly into buffers
specified by the Upper Layer Protocol (ULP). specified by the Upper Layer Protocol (ULP).
The DDP protocol is responsible for direct placement of received The DDP protocol is responsible for direct placement of received
payload into ULP specified buffers. The RDMAP protocol provides payload into ULP specified buffers. The RDMAP protocol provides
skipping to change at page 21, line 5 skipping to change at page 21, line 5
connection itself is used to determine whether RDMA is supported. connection itself is used to determine whether RDMA is supported.
7. Local Interface Implications 7. Local Interface Implications
Full utilization of DDP and RDMAP capabilities requires a local Full utilization of DDP and RDMAP capabilities requires a local
interface that explicitly requests these services. Protocols such as interface that explicitly requests these services. Protocols such as
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. Security considerations 8. IANA Considerations
8.1. Connection/Association Setup There are no IANA considerations in this document.
9. Security considerations
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.
8.2. Tagged Buffer Exposure 9.2. Tagged Buffer Exposure
DDP only exposes ULP memory to the extent explicitly allowed by ULP DDP only exposes ULP memory to the extent explicitly allowed by ULP
actions. These include posting of receive operations and enabling of actions. These include posting of receive operations and enabling of
Steering Tags. Steering Tags.
Neither RDMAP or DDP place requirements on how ULP's advertise Neither RDMAP or DDP place requirements on how ULP's advertise
buffers. A ULP may use a single Steering Tag for multiple buffer buffers. A ULP may use a single Steering Tag for multiple buffer
advertisements. However, the ULP should be aware that enforcement on advertisements. However, the ULP should be aware that enforcement on
STag usage is likely limited to the overall range that is enabled. STag usage is likely limited to the overall range that is enabled.
If the remote peer writes into the 'wrong' advertised buffer, neither If the remote peer writes into the 'wrong' advertised buffer, neither
the DDP or RDMAP layer will be aware of this. Nor is there any the DDP or RDMAP layer will be aware of this. Nor is there any
report to the ULP on how the remote peer specifically used tagged report to the ULP on how the remote peer specifically used tagged
buffers. buffers.
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.
8.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). If the LLP must decrypt in order, as Transport Layer Security (TLS). If the LLP must decrypt in order,
it cannot provide out-of-order DDP Segments to the DDP layer for it cannot provide out-of-order DDP Segments to the DDP layer for
placement purposes. IPsec tunnel mode encrypts entire IP Datagrams. placement purposes. IPsec tunnel mode encrypts entire IP Datagrams.
IPsec transport mode encrypts TCP Segments or SCTP packets. In IPsec transport mode encrypts TCP Segments or SCTP packets. In
neither case should IPsec preclude providing out-of-order DDP neither case should IPsec preclude providing out-of-order DDP
Segments to the DDP layer for placement. 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 IPsec cryptographic integrity protection
may allow suppression of MPA CRC generation and checking under may allow suppression of MPA CRC generation and checking under
certain circumstances. This is one example where the LLP may be certain circumstances. This is one example where the LLP may be
judged to have "or equivalent" protection to an end-to-end CRC32c. judged to have "or equivalent" protection to an end-to-end CRC32c.
9. References 10. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
Paxson, "Stream Control Transmission Protocol", RFC 2960, "Stream Control Transmission Protocol", RFC 2960, October 2000.
October 2000.
[5] Coene, L., "Stream Control Transmission Protocol Applicability [5] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", RFC 3257, April 2002. Statement", RFC 3257, April 2002.
[6] Recio, R., "An RDMA Protocol Specification", [6] 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.
[7] Shah, H., "Direct Data Placement over Reliable Transports", [7] 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.
[8] Stewart, R., "Stream Control Transmission Protocol (SCTP) [8] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote
Remote Direct Memory Access (RDMA) Direct Data Placement (DDP) Direct Memory Access (RDMA) Direct Data Placement (DDP)
Adaptationn", draft-ietf-rddp-sctp-02 (work in progress), Adaptationn", draft-ietf-rddp-sctp-02 (work in progress),
August 2005. August 2005.
[9] Culley, P., "Marker PDU Aligned Framing for TCP Specification", [9] Culley, P., "Marker PDU Aligned Framing for TCP Specification",
draft-ietf-rddp-mpa-02 (work in progress), February 2005. draft-ietf-rddp-mpa-02 (work in progress), February 2005.
[10] "Direct Access File System versino 1.0", September 2001.
[11] Pinkerton, J., "Sockets Direct Protocol (SDP) for iWARP over
TCP 1.0", October 2003.
Authors' Addresses Authors' Addresses
Caitlin Bestler Caitlin Bestler
Broadcom Broadcom
49 Discovery 49 Discovery
Irvine, CA 92618 Irvine, CA 92618
USA USA
Phone: 949-926-6383 Phone: 949-926-6383
Email: caitlinb@broadcom.com Email: caitlinb@broadcom.com
 End of changes. 12 change blocks. 
26 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/