Network File System Version 4 Requirements for Computational Storage
draft-cel-nfsv4-comp-stor-reqs-01

Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Intended status: Informational                           August 12, 2019
Expires: February 13, 2020

  Network File System Version 4 Requirements for Computational Storage
                   draft-cel-nfsv4-comp-stor-reqs-01

Abstract

   This document introduces an architecture for supporting Computational
   Storage on Network File System version 4 (NFS) servers and clients.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 13, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Lever                   Expires February 13, 2020               [Page 1]
Internet-Draft        Computational Storage for NFS          August 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Service Discovery . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Service Configuration . . . . . . . . . . . . . . . . . . . .   3
   5.  Service Operation . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   True computational storage conforms to one or both of the following
   criteria:

   o  A compute resource co-located with data storage leverages a high
      bandwidth link between that compute resource and storage.

   o  A compute resource co-located with data storage reduces interrupt
      or data bandwidth needed between storage and host.

   There are several broad use cases for computation offloaded to
   storage:

   Search:  Examples include SQL offload, a machine learning inference
      engine co-located with its dataset, or performing a "find"
      operation without pulling an entire filesystem's data to a client.

   Data Transformation:  Examples include compression, transcoding, and
      encryption.

   Data Management:  This might be a control plane that permits
      administrative actions such as instantiating a transfer to cold
      storage, integrity measurement (scrubbing), or creating a snapshot
      of a particular file.

   In some cases, computational storage is a computational service that
   is available as a direct offload for a host CPU.  The source and sink
   data both reside in the host's memory.  For NFS, however, the mission
   of computational storage techniques is to reduce network utilization
   between an NFS server and its clients.  Here, the source and sink are
   typically located in files on NFS servers; the operation of the

Lever                   Expires February 13, 2020               [Page 2]
Internet-Draft        Computational Storage for NFS          August 2019

   computational service is often transparent to applications running on
   NFS clients.

   NFSv4.2 [RFC7862] already applies this approach -- features new to
   NFSv4.2 include copy offload and file initialization (ALLOCATE), both
   of which are intended to prevent extra data round-trips between
   clients and server.

   The purpose of the current document is to provide a framework for
   discussing and reasoning about computational storage relative to the
   NFS protocol and typical NFS deployments.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Service Discovery

   For various reasons, we do not want to require changes to the NFS
   protocol to expose computational storage resources.  Instead, an NFS
   server host can advertise RPC programs which allow NFS clients to
   configure the server's computational services, and the services then
   operate on data in files stored there.  CSS configuration programs
   can be advertised via the rpcbind service [RFC1833].

   Typically a CSS configuration facility would register with the NFS
   server's rpcbind service, advertising its listening port and RPC
   program number.  Administrative clients would then contact this
   service to configure it for use.

4.  Service Configuration

   A configuration program exposes the parameters of an individual CSS.
   Such configuration might include the selection of encryption
   algorithms or keys, or the specification of regular expressions or
   prepared SQL statements.  The location of the input dataset or
   results of a CSS might also be specified.

   An important class of input and output parameters for configuration
   programs are objects (e.g. files and directories) that exist in a
   filesystem that is shared via NFS.  When they are local, such objects
   can be referenced by filehandle and optionally a range of bytes.  To
   reference a remote object, either an NFS URI (defined in

Lever                   Expires February 13, 2020               [Page 3]
Internet-Draft        Computational Storage for NFS          August 2019

   Section 2.8.1 of [RFC7532]) or a tuple consisting of a network
   address and a filehandle may be used.

5.  Service Operation

   There are two possible modes of operation:

   Transparent:  After the computational service is configured, its
      operation occurs behind NFS READ and WRITE operations, and is not
      directly visible to NFS clients.  Examples of this mode include
      data reduction (e.g., deduplication) and encryption-at-rest.

   Verbal:  Clients would use a separate (RPC) protocol to initiate
      requests or capture results, when the results are expected to be
      small, or are not appropriate for storing into a file.  An example
      of this mode is invoking search operations over large datasets
      where the results might a small set of filehandles with byte
      ranges.

   Serialization is often necessary to prevent an offload agent from
   colliding with accesses by standard NFS clients.  Open state or a
   delegation might be necessary for this purpose.  Alternatively, no
   locking would be provided via NFS, and the applications themselves
   would be responsible for seeing that the integrity of the input
   datasets is maintained during offloaded operations.

6.  Security Considerations

   Unlike most block storage, NFS is typically deployed on open networks
   rather than environments with limited access (such as a PCIe bus).
   In such open environments, extra attention must be focused on
   security.  In particular:

   o  Remote access to configuration programs and computational results
      will need to be authenticated and authorized in some fashion.  The
      ONC RPC protocol itself [RFC5531] has authentication mechanisms,
      including mechanisms that use strong cryptography [RFC7861].

   o  There will need to be a mechanism for authorizing offload agents
      to access file data on behalf of authenticated users.

   o  A trust relationship must exist between clients and servers.  For
      example, how would clients be certain that the server has actually
      encrypted a file's content?

Lever                   Expires February 13, 2020               [Page 4]
Internet-Draft        Computational Storage for NFS          August 2019

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

   [RFC1833]  Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
              RFC 1833, DOI 10.17487/RFC1833, August 1995,
              <https://www.rfc-editor.org/info/rfc1833>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
              May 2009, <https://www.rfc-editor.org/info/rfc5531>.

   [RFC7532]  Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace
              Database (NSDB) Protocol for Federated File Systems",
              RFC 7532, DOI 10.17487/RFC7532, March 2015,
              <https://www.rfc-editor.org/info/rfc7532>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC7861]  Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
              Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
              November 2016, <https://www.rfc-editor.org/info/rfc7861>.

   [RFC7862]  Haynes, T., "Network File System (NFS) Version 4 Minor
              Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
              November 2016, <https://www.rfc-editor.org/info/rfc7862>.

Acknowledgments

   The author is grateful to Bill Baker, Greg Marsden, and Jim Williams
   of Oracle, and Glenn Watkins of HPE for their input and support of
   this work.

Lever                   Expires February 13, 2020               [Page 5]
Internet-Draft        Computational Storage for NFS          August 2019

   Special thanks go to Transport Area Director Magnus Westerlund, NFSV4
   Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
   Working Group Secretary Thomas Haynes for their support.

Author's Address

   Charles Lever
   Oracle Corporation
   United States of America

   Email: chuck.lever@oracle.com

Lever                   Expires February 13, 2020               [Page 6]