draft-ietf-nfsv4-requirements-01.txt   draft-ietf-nfsv4-requirements-02.txt 
Network Working Group Spencer Shepler Network Working Group Spencer Shepler
Document: draft-ietf-nfsv4-requirements-01.txt Document: draft-ietf-nfsv4-requirements-02.txt
NFS Version 4 Requirements NFS Version 4 Requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Abstract Abstract
With the creation of the NFS version 4 working group, a set of 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 requirements for the next version of NFS must be codified to create a
reasonable context for the new protocol discussions and aide in the reasonable context for the new protocol discussions and aide in the
upcoming decisions. This Internet Draft has the purpose of upcoming decisions. This Internet Draft has the purpose of
presenting the requirements for NFS version 4 and will be used as the presenting the requirements for NFS version 4 and will be used as the
leading document for NFSv4 working group. leading document for NFSv4 working group.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
Table of Contents Table of Contents
1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3 1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3
2. Ease of implementation or complexity of protocol . . . . . . 3 2. Ease of implementation or complexity of protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4
4.1. Throughput and Latency on the Network . . . . . . . . . . 5 4.1. Throughput and Latency on the Network . . . . . . . . . . 5
skipping to change at page 3, line 5 skipping to change at page 3, line 5
6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 10 6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 10
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10
7.1. Congestion Control and Transport Selection . . . . . . . 11 7.1. Congestion Control and Transport Selection . . . . . . . 11
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 11 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 11
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 11 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 11
8. File locking / recovery . . . . . . . . . . . . . . . . . 12 8. File locking / recovery . . . . . . . . . . . . . . . . . 12
9. Internationalization . . . . . . . . . . . . . . . . . . . 13 9. Internationalization . . . . . . . . . . . . . . . . . . . 13
10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 14 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 14
11. Author's Address . . . . . . . . . . . . . . . . . . . . 16 11. Author's Address . . . . . . . . . . . . . . . . . . . . 16
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
1. NFS Version 4 Requirements 1. NFS Version 4 Requirements
As stated in the charter the first deliverable for the NFS version 4 As stated in the charter the first deliverable for the NFS version 4
working group is this requirements document. This document is to working group is this requirements document. This document is to
cover the "limitations and deficiencies of NFS version 3". Therefore cover the "limitations and deficiencies of NFS version 3". Therefore
the intent of the following sections is to identify the various the intent of the following sections is to identify the various
feature points of NFS as a distributed file system and discuss its feature points of NFS as a distributed file system and discuss its
current functionality and compare to other distributed file systems current functionality and compare to other distributed file systems
and offer reasonable requirements for each of these areas. and offer reasonable requirements for each of these areas.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
For those cases where the NFS protocol is deficient or where a minor 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 modification is the best solution for a problem, a minor version or a
managed extension could be helpful. There have been instances with managed extension could be helpful. There have been instances with
NFS version 2 and 3 where small straightforward functional additions NFS version 2 and 3 where small straightforward functional additions
would have increased the overall value of the protocol immensely. would have increased the overall value of the protocol immensely.
However, the perceived size and burden of using a change of RPC However, the perceived size and burden of using a change of RPC
version number for the introduction of new functionality led to no or 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 slow change. It is possible that a new NFS protocol could allow for
the rare instance where protocol extension within the RPC version the rare instance where protocol extension within the RPC version
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
number is the most prudent course and an RPC revision would be number is the most prudent course and an RPC revision would be
unnecessary or impractical. unnecessary or impractical.
The areas of an NFS protocol which are most obviously volatile are The areas of an NFS protocol which are most obviously volatile are
new orthogonal procedures, new well-defined file or directory new orthogonal procedures, new well-defined file or directory
attributes and potentially new file types. It is possible and highly attributes and potentially new file types. It is possible and highly
desirable that these types of additions can be done without changing desirable that these types of additions can be done without changing
the overall design model of NFS without significant effort or delay. the overall design model of NFS without significant effort or delay.
This is particularly true in adding new procedures. This is particularly true in adding new procedures.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
4. Scalable Performance 4. Scalable Performance
In designing and developing an NFS protocol from a performance In designing and developing an NFS protocol from a performance
viewpoint there are several different points to consider. Each can viewpoint there are several different points to consider. Each can
play a significant role in perceived and real performance from the play a significant role in perceived and real performance from the
user's perspective. The three main areas of interest are: throughput user's perspective. The three main areas of interest are: throughput
and latency on the network, server work load or scalability and and latency on the network, server work load or scalability and
client side caching. client side caching.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
4.1. Throughput and Latency on the Network 4.1. Throughput and Latency on the Network
NFS currently has characteristics that provide good throughput for NFS currently has characteristics that provide good throughput for
the reading and writing of file data. However, the number of RPCs the reading and writing of file data. However, the number of RPCs
required to accomplish some tasks combined with high latency network required to accomplish some tasks combined with high latency network
environments leads to sluggish response. The protocol should environments leads to sluggish response. The protocol should
continue to provide good raw read and write throughput while continue to provide good raw read and write throughput while
addressing the issue of network latency. This issue is discussed addressing the issue of network latency. This issue is discussed
further in the section on Internet Accessibility. further in the section on Internet Accessibility.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Client caching is increasingly important for Internet environments Client caching is increasingly important for Internet environments
where throughput can be limited and response time can grow where throughput can be limited and response time can grow
significantly. significantly.
The NFS protocol should allow for aggressive caching while balancing The NFS protocol should allow for aggressive caching while balancing
the needs for simplicity and Internet accessibility (i.e. firewalls). the needs for simplicity and Internet accessibility (i.e. firewalls).
If possible, the caching ability should be layered on the protocol If possible, the caching ability should be layered on the protocol
instead of embedding specific client caching functions in the instead of embedding specific client caching functions in the
protocol itself. protocol itself.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
4.4. Disconnected Client Operation 4.4. Disconnected Client Operation
An extension of client caching is the idea or functionality of An extension of client caching is the idea or functionality of
disconnected operation at the client. With the ability to cache disconnected operation at the client. With the ability to cache
directory and file data aggressively, a client could then provide directory and file data aggressively, a client could then provide
service to the end user while disconnected from the server or service to the end user while disconnected from the server or
network. network.
While very desirable, disconnected operation has the opportunity to While very desirable, disconnected operation has the opportunity to
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Unix uid/gid mappings, directory modification time, accurate file Unix uid/gid mappings, directory modification time, accurate file
sizes, file/directory locking semantics (SHAREs, PC-style locking). sizes, file/directory locking semantics (SHAREs, PC-style locking).
5.2. Additional or Extended Attributes 5.2. Additional or Extended Attributes
NFS Versions 2 and 3 do not provide for file or directory attributes NFS Versions 2 and 3 do not provide for file or directory attributes
beyond those that are found in the traditional Unix environment; for beyond those that are found in the traditional Unix environment; for
example the user identifier/owner of the file, a permission or access example the user identifier/owner of the file, a permission or access
bitmap, time stamps for modification of the file or directory and bitmap, time stamps for modification of the file or directory and
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
file size to name a few. While the current set of attributes has file size to name a few. While the current set of attributes has
usually been sufficient, the file system's ability to manage usually been sufficient, the file system's ability to manage
additional information associated with a file or directory can be additional information associated with a file or directory can be
useful. useful.
There are many possibilities for additional attributes in the next There are many possibilities for additional attributes in the next
version of NFS. Some of these include: object creation timestamp, version of NFS. Some of these include: object creation timestamp,
user identifier of file's creator, timestamp of last backup or user identifier of file's creator, timestamp of last backup or
archival bit, version number, file content type (MIME type), archival bit, version number, file content type (MIME type),
skipping to change at page 8, line 5 skipping to change at page 8, line 5
environments. Even though the server still interprets the ACL and has environments. Even though the server still interprets the ACL and has
final control over access to a file system object, the client is able final control over access to a file system object, the client is able
to manipulate the ACL via these additional protocols. to manipulate the ACL via these additional protocols.
Other distributed file systems have also provided ACL support. DFS, Other distributed file systems have also provided ACL support. DFS,
AFS and CIFS to name a few. Based on current capabilities, it seems AFS and CIFS to name a few. Based on current capabilities, it seems
to be a requirement that NFS provide this capability as well but the to be a requirement that NFS provide this capability as well but the
major issue is one of compatibility. It may be problematic to create major issue is one of compatibility. It may be problematic to create
a workable ACL mechanism that will encompass a reasonable set of a workable ACL mechanism that will encompass a reasonable set of
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
functionality for all operating environments. functionality for all operating environments.
The three major reasons behind providing ACL support are existing The three major reasons behind providing ACL support are existing
distributed file system support, file servers not providing native distributed file system support, file servers not providing native
environment for user management of ACLs and perception of ACL support environment for user management of ACLs and perception of ACL support
as part of security requirement. Even with the complicated nature of as part of security requirement. Even with the complicated nature of
ACL support it is still worthwhile to work towards a solution that ACL support it is still worthwhile to work towards a solution that
can at least provide basic functionality for the user. can at least provide basic functionality for the user.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
6.2. User identification 6.2. User identification
NFS has been limited to the use of the Unix centric user NFS has been limited to the use of the Unix centric user
identification mechanism of numeric user id based on the available identification mechanism of numeric user id based on the available
file system attributes and the use of the ONCRPC. However, for NFS file system attributes and the use of the ONCRPC. However, for NFS
to move beyond the limits of large work groups, user identification to move beyond the limits of large work groups, user identification
should be string based and the definition of the user identifier should be string based and the definition of the user identifier
should allow for integration into an external naming service or should allow for integration into an external naming service or
services. services.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
Internet scaling should also be considered for this as well. The Internet scaling should also be considered for this as well. The
identification mechanism should take into account multiple naming identification mechanism should take into account multiple naming
domains and other extremes that can be presented by use outside of domains and other extremes that can be presented by use outside of
the work group. the work group.
If NFS is to move among various naming and security services, it may If NFS is to move among various naming and security services, it may
be necessary to stay with a string based identification. This would be necessary to stay with a string based identification. This would
allow for servers and clients to translate between the external allow for servers and clients to translate between the external
string representation to a local or internal numeric (or other string representation to a local or internal numeric (or other
skipping to change at page 10, line 5 skipping to change at page 10, line 5
not continue this authentication during subsequent interaction. not continue this authentication during subsequent interaction.
6.3.1. Authentication 6.3.1. Authentication
Strong authentication is a requirement for NFS and the logical Strong authentication is a requirement for NFS and the logical
solution for this is in the use of ONCRPC and RPCSEC_GSS. This solution for this is in the use of ONCRPC and RPCSEC_GSS. This
solution will allow for both private and public key mechanisms to be solution will allow for both private and public key mechanisms to be
employed if required. This flexibility will allow for security employed if required. This flexibility will allow for security
usability in varying environments. usability in varying environments.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
6.3.2. Data Integrity 6.3.2. Data Integrity
Since file and directory data is the essence of distributed file Since file and directory data is the essence of distributed file
service, the NFS protocol should provide to the users of the file service, the NFS protocol should provide to the users of the file
service a reasonable level of data integrity. The RPCSEC_GSS service a reasonable level of data integrity. The RPCSEC_GSS
mechanism provides a framework for data integrity and the security mechanism provides a framework for data integrity and the security
mechanisms chosen for NFS should be implemented to provide data mechanisms chosen for NFS should be implemented to provide data
integrity. integrity.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
appropriate usage based on availability and policy. This negotiation appropriate usage based on availability and policy. This negotiation
should account for authentication, integrity, and privacy so that should account for authentication, integrity, and privacy so that
administrators and users can employ the appropriate security policies administrators and users can employ the appropriate security policies
for their environments. for their environments.
7. Internet Accessibility 7. Internet Accessibility
Being a product of an IETF working group, the NFS protocol should not Being a product of an IETF working group, the NFS protocol should not
only be built upon IETF technologies where possible but should also only be built upon IETF technologies where possible but should also
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
work well within the broader Internet environment. work well within the broader Internet environment.
7.1. Congestion Control and Transport Selection 7.1. Congestion Control and Transport Selection
As with any network protocol, congestion control is a major issue and As with any network protocol, congestion control is a major issue and
the transport mechanisms that are chosen for NFS should take this the transport mechanisms that are chosen for NFS should take this
into account. Traditionally implementations of NFS have been into account. Traditionally implementations of NFS have been
deployed using both UDP and TCP. With the use of UDP, most deployed using both UDP and TCP. With the use of UDP, most
implementations provide a rudimentary attempt of congestion control implementations provide a rudimentary attempt of congestion control
skipping to change at page 12, line 5 skipping to change at page 12, line 5
As an application at the NFS client performs simple file system As an application at the NFS client performs simple file system
operations, multiple NFS operations or RPCs may be executed to operations, multiple NFS operations or RPCs may be executed to
accomplish the work for the application. While the NFS version 3 accomplish the work for the application. While the NFS version 3
protocol addressed some of this by returning file and directory protocol addressed some of this by returning file and directory
attributes for most procedures hence reducing follow up GETATTR attributes for most procedures hence reducing follow up GETATTR
requests, there is still room for improvement. Reducing the number requests, there is still room for improvement. Reducing the number
of RPCs can lead to a reduction of processing overhead on the server of RPCs can lead to a reduction of processing overhead on the server
(transport and security processing) along with reducing the time (transport and security processing) along with reducing the time
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
spent at the client waiting for the server's individual responses. spent at the client waiting for the server's individual responses.
This issue is more prominent in environments with larger degrees of This issue is more prominent in environments with larger degrees of
latency. latency.
The CIFS file access protocol supports 'batched requests' that allow The CIFS file access protocol supports 'batched requests' that allow
multiple requests to be batched and therefore reducing the number of multiple requests to be batched and therefore reducing the number of
round trip messages between client and server. round trip messages between client and server.
This same approach can be used by NFS to allow the grouping of This same approach can be used by NFS to allow the grouping of
skipping to change at page 12, line 33 skipping to change at page 12, line 33
NFS has provided Unix file locking and DOS SHARE capability with the NFS has provided Unix file locking and DOS SHARE capability with the
use of an ancillary protocol (Network Lock Manager / NLM). The NLM use of an ancillary protocol (Network Lock Manager / NLM). The NLM
protocol provides for file locking and recovery of those locks in the protocol provides for file locking and recovery of those locks in the
event of client or server failure. NLM requires that the server make event of client or server failure. NLM requires that the server make
call backs to the client for certain scenarios and therefore is not call backs to the client for certain scenarios and therefore is not
necessarily well suited for Internet firewall traversal. necessarily well suited for Internet firewall traversal.
Desirable features of file locking support are: Desirable features of file locking support are:
o Integration with the NFS protocol o Integration with the NFS protocol.
o Interoperability between operating environments (i.e.
traditional NFS, CIFS, DFS, Novell environments)
o Scalable solutions - thousands of clients o Interoperability between operating environments. The protocol
should make a reasonable effort to support the locking semantics
of both PC and Unix clients and servers.
o Internet capable (firewall traversal, latency sensitive) o Scalable solutions - thousands of clients. The server should
not be required to maintain client lock state across reboots.
o Timely recovery in the event of client/server failure or cluster o Internet capable (firewall traversal, latency sensitive). The
fail-over. server should not be required to initiate TCP connections to
clients.
DFS offers file locking but does not provide DOS SHARE o Timely recovery in the event of client/server or network
capability. DFS' relies on the server calling back to the failure. Server recovery should be rapid. The protocol should
client for the file locking functionality. allow clients to detect the loss of a lock.
CIFS supports file locking and DOS SHARE support. CIFS supports file locking and DOS SHARE support.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
9. Internationalization 9. Internationalization
The current NFS protocols are limited in their support of anything The current NFS protocols are limited in their support of anything
more than 7-bit ASCII strings. It is imperative that NFS support a more than 7-bit ASCII strings. It is imperative that NFS support a
range of character sets. This can be provided by requiring support range of character sets. This can be provided by requiring support
for Unicode with a UTF-8 wire encoding. Therefore, all strings 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 defined as part of the NFS protocol will need to be defined as UTF-8
and the appropriate XDR encoding used. and the appropriate XDR encoding used.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
10. Bibliography 10. Bibliography
[RFC1094] [RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC1094, March 1989. Specification", RFC1094, March 1989.
ftp://ftp.isi.edu/in-notes/rfc1094.txt ftp://ftp.isi.edu/in-notes/rfc1094.txt
[RFC1813] [RFC1813]
skipping to change at page 15, line 5 skipping to change at page 15, line 5
[RFC2025] [RFC2025]
Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025,
Bell-Northern Research, October 1996. Bell-Northern Research, October 1996.
ftp://ftp.isi.edu/in-notes/rfc2025.txt ftp://ftp.isi.edu/in-notes/rfc2025.txt
[RFC2078] [RFC2078]
Linn, J., "Generic Security Service Application Program Interface, Linn, J., "Generic Security Service Application Program Interface,
Version 2", RFC2078, OpenVision Technologies, January 1997. Version 2", RFC2078, OpenVision Technologies, January 1997.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
ftp://ftp.isi.edu/in-notes/rfc2078.txt ftp://ftp.isi.edu/in-notes/rfc2078.txt
[RFC2203] [RFC2203]
Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification" Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification"
RFC2203, Sun Microsystems, Inc., August 1995. RFC2203, Sun Microsystems, Inc., August 1995.
ftp://ftp.isi.edu/in-notes/rfc2203.txt ftp://ftp.isi.edu/in-notes/rfc2203.txt
[Sandberg] [Sandberg]
skipping to change at page 16, line 5 skipping to change at page 16, line 5
protocols, including the Lock Manager and the Portmapper. protocols, including the Lock Manager and the Portmapper.
[X/OpenPCNFS] [X/OpenPCNFS]
X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open
Internetworking: (PC)NFS, Developer's Specification, X/Open Company, Internetworking: (PC)NFS, Developer's Specification, X/Open Company,
Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United
Kingdom, 1991. This is an indispensable reference for NFS version 2 Kingdom, 1991. This is an indispensable reference for NFS version 2
protocol and accompanying protocols, including the Lock Manager and protocol and accompanying protocols, including the Lock Manager and
the Portmapper. the Portmapper.
NFSv4 NFSv4 Requirements September 1998 NFSv4 NFSv4 Requirements October 1998
11. Author's Address 11. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
Spencer Shepler Spencer Shepler
Sun Microsystems, Inc. Sun Microsystems, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/