[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03

Network Working Group                                    Spencer Shepler
Internet Draft                                            September 1998
Document: draft-ietf-nfsv4-requirements-00.txt



                       NFS Version 4 Requirements



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   With the creation of the NFS version 4 working group, a set of
   requirements for the next version of NFS must be codified to create a
   reasonable context for the new protocol discussions and aide in the
   upcoming decisions.  This Internet Draft has the purpose of
   presenting the requirements for NFS version 4 and will be used as the
   leading document for NFSv4 working group.















Expires: February 1999                                          [Page 1]


NFSv4                         Requirements                September 1998


Table of Contents

   1.  NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3
   2.  Ease of implementation or complexity of protocol . . . . . . 3
   2.1.  Extensibility / layering . . . . . . . . . . . . . . . . . 3
   2.2.  Managed Extensions or Minor Versioning . . . . . . . . . . 3
   3.  Reliable and Available . . . . . . . . . . . . . . . . . . . 4
   4.  Scalable Performance . . . . . . . . . . . . . . . . . . . . 4
   4.1.  Throughput and Latency on the Network  . . . . . . . . . . 4
   4.2.  Server Work Load or Scalability  . . . . . . . . . . . . . 4
   4.3.  Client Caching . . . . . . . . . . . . . . . . . . . . . . 5
   4.4.  Disconnected Client Operation  . . . . . . . . . . . . . . 5
   5.  Interoperability . . . . . . . . . . . . . . . . . . . . . . 5
   5.1.  Platform Specific Behavior . . . . . . . . . . . . . . . . 6
   5.2.  Extended Attributes  . . . . . . . . . . . . . . . . . . . 6
   5.3.  Access Control Lists . . . . . . . . . . . . . . . . . . . 6
   6.  RPC Mechanism and Security . . . . . . . . . . . . . . . . . 7
   6.1.  Remote Procedure Call Mechanism  . . . . . . . . . . . . . 7
   6.2.  User identification  . . . . . . . . . . . . . . . . . . . 7
   6.3.  Authentication . . . . . . . . . . . . . . . . . . . . . . 8
   6.4.  Security Negotiation . . . . . . . . . . . . . . . . . . . 8
   7.  Internet Accessibility . . . . . . . . . . . . . . . . . . . 9
   7.1.  Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
   7.2.  Firewalls and Proxy Servers  . . . . . . . . . . . . . . . 9
   7.3.  Multiple RPCs and Latency  . . . . . . . . . . . . . . . . 9
   8.  File locking / recovery  . . . . . . . . . . . . . . . . .  10
   9.  Internationalization . . . . . . . . . . . . . . . . . . .  11
   10.  Bibliography  . . . . . . . . . . . . . . . . . . . . . .  12
   11.  Author's Address  . . . . . . . . . . . . . . . . . . . .  14






















Expires: February 1999                                          [Page 2]


NFSv4                         Requirements                September 1998


1.  NFS Version 4 Requirements

   As stated in the charter the first deliverable for the NFS version 4
   working group is this requirements document.  This document is to
   cover the "limitations and deficiencies of NFS version 3".  Therefore
   the intent of the following sections is to identify the various
   feature points of NFS as a distributed file system and discuss its
   current functionality and compare to other distributed file systems
   and offer reasonable requirements for each of these areas.


2.  Ease of implementation or complexity of protocol

   One of the strengths of NFS has been the ability to implement a
   client or server with comparative ease.  The eventual size of a basic
   implementation is relatively small.  One reason that keeping NFS as
   simple as possible is that a simple protocol design can be described
   in a simple specification that promotes straightforward,
   interoperable implementations.  All protocols can run into problems
   when deployed on real networks, but simple protocols yield problems
   that are easier to diagnose and correct.


2.1.  Extensibility / layering


   With NFS' relative simplicity, the addition or layering of
   functionality has been easy to accomplish.  The addition of features
   like the client automount or autofs, client side disk caching and
   high availability servers are some examples.  This type of
   extensibility is desirable in an environment where problem solutions
   do not require protocol revision.  This extensibility can also be
   helpful in the future where unforeseen problems or opportunities can
   be solved by layering functionality on an existing set of tools or
   protocol.


2.2.  Managed Extensions or Minor Versioning

   For those cases where a the protocol is deficient or where a minor
   modification is the best solution for a problem, a minor version or a
   managed extension of the NFS protocol would be helpful.  With NFS
   version 2, there were many minor extensions in the protocol to solve
   problems which were unforeseen.  However they were done in a way that
   was not well documented or detection of support was not possible.  A
   new NFS protocol should allow for the rare instance where protocol
   extension is the most prudent course and an entire revision would be
   unnecessary or impractical.



Expires: February 1999                                          [Page 3]


NFSv4                         Requirements                September 1998


3.  Reliable and Available


   Current NFS protocol design has lead to quick recovery from server
   and client failure.  This approach to the design has lended itself
   well to layered technologies like high availability and clustered
   servers.  Providing a protocol design approach that lends itself to
   these types of reliability and availability features is very
   desirable.


4.  Scalable Performance


   In designing and developing an NFS protocol from a performance
   viewpoint there are several different points to consider.  Each can
   play a significant role in perceived and real performance from the
   user's perspective.  The three main areas of interest are: throughput
   and latency on the network, server work load or scalability and
   client side caching.


4.1.  Throughput and Latency on the Network


   NFS currently has characteristics that provide good throughput for
   read and write of file data.  However, the number of RPCs required to
   accomplish some tasks combined with high latency network environments
   leads to sluggish response.  The protocol should continue to provide
   good raw read and write throughput.  It should also address the issue
   of network latencies.  This issue is discussed further in the section
   on Internet Accessibility.


4.2.  Server Work Load or Scalability


   Current NFS operations are relatively lightweight in that the
   processing work for most of the operations is not CPU intensive.
   This allows for potential support of a large number of clients.  This
   attribute can also be helpful in building efficient and scalable SMP
   or cluster based servers.  While this type of protocol design
   (lightweight operations) is desirable, it needs to be balanced
   against the previous issue of having the client generate a large
   number of RPCs to accomplish a straight forward task.






Expires: February 1999                                          [Page 4]


NFSv4                         Requirements                September 1998


4.3.  Client Caching


   In an attempt to speed response time and to reduce network and server
   load, NFS clients have always cached directory and file data.
   However, this has usually been done as memory cache and in relatively
   recent history, local disk caching has been added.

   Having the client cache directory and file data is very desirable.
   Other distributed file systems have shown that aggressive client side
   caching can be very visible to the end user in response time gains.
   Client caching is increasingly important for Internet environments
   where throughput can be limited and response time can grow
   significantly.

   The NFS protocol should allow for aggressive caching while balancing
   the needs for simplicity and Internet accessibility (i.e. firewalls).
   If possible, the caching ability should be layered on the protocol
   instead of embedding specific client caching functions in the
   protocol itself.


4.4.  Disconnected Client Operation


   An extension of client caching is the idea or functionality of
   disconnected operation at the client.  With the ability to cache
   directory and file data aggressively, a client could then provide
   service to the end user while disconnected from the server or
   network.

   While very desirable, disconnected operation has the opportunity to
   inflict itself on the NFS protocol more so than regular client
   caching.  If this area is pursued, the tradeoffs will need to be
   weighed carefully in the areas of the semantics of disconnected
   operation along with user data synchronization or resolution at the
   point of reconnection.

        Editors Note:  This section needs to be discussed and
        expanded or clarified if it is found to be a stronger
        requirement than what is stated in the above text.



5.  Interoperability

   The NFS protocols are available for many different operating
   environments.  Even though this shows the protocol's ability to



Expires: February 1999                                          [Page 5]


NFSv4                         Requirements                September 1998


   provide distributed file system service in for more than a single
   operating system, the design of NFS is certainly Unix centric.
   Distributed file systems are usually tied in some way to the original
   operating environment for which they were developed.  A desired
   feature of the next NFS protocol is to reduce platform centric
   features while retaining reasonable functionality and performance in
   the protocol.


5.1.  Platform Specific Behavior


   Because of its Unix centric design, some of the protocol requirements
   have been difficult to implement in some environments.  For example,
   persistent file handles (unique identifiers of file system objects),
   Unix uid/gid mappings, directory modification time, accurate file
   sizes.

        Editors Note:  This list could be expanded or more detail
        of the associated problems could be added.



5.2.  Extended Attributes

   NFS does not provide for file or directory attributes beyond those
   that are found in the traditional Unix environment; for example the
   user identifier of the owner of the file, a permission or access
   bitmap, time stamps for modification time of the file or directory
   and file size to name a few.  While the current set of attributes has
   usually been sufficient, the file system's ability to manage
   additional information associated with a file or directory can be
   useful.

        Editors Note:  Need to add examples of the use or potential
        extended attributes.


        Editors Note:  Discussion of extended attribute support in
        other file systems needs to be added.



5.3.  Access Control Lists

   One specific type of extended attribute can be the Access Control
   List (ACL).  This attribute is a designation of user access to a file
   or directory.  Many vendors have created ancillary protocols to NFS



Expires: February 1999                                          [Page 6]


NFSv4                         Requirements                September 1998


   to extend the server's ACL mechanism across the network.  Even though
   the server still interprets the ACL and has final control over access
   to a file system object, the client is able to manipulate the ACL via
   these additional protocols.

   DFS provides the ability to manipulate the ACLs of their file
   servers.  CIFS provides this capability as well.

        Editors Note:  Is the CIFS statement true in this case?
        What are the mechanisms?




6.  RPC Mechanism and Security


   NFS relies on the underlying security mechanisms provided by the
   ONCRPC protocol.  Until the introduction of the ONCRPC RPCSEC_GSS
   security flavor, NFS security was generally limited to none
   (AUTH_SYS) or DES (AUTH_DH).  The AUTH_DH security flavor was not
   successful in providing readily available security for NFS because of
   a lack of implementation and deployment.  Also the 192 bit public
   keys modulos used for the AUTH_DH security flavor quickly became too
   small for reasonable security.


6.1.  Remote Procedure Call Mechanism


   The ONCRPC protocol provides the basic NFS foundation for the
   following reasons:

   o    Open protocol definition managed by IETF

   o    Transport independent (UDP and TCP supported -- and others????)

   o    Simple data representation and procedure encoding models

   o    Various security mechanisms available through use of RPCSEC_GSS


6.2.  User identification


   NFS has been limited to the use of the Unix centric user
   identification mechanism of numeric user id based on the available
   file system attributes and the use of the ONCRPC.  However, for NFS



Expires: February 1999                                          [Page 7]


NFSv4                         Requirements                September 1998


   to move beyond the limits of large work groups, user identification
   should be string based and the definition of the user identifier
   should allow for integration into an external naming service or
   services.

   Internet scaling should also be considered for this as well.  The
   identification mechanism should take into account multiple naming
   domains and other extremes that can be presented by use outside of
   the work group.

        Editors Note:  Should identify what other distributed file
        systems do for naming and if these approaches can help
        solve the issues above or are themselves limited.



6.3.  Authentication


   As a result of a lack of implementation and deployment and relatively
   weak protection, authentication has been a major issue for ONCRPC and
   hence NFS.  With the introduction of the RPCSEC_GSS security flavor,
   ONCRPC can provide for reasonable authentication along with integrity
   and privacy, if desired.  The RPCSEC_GSS framework will allow the use
   of both public and private key mechanisms.  Therefore, NFS as a user
   of ONCRPC should state its specific requirements for each of these
   areas.

   Strong authentication is a requirement for NFS and the logical
   solution for this is in the use of ONCRPC and RPCSEC_GSS.

        Editors Note:  Beyond authentication, should NFS make use
        of the integrity and privacy features of RPCSEC_GSS?  This
        could prove useful in the broader Internet environment.


        Editors Note:  What security mechanisms should be specified
        or required by NFS?  For private key, Kerberos V5 can be
        used.  Are there other obvious suggestions?  For public
        key, SPKM [RFC2025] can be used.  Are there other
        suggestions for public key?


6.4.  Security Negotiation

   Along with the authentication requirements, a method for client and
   server to automatically negotiate an agreeable security mechanism
   needs to be in place.  This will ease administration overhead and



Expires: February 1999                                          [Page 8]


NFSv4                         Requirements                September 1998


   interoperability difficulties.


7.  Internet Accessibility


   Being a product of an IETF working group, the NFS protocol should not
   only be built upon IETF technologies where possible but should also
   work well within the broader Internet environment.


7.1.  Transports


   ONCRPC is available for both UDP and TCP transports.  NFS as a user
   of ONCRPC has not placed any requirements on the use of either UDP or
   TCP.  Today's NFS implementations generally support both transports.

   At a minimum, NFS should require the support of both UDP and TCP at
   the client and server.  An alternative would be to require TCP only
   for both client and server.

   However, it can be argued that some new NFS protocol features could
   rely on the use of TCP and its connection state.  If this type of
   transport dependency were built into NFS, UDP would be lost for some
   environments as the low overhead and potentially better performing
   alternative.


7.2.  Firewalls and Proxy Servers


   NFS's protocol design should allow its use via Internet firewalls.
   The protocol should also allow for the use of file system proxy
   servers if possible (especially for caching).

        Editors Note:  What potential issues exist with the
        combination of aggressive client caching and proxy caching?


        Editors Note:  Also what are the security implications of
        proxy NFS servers?



7.3.  Multiple RPCs and Latency

   As an application at the NFS client performs simple file system



Expires: February 1999                                          [Page 9]


NFSv4                         Requirements                September 1998


   operations, multiple NFS operations or RPCs may be executed to
   accomplish the work for the application.  While the NFS version 3
   protocol addressed some of this by returning file and directory
   attributes for most procedures hence reducing follow up GETATTR
   requests, there is still room for improvement.  Reducing the number
   of RPCs can lead to a reduction of processing overhead on the server
   (transport and security processing) along with reducing the time
   spent at the client waiting for the server's individual responses.
   This issue is more prominent environments with higher degrees of
   latency.

   One approach to resolving this issue is by allowing multiple
   individual operations to be combined together in a single RPC.  This
   would reduce the transport and security processing overhead while
   allowing for the use of simple protocol operations to accomplish more
   complete tasks.

   Note that CIFS provides a similar mechanism with its chaining.


8.  File locking / recovery


   NFS has provided Unix file locking and DOS SHARE capability with the
   use of an ancillary protocol (Network Lock Manager / NLM).  The NLM
   protocol provides for file locking and recovery of those locks in the
   event of client or server failure.  NLM requires that the server make
   call backs to the client for certain scenarios and therefore is not
   necessarily well suited for Internet firewall traversal.

   Desirable features of file locking support are:

   o    Integration with the NFS protocol

   o    Interoperability between operating environments

   o    Scalable solutions - thousands of clients

   o    Internet capable (firewall traversal, latency sensitive)

   o    Timely recovery in the event of client/server failure


        Editors Note:  Do these items need further definition?


   DFS offers file locking but does not provide DOS SHARE capability.
   DFS' relies on the server calling back to the client for the file



Expires: February 1999                                         [Page 10]


NFSv4                         Requirements                September 1998


   locking functionality.

   CIFS supports file locking and DOS SHARE support.


9.  Internationalization


   The current NFS protocols are limited in their support of anything
   more than 7-bit ASCII strings.  It is imperative that NFS support a
   range of character sets.  This can be provided by requiring support
   for Unicode with a UTF-8 wire encoding.  Therefore, all strings
   defined as part of the NFS protocol will need to be defined as UTF-8
   and the appropriate XDR encoding used.





































Expires: February 1999                                         [Page 11]


NFSv4                         Requirements                September 1998


10.  Bibliography


   [RFC1094]
   Sun Microsystems, Inc., "NFS: Network File System Protocol
   Specification", RFC1094, March 1989.

   ftp://ftp.isi.edu/in-notes/rfc1094.txt


   [RFC1813]
   Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol
   Specification", RFC1813, Sun Microsystems, Inc., June 1995.

   ftp://ftp.isi.edu/in-notes/rfc1813.txt


   [RFC1831]
   Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
   Version 2", RFC1831, Sun Microsystems, Inc., August 1995.

   ftp://ftp.isi.edu/in-notes/rfc1831.txt


   [RFC1832]
   Srinivasan, R., "XDR: External Data Representation Standard",
   RFC1832, Sun Microsystems, Inc., August 1995.

   ftp://ftp.isi.edu/in-notes/rfc1832.txt


   [RFC1833]
   Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833,
   Sun Microsystems, Inc., August 1995.

   ftp://ftp.isi.edu/in-notes/rfc1833.txt


   [RFC2025]
   Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025,
   Bell-Northern Research, October 1996.

   ftp://ftp.isi.edu/in-notes/rfc2025.txt


   [RFC2078]
   Linn, J., "Generic Security Service Application Program Interface,
   Version 2", RFC2078, OpenVision Technologies, January 1997.



Expires: February 1999                                         [Page 12]


NFSv4                         Requirements                September 1998


   ftp://ftp.isi.edu/in-notes/rfc2078.txt


   [RFC2203]
   Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification"
   RFC2203, Sun Microsystems, Inc., August 1995.

   ftp://ftp.isi.edu/in-notes/rfc2203.txt


   [Sandberg]
   Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B.  Lyon, "Design
   and Implementation of the Sun Network Filesystem," USENIX Conference
   Proceedings, USENIX Association, Berkeley, CA, Summer 1985.  The
   basic paper describing the SunOS implementation of the NFS version 2
   protocol, and discusses the goals, protocol specification and trade-
   offs.


   [X/OpenNFS]
   X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open
   Internetworking: XNFS, X/Open Company, Ltd., Apex Plaza, Forbury
   Road, Reading Berkshire, RG1 1AX, United Kingdom, 1991.  This is an
   indispensable reference for NFS version 2 protocol and accompanying
   protocols, including the Lock Manager and the Portmapper.


   [X/OpenPCNFS]
   X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open
   Internetworking: (PC)NFS, Developer's Specification, X/Open Company,
   Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United
   Kingdom, 1991.  This is an indispensable reference for NFS version 2
   protocol and accompanying protocols, including the Lock Manager and
   the Portmapper.

















Expires: February 1999                                         [Page 13]


NFSv4                         Requirements                September 1998


11.  Author's Address

   Address comments related to this memorandum to:

        spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com

   Spencer Shepler
   Sun Microsystems, Inc.
   7808 Moonflower Drive
   Austin, Texas 78750

   Phone: (512) 349-9376
   E-mail: spencer.shepler@eng.sun.com






































Expires: February 1999                                         [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/