One document matched: draft-ietf-nfsv4-rpcrdma-bidirection-04.ps
%!PS-Adobe-3.0
%%BoundingBox: 76 24 571 766
%%Title: Enscript Output
%%For: Chuck Lever
%%Creator: GNU Enscript 1.6.6
%%CreationDate: Fri May 27 10:07:33 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-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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 27, 2016) s
5 652 M
(Expires: November 28, 2016) s
5 619 M
( Bi-directional Remote Procedure Call On RPC-over-RDMA Transports) s
5 608 M
( draft-ietf-nfsv4-rpcrdma-bidirection-04) s
5 586 M
(Abstract) s
5 564 M
( Minor versions of NFSv4 newer than NFSv4.0 work best when ONC RPC) s
5 553 M
( transports can send Remote Procedure Call transactions in both) s
5 542 M
( directions on the same connection. This document describes how RPC-) s
5 531 M
( over-RDMA transport endpoints convey RPCs in both directions on a) s
5 520 M
( single connection.) 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 November 28, 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 November 28, 2016 [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
76 24 translate
/pagenum 2 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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. Immediate Uses Of 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. Inline Thresholds . . . . . . . . . . . . . . . . . . . . 7) s
5 520 M
( 4.3. Managing Receive Buffers . . . . . . . . . . . . . . . . 7) s
5 509 M
( 5. Sending And Receiving Backward Operations . . . . . . . . . . 8) s
5 498 M
( 5.1. Sending A Backward Direction Call . . . . . . . . . . . . 9) s
5 487 M
( 5.2. Sending A Backward Direction Reply . . . . . . . . . . . 9) s
5 476 M
( 5.3. Backward Direction Chunks . . . . . . . . . . . . . . . . 9) s
5 465 M
( 5.4. Backward Direction Retransmission . . . . . . . . . . . . 10) s
5 454 M
( 6. In the Absence of Backward Direction Support . . . . . . . . 11) s
5 443 M
( 7. Considerations For Upper Layer Bindings . . . . . . . . . . . 11) s
5 432 M
( 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12) s
5 421 M
( 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12) s
5 410 M
( 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12) s
5 399 M
( 11. Normative References . . . . . . . . . . . . . . . . . . . . 12) s
5 388 M
( Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13) s
5 366 M
(1. Introduction) s
5 344 M
( The purpose of this document is to enable concurrent operation in) s
5 333 M
( both directions on a single transport connection using RPC-over-RDMA) s
5 322 M
( protocol versions that do not have specific facilities for backward) s
5 311 M
( direction operation.) s
5 289 M
( Backward direction RPC transactions are necessary for the operation) s
5 278 M
( of NFSv4.1, and in particular, of pNFS, though any Upper Layer) s
5 267 M
( Protocol implementation may make use of them. An Upper Layer Binding) s
5 256 M
( for NFSv4.x callback operation is additionally required \(see) s
5 245 M
( Section 7\), but is not provided in this document.) s
5 223 M
( For example, using the approach described herein, RPC transactions) s
5 212 M
( can be conveyed in both directions on the same RPC-over-RDMA Version) s
5 201 M
( One connection without changes to the the XDR description of RPC-) s
5 190 M
( over-RDMA Version One. This document does not modify the XDR or) s
5 179 M
( protocol described in [I-D.ietf-nfsv4-rfc5666bis]. Future versions) s
5 124 M
(Lever Expires November 28, 2016 [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
76 24 translate
/pagenum 3 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( of RPC-over-RDMA may adopt the approach described herein, or may) s
5 674 M
( replace it with a different approach.) s
5 652 M
(1.1. Requirements Language) s
5 630 M
( The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",) s
5 619 M
( "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this) s
5 608 M
( document are to be interpreted as described in [RFC2119].) s
5 586 M
(2. Understanding RPC Direction) s
5 564 M
( The ONC RPC protocol as described in [RFC5531] is architected as a) s
5 553 M
( message-passing protocol between one server and one or more clients.) s
5 542 M
( ONC RPC transactions are made up of two types of messages.) s
5 520 M
( A CALL message, or "Call", requests work. A Call is designated by) s
5 509 M
( the value CALL in the message's msg_type field. An arbitrary unique) s
5 498 M
( value is placed in the message's xid field. A host that originates a) s
5 487 M
( Call is referred to in this document as a "Requester.") s
5 465 M
( A REPLY message, or "Reply", reports the results of work requested by) s
5 454 M
( a Call. A Reply is designated by the value REPLY in the message's) s
5 443 M
( msg_type field. The value contained in the message's xid field is) s
5 432 M
( copied from the Call whose results are being returned. A host that) s
5 421 M
( emits a Reply is referred to as a "Responder.") s
5 399 M
( Typically, a Call results in a corresponding Reply. A Reply is never) s
5 388 M
( sent without a corresponding Call.) s
5 366 M
( RPC-over-RDMA is a connection-oriented RPC transport. In all cases,) s
5 355 M
( when a connection-oriented transport is used, ONC RPC client) s
5 344 M
( endpoints are responsible for initiating transport connections, while) s
5 333 M
( ONC RPC service endpoints passively await incoming connection) s
5 322 M
( requests.) s
5 300 M
( RPC direction on connectionless RPC transports is not addressed in) s
5 289 M
( this document.) s
5 267 M
(2.1. Forward Direction) s
5 245 M
( Traditionally, an ONC RPC client acts as a Requester, while an ONC) s
5 234 M
( RPC service acts as a Responder. This form of message passing is) s
5 223 M
( referred to as "forward direction" operation.) s
5 124 M
(Lever Expires November 28, 2016 [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
76 24 translate
/pagenum 4 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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 "backward) s
5 619 M
( direction" operation.) 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
( NFSv4.1 [RFC5661] has there been a strong need to handle backward) s
5 509 M
( direction 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.) s
5 377 M
( Bi-directionality is an extension of RPC transport connection) s
5 366 M
( sharing. Two RPC endpoints wish to exchange independent RPC messages) s
5 355 M
( over a shared connection, but in opposite directions. These messages) s
5 344 M
( may or may not be related to the same workloads or RPC Programs.) s
5 322 M
(2.4. XID Values) s
5 300 M
( Section 9 of [RFC5531] introduces the ONC RPC transaction identifier,) s
5 289 M
( or "xid" for short. The value of an xid is interpreted in the) s
5 278 M
( context of the message's msg_type field.) s
5 256 M
( o The xid of a Call is arbitrary but is unique among outstanding) s
5 245 M
( Calls from that Requester.) s
5 223 M
( o The xid of a Reply always matches that of the initiating Call.) s
5 201 M
( When receiving a Reply, a Requester matches the xid value in the) s
5 190 M
( Reply with a Call it previously sent.) s
5 124 M
(Lever Expires November 28, 2016 [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
76 24 translate
/pagenum 5 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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. Immediate Uses Of 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 client or program running on the) s
5 421 M
( server is allowed access to a file. With this guarantee, that client) s
5 410 M
( can operate as sole accessor of the file. In particular, it can) s
5 399 M
( manage the file's data and 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 can function without a backchannel in place.) s
5 201 M
( In this case, the server does not grant file delegations. This might) s
5 190 M
( result in a negative performance effect, but correctness is not) s
5 179 M
( affected.) s
5 124 M
(Lever Expires November 28, 2016 [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
76 24 translate
/pagenum 6 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( Implementations often find it more convenient to use a single) s
5 388 M
( combined 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. This can) s
5 355 M
( also enable better scaling by using fewer transport connections to) s
5 344 M
( perform the same work.) s
5 322 M
( As with NFSv4.0, if a backchannel is not in use, an NFSv4.1 server) s
5 311 M
( does not grant delegations. Because NFSv4.1 relies on callbacks to) s
5 300 M
( manage pNFS layout state, pNFS operation is not possible without a) s
5 289 M
( backchannel.) s
5 267 M
(4. Flow Control) s
5 245 M
( For an RDMA Send operation to work properly, the receiving peer must) s
5 234 M
( have posted a receive buffer in which to accept the incoming message.) s
5 223 M
( If a receiver hasn't posted enough buffers to accommodate each) s
5 212 M
( incoming Send operation, the receiving RDMA provider is allowed to) s
5 201 M
( terminate the RDMA connection.) s
5 179 M
( RPC-over-RDMA transport protocols provide built-in send flow control) s
5 168 M
( to prevent overrunning the number of pre-posted receive buffers on a) s
5 124 M
(Lever Expires November 28, 2016 [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
76 24 translate
/pagenum 7 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( connection's receive endpoint. For RPC-over-RDMA Version One, this) s
5 674 M
( is discussed in Section 4.3 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 652 M
(4.1. Backward Credits) s
5 630 M
( Credits work the same way in the backward direction as they do in the) s
5 619 M
( forward direction. However, forward direction credits and backward) s
5 608 M
( direction credits are accounted separately.) s
5 586 M
( In other words, the forward direction credit value is the same) s
5 575 M
( whether or not there are backward direction resources associated with) s
5 564 M
( an RPC-over-RDMA transport connection. The backward direction credit) s
5 553 M
( value MAY be different than the forward direction credit value. The) s
5 542 M
( rdma_credit field in a backward direction RPC-over-RDMA message MUST) s
5 531 M
( NOT contain the value zero.) s
5 509 M
( A backward direction Requester \(ie, an RPC-over-RDMA service) s
5 498 M
( endpoint\) requests credits from the Responder \(ie, an RPC-over-RDMA) s
5 487 M
( client endpoint\). The Responder reports how many credits it has) s
5 476 M
( granted. This is the number of backward direction Calls the) s
5 465 M
( Responder is prepared to handle at once.) s
5 443 M
( When message direction is not fully determined by context or by an) s
5 432 M
( accompanying RPC message with a call direction field, it is not) s
5 421 M
( possible to tell whether the header credit value is a request or) s
5 410 M
( grant, or whether the value applies to the forward direction or) s
5 399 M
( backward direction. In such cases, the receiver MUST NOT use the) s
5 388 M
( header's credit value.) s
5 366 M
(4.2. Inline Thresholds) s
5 344 M
( Forward and backward operation on the same connection share the same) s
5 333 M
( receive buffers. Therefore the inline threshold values for the) s
5 322 M
( forward direction and the backward direction are the same. The call) s
5 311 M
( inline threshold for the backward direction is the same as the reply) s
5 300 M
( inline threshold for the forward direction, and vice versa. For more) s
5 289 M
( information, see Section 4.3.2 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 267 M
(4.3. Managing Receive Buffers) s
5 245 M
( An RPC-over-RDMA transport endpoint must pre-post receive buffers) s
5 234 M
( before it can receive and process incoming RPC-over-RDMA messages.) s
5 223 M
( If a sender transmits a message for a receiver which has no posted) s
5 212 M
( receive buffer, the RDMA provider is allowed to drop the RDMA) s
5 201 M
( connection.) s
5 124 M
(Lever Expires November 28, 2016 [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
76 24 translate
/pagenum 8 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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.3.1. Client Receive Buffers) s
5 663 M
( Typically an RPC-over-RDMA Requester posts only as many receive) s
5 652 M
( buffers as there are outstanding RPC Calls. A client endpoint) s
5 641 M
( without backward direction support might therefore at times have no) s
5 630 M
( pre-posted receive buffers.) s
5 608 M
( To receive incoming backward direction Calls, an RPC-over-RDMA client) s
5 597 M
( endpoint must pre-post enough additional receive buffers to match its) s
5 586 M
( advertised backward direction credit value. Each outstanding forward) s
5 575 M
( direction RPC requires an additional receive buffer above this) s
5 564 M
( minimum.) s
5 542 M
( When an RDMA transport connection is lost, all active receive buffers) s
5 531 M
( are flushed and are no longer available to receive incoming messages.) s
5 520 M
( When a fresh transport connection is established, a client endpoint) s
5 509 M
( must re-post a receive buffer to handle the Reply for each) s
5 498 M
( retransmitted forward direction Call, and a full set of receive) s
5 487 M
( buffers to handle backward direction Calls.) s
5 465 M
(4.3.2. Server Receive Buffers) s
5 443 M
( A forward direction RPC-over-RDMA service endpoint posts as many) s
5 432 M
( receive buffers as it expects incoming forward direction Calls. That) s
5 421 M
( is, it posts no fewer buffers than the number of credits granted in) s
5 410 M
( the rdma_credit field of forward direction RPC replies.) s
5 388 M
( To receive incoming backward direction replies, an RPC-over-RDMA) s
5 377 M
( server endpoint must pre-post a receive buffer for each backward) s
5 366 M
( direction Call it sends.) s
5 344 M
( When the existing transport connection is lost, all active receive) s
5 333 M
( buffers are flushed and are no longer available to receive incoming) s
5 322 M
( messages. When a fresh transport connection is established, a server) s
5 311 M
( endpoint must re-post a receive buffer to handle the Reply for each) s
5 300 M
( retransmitted backward direction Call, and a full set of receive) s
5 289 M
( buffers for receiving forward direction Calls.) s
5 267 M
(5. Sending And Receiving Backward Operations) s
5 245 M
( The operation of RPC-over-RDMA transports in the forward direction is) s
5 234 M
( defined in [RFC5531] and [I-D.ietf-nfsv4-rfc5666bis]. In this) s
5 223 M
( section, a mechanism for backward direction operation on RPC-over-) s
5 212 M
( RDMA is defined. Backward operation used in combination with forward) s
5 201 M
( operation enables bi-directional communication on a common RPC) s
5 190 M
( transport connection.) s
5 124 M
(Lever Expires November 28, 2016 [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
76 24 translate
/pagenum 9 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( Certain fields in the RPC-over-RDMA header are fixed for all versions) s
5 674 M
( of RPC-over-RDMA. The XDR description of these fields is contained) s
5 663 M
( in Section 5.1 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 641 M
(5.1. Sending A Backward Direction Call) s
5 619 M
( To form a backward direction RPC-over-RDMA Call message, an ONC RPC) s
5 608 M
( service endpoint constructs an RPC-over-RDMA header containing a) s
5 597 M
( fresh RPC XID in the rdma_xid field \(see Section 2.4 for full) s
5 586 M
( requirements\).) s
5 564 M
( The rdma_vers field MUST contain the same value in backward and) s
5 553 M
( forward direction Call messages on the same connection.) s
5 531 M
( The number of requested backward direction credits is placed in the) s
5 520 M
( rdma_credit field \(see Section 4\).) s
5 498 M
( Whether presented inline or as a separate chunk, the ONC RPC Call) s
5 487 M
( header MUST start with the same XID value that is present in the RPC-) s
5 476 M
( over-RDMA header, and the RPC header's msg_type field MUST contain) s
5 465 M
( the value CALL.) s
5 443 M
(5.2. Sending A Backward Direction Reply) s
5 421 M
( To form a backward direction RPC-over-RDMA Reply message, an ONC RPC) s
5 410 M
( client endpoint constructs an RPC-over-RDMA header containing a copy) s
5 399 M
( of the matching ONC RPC Call's RPC XID in the rdma_xid field \(see) s
5 388 M
( Section 2.4 for full requirements\).) s
5 366 M
( The rdma_vers field MUST contain the same value in a backward) s
5 355 M
( direction Reply message as in the matching Call message.) s
5 333 M
( The number of granted backward direction credits is placed in the) s
5 322 M
( rdma_credit field \(see Section 4\).) s
5 300 M
( Whether presented inline or as a separate chunk, the ONC RPC Reply) s
5 289 M
( header MUST start with the same XID value that is present in the RPC-) s
5 278 M
( over-RDMA header, and the RPC header's msg_type field MUST contain) s
5 267 M
( the value REPLY.) s
5 245 M
(5.3. Backward Direction Chunks) s
5 223 M
( Chunks MAY be used in the backward direction. They operate the same) s
5 212 M
( way as in the forward direction \(see [I-D.ietf-nfsv4-rfc5666bis] for) s
5 201 M
( details\).) s
5 179 M
( An implementation might not support any Upper Layer Protocol that has) s
5 168 M
( DDP-eligible data items. The Upper Layer Protocol may also use only) s
5 124 M
(Lever Expires November 28, 2016 [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
76 24 translate
/pagenum 10 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( small messages, or it may have a native mechanism for restricting the) s
5 674 M
( size of backward direction RPC messages, obviating the need to handle) s
5 663 M
( Long Messages in the backward direction.) s
5 641 M
( When there is no Upper Layer Protocol requirement for chunks,) s
5 630 M
( implementers can choose not to provide support for chunks in the) s
5 619 M
( backward direction. This avoids the complexity of adding support for) s
5 608 M
( performing RDMA Reads and Writes in the backward direction.) s
5 586 M
( When chunks are not implemented, RPC messages in the backward) s
5 575 M
( direction are always sent using RDMA_MSG, and therefore can be no) s
5 564 M
( larger than what can be sent inline \(that is, without chunks\).) s
5 553 M
( Sending an inline message larger than the inline threshold can result) s
5 542 M
( in loss of connection.) s
5 520 M
( If a backward direction requester provides a non-empty chunk list to) s
5 509 M
( a responder that does not support chunks, the responder MUST reply) s
5 498 M
( with an RDMA_ERROR message with rdma_err field set to ERR_CHUNK.) s
5 476 M
(5.4. Backward Direction Retransmission) s
5 454 M
( In rare cases, an ONC RPC transaction cannot be completed within a) s
5 443 M
( certain time. This can be because the transport connection was lost,) s
5 432 M
( the Call or Reply message was dropped, or because the Upper Layer) s
5 421 M
( consumer delayed or dropped the ONC RPC request. Typically, the) s
5 410 M
( Requester sends the transaction again, reusing the same RPC XID.) s
5 399 M
( This is known as an "RPC retransmission".) s
5 377 M
( In the forward direction, the Requester is the ONC RPC client. The) s
5 366 M
( client is always responsible for establishing a transport connection) s
5 355 M
( before sending again.) s
5 333 M
( In the backward direction, the Requester is the ONC RPC server.) s
5 322 M
( Because an ONC RPC server does not establish transport connections) s
5 311 M
( with clients, it cannot send a retransmission if there is no) s
5 300 M
( transport connection. It must wait for the ONC RPC client to re-) s
5 289 M
( establish the transport connection before it can retransmit ONC RPC) s
5 278 M
( transactions in the backward direction.) s
5 256 M
( If an ONC RPC client has no work to do, it may be some time before it) s
5 245 M
( re-establishes a transport connection. Backward direction Requesters) s
5 234 M
( must be prepared to wait indefinitely for a connection to be) s
5 223 M
( established before a pending backward direction ONC RPC Call can be) s
5 212 M
( retransmitted.) s
5 190 M
( Forward direction Requesters are responsible for maintaining a) s
5 179 M
( transport connection as long as there is the possibility of backward) s
5 168 M
( direction requests. For example, an NFSv4.1 client with open) s
5 124 M
(Lever Expires November 28, 2016 [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
76 24 translate
/pagenum 11 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( delegated files or active pNFS layouts should maintain a transport) s
5 674 M
( connection so the server can send callback operations.) s
5 652 M
(6. In the Absence of Backward Direction Support) s
5 630 M
( An RPC-over-RDMA transport endpoint might not support backward) s
5 619 M
( direction operation \(and thus bi-directional operation\). There might) s
5 608 M
( be no mechanism in the transport implementation to do so. Or in an) s
5 597 M
( implementation that can support operation in the backward direction,) s
5 586 M
( the Upper Layer Protocol consumer might not yet have configured or) s
5 575 M
( enabled the transport to handle backward direction traffic.) s
5 553 M
( If an endpoint is not prepared to receive an incoming backward) s
5 542 M
( direction message, loss of the RDMA connection might result. Thus) s
5 531 M
( denial of service could result if a sender continues to send backward) s
5 520 M
( direction messages after every transport reconnect to an endpoint) s
5 509 M
( that is not prepared to receive them.) s
5 487 M
( When dealing with the possibility that the remote peer has no) s
5 476 M
( transport level support for backward direction operation, the Upper) s
5 465 M
( Layer Protocol becomes responsible for informing peers when backward) s
5 454 M
( direction operation is supported. Otherwise even a simple backward) s
5 443 M
( direction NULL probe from a peer could result in a lost connection.) s
5 421 M
( Therefore, an Upper Layer Protocol consumer MUST NOT perform backward) s
5 410 M
( direction ONC RPC operations unless the peer consumer has indicated) s
5 399 M
( it is prepared to handle them. A description of Upper Layer Protocol) s
5 388 M
( mechanisms used for this indication is outside the scope of this) s
5 377 M
( document.) s
5 355 M
( For example, an NFSv4.1 server does not send backchannel messages to) s
5 344 M
( an NFSv4.1 client before the NFSv4.1 client has sent a CREATE_SESSION) s
5 333 M
( or a BIND_CONN_TO_SESSION operation. As long as an NFSv4.1 client) s
5 322 M
( has prepared appropriate backchannel resources before sending one of) s
5 311 M
( these operations announcing support for backchannel operation, denial) s
5 300 M
( of service is avoided.) s
5 278 M
(7. Considerations For Upper Layer Bindings) s
5 256 M
( An Upper Layer Protocol that operates on RPC-over-RDMA transports may) s
5 245 M
( have procedures that include DDP-eligible data items. DDP-) s
5 234 M
( eligibility is specified in an Upper Layer Binding. Direction of) s
5 223 M
( operation does not obviate the need for DDP-eligibility statements.) s
5 201 M
( Backward-only operation requires the client endpoint to establish a) s
5 190 M
( fresh connection. The Upper Layer Binding can specify appropriate) s
5 179 M
( RPC binding parameters for such connections.) s
5 124 M
(Lever Expires November 28, 2016 [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
76 24 translate
/pagenum 12 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( Bi-directional operation occurs on an already-established connection.) s
5 674 M
( Specification of RPC binding parameters is usually not necessary in) s
5 663 M
( this case.) s
5 641 M
( For bi-directional operation, other considerations about sharing an) s
5 630 M
( RPC-over-RDMA transport with another ULP may apply. Consult) s
5 619 M
( Section 7 of [I-D.ietf-nfsv4-rfc5666bis] for details about what else) s
5 608 M
( may be contained in an Upper Layer Binding.) s
5 586 M
(8. Security Considerations) s
5 564 M
( Security considerations for operation on RPC-over-RDMA transports are) s
5 553 M
( outlined in Section 9 of [I-D.ietf-nfsv4-rfc5666bis].) s
5 531 M
(9. IANA Considerations) s
5 509 M
( This document does not require actions by IANA.) s
5 487 M
(10. Acknowledgements) s
5 465 M
( Tom Talpey was an indispensable resource, in addition to creating the) s
5 454 M
( foundation upon which this work is based. Our warmest regards go to) s
5 443 M
( him for his help and support.) s
5 421 M
( Dave Noveck provided excellent review, constructive suggestions, and) s
5 410 M
( navigational guidance throughout the process of drafting this) s
5 399 M
( document.) s
5 377 M
( Dai Ngo was a solid partner and collaborator. Together we) s
5 366 M
( constructed and tested independent prototypes of the changes) s
5 355 M
( described in this document.) s
5 333 M
( The author wishes to thank Bill Baker for his unwavering support of) s
5 322 M
( this work. In addition, the author gratefully acknowledges the) s
5 311 M
( expert contributions of Karen Deitke, Chunli Zhang, Mahesh) s
5 300 M
( Siddheshwar, Steve Wise, and Tom Tucker.) s
5 278 M
( Special thanks go to the nfsv4 Working Group Chair Spencer Shepler) s
5 267 M
( and the nfsv4 Working Group Secretary Tom Haynes for their support.) s
5 245 M
(11. Normative References) s
5 223 M
( [I-D.ietf-nfsv4-rfc5666bis]) s
5 212 M
( Lever, C., Simpson, W., and T. Talpey, "Remote Direct) s
5 201 M
( Memory Access Transport for Remote Procedure Call", draft-) s
5 190 M
( ietf-nfsv4-rfc5666bis-04 \(work in progress\), March 2016.) s
5 124 M
(Lever Expires November 28, 2016 [Page 12]) s
_R
S
%%Page: (13) 13
%%BeginPageSetup
_S
76 24 translate
/pagenum 13 def
/fname (draft-ietf-nfsv4-rpcrdma-bidirection-04.txt) def
/fdir (.) def
/ftail (draft-ietf-nfsv4-rpcrdma-bidirection-04.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
( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s
5 674 M
( Requirement Levels", BCP 14, RFC 2119, March 1997.) s
5 652 M
( [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol) s
5 641 M
( Specification Version 2", RFC 5531, May 2009.) s
5 619 M
( [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File) s
5 608 M
( System \(NFS\) Version 4 Minor Version 1 Protocol", RFC) s
5 597 M
( 5661, January 2010.) s
5 575 M
( [RFC7530] Haynes, T. and D. Noveck, "Network File System \(NFS\)) s
5 564 M
( Version 4 Protocol", RFC 7530, March 2015.) s
5 542 M
(Author's Address) s
5 520 M
( Charles Lever) s
5 509 M
( Oracle Corporation) s
5 498 M
( 1015 Granger Avenue) s
5 487 M
( Ann Arbor, MI 48104) s
5 476 M
( USA) s
5 454 M
( Phone: +1 734 274 2396) s
5 443 M
( Email: chuck.lever@oracle.com) s
5 124 M
(Lever Expires November 28, 2016 [Page 13]) s
_R
S
%%Trailer
%%Pages: 13
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-19 09:02:12 |