One document matched: draft-ietf-nfsv4-rpcrdma-bidirection-03.ps
%!PS-Adobe-3.0
%%BoundingBox: 76 24 571 766
%%Title: Enscript Output
%%For: Chuck Lever
%%Creator: GNU Enscript 1.6.6
%%CreationDate: Mon May 2 11:40:04 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-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.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 May 2, 2016) s
5 652 M
(Expires: November 3, 2016) s
5 619 M
( Bi-directional Remote Procedure Call On RPC-over-RDMA Transports) s
5 608 M
( draft-ietf-nfsv4-rpcrdma-bidirection-03) s
5 586 M
(Abstract) s
5 564 M
( Recent minor versions of NFSv4 work best when ONC RPC transports can) s
5 553 M
( send Remote Procedure Call transactions in both directions on the) s
5 542 M
( same connection. This document describes how RPC-over-RDMA transport) s
5 531 M
( endpoints convey RPCs in both directions on a single connection.) s
5 509 M
(Status of This Memo) s
5 487 M
( This Internet-Draft is submitted in full conformance with the) s
5 476 M
( provisions of BCP 78 and BCP 79.) s
5 454 M
( Internet-Drafts are working documents of the Internet Engineering) s
5 443 M
( Task Force \(IETF\). Note that other groups may also distribute) s
5 432 M
( working documents as Internet-Drafts. The list of current Internet-) s
5 421 M
( Drafts is at http://datatracker.ietf.org/drafts/current/.) s
5 399 M
( Internet-Drafts are draft documents valid for a maximum of six months) s
5 388 M
( and may be updated, replaced, or obsoleted by other documents at any) s
5 377 M
( time. It is inappropriate to use Internet-Drafts as reference) s
5 366 M
( material or to cite them other than as "work in progress.") s
5 344 M
( This Internet-Draft will expire on November 3, 2016.) s
5 322 M
(Copyright Notice) s
5 300 M
( Copyright \(c\) 2016 IETF Trust and the persons identified as the) s
5 289 M
( document authors. All rights reserved.) s
5 267 M
( This document is subject to BCP 78 and the IETF Trust's Legal) s
5 256 M
( Provisions Relating to IETF Documents) s
5 245 M
( \(http://trustee.ietf.org/license-info\) in effect on the date of) s
5 234 M
( publication of this document. Please review these documents) s
5 223 M
( carefully, as they describe your rights and restrictions with respect) s
5 212 M
( to this document. Code Components extracted from this document must) s
5 201 M
( include Simplified BSD License text as described in Section 4.e of) s
5 190 M
( the Trust Legal Provisions and are provided without warranty as) s
5 179 M
( described in the Simplified BSD License.) s
5 124 M
(Lever Expires November 3, 2016 [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
76 24 translate
/pagenum 2 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(Table of Contents) s
5 663 M
( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2) s
5 652 M
( 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3) s
5 641 M
( 2. Understanding RPC Direction . . . . . . . . . . . . . . . . . 3) s
5 630 M
( 2.1. Forward Direction . . . . . . . . . . . . . . . . . . . . 3) s
5 619 M
( 2.2. Backward Direction . . . . . . . . . . . . . . . . . . . 4) s
5 608 M
( 2.3. Bi-directional Operation . . . . . . . . . . . . . . . . 4) s
5 597 M
( 2.4. XID Values . . . . . . . . . . . . . . . . . . . . . . . 4) s
5 586 M
( 3. Rationale For Bi-Directional RPC-over-RDMA . . . . . . . . . 5) s
5 575 M
( 3.1. NFSv4.0 Callback Operation . . . . . . . . . . . . . . . 5) s
5 564 M
( 3.2. NFSv4.1 Callback Operation . . . . . . . . . . . . . . . 6) s
5 553 M
( 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 6) s
5 542 M
( 4.1. Backward Credits . . . . . . . . . . . . . . . . . . . . 7) s
5 531 M
( 4.2. Managing Receive Buffers . . . . . . . . . . . . . . . . 7) s
5 520 M
( 5. Protocol For Backward Operation . . . . . . . . . . . . . . . 8) s
5 509 M
( 5.1. Sending A Backward Direction Call . . . . . . . . . . . . 8) s
5 498 M
( 5.2. Sending A Backward Direction Reply . . . . . . . . . . . 9) s
5 487 M
( 5.3. Backward Direction Chunks . . . . . . . . . . . . . . . . 9) s
5 476 M
( 5.4. Backward Direction Retransmission . . . . . . . . . . . . 10) s
5 465 M
( 6. In the Absence of Backward Direction Support . . . . . . . . 10) s
5 454 M
( 7. Backward Direction Upper Layer Binding . . . . . . . . . . . 11) s
5 443 M
( 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11) s
5 432 M
( 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11) s
5 421 M
( 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11) s
5 410 M
( 11. Normative References . . . . . . . . . . . . . . . . . . . . 12) s
5 399 M
( Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12) s
5 377 M
(1. Introduction) s
5 355 M
( The purpose of this document is to enable bi-directional RPC) s
5 344 M
( operation on RPC-over-RDMA protocol versions that do not have) s
5 333 M
( specific protocol facilities for backward direction operation.) s
5 322 M
( Backward direction RPC transactions enable the operation of NFSv4.1,) s
5 311 M
( and in particular pNFS.) s
5 289 M
( For example, using the protocol described in this document, RPC) s
5 278 M
( transactions can be conveyed in both directions on the same RPC-over-) s
5 267 M
( RDMA Version One connection without changes to the Version One header) s
5 256 M
( XDR description. Therefore this document does not update) s
5 245 M
( [I-D.ietf-nfsv4-rfc5666bis].) s
5 223 M
( Providing an Upper Layer Binding for NFSv4.x callback operations is) s
5 212 M
( outside the scope of this document.) s
5 124 M
(Lever Expires November 3, 2016 [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
76 24 translate
/pagenum 3 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(1.1. 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. Understanding RPC Direction) s
5 597 M
( The ONC RPC protocol as described in [RFC5531] is fundamentally a) s
5 586 M
( message-passing protocol between one server and one or more clients.) s
5 575 M
( ONC RPC transactions are made up of two types of messages.) s
5 553 M
( A CALL message, or "Call", requests work. A Call is designated by) s
5 542 M
( the value CALL in the message's msg_type field. An arbitrary unique) s
5 531 M
( value is placed in the message's xid field. A host that originates a) s
5 520 M
( Call is referred to in this document as a "Requester.") s
5 498 M
( A REPLY message, or "Reply", reports the results of work requested by) s
5 487 M
( a Call. A Reply is designated by the value REPLY in the message's) s
5 476 M
( msg_type field. The value contained in the message's xid field is) s
5 465 M
( copied from the Call whose results are being returned. A host that) s
5 454 M
( emits a Reply is referred to as a "Responder.") s
5 432 M
( Typically, a Call generates a corresponding Reply. A Reply is never) s
5 421 M
( sent without a corresponding Call.) s
5 399 M
( RPC-over-RDMA is a connection-oriented RPC transport. When a) s
5 388 M
( connection-oriented transport is used, ONC RPC client endpoints are) s
5 377 M
( responsible for initiating transport connections, while ONC RPC) s
5 366 M
( service endpoints wait passively for incoming connection requests.) s
5 344 M
( RPC direction on connectionless RPC transports is not considered in) s
5 333 M
( this document.) s
5 311 M
(2.1. Forward Direction) s
5 289 M
( A traditional ONC RPC client is always a Requester. A traditional) s
5 278 M
( ONC RPC service is always a Responder. This traditional form of ONC) s
5 267 M
( RPC message passing is referred to as operation in the "forward) s
5 256 M
( direction.") s
5 234 M
( During forward direction operation, the ONC RPC client is responsible) s
5 223 M
( for establishing transport connections.) s
5 124 M
(Lever Expires November 3, 2016 [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
76 24 translate
/pagenum 4 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(2.2. Backward Direction) s
5 663 M
( The ONC RPC specification [RFC5531] does not forbid passing messages) s
5 652 M
( in the other direction. An ONC RPC service endpoint can act as a) s
5 641 M
( Requester, in which case an ONC RPC client endpoint acts as a) s
5 630 M
( Responder. This form of message passing is referred to as operation) s
5 619 M
( in the "backward direction.") s
5 597 M
( During backward direction operation, the ONC RPC client is) s
5 586 M
( responsible for establishing transport connections, even though ONC) s
5 575 M
( RPC Calls come from the ONC RPC server.) s
5 553 M
( ONC RPC clients and services are optimized to perform and scale well) s
5 542 M
( while handling traffic in the forward direction, and may not be) s
5 531 M
( prepared to handle operation in the backward direction. Not until) s
5 520 M
( recently has there been a need to handle backward direction) s
5 509 M
( operation.) s
5 487 M
(2.3. Bi-directional Operation) s
5 465 M
( A pair of connected RPC endpoints may choose to use only forward or) s
5 454 M
( only backward direction operations on a particular transport. Or,) s
5 443 M
( these endpoints may send Calls in both directions concurrently on the) s
5 432 M
( same transport.) s
5 410 M
( "Bi-directional operation" occurs when both transport endpoints act) s
5 399 M
( as a Requester and a Responder at the same time. As above, the ONC) s
5 388 M
( RPC client is always responsible for establishing transport) s
5 377 M
( connections.) s
5 355 M
(2.4. XID Values) s
5 333 M
( Section 9 of [RFC5531] introduces the ONC RPC transaction identifier,) s
5 322 M
( or "xid" for short. The value of an xid is interpreted in the) s
5 311 M
( context of the message's msg_type field.) s
5 289 M
( o The xid of a Call is arbitrary but is unique among outstanding) s
5 278 M
( Calls from that Requester.) s
5 256 M
( o The xid of a Reply always matches that of the initiating Call.) s
5 234 M
( When receiving a Reply, a Requester matches the xid value in the) s
5 223 M
( Reply with a Call it previously sent.) s
5 124 M
(Lever Expires November 3, 2016 [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
76 24 translate
/pagenum 5 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(2.4.1. XID Generation) s
5 663 M
( During bi-directional operation, forward and backward direction XIDs) s
5 652 M
( are typically generated on distinct hosts by possibly different) s
5 641 M
( algorithms. There is no co-ordination between forward and backward) s
5 630 M
( direction XID generation.) s
5 608 M
( Therefore, a forward direction Requester MAY use the same xid value) s
5 597 M
( at the same time as a backward direction Requester on the same) s
5 586 M
( transport connection. Though such concurrent requests use the same) s
5 575 M
( xid value, they represent distinct ONC RPC transactions.) s
5 553 M
(3. Rationale For Bi-Directional RPC-over-RDMA) s
5 531 M
(3.1. NFSv4.0 Callback Operation) s
5 509 M
( An NFSv4.0 client employs a traditional ONC RPC client to send NFS) s
5 498 M
( requests to an NFSv4.0 server's traditional ONC RPC service) s
5 487 M
( [RFC7530]. NFSv4.0 requests flow in the forward direction on a) s
5 476 M
( connection established by the client. This connection is referred to) s
5 465 M
( as a "forechannel" connection.) s
5 443 M
( An NFSv4 "delegation" is simply a promise made by a server that it) s
5 432 M
( will notify a client before another agent is allowed access to a) s
5 421 M
( file. With this guarantee, that client can operate as sole accessor) s
5 410 M
( of the file. In particular, it can manage the file's data and) s
5 399 M
( metadata caches aggressively.) s
5 377 M
( To administer file delegations, NFSv4.0 introduces the use of) s
5 366 M
( callback operations, or "callbacks", in Section 10.2 of [RFC7530].) s
5 355 M
( An NFSv4.0 server sets up a traditional ONC RPC client, and an) s
5 344 M
( NFSv4.0 client sets up a traditional ONC RPC service. Callbacks flow) s
5 333 M
( in the forward direction on a connection established between the) s
5 322 M
( server's callback client, and the client's callback server. This) s
5 311 M
( connection is distinct from connections being used as forechannels,) s
5 300 M
( and is referred to as a "backchannel connection.") s
5 278 M
( When an RDMA transport is used as a forechannel, an NFSv4.0 client) s
5 267 M
( typically provides a TCP callback service. The client's SETCLIENTID) s
5 256 M
( operation advertises the callback service endpoint with a "tcp" or) s
5 245 M
( "tcp6" netid. The server then connects to this service using a TCP) s
5 234 M
( socket.) s
5 212 M
( NFSv4.0 implementations are fully functional without a backchannel in) s
5 201 M
( place. In this case, the server does not grant file delegations.) s
5 190 M
( This might result in a negative performance effect, but functional) s
5 179 M
( correctness is unaffected.) s
5 124 M
(Lever Expires November 3, 2016 [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
76 24 translate
/pagenum 6 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(3.2. NFSv4.1 Callback Operation) s
5 663 M
( NFSv4.1 supports file delegation in a similar fashion to NFSv4.0, and) s
5 652 M
( extends the callback mechanism to manage pNFS layouts, as discussed) s
5 641 M
( in Section 12 of [RFC5661].) s
5 619 M
( To facilitate operation through NAT routers, all NFSv4.1 transport) s
5 608 M
( connections are initiated by NFSv4.1 clients. Therefore NFSv4.1) s
5 597 M
( servers send callbacks to clients in the backward direction on) s
5 586 M
( connections established by NFSv4.1 clients.) s
5 564 M
( NFSv4.1 clients and servers indicate to their peers that a) s
5 553 M
( backchannel capability is available on a given transport in the) s
5 542 M
( arguments and results of NFS CREATE_SESSION or BIND_CONN_TO_SESSION) s
5 531 M
( operations.) s
5 509 M
( NFSv4.1 clients may establish distinct transport connections for) s
5 498 M
( forechannel and backchannel operation, or they may combine) s
5 487 M
( forechannel and backchannel operation on one transport connection) s
5 476 M
( using bi-directional operation.) s
5 454 M
( Without a backward direction RPC-over-RDMA capability, an NFSv4.1) s
5 443 M
( client must additionally connect using a transport with backward) s
5 432 M
( direction capability to use as a backchannel. TCP is the only choice) s
5 421 M
( for an NFSv4.1 backchannel connection in this case.) s
5 399 M
( Some implementations find it more convenient to use a single combined) s
5 388 M
( transport \(ie. a transport that is capable of bi-directional) s
5 377 M
( operation\). This simplifies connection establishment and recovery) s
5 366 M
( during network partitions or when one endpoint restarts.) s
5 344 M
( As with NFSv4.0, if a backchannel is not in use, an NFSv4.1 server) s
5 333 M
( does not grant delegations. But because of its reliance on callbacks) s
5 322 M
( to manage pNFS layout state, pNFS operation is not possible without a) s
5 311 M
( backchannel.) s
5 289 M
(4. Flow Control) s
5 267 M
( For an RDMA Send operation to work, the receiving peer must have) s
5 256 M
( posted an RDMA Receive Work Request \(WR\) to provide a receive buffer) s
5 245 M
( in which to land the incoming message. If a receiver hasn't posted) s
5 234 M
( enough Receive WRs to land incoming Send operations, the RDMA) s
5 223 M
( provider is allowed to drop the RDMA connection.) s
5 201 M
( RPC-over-RDMA transport protocols provide built-in send flow control) s
5 190 M
( to prevent overrunning the number of pre-posted receive buffers on a) s
5 179 M
( connection's receive endpoint. This is fully discussed in) s
5 168 M
( Section 4.3 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 124 M
(Lever Expires November 3, 2016 [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
76 24 translate
/pagenum 7 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(4.1. 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 has) s
5 509 M
( granted. This is the number of backward direction Calls the) s
5 498 M
( Responder is prepared to handle at once.) s
5 476 M
( When message direction is not fully determined by context or by an) s
5 465 M
( accompanying RPC message with a call direction field, it is not) s
5 454 M
( possible to tell whether the header credit value is a request or) s
5 443 M
( grant, or whether the value applies to the forward direction or) s
5 432 M
( backward direction. In such cases, the receiver MUST NOT use the) s
5 421 M
( header's credit value.) s
5 399 M
(4.2. Managing Receive Buffers) s
5 377 M
( An RPC-over-RDMA transport endpoint must pre-post receive buffers) s
5 366 M
( before it can receive and process incoming RPC-over-RDMA messages.) s
5 355 M
( If a sender transmits a message for a receiver which has no prepared) s
5 344 M
( receive buffer, the RDMA provider is allowed to drop the RDMA) s
5 333 M
( connection.) s
5 311 M
(4.2.1. Client Receive Buffers) s
5 289 M
( Typically an RPC-over-RDMA Requester posts only as many receive) s
5 278 M
( buffers as there are outstanding RPC Calls. A client endpoint) s
5 267 M
( without backward direction support might therefore at times have no) s
5 256 M
( pre-posted receive buffers.) s
5 234 M
( To receive incoming backward direction Calls, an RPC-over-RDMA client) s
5 223 M
( endpoint must pre-post enough additional receive buffers to match its) s
5 212 M
( advertised backward direction credit value. Each outstanding forward) s
5 201 M
( direction RPC requires an additional receive buffer above this) s
5 190 M
( minimum.) s
5 124 M
(Lever Expires November 3, 2016 [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
76 24 translate
/pagenum 8 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
( When an RDMA transport connection is lost, all active receive buffers) s
5 674 M
( are flushed and are no longer available to receive incoming messages.) s
5 663 M
( When a fresh transport connection is established, a client endpoint) s
5 652 M
( must re-post a receive buffer to handle the Reply for each) s
5 641 M
( retransmitted forward direction Call, and a full set of receive) s
5 630 M
( buffers to handle backward direction Calls.) s
5 608 M
(4.2.2. Server Receive Buffers) s
5 586 M
( A forward direction RPC-over-RDMA service endpoint posts as many) s
5 575 M
( receive buffers as it expects incoming forward direction Calls. That) s
5 564 M
( is, it posts no fewer buffers than the number of credits granted in) s
5 553 M
( the rdma_credit field of forward direction RPC replies.) s
5 531 M
( To receive incoming backward direction replies, an RPC-over-RDMA) s
5 520 M
( server endpoint must pre-post a receive buffer for each backward) s
5 509 M
( direction Call it sends.) s
5 487 M
( When the existing transport connection is lost, all active receive) s
5 476 M
( buffers are flushed and are no longer available to receive incoming) s
5 465 M
( messages. When a fresh transport connection is established, a server) s
5 454 M
( endpoint must re-post a receive buffer to handle the Reply for each) s
5 443 M
( retransmitted backward direction Call, and a full set of receive) s
5 432 M
( buffers for receiving forward direction Calls.) s
5 410 M
(5. Protocol For Backward Operation) s
5 388 M
( Performing backward direction ONC RPC operations over an RPC-over-) s
5 377 M
( RDMA transport connection can be accomplished by observing the) s
5 366 M
( protocol described in the following subsections. For reference, the) s
5 355 M
( XDR description of RPC-over-RDMA Version One is contained in) s
5 344 M
( Section 5.1 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 322 M
(5.1. Sending A Backward Direction Call) s
5 300 M
( To form a backward direction RPC-over-RDMA Call message, an ONC RPC) s
5 289 M
( service endpoint constructs an RPC-over-RDMA header containing a) s
5 278 M
( fresh RPC XID in the rdma_xid field \(see Section 2.4 for full) s
5 267 M
( requirements\).) s
5 245 M
( The rdma_vers field MUST contain the same value in backward and) s
5 234 M
( forward direction Call messages on the same connection.) s
5 212 M
( The number of requested backward direction credits is placed in the) s
5 201 M
( rdma_credit field \(see Section 4\).) s
5 179 M
( Whether presented inline or as a separate chunk, the ONC RPC Call) s
5 168 M
( header MUST start with the same XID value that is present in the RPC-) s
5 124 M
(Lever Expires November 3, 2016 [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
76 24 translate
/pagenum 9 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
( over-RDMA header, and the header's msg_type field MUST contain the) s
5 674 M
( value CALL.) s
5 652 M
(5.2. Sending A Backward Direction Reply) s
5 630 M
( To form a backward direction RPC-over-RDMA Reply message, an ONC RPC) s
5 619 M
( client endpoint constructs an RPC-over-RDMA header containing a copy) s
5 608 M
( of the matching ONC RPC Call's RPC XID in the rdma_xid field \(see) s
5 597 M
( Section 2.4 for full requirements\).) s
5 575 M
( The rdma_vers field MUST contain the same value in a backward) s
5 564 M
( direction Reply message as in the matching Call message.) s
5 542 M
( The number of granted backward direction credits is placed in the) s
5 531 M
( rdma_credit field \(see Section 4\).) s
5 509 M
( Whether presented inline or as a separate chunk, the ONC RPC Reply) s
5 498 M
( header MUST start with the same XID value that is present in the RPC-) s
5 487 M
( over-RDMA header, and the header's msg_type field MUST contain the) s
5 476 M
( value REPLY.) s
5 454 M
(5.3. Backward Direction Chunks) s
5 432 M
( Chunks MAY be used in the backward direction. They operate the same) s
5 421 M
( way as in the forward direction \(see [I-D.ietf-nfsv4-rfc5666bis] for) s
5 410 M
( details\).) s
5 388 M
( An implementation might not support any Upper Layer Protocol that has) s
5 377 M
( DDP-eligible data items. The Upper Layer Protocol may also use only) s
5 366 M
( small messages, or it may have a native mechanism for restricting the) s
5 355 M
( size of backward direction RPC messages, obviating the need to handle) s
5 344 M
( Long Messages in the backward direction.) s
5 322 M
( When there is no Upper Layer Protocol requirement for chunks,) s
5 311 M
( implementers can choose not to provide support for chunks in the) s
5 300 M
( backward direction. This avoids the complexity of adding support for) s
5 289 M
( performing RDMA Reads and Writes in the backward direction.) s
5 267 M
( When chunks are not implemented, RPC messages in the backward) s
5 256 M
( direction are always sent using RDMA_MSG, and therefore can be no) s
5 245 M
( larger than what can be sent inline \(that is, without chunks\).) s
5 234 M
( Sending an inline message larger than the receiver's inline threshold) s
5 223 M
( can result in loss of connection.) s
5 201 M
( If a backward direction requester provides a non-empty chunk list to) s
5 190 M
( a responder that does not support chunks, the responder MUST reply) s
5 179 M
( with an RDMA_ERROR message with rdma_err field set to ERR_CHUNK.) s
5 124 M
(Lever Expires November 3, 2016 [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
76 24 translate
/pagenum 10 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
(5.4. Backward Direction Retransmission) s
5 663 M
( In rare cases, an ONC RPC transaction cannot be completed within a) s
5 652 M
( certain time. This can be because the transport connection was lost,) s
5 641 M
( the Call or Reply message was dropped, or because the Upper Layer) s
5 630 M
( consumer delayed or dropped the ONC RPC request. Typically, the) s
5 619 M
( Requester sends the transaction again, reusing the same RPC XID.) s
5 608 M
( This is known as an "RPC retransmission".) s
5 586 M
( In the forward direction, the Requester is the ONC RPC client. The) s
5 575 M
( client is always responsible for establishing a transport connection) s
5 564 M
( before sending again.) s
5 542 M
( In the backward direction, the Requester is the ONC RPC server.) s
5 531 M
( Because an ONC RPC server does not establish transport connections) s
5 520 M
( with clients, it cannot send a retransmission if there is no) s
5 509 M
( transport connection. It must wait for the ONC RPC client to re-) s
5 498 M
( establish the transport connection before it can retransmit ONC RPC) s
5 487 M
( transactions in the backward direction.) s
5 465 M
( If an ONC RPC client has no work to do, it may be some time before it) s
5 454 M
( re-establishes a transport connection. Backward direction Requesters) s
5 443 M
( must be prepared to wait indefinitely for a connection to be) s
5 432 M
( established before a pending backward direction ONC RPC Call can be) s
5 421 M
( retransmitted.) s
5 399 M
(6. In the Absence of Backward Direction Support) s
5 377 M
( An RPC-over-RDMA transport endpoint might not support backward) s
5 366 M
( direction operation. There might be no mechanism in the transport) s
5 355 M
( implementation to do so. Or the Upper Layer Protocol consumer might) s
5 344 M
( not yet have configured the transport to handle backward direction) s
5 333 M
( traffic.) s
5 311 M
( If an endpoint is not prepared to receive an incoming backward) s
5 300 M
( direction message, loss of the RDMA connection might result. Thus a) s
5 289 M
( denial-of-service could result if a sender continues to send backward) s
5 278 M
( direction messages after every transport reconnect to an endpoint) s
5 267 M
( that is not prepared to receive them.) s
5 245 M
( When dealing with the possibility that the remote peer has no) s
5 234 M
( transport level support for backward direction operation, the Upper) s
5 223 M
( Layer Protocol becomes responsible for informing peers when backward) s
5 212 M
( direction operation is supported. Otherwise even a simple backward) s
5 201 M
( direction NULL probe from a peer could result in a lost connection.) s
5 179 M
( An NFSv4.1 server does not send backchannel messages to an NFSv4.1) s
5 168 M
( client before the NFSv4.1 client has sent a CREATE_SESSION or a) s
5 124 M
(Lever Expires November 3, 2016 [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
76 24 translate
/pagenum 11 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 2016) s
5 685 M
( BIND_CONN_TO_SESSION operation. As long as an NFSv4.1 client has) s
5 674 M
( prepared appropriate backchannel resources before sending one of) s
5 663 M
( these operations announcing support for backchannel operation,) s
5 652 M
( denial-of-service is avoided.) s
5 630 M
( Therefore, an Upper Layer Protocol consumer MUST NOT perform backward) s
5 619 M
( direction ONC RPC operations unless the peer consumer has indicated) s
5 608 M
( it is prepared to handle them. A description of Upper Layer Protocol) s
5 597 M
( mechanisms used for this indication is outside the scope of this) s
5 586 M
( document.) s
5 564 M
(7. Backward Direction Upper Layer Binding) s
5 542 M
( Since backward direction operation occurs on an already-established) s
5 531 M
( connection, there is no need to specify RPC bind parameters.) s
5 509 M
( An Upper Layer Protocol that operates on RPC-over-RDMA transports in) s
5 498 M
( the backward direction may have DDP-eligible data items. These are) s
5 487 M
( specified in an Upper Layer Binding document.) s
5 465 M
( By default, no data items in a ULP are DDP-eligible. If there are no) s
5 454 M
( DDP-eligible data items to document, an explicit Upper Layer Binding) s
5 443 M
( may not be needed for an Upper Layer Protocol that operates only in) s
5 432 M
( the backward direction.) s
5 410 M
( Consult Section 7 of [I-D.ietf-nfsv4-rfc5666bis] for details about) s
5 399 M
( what else may be contained in a binding.) s
5 377 M
(8. Security Considerations) s
5 355 M
( Security considerations for operation on RPC-over-RDMA transports are) s
5 344 M
( outlined in Section 9 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 322 M
(9. IANA Considerations) s
5 300 M
( This document does not require actions by IANA.) s
5 278 M
(10. Acknowledgements) s
5 256 M
( Tom Talpey was an indispensable resource, in addition to creating the) s
5 245 M
( foundation upon which this work is based. Our warmest regards go to) s
5 234 M
( him for his help and support.) s
5 212 M
( Dave Noveck provided excellent review, constructive suggestions, and) s
5 201 M
( navigational guidance throughout the process of drafting this) s
5 190 M
( document.) s
5 124 M
(Lever Expires November 3, 2016 [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
76 24 translate
/pagenum 12 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-03.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 718 M
(Internet-Draft Bidirectional RPC-over-RDMA May 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 changes) 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
(11. 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
( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s
5 465 M
( Requirement Levels", BCP 14, RFC 2119, March 1997.) s
5 443 M
( [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol) s
5 432 M
( Specification Version 2", RFC 5531, May 2009.) s
5 410 M
( [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File) s
5 399 M
( System \(NFS\) Version 4 Minor Version 1 Protocol", RFC) s
5 388 M
( 5661, January 2010.) s
5 366 M
( [RFC7530] Haynes, T. and D. Noveck, "Network File System \(NFS\)) s
5 355 M
( Version 4 Protocol", RFC 7530, March 2015.) s
5 333 M
(Author's Address) s
5 311 M
( Charles Lever) s
5 300 M
( Oracle Corporation) s
5 289 M
( 1015 Granger Avenue) s
5 278 M
( Ann Arbor, MI 48104) s
5 267 M
( USA) s
5 245 M
( Phone: +1 734 274 2396) s
5 234 M
( Email: chuck.lever@oracle.com) s
5 124 M
(Lever Expires November 3, 2016 [Page 12]) s
_R
S
%%Trailer
%%Pages: 12
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-19 09:04:01 |