draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06.txt   draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Updates: 8166 (if approved) January 2, 2020 Updates: 8166 (if approved) January 31, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: July 5, 2020 Expires: August 3, 2020
RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1 RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07
Abstract Abstract
This document specifies the format of RDMA-CM Private Data exchanged This document specifies the format of RDMA-CM Private Data exchanged
between RPC-over-RDMA version 1 peers as part of establishing a between RPC-over-RDMA version 1 peers as part of establishing a
connection. The addition of the private data payload specified in connection. The addition of the private data payload specified in
this document is an optional extension that does not alter the RPC- this document is an optional extension that does not alter the RPC-
over-RDMA version 1 protocol. This document updates RFC 8166. over-RDMA version 1 protocol. This document updates RFC 8166.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 5, 2020. This Internet-Draft will expire on August 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4.1.2. Interoperability Amongst RDMA Transports . . . . . . 7 4.1.2. Interoperability Amongst RDMA Transports . . . . . . 7
5. Updating the Message Format . . . . . . . . . . . . . . . . . 7 5. Updating the Message Format . . . . . . . . . . . . . . . . . 7
5.1. Feature Support Flags . . . . . . . . . . . . . . . . . . 8 5.1. Feature Support Flags . . . . . . . . . . . . . . . . . . 8
5.2. Inline Threshold Values . . . . . . . . . . . . . . . . . 8 5.2. Inline Threshold Values . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Guidance for Designated Experts . . . . . . . . . . . . . 10 7.1. Guidance for Designated Experts . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The RPC-over-RDMA version 1 transport protocol [RFC8166] enables The RPC-over-RDMA version 1 transport protocol [RFC8166] enables
payload data transfer using Remote Direct Memory Access (RDMA) for payload data transfer using Remote Direct Memory Access (RDMA) for
upper-layer protocols based on Remote Procedure Calls (RPC) upper-layer protocols based on Remote Procedure Calls (RPC)
[RFC5531]. The terms "Remote Direct Memory Access" (RDMA) and [RFC5531]. The terms "Remote Direct Memory Access" (RDMA) and
"Direct Data Placement" (DDP) are introduced in [RFC5040]. "Direct Data Placement" (DDP) are introduced in [RFC5040].
skipping to change at page 4, line 7 skipping to change at page 4, line 7
3. Advertised Transport Properties 3. Advertised Transport Properties
3.1. Inline Threshold Size 3.1. Inline Threshold Size
Section 3.3.2 of [RFC8166] defines the term "inline threshold." An Section 3.3.2 of [RFC8166] defines the term "inline threshold." An
inline threshold is the maximum number of bytes that can be inline threshold is the maximum number of bytes that can be
transmitted using one RDMA Send and one RDMA Receive. There are a transmitted using one RDMA Send and one RDMA Receive. There are a
pair of inline thresholds for a connection: a client-to-server pair of inline thresholds for a connection: a client-to-server
threshold and a server-to-client threshold. threshold and a server-to-client threshold.
If an incoming message exceeds the size of a receiver's inline If an incoming RDMA message exceeds the size of a receiver's inline
threshold, the receive operation fails and the connection is threshold, the receive operation fails and the RDMA provider
typically terminated. To convey a message larger than a receiver's typically terminates the connection. To convey an RPC message larger
inline threshold, an NFS client uses explicit RDMA data transfer than the receiver's inline threshold without risking receive failure,
operations, which are more expensive to use than RDMA Send. a sender must use explicit RDMA data transfer operations, which are
more expensive than an RDMA Send. See Sections 3.3 and 3.5 of
[RFC8166] for a complete discussion.
The default value of inline thresholds for RPC-over-RDMA version 1 The default value of inline thresholds for RPC-over-RDMA version 1
connections is 1024 bytes (see Section 3.3.3 of [RFC8166]). This connections is 1024 bytes (as defined in Section 3.3.3 of [RFC8166]).
value is adequate for nearly all NFS version 3 procedures. This value is adequate for nearly all NFS version 3 procedures.
NFS version 4 COMPOUND operations [RFC7530] are larger on average NFS version 4 COMPOUND operations [RFC7530] are larger on average
than NFS version 3 procedures [RFC1813], forcing clients to use than NFS version 3 procedures [RFC1813], forcing clients to use
explicit RDMA operations for frequently-issued requests such as explicit RDMA operations for frequently-issued requests such as
LOOKUP and GETATTR. The use of RPCSEC_GSS security also increases LOOKUP and GETATTR. The use of RPCSEC_GSS security also increases
the average size of RPC messages, due to the larger size of the average size of RPC messages, due to the larger size of
RPCSEC_GSS credential material included in RPC headers [RFC7861]. RPCSEC_GSS credential material included in RPC headers [RFC7861].
If a sender and receiver could somehow agree on larger inline If a sender and receiver could somehow agree on larger inline
thresholds, frequently-used RPC transactions avoid the cost of thresholds, frequently-used RPC transactions avoid the cost of
skipping to change at page 8, line 45 skipping to change at page 8, line 45
When either peer on a connection clears this flag, the responder When either peer on a connection clears this flag, the responder
MUST use only RDMA Send when transmitting RPC Replies. MUST use only RDMA Send when transmitting RPC Replies.
Bits 14 - 8: These bits are reserved and are always zero when the Bits 14 - 8: These bits are reserved and are always zero when the
Version field contains 1. Version field contains 1.
5.2. Inline Threshold Values 5.2. Inline Threshold Values
Inline threshold sizes from 1KB to 256KB can be represented in the Inline threshold sizes from 1KB to 256KB can be represented in the
Send Size and Receive Size fields. A sender computes the encoded Send Size and Receive Size fields. A sender computes the encoded
value by dividing the actual value by 1024 and subtracting one from value by dividing the buffer size, in octets, by 1024 and subtracting
the result. A receiver decodes this value by performing a one from the result. A receiver decodes this value by performing the
complementary set of operations. inverse set of operations: it adds one to the encoded value and then
multiplies that result by 1024.
The client uses the smaller of its own send size and the server's The client uses the smaller of its own send size and the server's
reported receive size as the client-to-server inline threshold. The reported receive size as the client-to-server inline threshold. The
server uses the smaller of its own send size and the clients's server uses the smaller of its own send size and the clients's
reported receive size as the server-to-client inline threshold. reported receive size as the server-to-client inline threshold.
6. Security Considerations 6. Security Considerations
The Private Data extension specified in this document inherits the The reader is directed to the Security Considerations section of
security considerations of the protocols it extends, which in this [RFC8166] for background and further discussion.
case is defined in [RFC8166].
The integrity of CM Private Data and the authenticity of it's source The RPC-over-RDMA version 1 protocol framework depends on the
is ensured by the use of the Reliable connected (RC) Queue Pair (QP) semantics of the Reliable Connected (RC) queue pair (QP) type, as
type, required by RPC-over-RDMA version 1. Any attempts to interfere defined in Section 9.7.7 of [IBA]. The integrity of CM Private Data
with or hijack an RC connection will result in the connection being and the authenticity of its source are ensured by the exclusive use
immediately terminated. Additional relevant analysis of RDMA of RC queue pairs. Any attempt to interfere with or hijack data in
security appears in the Security Considerations section of [RFC5042]. transit on an RC connection results in the RDMA provider terminating
the connection.
Improperly setting one of the fields in the private message payload Additional analysis of RDMA transport security appears in the
will result in a greatly increased risk of disconnection (i.e., self- Security Considerations section of [RFC5042]. That document
imposed Denial of Service). There is no increased risk of exposing recommends IPsec as the default transport layer security solution.
upper-layer data inappropriately. When deployed with iWARP, IPsec establishes a protected channel
before any iWARP operations are exchanged, thus it protects the
exchange of Private Data that occurs as each QP is established.
However, IPsec is not available for InfiniBand or RoCE deployments.
Those fabrics rely on physical security and cyclic redundancy checks
to protect network traffic.
Improperly setting one of the fields in a version 1 Private Message
can result in an increased risk of disconnection (i.e., self-imposed
Denial of Service). There is no additional risk of exposing upper-
layer payloads after exchanging the Private Message format defined in
the current document.
In addition to describing the structure of a new format version, any
document that extends the Private Data format described in the
current document must discuss security considerations of new data
items exchanged between connection peers.
7. IANA Considerations 7. IANA Considerations
In accordance with [RFC8126], the author requests that IANA create a In accordance with [RFC8126], the author requests that IANA create a
new registry in the "Remote Direct Data Placement" Protocol Category new registry in the "Remote Direct Data Placement" Protocol Category
Group. The new registry is to be called the "RDMA-CM Private Data Group. The new registry is to be called the "RDMA-CM Private Data
Identifier Registry". This is a registry of 32-bit numbers that Identifier Registry". This is a registry of 32-bit numbers that
identify the upper-layer protocol associated with data that appears identify the upper-layer protocol associated with data that appears
in the application-specific RDMA-CM Private Data area. The fields in in the application-specific RDMA-CM Private Data area. The fields in
this registry include: Format Identifier, Description, and Reference. this registry include: Format Identifier, Description, and Reference.
skipping to change at page 12, line 7 skipping to change at page 12, line 26
November 2016, <https://www.rfc-editor.org/info/rfc7861>. November 2016, <https://www.rfc-editor.org/info/rfc7861>.
Acknowledgments Acknowledgments
Thanks to Christoph Hellwig and Devesh Sharma for suggesting this Thanks to Christoph Hellwig and Devesh Sharma for suggesting this
approach, and to Tom Talpey and Dave Noveck for their expert comments approach, and to Tom Talpey and Dave Noveck for their expert comments
and review. The author also wishes to thank Bill Baker and Greg and review. The author also wishes to thank Bill Baker and Greg
Marsden for their support of this work. Also, thanks to expert Marsden for their support of this work. Also, thanks to expert
reviewers Sean Hefty and Dave Minturn. reviewers Sean Hefty and Dave Minturn.
Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 Special thanks go to document shepherd Brian Pawlowski, Transport
Working Group Chairs David Noveck, Spencer Shepler, and Brian Area Director Magnus Westerlund, NFSV4 Working Group Chairs David
Pawlowski, NFSV4 Working Group Chair Spencer Shepler, and NFSV4 Noveck and Spencer Shepler, and NFSV4 Working Group Secretary Thomas
Working Group Secretary Thomas Haynes. Haynes.
Author's Address Author's Address
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
United States of America United States of America
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 12 change blocks. 
32 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/