rfc2624.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Network Working Group                                        S. Shepler
Request for Comments: 2624                       Sun Microsystems, Inc.
Category: Informational                                       June 1999


                  NFS Version 4 Design Considerations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The main task of the NFS version 4 working group is to create a
   protocol definition for a distributed file system that focuses on the
   following items: improved access and good performance on the
   Internet, strong security with negotiation built into the protocol,
   better cross-platform interoperability, and designed for protocol
   extensions.  NFS version 4 will owe its general design to the
   previous versions of NFS.  It is expected, however, that many
   features will be quite different in NFS version 4 than previous
   versions to facilitate the goals of the working group and to address
   areas that NFS version 2 and 3 have not.

   This design considerations document is meant to present more detail
   than the working group charter.  Specifically, it presents the areas
   that the working group will investigate and consider while developing
   a protocol specification for NFS version 4.  Based on this
   investigation the working group will decide the features of the new
   protocol based on the cost and benefits within the specific feature
   areas.

Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.








Shepler                      Informational                      [Page 1]

RFC 2624              NFSv4 Design Considerations              June 1999


Table of Contents

   1.  NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
   2.  Ease of Implementation or Complexity of Protocol  . . . . . . 3
   2.1.  Extensibility / layering  . . . . . . . . . . . . . . . . . 3
   2.2.  Managed Extensions or Minor Versioning  . . . . . . . . . . 3
   2.3.  Relationship with Older Versions of NFS . . . . . . . . . . 4
   3.  Reliable and Available  . . . . . . . . . . . . . . . . . . . 5
   4.  Scalable Performance  . . . . . . . . . . . . . . . . . . . . 5
   4.1.  Throughput and Latency via the Network  . . . . . . . . . . 6
   4.2.  Client Caching  . . . . . . . . . . . . . . . . . . . . . . 6
   4.3.  Disconnected Client Operation . . . . . . . . . . . . . . . 7
   5.  Interoperability  . . . . . . . . . . . . . . . . . . . . . . 7
   5.1.  Platform Specific Behavior  . . . . . . . . . . . . . . . . 8
   5.2.  Additional or Extended Attributes . . . . . . . . . . . . . 8
   5.3.  Access Control Lists  . . . . . . . . . . . . . . . . . .   9
   6.  RPC Mechanism and Security  . . . . . . . . . . . . . . . .  10
   6.1.  User identification . . . . . . . . . . . . . . . . . . .  10
   6.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.2.1.  Transport Independence  . . . . . . . . . . . . . . . .  11
   6.2.2.  Authentication  . . . . . . . . . . . . . . . . . . . .  11
   6.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . . .  11
   6.2.4.  Data Privacy  . . . . . . . . . . . . . . . . . . . . .  12
   6.2.5.  Security Negotiation  . . . . . . . . . . . . . . . . .  12
   6.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Internet Accessibility  . . . . . . . . . . . . . . . . . .  13
   7.1.  Congestion Control and Transport Selection  . . . . . . .  13
   7.2.  Firewalls and Proxy Servers . . . . . . . . . . . . . . .  14
   7.3.  Multiple RPCs and Latency . . . . . . . . . . . . . . . .  14
   8.  File locking / recovery . . . . . . . . . . . . . . . . . .  15
   9.  Internationalization  . . . . . . . . . . . . . . . . . . .  16
   10.  Security Considerations  . . . . . . . . . . . . . . . . .  17
   10.1.  Denial of Service  . . . . . . . . . . . . . . . . . . .  17
   11.  Bibliography . . . . . . . . . . . . . . . . . . . . . . .  18
   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  21
   13.  Author's Address . . . . . . . . . . . . . . . . . . . . .  21
   14.  Full Copyright Statement . . . . . . . . . . . . . . . . .  22

1.  NFS Version 4 Design Considerations

   As stated in the charter, the first deliverable for the NFS version 4
   working group is this design considerations document.  This document
   is to cover the "limitations and deficiencies of NFS version 3".
   This document will also be used as a mechanism to focus discussion
   and avenues of investigation as the definition of NFS version 4
   progresses.  Therefore, the contents of this document cover the
   general functional/feature areas that are anticipated for NFS version
   4.  Where appropriate, discussion of current NFS version 2 and 3



Shepler                      Informational                      [Page 2]

RFC 2624              NFSv4 Design Considerations              June 1999


   practice will be presented along with other appropriate references to
   current distributed file system practice.

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 relative ease.  The eventual size of a basic
   implementation is relatively small.  The main reason for 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 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 the NFS protocol is deficient or where a minor
   modification is the best solution for a problem, a minor version or a
   managed extension could be helpful.  There have been instances with
   NFS version 2 and 3 where small straightforward functional additions
   would have increased the overall value of the protocol immensely.
   For instance, the PATHCONF procedure that was added to version 2 of
   the MOUNT protocol would have been more appropriate for the NFS
   protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP
   procedure for NFS versions 2 and 3 would have been more cleanly
   implemented in a new LOOKUP procedure.

   However, the perceived size and burden of using a change of RPC
   version number for the introduction of new functionality led to no or
   slow change.  It is possible that a new NFS protocol could allow for
   the rare instance where protocol extension within the RPC version
   number is the most prudent course and an RPC revision would be
   unnecessary or impractical.

   The areas of an NFS protocol which are most obviously volatile are
   new orthogonal procedures, new well-defined file or directory
   attributes and potentially new file types.  As an example, potential



Shepler                      Informational                      [Page 3]

RFC 2624              NFSv4 Design Considerations              June 1999


   file types of the future could be a type such as "attribute" that
   represents a named file stream or a "dynamic" file type that
   generates dynamic data in response to a "query" procedure from the
   client.

   It is possible and highly desirable that these types of additions be
   done without changing the overall design model of NFS without
   significant effort or delay.

   A strong consideration should be given to a NFS protocol mechanism
   for the introduction of this type of new functionality.  This is
   obviously in contrast to using the standard RPC version mechanism to
   provide minor changes.  The process of using RPC version numbers to
   introduce new functionality brings with it a lot of history which may
   not technically prevent its use.  However, the historical issues
   involved will need to be addressed as part of the NFS version 4
   protocol work; this should increase the ability for current and
   future success of the protocol.

   As background, the RPC protocol described in [RFC1831] uses a version
   number to describe the set of procedure calls, replies, and their
   semantics.  Any change in this set must be reflected in a new version
   number for the program.  An example of this was the
   MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT
   protocol.  Except for the addition of this new procedure, the
   protocol was unchanged.  Many thought this protocol revision was
   unnecessary, since the RPC protocol already allows certain procedures
   not be implemented and defines a PROC_UNAVAIL error.

   Another historical data-point from NFS version 2 and 3 is the support
   (or lack) of symbolic links.  Servers that cannot support this
   feature will simply reject calls to the SYMLINK and READLINK
   procedures.  Additionally, NFS version 4 may describe many file
   attributes which cannot be supported by the server or file systems on
   the server.  Therefore, the protocol must support a discovery
   mechanism that allows clients to determine which features of the
   protocol are supported by a server.

2.3.  Relationship with Older Versions of NFS

   NFS version 4 will be a self contained protocol in that it will not
   have any dependencies on the previous versions of NFS.  Stated
   another way, an NFS version 4 server or client will not require a
   NFSv2 or NFSv3 implementation be present for NFS version 4 to
   function as designed.  It should also be noted that having an NFS
   version 2 or 3 implementation present at the client or server will
   not enhance the functionality of an NFS version 4 implementation.




Shepler                      Informational                      [Page 4]

RFC 2624              NFSv4 Design Considerations              June 1999


   In the case where an NFS client has a choice of using various NFS
   protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms
   will allow the client to appropriately choose an available version of
   the protocol at the NFS server.  The ONCRPC protocol contains the
   semantics and error returns for the case where an RPC server program
   does not support a particular version.  This mechanism is used by the
   NFS client to receive notification of an unavailable version and in
   conjunction with the error the client will also receive the range of
   versions (min to max) that are available.  Therefore, the ONCRPC
   mechanism can be used by implementors of both clients and servers to
   provide for the transitioning to or installation of NFS version 4
   services.

3.  Reliable and Available

   Current NFS protocol design, while placing an emphasis on simple
   server design, has led to timely recovery from server and client
   failure.  This and other aspects to the design have provided a basis
   for 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.

   For the next version of NFS, consideration should be given to client
   side availability schemes such as client switching between or fail-
   over to available server replicas.  NFS currently requires that file
   handles be immutable; this requirement adds unnecessarily to the
   complexity of building fail-over configurations.  If possible, the
   protocol should allow for or ease the building of such layered
   solutions.

   For the next version of NFS, consideration should be given to schemes
   that support client switching between server replicas or highly
   available NFS servers that provide paths to data through multiple
   servers. For example: NFS currently requires that filehandles be
   unchanging for any instance of a file or directory. This requirement
   makes it more difficult for a client to switch from one server to
   another, since each server may construct filehandles differently.
   Protocol support could allow the client to handle a filehandle
   change.

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 via the network, server work load or scalability and



Shepler                      Informational                      [Page 5]

RFC 2624              NFSv4 Design Considerations              June 1999


   client side caching.

4.1.  Throughput and Latency via the Network

   NFS currently has characteristics that provide good throughput for
   reading and writing file data. This is commonly achieved by the
   client's use of pipelining or windowing multiple RPC READ/WRITE
   requests to the server. The flexibility of the NFS and ONCRPC
   protocols allow for implementations to use this type of adaptation to
   provide efficient use of the network connection.

   However, the number of RPCs required to accomplish some tasks
   combined with high latency network environments may lead to sluggish
   single user or single client response.  The protocol should continue
   to provide good raw read and write throughput while addressing the
   issue of network latency.  This issue is discussed further in the
   section on Internet Accessibility.

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