draft-ietf-nfsv4-rfc5666bis-07.txt   draft-ietf-nfsv4-rfc5666bis-08.txt 
Network File System Version 4 C. Lever, Ed. Network File System Version 4 C. Lever, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 5666 (if approved) W. Simpson Obsoletes: 5666 (if approved) W. Simpson
Intended status: Standards Track DayDreamer Intended status: Standards Track DayDreamer
Expires: November 28, 2016 T. Talpey Expires: May 25, 2017 T. Talpey
Microsoft Microsoft
May 27, 2016 November 21, 2016
Remote Direct Memory Access Transport for Remote Procedure Call, Version Remote Direct Memory Access Transport for Remote Procedure Call, Version
One One
draft-ietf-nfsv4-rfc5666bis-07 draft-ietf-nfsv4-rfc5666bis-08
Abstract Abstract
This document specifies a protocol for conveying Remote Procedure This document specifies a protocol for conveying Remote Procedure
Call (RPC) messages on physical transports capable of Remote Direct Call (RPC) messages on physical transports capable of Remote Direct
Memory Access (RDMA). It requires no revision to application RPC Memory Access (RDMA). It requires no revision to application RPC
protocols or the RPC protocol itself. This document obsoletes RFC protocols or the RPC protocol itself. This document obsoletes RFC
5666. 5666.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2016. This Internet-Draft will expire on May 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5. RPC-Over-RDMA In Operation . . . . . . . . . . . . . . . . . 23 5. RPC-Over-RDMA In Operation . . . . . . . . . . . . . . . . . 23
5.1. XDR Protocol Definition . . . . . . . . . . . . . . . . . 24 5.1. XDR Protocol Definition . . . . . . . . . . . . . . . . . 24
5.2. Fixed Header Fields . . . . . . . . . . . . . . . . . . . 28 5.2. Fixed Header Fields . . . . . . . . . . . . . . . . . . . 28
5.3. Chunk Lists . . . . . . . . . . . . . . . . . . . . . . . 30 5.3. Chunk Lists . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Memory Registration . . . . . . . . . . . . . . . . . . . 32 5.4. Memory Registration . . . . . . . . . . . . . . . . . . . 32
5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 34 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 34
5.6. Protocol Elements No Longer Supported . . . . . . . . . . 36 5.6. Protocol Elements No Longer Supported . . . . . . . . . . 36
5.7. XDR Examples . . . . . . . . . . . . . . . . . . . . . . 37 5.7. XDR Examples . . . . . . . . . . . . . . . . . . . . . . 37
6. RPC Bind Parameters . . . . . . . . . . . . . . . . . . . . . 39 6. RPC Bind Parameters . . . . . . . . . . . . . . . . . . . . . 39
7. Upper Layer Binding Specifications . . . . . . . . . . . . . 40 7. Upper Layer Binding Specifications . . . . . . . . . . . . . 40
7.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 40 7.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 41
7.2. Maximum Reply Size . . . . . . . . . . . . . . . . . . . 42 7.2. Maximum Reply Size . . . . . . . . . . . . . . . . . . . 42
7.3. Additional Considerations . . . . . . . . . . . . . . . . 42 7.3. Additional Considerations . . . . . . . . . . . . . . . . 42
7.4. Upper Layer Protocol Extensions . . . . . . . . . . . . . 43 7.4. Upper Layer Protocol Extensions . . . . . . . . . . . . . 43
8. Protocol Extensibility . . . . . . . . . . . . . . . . . . . 43 8. Protocol Extensibility . . . . . . . . . . . . . . . . . . . 43
8.1. Conventional Extensions . . . . . . . . . . . . . . . . . 43 8.1. Conventional Extensions . . . . . . . . . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Memory Protection . . . . . . . . . . . . . . . . . . . . 44 9.1. Memory Protection . . . . . . . . . . . . . . . . . . . . 44
9.2. RPC Message Security . . . . . . . . . . . . . . . . . . 45 9.2. RPC Message Security . . . . . . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Normative References . . . . . . . . . . . . . . . . . . 49 12.1. Normative References . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . . . . . . . . . . . 50 12.2. Informative References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
skipping to change at page 20, line 24 skipping to change at page 20, line 24
In other words, even if a responder indicates that a Write chunk is In other words, even if a responder indicates that a Write chunk is
not consumed (by setting all of the segment lengths in the chunk to not consumed (by setting all of the segment lengths in the chunk to
zero), the responder may have written some data into the segments zero), the responder may have written some data into the segments
before deciding not to return that data item. For example, a problem before deciding not to return that data item. For example, a problem
reading local storage might occur while an NFS server is filling reading local storage might occur while an NFS server is filling
Write chunks. This would interrupt the stream of RDMA Write Write chunks. This would interrupt the stream of RDMA Write
operations that sends data back to the NFS client, but at that point operations that sends data back to the NFS client, but at that point
the NFS server needs to return an NFS error that reflects that the the NFS server needs to return an NFS error that reflects that the
Upper Layer NFS request has failed. Upper Layer NFS request has failed.
When there is a DDP-eligible result data item, and the requester
prefers the data item returned inline, the requester provides a Write
chunk for that item where either the segment count is zero, or the
length of each of the chunk's segments is zero. The responder MUST
return the corresponding data item inline.
4.5. Message Size 4.5. Message Size
A receiver of RDMA Send operations is required by RDMA to have A receiver of RDMA Send operations is required by RDMA to have
previously posted one or more adequately sized buffers. Memory previously posted one or more adequately sized buffers. Memory
savings are achieved on both requesters and responders by posting savings are achieved on both requesters and responders by posting
small Receive buffers. However, not all RPC messages are small. small Receive buffers. However, not all RPC messages are small.
4.5.1. Short Messages 4.5.1. Short Messages
RPC messages are frequently smaller than typical inline thresholds. RPC messages are frequently smaller than typical inline thresholds.
skipping to change at page 34, line 17 skipping to change at page 34, line 17
each segment. For such implementations, this can be a significant each segment. For such implementations, this can be a significant
overhead. By providing an offset in each chunk, many pre- overhead. By providing an offset in each chunk, many pre-
registration or region-based registrations can be readily supported. registration or region-based registrations can be readily supported.
By using a single, universal chunk representation, the RPC-over-RDMA By using a single, universal chunk representation, the RPC-over-RDMA
protocol implementation is simplified to its most general form. protocol implementation is simplified to its most general form.
5.5. Error Handling 5.5. Error Handling
A receiver performs basic validity checks on the RPC-over-RDMA header A receiver performs basic validity checks on the RPC-over-RDMA header
and chunk contents before it passes the RPC message to the RPC and chunk contents before it passes the RPC message to the RPC
consumer. If errors are detected in the RPC-over-RDMA header of a consumer. If an incoming RPC-over-RDMA message is not as long as a
Call message, a responder MUST send an RDMA_ERROR message back to the minimal size RPC-over-RDMA header (28 bytes), the receiver cannot
requester. If errors are detected in the RPC-over-RDMA header of a trust the value of the XID field, and therefore MUST silently discard
Reply message, a requester MUST silently discard the message. the message before performing any parsing. If other errors are
detected in the RPC-over-RDMA header of a Call message, a responder
MUST send an RDMA_ERROR message back to the requester. If errors are
detected in the RPC-over-RDMA header of a Reply message, a requester
MUST silently discard the message.
To form an RDMA_ERROR procedure: The rdma_xid field MUST contain the To form an RDMA_ERROR procedure: The rdma_xid field MUST contain the
same XID that was in the rdma_xid field in the failing request; The same XID that was in the rdma_xid field in the failing request; The
rdma_vers field MUST contain the same version that was in the rdma_vers field MUST contain the same version that was in the
rdma_vers field in the failing request; The rdma_proc field MUST rdma_vers field in the failing request; The rdma_proc field MUST
contain the value RDMA_ERROR; The rdma_err field contains a value contain the value RDMA_ERROR; The rdma_err field contains a value
that reflects the type of error that occurred, as described below. that reflects the type of error that occurred, as described below.
An RDMA_ERROR procedure indicates a permanent error. Receipt of this An RDMA_ERROR procedure indicates a permanent error. Receipt of this
procedure completes the RPC transaction associated with XID in the procedure completes the RPC transaction associated with XID in the
skipping to change at page 49, line 45 skipping to change at page 50, line 15
[I-D.ietf-nfsv4-rpcsec-gssv3] [I-D.ietf-nfsv4-rpcsec-gssv3]
Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-17 Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-17
(work in progress), January 2016. (work in progress), January 2016.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, DOI 10.17487/RFC1833, August 1995, RFC 1833, DOI 10.17487/RFC1833, August 1995,
<http://www.rfc-editor.org/info/rfc1833>. <http://www.rfc-editor.org/info/rfc1833>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <http://www.rfc-editor.org/info/rfc4506>. 2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement [RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement
Protocol (DDP) / Remote Direct Memory Access Protocol Protocol (DDP) / Remote Direct Memory Access Protocol
(RDMAP) Security", RFC 5042, DOI 10.17487/RFC5042, October (RDMAP) Security", RFC 5042, DOI 10.17487/RFC5042, October
2007, <http://www.rfc-editor.org/info/rfc5042>. 2007, <http://www.rfc-editor.org/info/rfc5042>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<http://www.rfc-editor.org/info/rfc5056>. <http://www.rfc-editor.org/info/rfc5056>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <http://www.rfc-editor.org/info/rfc5531>. May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", RFC [RFC5660] Williams, N., "IPsec Channels: Connection Latching",
5660, DOI 10.17487/RFC5660, October 2009, RFC 5660, DOI 10.17487/RFC5660, October 2009,
<http://www.rfc-editor.org/info/rfc5660>. <http://www.rfc-editor.org/info/rfc5660>.
[RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call [RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call
(RPC) Network Identifiers and Universal Address Formats", (RPC) Network Identifiers and Universal Address Formats",
RFC 5665, DOI 10.17487/RFC5665, January 2010, RFC 5665, DOI 10.17487/RFC5665, January 2010,
<http://www.rfc-editor.org/info/rfc5665>. <http://www.rfc-editor.org/info/rfc5665>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-nfsv4-rpcrdma-bidirection] [I-D.ietf-nfsv4-rpcrdma-bidirection]
Lever, C., "Size-Limited Bi-directional Remote Procedure Lever, C., "Bi-directional Remote Procedure Call On RPC-
Call On Remote Direct Memory Access Transports", draft- over-RDMA Transports", draft-ietf-nfsv4-rpcrdma-
ietf-nfsv4-rpcrdma-bidirection-01 (work in progress), bidirection-05 (work in progress), June 2016.
September 2015.
[IB] InfiniBand Trade Association, "InfiniBand Architecture [IB] InfiniBand Trade Association, "InfiniBand Architecture
Specifications", <http://www.infinibandta.org>. Specifications", <http://www.infinibandta.org>.
[IBPORT] InfiniBand Trade Association, "IP Addressing Annex", [IBPORT] InfiniBand Trade Association, "IP Addressing Annex",
<http://www.infinibandta.org>. <http://www.infinibandta.org>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, DOI 10.17487/RFC1094, March specification", RFC 1094, DOI 10.17487/RFC1094, March
1989, <http://www.rfc-editor.org/info/rfc1094>. 1989, <http://www.rfc-editor.org/info/rfc1094>.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, DOI 10.17487/ Version 3 Protocol Specification", RFC 1813,
RFC1813, June 1995, DOI 10.17487/RFC1813, June 1995,
<http://www.rfc-editor.org/info/rfc1813>. <http://www.rfc-editor.org/info/rfc1813>.
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol Garcia, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, DOI 10.17487/RFC5040, October Specification", RFC 5040, DOI 10.17487/RFC5040, October
2007, <http://www.rfc-editor.org/info/rfc5040>. 2007, <http://www.rfc-editor.org/info/rfc5040>.
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct [RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
Data Placement over Reliable Transports", RFC 5041, DOI Data Placement over Reliable Transports", RFC 5041,
10.17487/RFC5041, October 2007, DOI 10.17487/RFC5041, October 2007,
<http://www.rfc-editor.org/info/rfc5041>. <http://www.rfc-editor.org/info/rfc5041>.
[RFC5532] Talpey, T. and C. Juszczak, "Network File System (NFS) [RFC5532] Talpey, T. and C. Juszczak, "Network File System (NFS)
Remote Direct Memory Access (RDMA) Problem Statement", RFC Remote Direct Memory Access (RDMA) Problem Statement",
5532, DOI 10.17487/RFC5532, May 2009, RFC 5532, DOI 10.17487/RFC5532, May 2009,
<http://www.rfc-editor.org/info/rfc5532>. <http://www.rfc-editor.org/info/rfc5532>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>. <http://www.rfc-editor.org/info/rfc5661>.
[RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description", External Data Representation Standard (XDR) Description",
RFC 5662, DOI 10.17487/RFC5662, January 2010, RFC 5662, DOI 10.17487/RFC5662, January 2010,
<http://www.rfc-editor.org/info/rfc5662>. <http://www.rfc-editor.org/info/rfc5662>.
[RFC5666] Talpey, T. and B. Callaghan, "Remote Direct Memory Access [RFC5666] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
Transport for Remote Procedure Call", RFC 5666, DOI Transport for Remote Procedure Call", RFC 5666,
10.17487/RFC5666, January 2010, DOI 10.17487/RFC5666, January 2010,
<http://www.rfc-editor.org/info/rfc5666>. <http://www.rfc-editor.org/info/rfc5666>.
[RFC5667] Talpey, T. and B. Callaghan, "Network File System (NFS) [RFC5667] Talpey, T. and B. Callaghan, "Network File System (NFS)
Direct Data Placement", RFC 5667, DOI 10.17487/RFC5667, Direct Data Placement", RFC 5667, DOI 10.17487/RFC5667,
January 2010, <http://www.rfc-editor.org/info/rfc5667>. January 2010, <http://www.rfc-editor.org/info/rfc5667>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
 End of changes. 17 change blocks. 
30 lines changed or deleted 39 lines changed or added

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