| < draft-ietf-nfsv4-rfc5667bis-08.txt | draft-ietf-nfsv4-rfc5667bis-09.txt > | |||
|---|---|---|---|---|
| Network File System Version 4 C. Lever, Ed. | Network File System Version 4 C. Lever, Ed. | |||
| Internet-Draft Oracle | Internet-Draft Oracle | |||
| Obsoletes: 5667 (if approved) April 4, 2017 | Obsoletes: 5667 (if approved) April 10, 2017 | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: October 6, 2017 | Expires: October 12, 2017 | |||
| Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version | Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version | |||
| One | One | |||
| draft-ietf-nfsv4-rfc5667bis-08 | draft-ietf-nfsv4-rfc5667bis-09 | |||
| Abstract | Abstract | |||
| This document specifies Upper Layer Bindings of Network File System | This document specifies Upper Layer Bindings of Network File System | |||
| (NFS) protocol versions to RPC-over-RDMA Version One, enabling the | (NFS) protocol versions to RPC-over-RDMA Version One, enabling the | |||
| use of Direct Data Placement. This document obsoletes RFC 5667. | use of Direct Data Placement. This document obsoletes RFC 5667. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| 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 October 6, 2017. | This Internet-Draft will expire on October 12, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 45 ¶ | skipping to change at page 2, line 45 ¶ | |||
| 5. Upper Layer Binding For NFS Version 4 . . . . . . . . . . . . 7 | 5. Upper Layer Binding For NFS Version 4 . . . . . . . . . . . . 7 | |||
| 5.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 7 | 5.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7 | 5.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7 | |||
| 5.3. RPC Binding Considerations . . . . . . . . . . . . . . . 8 | 5.3. RPC Binding Considerations . . . . . . . . . . . . . . . 8 | |||
| 5.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 8 | 5.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 8 | |||
| 5.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 10 | 5.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 10 | |||
| 5.6. Session-Related Considerations . . . . . . . . . . . . . 11 | 5.6. Session-Related Considerations . . . . . . . . . . . . . 11 | |||
| 5.7. Transport Considerations . . . . . . . . . . . . . . . . 12 | 5.7. Transport Considerations . . . . . . . . . . . . . . . . 12 | |||
| 6. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 13 | 6. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 13 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
| Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 16 | Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 16 | |||
| Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17 | Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 1. Introduction | 1. Introduction | |||
| The RPC-over-RDMA Version One transport may employ direct data | The RPC-over-RDMA Version One transport may employ direct data | |||
| skipping to change at page 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
| o If a READ operation returns a union arm which does not contain a | o If a READ operation returns a union arm which does not contain a | |||
| DDP-eligible result, and the NFS version 4 client has provided a | DDP-eligible result, and the NFS version 4 client has provided a | |||
| matching non-empty Write chunk, an NFS version 4 server MUST | matching non-empty Write chunk, an NFS version 4 server MUST | |||
| return an empty Write chunk in that Write list position. | return an empty Write chunk in that Write list position. | |||
| o If there are more READ operations than Write chunks, then | o If there are more READ operations than Write chunks, then | |||
| remaining NFS Read operations in an NFS version 4 COMPOUND that | remaining NFS Read operations in an NFS version 4 COMPOUND that | |||
| have no matching Write chunk MUST return their results inline. | have no matching Write chunk MUST return their results inline. | |||
| If an NFS version 4 client sends an RPC Call with a Write list that | ||||
| contains more chunks than an NFS version 4 server is prepared to | ||||
| process, the server MUST reject the RPC by responding with an | ||||
| RDMA_ERROR message with the rdma_err value set to ERR_CHUNK. | ||||
| If an NFS version 4 client sends an RPC Call with a Read list that | ||||
| contains more chunks than an NFS version 4 server is prepared to | ||||
| process, the server MUST reject the RPC by responding with an | ||||
| RDMA_MSG message containing an RPC Reply with an accept status of | ||||
| GARBAGE_ARGS, or with an RDMA_ERROR message with the rdma_err value | ||||
| set to ERR_CHUNK. | ||||
| 5.4.2. NFS Version 4 COMPOUND Example | 5.4.2. NFS Version 4 COMPOUND Example | |||
| The following example shows a Write list with three Write chunks, A, | The following example shows a Write list with three Write chunks, A, | |||
| B, and C. The NFS version 4 server consumes the provided Write | B, and C. The NFS version 4 server consumes the provided Write | |||
| chunks by writing the results of the designated operations in the | chunks by writing the results of the designated operations in the | |||
| compound request (READ and READLINK) back to each chunk. | compound request (READ and READLINK) back to each chunk. | |||
| Write list: | Write list: | |||
| A --> B --> C | A --> B --> C | |||
| skipping to change at page 11, line 32 ¶ | skipping to change at page 11, line 41 ¶ | |||
| The presence of an NFS session (defined in [RFC5661]) has no effect | The presence of an NFS session (defined in [RFC5661]) has no effect | |||
| on the operation of RPC-over-RDMA Version One. None of the | on the operation of RPC-over-RDMA Version One. None of the | |||
| operations introduced to support NFS sessions (e.g. the SEQUENCE | operations introduced to support NFS sessions (e.g. the SEQUENCE | |||
| operation) contain DDP-eligible data items. There is no need to | operation) contain DDP-eligible data items. There is no need to | |||
| match the number of session slots with the number of available RPC- | match the number of session slots with the number of available RPC- | |||
| over-RDMA credits. | over-RDMA credits. | |||
| However, there are a few new cases where an RPC transaction can fail. | However, there are a few new cases where an RPC transaction can fail. | |||
| For example, a requester might receive, in response to an RPC | For example, a requester might receive, in response to an RPC | |||
| request, an RDMA_ERROR message with an rdma_err value of ERR_CHUNK, | request, an RDMA_ERROR message with an rdma_err value of ERR_CHUNK. | |||
| or an RDMA_MSG containing an RPC_GARBAGEARGS reply. These situations | These situations are no different from existing RPC errors which an | |||
| are no different from existing RPC errors which an NFS session | NFS session implementation is already prepared to handle for other | |||
| implementation is already prepared to handle for other transports. | transports. And as with other transports during such a failure, | |||
| And as with other transports during such a failure, there might be no | there might be no SEQUENCE result available to the requester to | |||
| SEQUENCE result available to the requester to distinguish whether | distinguish whether failure occurred before or after the requested | |||
| failure occurred before or after the requested operations were | operations were executed on the responder. | |||
| executed on the responder. | ||||
| When a transport error occurs (e.g. RDMA_ERROR), the requester | When a transport error occurs (e.g. RDMA_ERROR), the requester | |||
| proceeds as usual to match the incoming XID value to a waiting RPC | proceeds as usual to match the incoming XID value to a waiting RPC | |||
| Call. The RPC transaction is terminated, and the result status is | Call. The RPC transaction is terminated, and the result status is | |||
| reported to the Upper Layer Protocol. The requester's session | reported to the Upper Layer Protocol. The requester's session | |||
| implementation then determines the session ID and slot for the failed | implementation then determines the session ID and slot for the failed | |||
| request, and performs slot recovery to make that slot usable again. | request, and performs slot recovery to make that slot usable again. | |||
| If this is not done, that slot could be rendered permanently | If this is not done, that slot could be rendered permanently | |||
| unavailable. | unavailable. | |||
| skipping to change at page 17, line 38 ¶ | skipping to change at page 17, line 38 ¶ | |||
| [RFC5667]. The author also wishes to thank Bill Baker and Greg | [RFC5667]. The author also wishes to thank Bill Baker and Greg | |||
| Marsden for their support of this work. | Marsden for their support of this work. | |||
| Dave Noveck provided excellent review, constructive suggestions, and | Dave Noveck provided excellent review, constructive suggestions, and | |||
| consistent navigational guidance throughout the process of drafting | consistent navigational guidance throughout the process of drafting | |||
| this document. Dave also contributed the text of Section 5.6 and | this document. Dave also contributed the text of Section 5.6 and | |||
| Section 6, and insisted on precise discussion of reply size | Section 6, and insisted on precise discussion of reply size | |||
| estimation. | estimation. | |||
| Thanks to Karen Deitke for her sharp observations about idempotency, | Thanks to Karen Deitke for her sharp observations about idempotency, | |||
| and the clarity of the discussion of NFS COMPOUNDs and NFS sessions. | NFS COMPOUNDs, and NFS sessions. | |||
| Special thanks go to Transport Area Director Spencer Dawkins, nfsv4 | Special thanks go to Transport Area Director Spencer Dawkins, nfsv4 | |||
| Working Group Chair Spencer Shepler, and nfsv4 Working Group | Working Group Chair Spencer Shepler, and nfsv4 Working Group | |||
| Secretary Thomas Haynes for their support. | Secretary Thomas Haynes for their support. | |||
| Author's Address | Author's Address | |||
| Charles Lever (editor) | Charles Lever (editor) | |||
| Oracle Corporation | Oracle Corporation | |||
| 1015 Granger Avenue | 1015 Granger Avenue | |||
| Ann Arbor, MI 48104 | Ann Arbor, MI 48104 | |||
| End of changes. 8 change blocks. | ||||
| 14 lines changed or deleted | 25 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||