draft-ietf-nfsv4-rpcrdma-bidirection-04.txt   draft-ietf-nfsv4-rpcrdma-bidirection-05.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track May 27, 2016 Intended status: Standards Track June 9, 2016
Expires: November 28, 2016 Expires: December 11, 2016
Bi-directional Remote Procedure Call On RPC-over-RDMA Transports Bi-directional Remote Procedure Call On RPC-over-RDMA Transports
draft-ietf-nfsv4-rpcrdma-bidirection-04 draft-ietf-nfsv4-rpcrdma-bidirection-05
Abstract Abstract
Minor versions of NFSv4 newer than NFSv4.0 work best when ONC RPC Minor versions of NFSv4 newer than NFSv4.0 work best when ONC RPC
transports can send Remote Procedure Call transactions in both transports can send Remote Procedure Call transactions in both
directions on the same connection. This document describes how RPC- directions on the same connection. This document describes how RPC-
over-RDMA transport endpoints convey RPCs in both directions on a over-RDMA transport endpoints convey RPCs in both directions on a
single connection. single connection.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 28, 2016. This Internet-Draft will expire on December 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 31 skipping to change at page 2, line 31
5. Sending And Receiving Backward Operations . . . . . . . . . . 8 5. Sending And Receiving Backward Operations . . . . . . . . . . 8
5.1. Sending A Backward Direction Call . . . . . . . . . . . . 9 5.1. Sending A Backward Direction Call . . . . . . . . . . . . 9
5.2. Sending A Backward Direction Reply . . . . . . . . . . . 9 5.2. Sending A Backward Direction Reply . . . . . . . . . . . 9
5.3. Backward Direction Chunks . . . . . . . . . . . . . . . . 9 5.3. Backward Direction Chunks . . . . . . . . . . . . . . . . 9
5.4. Backward Direction Retransmission . . . . . . . . . . . . 10 5.4. Backward Direction Retransmission . . . . . . . . . . . . 10
6. In the Absence of Backward Direction Support . . . . . . . . 11 6. In the Absence of Backward Direction Support . . . . . . . . 11
7. Considerations For Upper Layer Bindings . . . . . . . . . . . 11 7. Considerations For Upper Layer Bindings . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. Normative References . . . . . . . . . . . . . . . . . . . . 12 11. Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The purpose of this document is to enable concurrent operation in The purpose of this document is to enable concurrent operation in
both directions on a single transport connection using RPC-over-RDMA both directions on a single transport connection using RPC-over-RDMA
protocol versions that do not have specific facilities for backward protocol versions that do not have specific facilities for backward
direction operation. direction operation.
Backward direction RPC transactions are necessary for the operation Backward direction RPC transactions are necessary for the operation
skipping to change at page 7, line 9 skipping to change at page 7, line 9
incoming Send operation, the receiving RDMA provider is allowed to incoming Send operation, the receiving RDMA provider is allowed to
terminate the RDMA connection. terminate the RDMA connection.
RPC-over-RDMA transport protocols provide built-in send flow control RPC-over-RDMA transport protocols provide built-in send flow control
to prevent overrunning the number of pre-posted receive buffers on a to prevent overrunning the number of pre-posted receive buffers on a
connection's receive endpoint. For RPC-over-RDMA Version One, this connection's receive endpoint. For RPC-over-RDMA Version One, this
is discussed in Section 4.3 of [I-D.ietf-nfsv4-rfc5666bis]. is discussed in Section 4.3 of [I-D.ietf-nfsv4-rfc5666bis].
4.1. Backward Credits 4.1. Backward Credits
Credits work the same way in the backward direction as they do in the RPC-over-RDMA credits work the same way in the backward direction as
forward direction. However, forward direction credits and backward they do in the forward direction. However, forward direction credits
direction credits are accounted separately. and backward direction credits on the same connection are accounted
separately.
In other words, the forward direction credit value is the same The forward direction credit value retains the same meaning whether
whether or not there are backward direction resources associated with or not there are backward direction resources associated with an RPC-
an RPC-over-RDMA transport connection. The backward direction credit over-RDMA transport connection. This is the number of RPC requests
value MAY be different than the forward direction credit value. The the forward direction responder (the RPC server) is prepared to
rdma_credit field in a backward direction RPC-over-RDMA message MUST receive concurrently.
NOT contain the value zero.
A backward direction Requester (ie, an RPC-over-RDMA service The backward direction credit value is the number of RPC requests the
endpoint) requests credits from the Responder (ie, an RPC-over-RDMA backward direction responder (the RPC client) is prepared to receive
client endpoint). The Responder reports how many credits it has concurrently. The backward direction credit value MAY be different
granted. This is the number of backward direction Calls the than the forward direction credit value.
Responder is prepared to handle at once.
When message direction is not fully determined by context or by an During bi-directional operation, each receiver has to decide whether
accompanying RPC message with a call direction field, it is not an incoming message contains a credit request (the receiver is acting
possible to tell whether the header credit value is a request or as a responder) or a credit grant (the receiver is acting as a
grant, or whether the value applies to the forward direction or requester) and apply the credit value accordingly.
backward direction. In such cases, the receiver MUST NOT use the
header's credit value. When message direction is not fully determined by context (e.g.,
suggested by the definition of the RPC-over-RDMA version that is in
use) or by an accompanying RPC message payload with a call direction
field, it is not possible for the receiver to tell with certainty
whether the header credit value is a request or grant. In such
cases, the receiver MUST NOT use the header's credit value.
4.2. Inline Thresholds 4.2. Inline Thresholds
Forward and backward operation on the same connection share the same Forward and backward operation on the same connection share the same
receive buffers. Therefore the inline threshold values for the receive buffers. Therefore the inline threshold values for the
forward direction and the backward direction are the same. The call forward direction and the backward direction are the same. The call
inline threshold for the backward direction is the same as the reply inline threshold for the backward direction is the same as the reply
inline threshold for the forward direction, and vice versa. For more inline threshold for the forward direction, and vice versa. For more
information, see Section 4.3.2 of [I-D.ietf-nfsv4-rfc5666bis]. information, see Section 4.3.2 of [I-D.ietf-nfsv4-rfc5666bis].
 End of changes. 8 change blocks. 
25 lines changed or deleted 29 lines changed or added

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