idnits 2.17.1 draft-cel-nfsv4-comp-stor-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 12, 2019) is 1718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Informational August 12, 2019 5 Expires: February 13, 2020 7 Network File System Version 4 Requirements for Computational Storage 8 draft-cel-nfsv4-comp-stor-reqs-01 10 Abstract 12 This document introduces an architecture for supporting Computational 13 Storage on Network File System version 4 (NFS) servers and clients. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 13, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 51 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Service Configuration . . . . . . . . . . . . . . . . . . . . 3 53 5. Service Operation . . . . . . . . . . . . . . . . . . . . . . 4 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 58 8.2. Informative References . . . . . . . . . . . . . . . . . 5 59 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 True computational storage conforms to one or both of the following 65 criteria: 67 o A compute resource co-located with data storage leverages a high 68 bandwidth link between that compute resource and storage. 70 o A compute resource co-located with data storage reduces interrupt 71 or data bandwidth needed between storage and host. 73 There are several broad use cases for computation offloaded to 74 storage: 76 Search: Examples include SQL offload, a machine learning inference 77 engine co-located with its dataset, or performing a "find" 78 operation without pulling an entire filesystem's data to a client. 80 Data Transformation: Examples include compression, transcoding, and 81 encryption. 83 Data Management: This might be a control plane that permits 84 administrative actions such as instantiating a transfer to cold 85 storage, integrity measurement (scrubbing), or creating a snapshot 86 of a particular file. 88 In some cases, computational storage is a computational service that 89 is available as a direct offload for a host CPU. The source and sink 90 data both reside in the host's memory. For NFS, however, the mission 91 of computational storage techniques is to reduce network utilization 92 between an NFS server and its clients. Here, the source and sink are 93 typically located in files on NFS servers; the operation of the 94 computational service is often transparent to applications running on 95 NFS clients. 97 NFSv4.2 [RFC7862] already applies this approach -- features new to 98 NFSv4.2 include copy offload and file initialization (ALLOCATE), both 99 of which are intended to prevent extra data round-trips between 100 clients and server. 102 The purpose of the current document is to provide a framework for 103 discussing and reasoning about computational storage relative to the 104 NFS protocol and typical NFS deployments. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Service Discovery 116 For various reasons, we do not want to require changes to the NFS 117 protocol to expose computational storage resources. Instead, an NFS 118 server host can advertise RPC programs which allow NFS clients to 119 configure the server's computational services, and the services then 120 operate on data in files stored there. CSS configuration programs 121 can be advertised via the rpcbind service [RFC1833]. 123 Typically a CSS configuration facility would register with the NFS 124 server's rpcbind service, advertising its listening port and RPC 125 program number. Administrative clients would then contact this 126 service to configure it for use. 128 4. Service Configuration 130 A configuration program exposes the parameters of an individual CSS. 131 Such configuration might include the selection of encryption 132 algorithms or keys, or the specification of regular expressions or 133 prepared SQL statements. The location of the input dataset or 134 results of a CSS might also be specified. 136 An important class of input and output parameters for configuration 137 programs are objects (e.g. files and directories) that exist in a 138 filesystem that is shared via NFS. When they are local, such objects 139 can be referenced by filehandle and optionally a range of bytes. To 140 reference a remote object, either an NFS URI (defined in 141 Section 2.8.1 of [RFC7532]) or a tuple consisting of a network 142 address and a filehandle may be used. 144 5. Service Operation 146 There are two possible modes of operation: 148 Transparent: After the computational service is configured, its 149 operation occurs behind NFS READ and WRITE operations, and is not 150 directly visible to NFS clients. Examples of this mode include 151 data reduction (e.g., deduplication) and encryption-at-rest. 153 Verbal: Clients would use a separate (RPC) protocol to initiate 154 requests or capture results, when the results are expected to be 155 small, or are not appropriate for storing into a file. An example 156 of this mode is invoking search operations over large datasets 157 where the results might a small set of filehandles with byte 158 ranges. 160 Serialization is often necessary to prevent an offload agent from 161 colliding with accesses by standard NFS clients. Open state or a 162 delegation might be necessary for this purpose. Alternatively, no 163 locking would be provided via NFS, and the applications themselves 164 would be responsible for seeing that the integrity of the input 165 datasets is maintained during offloaded operations. 167 6. Security Considerations 169 Unlike most block storage, NFS is typically deployed on open networks 170 rather than environments with limited access (such as a PCIe bus). 171 In such open environments, extra attention must be focused on 172 security. In particular: 174 o Remote access to configuration programs and computational results 175 will need to be authenticated and authorized in some fashion. The 176 ONC RPC protocol itself [RFC5531] has authentication mechanisms, 177 including mechanisms that use strong cryptography [RFC7861]. 179 o There will need to be a mechanism for authorizing offload agents 180 to access file data on behalf of authenticated users. 182 o A trust relationship must exist between clients and servers. For 183 example, how would clients be certain that the server has actually 184 encrypted a file's content? 186 7. IANA Considerations 188 This document has no IANA actions. 190 8. References 192 8.1. Normative References 194 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 195 RFC 1833, DOI 10.17487/RFC1833, August 1995, 196 . 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 204 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 205 May 2009, . 207 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 208 Database (NSDB) Protocol for Federated File Systems", 209 RFC 7532, DOI 10.17487/RFC7532, March 2015, 210 . 212 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 213 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 214 May 2017, . 216 8.2. Informative References 218 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 219 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 220 November 2016, . 222 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 223 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 224 November 2016, . 226 Acknowledgments 228 The author is grateful to Bill Baker, Greg Marsden, and Jim Williams 229 of Oracle, and Glenn Watkins of HPE for their input and support of 230 this work. 232 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 233 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 234 Working Group Secretary Thomas Haynes for their support. 236 Author's Address 238 Charles Lever 239 Oracle Corporation 240 United States of America 242 Email: chuck.lever@oracle.com