One document matched: draft-ietf-nfsv4-rpcrdma-bidirection-02.ps
%!PS-Adobe-3.0
%%BoundingBox: 76 24 571 766
%%Title: Enscript Output
%%For: Chuck Lever
%%Creator: GNU Enscript 1.6.6
%%CreationDate: Fri Apr 8 13:57:00 2016
%%Orientation: Portrait
%%Pages: (atend)
%%DocumentMedia: A4 595 842 0 () ()
%%DocumentNeededResources: (atend)
%%EndComments
%%BeginProlog
%%BeginResource: procset Enscript-Prolog 1.6 6
%
% Procedures.
%
/_S { % save current state
/_s save def
} def
/_R { % restore from saved state
_s restore
} def
/S { % showpage protecting gstate
gsave
showpage
grestore
} bind def
/MF { % fontname newfontname -> - make a new encoded font
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
% insert only valid encoding vectors
encoding_vector length 256 eq {
newfont /Encoding encoding_vector put
} if
newfontname newfont definefont pop
} def
/MF_PS { % fontname newfontname -> - make a new font preserving its enc
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
newfontname newfont definefont pop
} def
/SF { % fontname width height -> - set a new font
/height exch def
/width exch def
findfont
[width 0 0 height 0 0] makefont setfont
} def
/SUF { % fontname width height -> - set a new user font
/height exch def
/width exch def
/F-gs-user-font MF
/F-gs-user-font width height SF
} def
/SUF_PS { % fontname width height -> - set a new user font preserving its enc
/height exch def
/width exch def
/F-gs-user-font MF_PS
/F-gs-user-font width height SF
} def
/M {moveto} bind def
/s {show} bind def
/Box { % x y w h -> - define box path
/d_h exch def /d_w exch def /d_y exch def /d_x exch def
d_x d_y moveto
d_w 0 rlineto
0 d_h rlineto
d_w neg 0 rlineto
closepath
} def
/bgs { % x y height blskip gray str -> - show string with bg color
/str exch def
/gray exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
gray setgray
fill
grestore
x y M str s
} def
/bgcs { % x y height blskip red green blue str -> - show string with bg color
/str exch def
/blue exch def
/green exch def
/red exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
red green blue setrgbcolor
fill
grestore
x y M str s
} def
% Highlight bars.
/highlight_bars { % nlines lineheight output_y_margin gray -> -
gsave
setgray
/ymarg exch def
/lineheight exch def
/nlines exch def
% This 2 is just a magic number to sync highlight lines to text.
0 d_header_y ymarg sub 2 sub translate
/cw d_output_w cols div def
/nrows d_output_h ymarg 2 mul sub lineheight div cvi def
% for each column
0 1 cols 1 sub {
cw mul /xp exch def
% for each rows
0 1 nrows 1 sub {
/rn exch def
rn lineheight mul neg /yp exch def
rn nlines idiv 2 mod 0 eq {
% Draw highlight bar. 4 is just a magic indentation.
xp 4 add yp cw 8 sub lineheight neg Box fill
} if
} for
} for
grestore
} def
% Line highlight bar.
/line_highlight { % x y width height gray -> -
gsave
/gray exch def
Box gray setgray fill
grestore
} def
% Column separator lines.
/column_lines {
gsave
.1 setlinewidth
0 d_footer_h translate
/cw d_output_w cols div def
1 1 cols 1 sub {
cw mul 0 moveto
0 d_output_h rlineto stroke
} for
grestore
} def
% Column borders.
/column_borders {
gsave
.1 setlinewidth
0 d_footer_h moveto
0 d_output_h rlineto
d_output_w 0 rlineto
0 d_output_h neg rlineto
closepath stroke
grestore
} def
% Do the actual underlay drawing
/draw_underlay {
ul_style 0 eq {
ul_str true charpath stroke
} {
ul_str show
} ifelse
} def
% Underlay
/underlay { % - -> -
gsave
0 d_page_h translate
d_page_h neg d_page_w atan rotate
ul_gray setgray
ul_font setfont
/dw d_page_h dup mul d_page_w dup mul add sqrt def
ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto
draw_underlay
grestore
} def
/user_underlay { % - -> -
gsave
ul_x ul_y translate
ul_angle rotate
ul_gray setgray
ul_font setfont
0 0 ul_h_ptsize 2 div sub moveto
draw_underlay
grestore
} def
% Page prefeed
/page_prefeed { % bool -> -
statusdict /prefeed known {
statusdict exch /prefeed exch put
} {
pop
} ifelse
} def
% Wrapped line markers
/wrapped_line_mark { % x y charwith charheight type -> -
/type exch def
/h exch def
/w exch def
/y exch def
/x exch def
type 2 eq {
% Black boxes (like TeX does)
gsave
0 setlinewidth
x w 4 div add y M
0 h rlineto w 2 div 0 rlineto 0 h neg rlineto
closepath fill
grestore
} {
type 3 eq {
% Small arrows
gsave
.2 setlinewidth
x w 2 div add y h 2 div add M
w 4 div 0 rlineto
x w 4 div add y lineto stroke
x w 4 div add w 8 div add y h 4 div add M
x w 4 div add y lineto
w 4 div h 8 div rlineto stroke
grestore
} {
% do nothing
} ifelse
} ifelse
} def
% EPSF import.
/BeginEPSF {
/b4_Inc_state save def % Save state for cleanup
/dict_count countdictstack def % Count objects on dict stack
/op_count count 1 sub def % Count objects on operand stack
userdict begin
/showpage { } def
0 setgray 0 setlinecap
1 setlinewidth 0 setlinejoin
10 setmiterlimit [ ] 0 setdash newpath
/languagelevel where {
pop languagelevel
1 ne {
false setstrokeadjust false setoverprint
} if
} if
} bind def
/EndEPSF {
count op_count sub { pos } repeat % Clean up stacks
countdictstack dict_count sub { end } repeat
b4_Inc_state restore
} bind def
% Check PostScript language level.
/languagelevel where {
pop /gs_languagelevel languagelevel def
} {
/gs_languagelevel 1 def
} ifelse
%%EndResource
%%BeginResource: procset Enscript-Encoding-88591 1.6 6
/encoding_vector [
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclam /quotedbl /numbersign
/dollar /percent /ampersand /quoteright
/parenleft /parenright /asterisk /plus
/comma /hyphen /period /slash
/zero /one /two /three
/four /five /six /seven
/eight /nine /colon /semicolon
/less /equal /greater /question
/at /A /B /C
/D /E /F /G
/H /I /J /K
/L /M /N /O
/P /Q /R /S
/T /U /V /W
/X /Y /Z /bracketleft
/backslash /bracketright /asciicircum /underscore
/quoteleft /a /b /c
/d /e /f /g
/h /i /j /k
/l /m /n /o
/p /q /r /s
/t /u /v /w
/x /y /z /braceleft
/bar /braceright /tilde /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclamdown /cent /sterling
/currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft
/logicalnot /hyphen /registered /macron
/degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /bullet
/cedilla /onesuperior /ordmasculine /guillemotright
/onequarter /onehalf /threequarters /questiondown
/Agrave /Aacute /Acircumflex /Atilde
/Adieresis /Aring /AE /Ccedilla
/Egrave /Eacute /Ecircumflex /Edieresis
/Igrave /Iacute /Icircumflex /Idieresis
/Eth /Ntilde /Ograve /Oacute
/Ocircumflex /Otilde /Odieresis /multiply
/Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls
/agrave /aacute /acircumflex /atilde
/adieresis /aring /ae /ccedilla
/egrave /eacute /ecircumflex /edieresis
/igrave /iacute /icircumflex /idieresis
/eth /ntilde /ograve /oacute
/ocircumflex /otilde /odieresis /divide
/oslash /ugrave /uacute /ucircumflex
/udieresis /yacute /thorn /ydieresis
] def
%%EndResource
%%EndProlog
%%BeginSetup
%%IncludeResource: font Courier-Bold
%%IncludeResource: font Courier
/HFpt_w 10 def
/HFpt_h 10 def
/Courier-Bold /HF-gs-font MF
/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def
/Courier /F-gs-font MF
/F-gs-font 10 10 SF
/#copies 1 def
% Pagedevice definitions:
gs_languagelevel 1 gt {
<<
/PageSize [595 842]
>> setpagedevice
} if
/d_page_w 495 def
/d_page_h 742 def
/d_header_x 0 def
/d_header_y 742 def
/d_header_w 495 def
/d_header_h 0 def
/d_footer_x 0 def
/d_footer_y 0 def
/d_footer_w 495 def
/d_footer_h 0 def
/d_output_w 495 def
/d_output_h 742 def
/cols 1 def
%%EndSetup
%%Page: (1) 1
%%BeginPageSetup
_S
76 24 translate
/pagenum 1 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 685 M
(Network File System Version 4 C. Lever) s
5 674 M
(Internet-Draft Oracle) s
5 663 M
(Intended status: Standards Track April 8, 2016) s
5 652 M
(Expires: October 10, 2016) s
5 619 M
( Size-Limited Bi-directional Remote Procedure Call On Remote Direct) s
5 608 M
( Memory Access Transports) s
5 597 M
( draft-ietf-nfsv4-rpcrdma-bidirection-02) s
5 575 M
(Abstract) s
5 553 M
( Recent minor versions of NFSv4 work best when ONC RPC transports can) s
5 542 M
( send ONC RPC transactions in both directions. This document) s
5 531 M
( describes conventions that enable RPC-over-RDMA transport endpoints) s
5 520 M
( to interoperate when operation in both directions is necessary.) s
5 498 M
(Status of This Memo) s
5 476 M
( This Internet-Draft is submitted in full conformance with the) s
5 465 M
( provisions of BCP 78 and BCP 79.) s
5 443 M
( Internet-Drafts are working documents of the Internet Engineering) s
5 432 M
( Task Force \(IETF\). Note that other groups may also distribute) s
5 421 M
( working documents as Internet-Drafts. The list of current Internet-) s
5 410 M
( Drafts is at http://datatracker.ietf.org/drafts/current/.) s
5 388 M
( Internet-Drafts are draft documents valid for a maximum of six months) s
5 377 M
( and may be updated, replaced, or obsoleted by other documents at any) s
5 366 M
( time. It is inappropriate to use Internet-Drafts as reference) s
5 355 M
( material or to cite them other than as "work in progress.") s
5 333 M
( This Internet-Draft will expire on October 10, 2016.) s
5 311 M
(Copyright Notice) s
5 289 M
( Copyright \(c\) 2016 IETF Trust and the persons identified as the) s
5 278 M
( document authors. All rights reserved.) s
5 256 M
( This document is subject to BCP 78 and the IETF Trust's Legal) s
5 245 M
( Provisions Relating to IETF Documents) s
5 234 M
( \(http://trustee.ietf.org/license-info\) in effect on the date of) s
5 223 M
( publication of this document. Please review these documents) s
5 212 M
( carefully, as they describe your rights and restrictions with respect) s
5 201 M
( to this document. Code Components extracted from this document must) s
5 190 M
( include Simplified BSD License text as described in Section 4.e of) s
5 179 M
( the Trust Legal Provisions and are provided without warranty as) s
5 168 M
( described in the Simplified BSD License.) s
5 124 M
(Lever Expires October 10, 2016 [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
76 24 translate
/pagenum 2 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
(Table of Contents) s
5 663 M
( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2) s
5 652 M
( 1.1. Understanding RPC Direction . . . . . . . . . . . . . . . 2) s
5 641 M
( 1.2. Rationale For RPC-over-RDMA Bi-Direction . . . . . . . . 4) s
5 630 M
( 1.3. Design Considerations . . . . . . . . . . . . . . . . . . 6) s
5 619 M
( 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 8) s
5 608 M
( 2. Conventions For Backward Operation . . . . . . . . . . . . . 8) s
5 597 M
( 2.1. Flow Control . . . . . . . . . . . . . . . . . . . . . . 8) s
5 586 M
( 2.2. Managing Receive Buffers . . . . . . . . . . . . . . . . 9) s
5 575 M
( 2.3. Backward Direction Retransmission . . . . . . . . . . . . 11) s
5 564 M
( 2.4. Backward Direction Message Size . . . . . . . . . . . . . 11) s
5 553 M
( 2.5. Sending A Backward Direction Call . . . . . . . . . . . . 12) s
5 542 M
( 2.6. Sending A Backward Direction Reply . . . . . . . . . . . 12) s
5 531 M
( 3. Backward Direction Upper Layer Binding . . . . . . . . . . . 13) s
5 520 M
( 4. Limits To This Approach . . . . . . . . . . . . . . . . . . . 13) s
5 509 M
( 4.1. Payload Size . . . . . . . . . . . . . . . . . . . . . . 13) s
5 498 M
( 4.2. Preparedness To Handle Backward Requests . . . . . . . . 13) s
5 487 M
( 4.3. Long Term . . . . . . . . . . . . . . . . . . . . . . . . 14) s
5 476 M
( 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14) s
5 465 M
( 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14) s
5 454 M
( 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14) s
5 443 M
( 8. Normative References . . . . . . . . . . . . . . . . . . . . 15) s
5 432 M
( Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15) s
5 410 M
(1. Introduction) s
5 388 M
( The purpose of this document is to enable bi-directional RPC) s
5 377 M
( transactions on RPC-over-RDMA transports that do not already support) s
5 366 M
( backward direction operation. The conventions described herein can) s
5 355 M
( be used with the RPC-over-RDMA Version One protocol without changes.) s
5 344 M
( Therefore this document does not update [I-D.ietf-nfsv4-rfc5666bis].) s
5 322 M
( Backward direction transactions enable the operation of NFSv4.1, and) s
5 311 M
( in particular pNFS, on RPC-over-RDMA. Providing an Upper Layer) s
5 300 M
( Binding for NFSv4.x callback operations is outside the scope of this) s
5 289 M
( document.) s
5 267 M
(1.1. Understanding RPC Direction) s
5 245 M
( The ONC RPC protocol as described in [RFC5531] is fundamentally a) s
5 234 M
( message-passing protocol between one server and one or more clients.) s
5 223 M
( ONC RPC transactions are made up of two types of messages.) s
5 201 M
( A CALL message, or "Call", requests work. A Call is designated by) s
5 190 M
( the value CALL in the message's msg_type field. An arbitrary unique) s
5 179 M
( value is placed in the message's xid field. A host that originates a) s
5 168 M
( Call is referred to in this document as a "Requester.") s
5 124 M
(Lever Expires October 10, 2016 [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
76 24 translate
/pagenum 3 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( A REPLY message, or "Reply", reports the results of work requested by) s
5 674 M
( a Call. A Reply is designated by the value REPLY in the message's) s
5 663 M
( msg_type field. The value contained in the message's xid field is) s
5 652 M
( copied from the Call whose results are being returned. A host that) s
5 641 M
( emits a Reply is referred to as a "Responder.") s
5 619 M
( RPC-over-RDMA is a connection-oriented RPC transport. When a) s
5 608 M
( connection-oriented transport is used, ONC RPC client endpoints are) s
5 597 M
( responsible for initiating transport connections, while ONC RPC) s
5 586 M
( service endpoints wait passively for incoming connection requests.) s
5 564 M
( RPC direction on connectionless RPC transports is not considered in) s
5 553 M
( this document.) s
5 531 M
(1.1.1. Forward Direction) s
5 509 M
( A traditional ONC RPC client is always a Requester. A traditional) s
5 498 M
( ONC RPC service is always a Responder. This traditional form of ONC) s
5 487 M
( RPC message passing is referred to as operation in the "forward) s
5 476 M
( direction.") s
5 454 M
( During forward direction operation, the ONC RPC client is responsible) s
5 443 M
( for establishing transport connections.) s
5 421 M
(1.1.2. Backward Direction) s
5 399 M
( The ONC RPC specification [RFC5531] does not forbid passing messages) s
5 388 M
( in the other direction. An ONC RPC service endpoint can act as a) s
5 377 M
( Requester, in which case an ONC RPC client endpoint acts as a) s
5 366 M
( Responder. This form of message passing is referred to as operation) s
5 355 M
( in the "backward direction.") s
5 333 M
( During backward direction operation, the ONC RPC client is) s
5 322 M
( responsible for establishing transport connections, even though ONC) s
5 311 M
( RPC Calls come from the ONC RPC server.) s
5 289 M
( ONC RPC clients and services are optimized to perform and scale well) s
5 278 M
( while handling traffic in the forward direction, and may not be) s
5 267 M
( prepared to handle operation in the backward direction. Not until) s
5 256 M
( recently has there been a need to handle backward direction) s
5 245 M
( operation.) s
5 223 M
(1.1.3. Bi-directional Operation) s
5 201 M
( A pair of connected RPC endpoints may choose to use only forward or) s
5 190 M
( only backward direction operations on a particular transport. Or,) s
5 179 M
( these endpoints may send Calls in both directions concurrently on the) s
5 168 M
( same transport.) s
5 124 M
(Lever Expires October 10, 2016 [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
76 24 translate
/pagenum 4 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( "Bi-directional operation" occurs when both transport endpoints act) s
5 674 M
( as a Requester and a Responder at the same time. As above, the ONC) s
5 663 M
( RPC client is always responsible for establishing transport) s
5 652 M
( connections.) s
5 630 M
(1.1.4. XID Values) s
5 608 M
( Section 9 of [RFC5531] introduces the ONC RPC transaction identifier,) s
5 597 M
( or "xid" for short. The value of an xid is interpreted in the) s
5 586 M
( context of the message's msg_type field.) s
5 564 M
( o The xid of a Call is arbitrary but is unique among outstanding) s
5 553 M
( Calls from that Requester.) s
5 531 M
( o The xid of a Reply always matches that of the initiating Call.) s
5 509 M
( When receiving a Reply, a Requester matches the xid value in the) s
5 498 M
( Reply with a Call it previously sent.) s
5 476 M
(1.1.4.1. XIDs with Bi-direction) s
5 454 M
( During bi-directional operation, the forward and backward directions) s
5 443 M
( use independent xid spaces.) s
5 421 M
( In other words, a forward direction Requester MAY use the same xid) s
5 410 M
( value at the same time as a backward direction Requester on the same) s
5 399 M
( transport connection. Though such concurrent requests use the same) s
5 388 M
( xid value, they represent distinct ONC RPC transactions.) s
5 366 M
(1.2. Rationale For RPC-over-RDMA Bi-Direction) s
5 344 M
(1.2.1. NFSv4.0 Callback Operation) s
5 322 M
( An NFSv4.0 client employs a traditional ONC RPC client to send NFS) s
5 311 M
( requests to an NFSv4.0 server's traditional ONC RPC service) s
5 300 M
( [RFC7530]. NFSv4.0 requests flow in the forward direction on a) s
5 289 M
( connection established by the client. This connection is referred to) s
5 278 M
( as a "forechannel" connection.) s
5 256 M
( An NFSv4 "delegation" is simply a promise made by a server that it) s
5 245 M
( will notify a client when another client requests access to a file.) s
5 234 M
( With this guarantee, that client can operate as sole accessor of this) s
5 223 M
( file, and manage the file's data and metadata caches aggressively.) s
5 201 M
( To manage file delegation, NFSv4.0 introduces the use of callback) s
5 190 M
( operations, or "callbacks", in Section 10.2 of [RFC7530]. An NFSv4.0) s
5 179 M
( server sets up a traditional ONC RPC client, and an NFSv4.0 client) s
5 168 M
( sets up a traditional ONC RPC service. Callbacks flow in the forward) s
5 124 M
(Lever Expires October 10, 2016 [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
76 24 translate
/pagenum 5 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( direction on a connection established between the server's client,) s
5 674 M
( and the client's server. This connection is distinct from) s
5 663 M
( connections being used as forechannels, and is referred to as a) s
5 652 M
( "backchannel connection.") s
5 630 M
( When an RDMA transport is used as a forechannel, an NFSv4.0 client) s
5 619 M
( typically provides a TCP callback service. The client's SETCLIENTID) s
5 608 M
( operation advertises the callback service endpoint with a "tcp" or) s
5 597 M
( "tcp6" netid. The server then connects to this service using a TCP) s
5 586 M
( socket.) s
5 564 M
( NFSv4.0 implementations are fully functional without a backchannel in) s
5 553 M
( place. In this case, the server does not grant file delegations.) s
5 542 M
( This might result in a negative performance effect, but functional) s
5 531 M
( correctness is unaffected.) s
5 509 M
(1.2.2. NFSv4.1 Callback Operation) s
5 487 M
( NFSv4.1 supports file delegation in a similar fashion to NFSv4.0, and) s
5 476 M
( extends the repertoire of callbacks to manage pNFS layouts, as) s
5 465 M
( discussed in Chapter 12 of [RFC5661].) s
5 443 M
( For various reasons, NFSv4.1 requires that all transport connections) s
5 432 M
( be initiated by NFSv4.1 clients. Therefore, NFSv4.1 servers send) s
5 421 M
( callbacks to clients in the backward direction on connections) s
5 410 M
( established by NFSv4.1 clients.) s
5 388 M
( NFSv4.1 clients and servers indicate to their peers that a) s
5 377 M
( backchannel capability is available on a given transport in the) s
5 366 M
( arguments and results of a CREATE_SESSION or BIND_CONN_TO_SESSION) s
5 355 M
( operation.) s
5 333 M
( NFSv4.1 clients may establish distinct transport connections for) s
5 322 M
( forechannel and backchannel operation, or they may combine) s
5 311 M
( forechannel and backchannel operation on one transport connection) s
5 300 M
( using bi-directional operation.) s
5 278 M
( Without a backward direction RPC-over-RDMA capability, an NFSv4.1) s
5 267 M
( client must additionally connect using a transport with backward) s
5 256 M
( direction capability to use as a backchannel. TCP is the only choice) s
5 245 M
( at present for an NFSv4.1 backchannel connection.) s
5 223 M
( Some implementations find it more convenient to use a single combined) s
5 212 M
( transport \(ie. a transport that is capable of bi-directional) s
5 201 M
( operation\). This simplifies connection establishment, and recovery) s
5 190 M
( during network partitions or when one endpoint restarts.) s
5 124 M
(Lever Expires October 10, 2016 [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
76 24 translate
/pagenum 6 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( As with NFSv4.0, if a backchannel is not in use, an NFSv4.1 server) s
5 674 M
( does not grant delegations. But because of its reliance on callbacks) s
5 663 M
( to manage pNFS layout state, pNFS operation is not possible without a) s
5 652 M
( backchannel.) s
5 630 M
(1.3. Design Considerations) s
5 608 M
( As of this writing, the only use case for backward direction ONC RPC) s
5 597 M
( messages is the NFSv4.1 backchannel. The conventions described in) s
5 586 M
( this document take advantage of certain characteristics of NFSv4.1) s
5 575 M
( callbacks, namely:) s
5 553 M
( o NFSv4.1 callbacks typically bear small arguments and results) s
5 531 M
( o NFSv4.1 callback arguments and results are insensitive to) s
5 520 M
( alignment relative to system pages) s
5 498 M
( o NFSv4.1 callbacks are infrequent relative to forechannel) s
5 487 M
( operations) s
5 465 M
(1.3.1. Backward Compatibility) s
5 443 M
( Existing clients that implement RPC-over-RDMA Version One should) s
5 432 M
( interoperate correctly with servers that implement RPC-over-RDMA with) s
5 421 M
( backward direction support, and vice versa.) s
5 399 M
( The approach taken here avoids altering the RPC-over-RDMA XDR) s
5 388 M
( specification. Keeping the XDR the same enables existing RPC-over-) s
5 377 M
( RDMA Version One implementations to interoperate with implementations) s
5 366 M
( that support operation in the backward direction.) s
5 344 M
(1.3.2. Performance Impact) s
5 322 M
( Support for operation in the backward direction should never impact) s
5 311 M
( the performance or scalability of forward direction operation, where) s
5 300 M
( the bulk of ONC RPC transport activity typically occurs.) s
5 278 M
(1.3.3. Server Memory Security) s
5 256 M
( RDMA transfers involve one endpoint exposing a section of its memory) s
5 245 M
( to the other endpoint, which then drives RDMA Read and Write) s
5 234 M
( operations to access or modify the exposed memory. RPC-over-RDMA) s
5 223 M
( client endpoints expose their memory, and RPC-over-RDMA server) s
5 212 M
( endpoints initiate RDMA data transfer operations.) s
5 190 M
( If RDMA transfers are not used for backward direction operations,) s
5 179 M
( there is no need for servers to expose their memory to clients.) s
5 124 M
(Lever Expires October 10, 2016 [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
76 24 translate
/pagenum 7 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( Further, this avoids the client complexity required to drive RDMA) s
5 674 M
( transfers.) s
5 652 M
(1.3.4. Payload Size) s
5 630 M
( Small RPC-over-RDMA messages are conveyed using only RDMA Send) s
5 619 M
( operations. Send is used to transmit both ONC RPC Calls and replies.) s
5 597 M
( To send a large payload, an RPC-over-RDMA client endpoint registers a) s
5 586 M
( region of memory \(known as a "chunk"\) and transmits its coordinates) s
5 575 M
( to an RPC-over-RDMA server endpoint, who uses an RDMA transfer to) s
5 564 M
( move data to or from the client. See Section 4.4 of) s
5 553 M
( [I-D.ietf-nfsv4-rfc5666bis].) s
5 531 M
( To transmit RPC-over-RDMA messages larger than the receive buffer) s
5 520 M
( size \(1024 bytes on an RPC-over-RDMA Version One transport\), a chunk) s
5 509 M
( must be used. For example, in an RDMA_NOMSG type message, the entire) s
5 498 M
( RPC header and Upper Layer payload are contained in one or more) s
5 487 M
( chunks. See Section 4.5 of [I-D.ietf-nfsv4-rfc5666bis]. for further) s
5 476 M
( details.) s
5 454 M
( If chunks are not allowed to be used for conveying backward direction) s
5 443 M
( messages, an RDMA_NOMSG type message cannot be used to convey a) s
5 432 M
( backward direction message using the conventions described in this) s
5 421 M
( document. Therefore, backward direction messages sent using the) s
5 410 M
( conventions in this document can be no larger than a single receive) s
5 399 M
( buffer.) s
5 377 M
( Stipulating such a limit on backward direction message size assumes) s
5 366 M
( that either Upper Layer Protocol consumers of backward direction) s
5 355 M
( messages can advertise this limit to peers, or that ULP consumers can) s
5 344 M
( agree by convention on a maximum size of their backchannel payloads.) s
5 322 M
( In addition, using only inline forms of RPC-over-RDMA messages and) s
5 311 M
( never populating the RPC-over-RDMA chunk lists means that the RPC) s
5 300 M
( header's msg_type field is always at a fixed location in messages) s
5 289 M
( flowing in the backward direction, allowing efficient detection of) s
5 278 M
( the direction of an RPC-over-RDMA message.) s
5 256 M
( With few exceptions, NFSv4.1 servers can break down callback requests) s
5 245 M
( so they fit within this limit. There are potentially large NFSv4.1) s
5 234 M
( callback operations, such as a CB_GETATTR operation where a large ACL) s
5 223 M
( must be conveyed. Although we are not aware of any NFSv4.1) s
5 212 M
( implementation that uses CB_GETATTR, this state of affairs is not) s
5 201 M
( guaranteed in perpetuity.) s
5 124 M
(Lever Expires October 10, 2016 [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
76 24 translate
/pagenum 8 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
(1.4. Requirements Language) s
5 663 M
( The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",) s
5 652 M
( "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this) s
5 641 M
( document are to be interpreted as described in [RFC2119].) s
5 619 M
(2. Conventions For Backward Operation) s
5 597 M
( Performing backward direction ONC RPC operations over an RPC-over-) s
5 586 M
( RDMA transport can be accomplished within limits by observing the) s
5 575 M
( conventions described in the following subsections. For reference,) s
5 564 M
( the XDR description of RPC-over-RDMA Version One is contained in) s
5 553 M
( Section 5.1 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 531 M
(2.1. Flow Control) s
5 509 M
( For an RDMA Send operation to work, the receiving peer must have) s
5 498 M
( posted an RDMA Receive Work Request \(WR\) to provide a receive buffer) s
5 487 M
( in which to capture the incoming message. If a receiver hasn't) s
5 476 M
( posted enough Receive WRs to catch incoming Send operations, the RDMA) s
5 465 M
( provider is allowed to drop the RDMA connection.) s
5 443 M
( RPC-over-RDMA protocols provide built-in send flow control to prevent) s
5 432 M
( overrunning the number of pre-posted receive buffers on a) s
5 421 M
( connection's receive endpoint. This is fully discussed in) s
5 410 M
( Section 4.3 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 388 M
(2.1.1. Forward Credits) s
5 366 M
( An RPC-over-RDMA credit is the capability to handle one RPC-over-RDMA) s
5 355 M
( transaction. Each forward direction RPC-over-RDMA Call requests a) s
5 344 M
( number of credits from the Responder. Each forward direction Reply) s
5 333 M
( informs the Requester how many credits the Responder is prepared to) s
5 322 M
( handle in total. The value of the request and grant are carried in) s
5 311 M
( each RPC-over-RDMA message's rdma_credit field.) s
5 289 M
( Practically speaking, the critical value is the value of the) s
5 278 M
( rdma_credit field in RPC-over-RDMA replies. When a Requester is) s
5 267 M
( operating correctly, it sends no more outstanding requests at a time) s
5 256 M
( than the Responder's advertised forward direction credit value.) s
5 234 M
( The credit value is a guaranteed minimum. However, a receiver can) s
5 223 M
( post more receive buffers than its credit value. There is no) s
5 212 M
( requirement in the RPC-over-RDMA protocol for a receiver to indicate) s
5 201 M
( a credit overrun. Operation continues as long as there are enough) s
5 190 M
( receive buffers to handle incoming messages.) s
5 124 M
(Lever Expires October 10, 2016 [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
76 24 translate
/pagenum 9 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
(2.1.2. Backward Credits) s
5 663 M
( Credits work the same way in the backward direction as they do in the) s
5 652 M
( forward direction. However, forward direction credits and backward) s
5 641 M
( direction credits are accounted separately.) s
5 619 M
( In other words, the forward direction credit value is the same) s
5 608 M
( whether or not there are backward direction resources associated with) s
5 597 M
( an RPC-over-RDMA transport connection. The backward direction credit) s
5 586 M
( value MAY be different than the forward direction credit value. The) s
5 575 M
( rdma_credit field in a backward direction RPC-over-RDMA message MUST) s
5 564 M
( NOT contain the value zero.) s
5 542 M
( A backward direction Requester \(ie, an RPC-over-RDMA service) s
5 531 M
( endpoint\) requests credits from the Responder \(ie, an RPC-over-RDMA) s
5 520 M
( client endpoint\). The Responder reports how many credits it can) s
5 509 M
( grant. This is the number of backward direction Calls the Responder) s
5 498 M
( is prepared to handle at once.) s
5 476 M
( When an RPC-over-RDMA server endpoint is operating correctly, it) s
5 465 M
( sends no more outstanding requests at a time than the client) s
5 454 M
( endpoint's advertised backward direction credit value.) s
5 432 M
(2.2. Managing Receive Buffers) s
5 410 M
( An RPC-over-RDMA transport endpoint must pre-post receive buffers) s
5 399 M
( before it can receive and process incoming RPC-over-RDMA messages.) s
5 388 M
( If a sender transmits a message for a receiver which has no prepared) s
5 377 M
( receive buffer, the RDMA provider is allowed to drop the RDMA) s
5 366 M
( connection.) s
5 344 M
(2.2.1. Client Receive Buffers) s
5 322 M
( Typically an RPC-over-RDMA Requester posts only as many receive) s
5 311 M
( buffers as there are outstanding RPC Calls. A client endpoint) s
5 300 M
( without backward direction support might therefore at times have no) s
5 289 M
( pre-posted receive buffers.) s
5 267 M
( To receive incoming backward direction Calls, an RPC-over-RDMA client) s
5 256 M
( endpoint must pre-post enough additional receive buffers to match its) s
5 245 M
( advertised backward direction credit value. Each outstanding forward) s
5 234 M
( direction RPC requires an additional receive buffer above this) s
5 223 M
( minimum.) s
5 201 M
( When an RDMA transport connection is lost, all active receive buffers) s
5 190 M
( are flushed and are no longer available to receive incoming messages.) s
5 179 M
( When a fresh transport connection is established, a client endpoint) s
5 168 M
( must re-post a receive buffer to handle the Reply for each) s
5 124 M
(Lever Expires October 10, 2016 [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
76 24 translate
/pagenum 10 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( retransmitted forward direction Call, and a full set of receive) s
5 674 M
( buffers to handle backward direction Calls.) s
5 652 M
(2.2.2. Server Receive Buffers) s
5 630 M
( A forward direction RPC-over-RDMA service endpoint posts as many) s
5 619 M
( receive buffers as it expects incoming forward direction Calls. That) s
5 608 M
( is, it posts no fewer buffers than the number of RPC-over-RDMA) s
5 597 M
( credits it advertises in the rdma_credit field of forward direction) s
5 586 M
( RPC replies.) s
5 564 M
( To receive incoming backward direction replies, an RPC-over-RDMA) s
5 553 M
( server endpoint must pre-post a receive buffer for each backward) s
5 542 M
( direction Call it sends.) s
5 520 M
( When the existing transport connection is lost, all active receive) s
5 509 M
( buffers are flushed and are no longer available to receive incoming) s
5 498 M
( messages. When a fresh transport connection is established, a server) s
5 487 M
( endpoint must re-post a receive buffer to handle the Reply for each) s
5 476 M
( retransmitted backward direction Call, and a full set of receive) s
5 465 M
( buffers for receiving forward direction Calls.) s
5 443 M
(2.2.3. In the Absense of Backward Direction Support) s
5 421 M
( An RPC-over-RDMA transport endpoint might not support backward) s
5 410 M
( direction operation. There might be no mechanism in the transport) s
5 399 M
( implementation to do so. Or the Upper Layer Protocol consumer might) s
5 388 M
( not yet have configured the transport to handle backward direction) s
5 377 M
( traffic.) s
5 355 M
( A loss of the RDMA connection may result if the receiver is not) s
5 344 M
( prepared to receive an incoming message. Thus a denial-of-service) s
5 333 M
( could result if a sender continues to send backchannel messages after) s
5 322 M
( every transport reconnect to an endpoint that is not prepared to) s
5 311 M
( receive them.) s
5 289 M
( Generally, for RPC-over-RDMA Version One transports, the Upper Layer) s
5 278 M
( Protocol consumer is responsible for informing its peer when it has) s
5 267 M
( support for the backward direction. Otherwise even a simple backward) s
5 256 M
( direction NULL probe from a peer could result in a lost connection.) s
5 234 M
( An NFSv4.1 server does not send backchannel messages to an NFSv4.1) s
5 223 M
( client before the NFSv4.1 client has sent a CREATE_SESSION or a) s
5 212 M
( BIND_CONN_TO_SESSION operation. As long as an NFSv4.1 client has) s
5 201 M
( prepared appropriate backchannel resources before sending one of) s
5 190 M
( these operations, denial-of-service is avoided. Legacy versions of) s
5 179 M
( NFS never send backchannel operations.) s
5 124 M
(Lever Expires October 10, 2016 [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
76 24 translate
/pagenum 11 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( Therefore, an Upper Layer Protocol consumer MUST NOT perform backward) s
5 674 M
( direction ONC RPC operations unless the peer consumer has indicated) s
5 663 M
( it is prepared to handle them. A description of Upper Layer Protocol) s
5 652 M
( mechanisms used for this indication is outside the scope of this) s
5 641 M
( document.) s
5 619 M
(2.3. Backward Direction Retransmission) s
5 597 M
( In rare cases, an ONC RPC transaction cannot be completed within a) s
5 586 M
( certain time. This can be because the transport connection was lost,) s
5 575 M
( the Call or Reply message was dropped, or because the Upper Layer) s
5 564 M
( consumer delayed or dropped the ONC RPC request. Typically, the) s
5 553 M
( Requester sends the transaction again, reusing the same RPC XID.) s
5 542 M
( This is known as an "RPC retransmission".) s
5 520 M
( In the forward direction, the Requester is the ONC RPC client. The) s
5 509 M
( client is always responsible for establishing a transport connection) s
5 498 M
( before sending again.) s
5 476 M
( In the backward direction, the Requester is the ONC RPC server.) s
5 465 M
( Because an ONC RPC server does not establish transport connections) s
5 454 M
( with clients, it cannot send a retransmission if there is no) s
5 443 M
( transport connection. It must wait for the ONC RPC client to re-) s
5 432 M
( establish the transport connection before it can retransmit ONC RPC) s
5 421 M
( transactions in the backward direction.) s
5 399 M
( If an ONC RPC client has no work to do, it may be some time before it) s
5 388 M
( re-establishes a transport connection. Backward direction Requesters) s
5 377 M
( must be prepared to wait indefinitely before a connection is) s
5 366 M
( established before a pending backward direction ONC RPC Call can be) s
5 355 M
( retransmitted.) s
5 333 M
(2.4. Backward Direction Message Size) s
5 311 M
( RPC-over-RDMA backward direction messages are transmitted and) s
5 300 M
( received using the same buffers as messages in the forward direction.) s
5 289 M
( Therefore they are constrained to be no larger than receive buffers) s
5 278 M
( posted for forward messages. The default Receive buffer size in RPC-) s
5 267 M
( over-RDMA Version One implementations is 1024 bytes.) s
5 245 M
( It is expected that the Upper Layer Protocol consumer establishes an) s
5 234 M
( appropriate payload size limit for backward direction operations,) s
5 223 M
( either by advertising that size limit to its peers, or by convention.) s
5 212 M
( If that is done, backward direction messages will not exceed the size) s
5 201 M
( of receive buffers at either endpoint.) s
5 124 M
(Lever Expires October 10, 2016 [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
76 24 translate
/pagenum 12 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( If a sender transmits a backward direction message that is larger) s
5 674 M
( than the receiver is prepared for, the RDMA provider drops the) s
5 663 M
( message and the RDMA connection.) s
5 641 M
( If a sender transmits an RDMA message that is too small to convey a) s
5 630 M
( complete and valid RPC-over-RDMA and RPC message in either direction,) s
5 619 M
( the receiver MUST NOT use any value in the fields that were) s
5 608 M
( transmitted. Namely, the rdma_credit field MUST be ignored, and the) s
5 597 M
( message silently discarded.) s
5 575 M
(2.5. Sending A Backward Direction Call) s
5 553 M
( To form a backward direction RPC-over-RDMA Call message, an ONC RPC) s
5 542 M
( service endpoint constructs an RPC-over-RDMA header containing a) s
5 531 M
( fresh RPC XID in the rdma_xid field \(see Section 1.1.4 for full) s
5 520 M
( requirements\).) s
5 498 M
( The number of requested backward direction credits is placed in the) s
5 487 M
( rdma_credit field \(see Section 2.1\).) s
5 465 M
( The rdma_proc field in the RPC-over-RDMA header MUST contain the) s
5 454 M
( value RDMA_MSG. All three chunk lists MUST be empty.) s
5 432 M
( The ONC RPC Call header MUST follow immediately, starting with the) s
5 421 M
( same XID value that is present in the RPC-over-RDMA header. The Call) s
5 410 M
( header's msg_type field MUST contain the value CALL.) s
5 388 M
(2.6. Sending A Backward Direction Reply) s
5 366 M
( To form a backward direction RPC-over-RDMA Reply message, an ONC RPC) s
5 355 M
( client endpoint constructs an RPC-over-RDMA header containing a copy) s
5 344 M
( of the matching ONC RPC Call's RPC XID in the rdma_xid field \(see) s
5 333 M
( Section 1.1.4 for full requirements\).) s
5 311 M
( The number of granted backward direction credits is placed in the) s
5 300 M
( rdma_credit field \(see Section 2.1\).) s
5 278 M
( The rdma_proc field in the RPC-over-RDMA header MUST contain the) s
5 267 M
( value RDMA_MSG. All three chunk lists MUST be empty.) s
5 245 M
( The ONC RPC Reply header MUST follow immediately, starting with the) s
5 234 M
( same XID value that is present in the RPC-over-RDMA header. The) s
5 223 M
( Reply header's msg_type field MUST contain the value REPLY.) s
5 124 M
(Lever Expires October 10, 2016 [Page 12]) s
_R
S
%%Page: (13) 13
%%BeginPageSetup
_S
76 24 translate
/pagenum 13 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
(3. Backward Direction Upper Layer Binding) s
5 663 M
( RPC programs that operate on RPC-over-RDMA transports using the) s
5 652 M
( conventions described in this document do not require an Upper Layer) s
5 641 M
( Binding specification. Because backward direction operation using) s
5 630 M
( these conventions cannot transfer data via RMDA Read or Write, there) s
5 619 M
( can be no RDMA-eligible data items in the Upper Layer Program on this) s
5 608 M
( transport.) s
5 586 M
( In addition, since backward direction operation occurs on an already-) s
5 575 M
( established connection, there is no need to specify RPC bind) s
5 564 M
( parameters.) s
5 542 M
(4. Limits To This Approach) s
5 520 M
(4.1. Payload Size) s
5 498 M
( The major drawback to the approach described in this document is the) s
5 487 M
( limit on payload size in backward direction requests.) s
5 465 M
( o Some NFSv4.1 callback operations can have potentially large) s
5 454 M
( arguments or results. For example, CB_GETATTR on a file with a) s
5 443 M
( large ACL; or CB_NOTIFY, which can provide a large, complex) s
5 432 M
( argument.) s
5 410 M
( o Any backward direction operation protected by RPCSEC_GSS might) s
5 399 M
( have additional header information that makes it difficult to send) s
5 388 M
( backward direction operations with large arguments or results.) s
5 366 M
( o Larger payloads could potentially require the use of RDMA data) s
5 355 M
( transfers, which are complex and make it more difficult to detect) s
5 344 M
( backward direction requests. The msg_type field in the ONC RPC) s
5 333 M
( header would no longer be at a fixed location in backward) s
5 322 M
( direction requests.) s
5 300 M
(4.2. Preparedness To Handle Backward Requests) s
5 278 M
( A second drawback is the exposure of the client transport endpoint to) s
5 267 M
( backward direction Calls before it has posted receive buffers to) s
5 256 M
( handle them.) s
5 234 M
( Clients that do not support backward direction operation typically) s
5 223 M
( drop messages they do not recognize. However, this does not allow) s
5 212 M
( bi-direction-capable servers to quickly identify clients that cannot) s
5 201 M
( handle backward direction requests.) s
5 124 M
(Lever Expires October 10, 2016 [Page 13]) s
_R
S
%%Page: (14) 14
%%BeginPageSetup
_S
76 24 translate
/pagenum 14 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( The conventions in this document rely on Upper Layer Protocol) s
5 674 M
( consumers to decide when backward direction transport operation is) s
5 663 M
( appropriate.) s
5 641 M
(4.3. Long Term) s
5 619 M
( To address the limitations described in this section in the long run,) s
5 608 M
( two approaches are available:) s
5 586 M
( o Larger inline thresholds would make the transport capable of) s
5 575 M
( conveying larger backward direction requests) s
5 553 M
( o The capability to move chunks in the backward direction would lift) s
5 542 M
( the size limit even further by enabling backward direction Long) s
5 531 M
( Call and Reply messages to be formed) s
5 509 M
( The latter approach would benefit from changes to the XDR definition) s
5 498 M
( of the RPC-over-RDMA protocol, and would require significant changes) s
5 487 M
( to implementations.) s
5 465 M
( The use of the conventions described in this document to enable) s
5 454 M
( backward direction operation should be considered a transitional) s
5 443 M
( approach that is appropriate while the predominantly deployed) s
5 432 M
( versions of the RPC-over-RDMA protocol do not have native support for) s
5 421 M
( large backward direction messages.) s
5 399 M
(5. Security Considerations) s
5 377 M
( When RPCSEC_GSS integrity and confidentiality services \(described in) s
5 366 M
( [I-D.ietf-nfsv4-rpcsec-gssv3]\) are in use, additional RPC header) s
5 355 M
( information is included in each message. This increases the size of) s
5 344 M
( each message, further limiting the size of backward direction) s
5 333 M
( operations.) s
5 311 M
(6. IANA Considerations) s
5 289 M
( This document does not require actions by IANA.) s
5 267 M
(7. Acknowledgements) s
5 245 M
( Tom Talpey was an indispensable resource, in addition to creating the) s
5 234 M
( foundation upon which this work is based. Our warmest regards go to) s
5 223 M
( him for his help and support.) s
5 201 M
( Dave Noveck provided excellent review, constructive suggestions, and) s
5 190 M
( navigational guidance throughout the process of drafting this) s
5 179 M
( document.) s
5 124 M
(Lever Expires October 10, 2016 [Page 14]) s
_R
S
%%Page: (15) 15
%%BeginPageSetup
_S
76 24 translate
/pagenum 15 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-02.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft RPC-over-RDMA Bidirection April 2016) s
5 685 M
( Dai Ngo was a solid partner and collaborator. Together we) s
5 674 M
( constructed and tested independent prototypes of the conventions) s
5 663 M
( described in this document.) s
5 641 M
( The author wishes to thank Bill Baker for his unwavering support of) s
5 630 M
( this work. In addition, the author gratefully acknowledges the) s
5 619 M
( expert contributions of Karen Deitke, Chunli Zhang, Mahesh) s
5 608 M
( Siddheshwar, Steve Wise, and Tom Tucker.) s
5 586 M
( Special thanks go to the nfsv4 Working Group Chair Spencer Shepler) s
5 575 M
( and the nfsv4 Working Group Secretary Tom Haynes for their support.) s
5 553 M
(8. Normative References) s
5 531 M
( [I-D.ietf-nfsv4-rfc5666bis]) s
5 520 M
( Lever, C., Simpson, W., and T. Talpey, "Remote Direct) s
5 509 M
( Memory Access Transport for Remote Procedure Call", draft-) s
5 498 M
( ietf-nfsv4-rfc5666bis-04 \(work in progress\), March 2016.) s
5 476 M
( [I-D.ietf-nfsv4-rpcsec-gssv3]) s
5 465 M
( Adamson, A. and N. Williams, "Remote Procedure Call \(RPC\)) s
5 454 M
( Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-17) s
5 443 M
( \(work in progress\), January 2016.) s
5 421 M
( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s
5 410 M
( Requirement Levels", BCP 14, RFC 2119, March 1997.) s
5 388 M
( [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol) s
5 377 M
( Specification Version 2", RFC 5531, May 2009.) s
5 355 M
( [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File) s
5 344 M
( System \(NFS\) Version 4 Minor Version 1 Protocol", RFC) s
5 333 M
( 5661, January 2010.) s
5 311 M
( [RFC7530] Haynes, T. and D. Noveck, "Network File System \(NFS\)) s
5 300 M
( Version 4 Protocol", RFC 7530, March 2015.) s
5 278 M
(Author's Address) s
5 256 M
( Charles Lever) s
5 245 M
( Oracle Corporation) s
5 234 M
( 1015 Granger Avenue) s
5 223 M
( Ann Arbor, MI 48104) s
5 212 M
( USA) s
5 190 M
( Phone: +1 734 274 2396) s
5 179 M
( Email: chuck.lever@oracle.com) s
5 124 M
(Lever Expires October 10, 2016 [Page 15]) s
_R
S
%%Trailer
%%Pages: 15
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-19 09:07:53 |