2.7.9 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 05-Aug-98

Chair(s):

Brent Callaghan <brent@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Vern Paxson <vern@ee.lbl.gov>

Mailing Lists:

General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: nfsv4-wg-request@sunroof.eng.sun.com
Archive: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive

Description of Working Group:

The objective of this working group is to advance the state of NFS technology by producing a specification for NFS version 4 which will be submitted as an Internet standards track RFC. The first phase of the working group activity will produce a requirements document describing the limitations and deficiencies of NFS version 3, potential solutions for addressing these, and a cost/benefit analysis of the different solutions. Input for the development of this document will include experiences with other distributed file systems such as DCE/DFS and Coda. Following the publication of this document, the charter of the working group will be reassessed; however, it is anticipated that NFS version 4 will emphasize the following core features:

o Improved access and good performance on the Internet.

The protocol will be designed to perform well where latency is high and bandwidth is low, to adapt to the presence of congestion, to scale to very large numbers of clients per server, and to transit firewalls easily.

o Strong security with negotiation built into the protocol.

The protocol may build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. The permission model needs to scale beyond the current flat integer UID space.

Additionally NFS version 4 will provide a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes.

o Better cross-platform interoperability.

The protocol will feature a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another.

o Designed for protocol extensions.

The protocol will be designed to accept standard extensions that do not compromise backward compatibility.

Goals and Milestones:

Jul 98

  

Issue strawman Internet-Draft for v4

Aug 98

  

Submit Initial Internet-Draft of requirements document

Sep 98

  

Submit Final Internet-Draft of requirements document

Oct 98

  

AD reassesses WG charter

Dec 98

  

Submit v4 Internet-Draft sufficient to begin prototype implementations

Mar 99

  

Begin Interoperability testing of prototype implementations

Apr 99

  

Submit NFS version 4 to IESG for consideration as a Proposed Standard.

Sep 99

  

Conduct final Interoperability tests

Oct 99

  

Submit NFS version 4 to IESG for consideration as a Draft Standard.

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

NFSv4 Working Group Meetings @ 42nd IETF Chicago

Reported by Brent Callaghan with contributions from Mike Eisler and Brian Pawlowski.

Morning Session

The morning session was attended by about 50 people. It was organized as a series
of presentations intended to present the state of the working group and its drafts. Brent
Callaghan lead off with an overview of the agenda for morning and afternoon sessions,
a brief history of the NFS protocol and its versions, an account of events leading to the
formation of the working group, and the draft working group charter and milestones.
Brian Pawlowski responded to a question as to whether NFS version 4 server would
support previous versions. NFS servers are typically compatible with all previous
versions. Brent mentioned that the milestones assumed availability of prototype
implementations early next year, though some of these early prototypes may implement
and test subsets of the protocol.

Spencer Shepler presented an outline of the Requirements Document, which is designed
to focus attention on the rationale for the working group and answer such questions as:
What do we need to fix in NFS version 3 ? What good features of NFS should be
preserved ? Continued use of the ONC RPC protocol seems to make sense given that
it is already on standards track. What new problems does the new protocol need to
address ? What are the cost/benefit tradeoffs ? The current draft needs to include more
comparisons with existing distributed filesystems.

Spencer then moved on to present an overview of the Strawman protocol document.
This is a rough protocol specification intended to provide a nexus for proposals relating
to specific protocol features. The strawman protocol integrates the mount and file
locking protocols into a single NFS protocol. File names are encoded UTF-8 strings
and name files within a single-root namespace on the server. Security utilizes the
RPCSEC_GSS framework (now a Proposed Standard) into which public key schemes,
like SPKM and private key schemes like Kerberos version 5, can be integrated. File
attributes are an extensible set, individually gettable and settable. NFS operations can
be aggregated into compound requests to provide more implementation flexibility and
address network latency. Integrated file locking operations utilize leases to avoid the
need for server callbacks or status monitoring. The strawman leaves many open issues
in the implementation of locking, minor versioning, required attributes, Access Control
Lists and security mechanisms. The future evolution of the strawman will be guided
by the final requirements document and the charter that derives from it.

Uresh Vahalia gave a short presentation outlining some issues and proposals for NFS
v4: NFS version 4 must perform well enough to provide very high bandwidth to servers
with many terabytes of data. While TCP is good for the Internet, UDP is still
significantly faster then TCP for NFS on LANs. We need to think about providing
client advisories to the server for file space reservation, caching policy, and per-file
access advisories. A file copy operation could be executed more efficiently on the server.
NFS version 4 also needs to work well with other file access protocols.

The morning session ended with a brief introduction by Brian Pawlowski to topics that
we should keep in mind for the afternoon session, i.e. what are the deficiencies in the
current protocol ? What is critical for NFS v4 ? Will it support Windows ? And finally,
a reality check: can it be implemented ?

Afternoon Session

The afternoon session promoted an interactive discussion of problems with NFS and
possible solutions for version 4. Since the group was in a much larger room than
needed (40 or so in a room for 200) we exchanged rooms with the MPLS WG. Brian
Pawlowski then moderated the discourse over a series of agenda items:

Security:

Latency and Bandwidth:

Filesystem Model:

File Attributes:

Naming:

Locking:

DOS File Sharing:

Testing:

Brian Pawlowski concluded the session with a request that the disparate locking
proposals be resolved along with the a coherent proposal for support of DOS shares.

Slides

Welcome, Agenda, WG Formation, Charter & Milestones
Requirements Document
Strawman Overview
NFSV4 - Solutions for Enterprise Storage

Attendees List

go to list