--- 1/draft-ietf-nfsv4-requirements-01.txt 2006-02-05 00:48:25.000000000 +0100 +++ 2/draft-ietf-nfsv4-requirements-02.txt 2006-02-05 00:48:25.000000000 +0100 @@ -1,14 +1,14 @@ Network Working Group Spencer Shepler -Document: draft-ietf-nfsv4-requirements-01.txt +Document: draft-ietf-nfsv4-requirements-02.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. @@ -25,21 +25,21 @@ 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 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 . . . . . . . . . . 5 @@ -61,21 +61,21 @@ 6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 10 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10 7.1. Congestion Control and Transport Selection . . . . . . . 11 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 11 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 11 8. File locking / recovery . . . . . . . . . . . . . . . . . 12 9. Internationalization . . . . . . . . . . . . . . . . . . . 13 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 14 11. Author's Address . . . . . . . . . . . . . . . . . . . . 16 -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 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. @@ -107,21 +107,21 @@ 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. 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 -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 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. It is possible and highly desirable that these types of additions can be done without changing the overall design model of NFS without significant effort or delay. This is particularly true in adding new procedures. @@ -150,21 +150,21 @@ 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 4.1. Throughput and Latency on the Network NFS currently has characteristics that provide good throughput for the reading and writing 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 while addressing the issue of network latency. This issue is discussed further in the section on Internet Accessibility. @@ -193,21 +193,21 @@ 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 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 @@ -239,21 +239,21 @@ Unix uid/gid mappings, directory modification time, accurate file sizes, file/directory locking semantics (SHAREs, PC-style locking). 5.2. Additional or Extended 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 example the user identifier/owner of the file, a permission or access 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 usually been sufficient, the file system's ability to manage additional information associated with a file or directory can be useful. There are many possibilities for additional attributes in the next version of NFS. Some of these include: object creation timestamp, user identifier of file's creator, timestamp of last backup or archival bit, version number, file content type (MIME type), @@ -289,21 +289,21 @@ environments. 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. Other distributed file systems have also provided ACL support. DFS, 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 major issue is one of compatibility. It may be problematic to create 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. The three major reasons behind providing ACL support are existing distributed file system support, file servers not providing native environment for user management of ACLs and perception of ACL support as part of security requirement. Even with the complicated nature of ACL support it is still worthwhile to work towards a solution that can at least provide basic functionality for the user. @@ -334,21 +334,21 @@ 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 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 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. If NFS is to move among various naming and security services, it may be necessary to stay with a string based identification. This would allow for servers and clients to translate between the external string representation to a local or internal numeric (or other @@ -378,21 +378,21 @@ not continue this authentication during subsequent interaction. 6.3.1. Authentication Strong authentication is a requirement for NFS and the logical 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 employed if required. This flexibility will allow for security usability in varying environments. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 6.3.2. Data Integrity Since file and directory data is the essence of distributed file service, the NFS protocol should provide to the users of the file service a reasonable level of data integrity. The RPCSEC_GSS mechanism provides a framework for data integrity and the security mechanisms chosen for NFS should be implemented to provide data integrity. @@ -420,21 +420,21 @@ appropriate usage based on availability and policy. This negotiation should account for authentication, integrity, and privacy so that administrators and users can employ the appropriate security policies for their environments. 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 -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 work well within the broader Internet environment. 7.1. Congestion Control and Transport Selection As with any network protocol, congestion control is a major issue and the transport mechanisms that are chosen for NFS should take this into account. Traditionally implementations of NFS have been deployed using both UDP and TCP. With the use of UDP, most implementations provide a rudimentary attempt of congestion control @@ -466,21 +466,21 @@ As an application at the NFS client performs simple file system 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 -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 spent at the client waiting for the server's individual responses. This issue is more prominent in environments with larger degrees of latency. The CIFS file access protocol supports 'batched requests' that allow multiple requests to be batched and therefore reducing the number of round trip messages between client and server. This same approach can be used by NFS to allow the grouping of @@ -494,50 +494,51 @@ 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 (i.e. - traditional NFS, CIFS, DFS, Novell environments) + o Integration with the NFS protocol. - 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 - fail-over. + o Internet capable (firewall traversal, latency sensitive). The + server should not be required to initiate TCP connections to + clients. - DFS offers file locking but does not provide DOS SHARE - capability. DFS' relies on the server calling back to the - client for the file locking functionality. + o Timely recovery in the event of client/server or network + failure. Server recovery should be rapid. The protocol should + allow clients to detect the loss of a lock. CIFS supports file locking and DOS SHARE support. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 1998 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 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] @@ -567,21 +568,21 @@ [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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 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] @@ -600,21 +601,21 @@ 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. -NFSv4 NFSv4 Requirements September 1998 +NFSv4 NFSv4 Requirements October 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