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
Brent Callaghan <firstname.lastname@example.org>
Brian Pawlowski <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Vern Paxson <firstname.lastname@example.org>
To Subscribe: email@example.com
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:
Issue strawman Internet-Draft for v4
Submit Initial Internet-Draft of requirements document
Submit Final Internet-Draft of requirements document
AD reassesses WG charter
Submit v4 Internet-Draft sufficient to begin prototype implementations
Begin Interoperability testing of prototype implementations
Submit NFS version 4 to IESG for consideration as a Proposed Standard.
Conduct final Interoperability tests
Submit NFS version 4 to IESG for consideration as a Draft Standard.
No Current Internet-Drafts
No Request For Comments
NFSv4 Working Group Meetings @ 42nd IETF Chicago
Reported by Brent Callaghan with contributions from Mike Eisler and Brian Pawlowski.
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 ?
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:
Which security flavors should be implemented ? There was some disagreement
as to whether schemes should be mandatory and which schemes should they be.
There seemed to be some reluctance to require only strong security to be
negotiated. Negotiation of security negotiated at the connection level (e.g. TLS)
was also raised. Edwards Reed of Novell provided a good reference to draft-
newman-auth-mandatory-00.txt (April 98) "The Mandatory-to-Implement
Authentication Problem" which discusses this issue. There was also some
questions on the use of strings to identify users and groups and the mapping of
these strings to local representations. The question of support for Access
Control Lists was raised. There is a problem determining which ACL model to
support: POSIX, Windows NT, or DCE/DFS ?
Latency and Bandwidth:
Where access to server data is limited by bandwidth and latency, clients can
benefit from aggressive caching. There was agreement that NFS version 4
should support this though no specific proposals as to what support was needed
within the protocol. A feature that allows the server to notify clients of changes
to cached data would assist cache consistency though this would be difficult to
support on an Internet scale. Brian Pawlowski mentioned that the SMB/CIFS
protocol already uses "oplocks" to support cache consistency albeit with a
requirement for much client state to be held on the server. The use of a
streaming protocol, like SGI's BDS, to better utilize bandwidth for large data
transfers was mentioned, though a close approximation to streaming can be
realized through very large READ and WRITE requests already possible with
NFS version 3.
NFS assumes a single-rooted, hierarchically organized tree of directories with
files as leaf nodes. Files are assumed to be an uninterpreted sequence of bytes.
There was a question as to whether NFS version 4 should allow this model to
be extended to handle multi-stream files as supported by NTFS and MacOS
(data & resource forks). NTFS data streams can be created, deleted, are
renameable and lockable. One possibility is to allow a multi-stream file to
function both as a directory and as a file. Support for case-insensitive lookups
and wildcard matching were also mentioned as requirements for PC support.
One objection raised was the complexity this introduces in reserving wildcard
characters in filenames and specifying case in a Unicode context.
If the protocol is to allow file attributes to be set and read individually, what
are the expectations of a client or server as to which attributes will be supported
and which will not ? What should the server do if the client sets and attribute
it cannot support ? The specification should state a clear policy on the issue of
attribute support. The use of "extended" attributes was mentioned: values named
with arbitrary strings. One way to support these may be through the concept of
named data streams within a file context.
There was some support voiced for a proposal to provide a global NFS namespace
through an LDAP schema, perhaps described in a separate document. There was
some disagreement as to whether the use of Unicode filenames in NFS v4 required
the separate specification of a codepage to be used. There seemed to be general
agreement that the use of on-the-wire UTF-8 encoding precluded the need for
David Robinson outlined an alternative locking proposal to that described in the
strawman. His proposal allows clients the option of having mandatory or advisory
locking and uses different mechanisms for extension of leases and lock recovery.
Ira Slutskaia pointed out a flaw in the proposal that prevented an I/O request from
straddling two independently locked regions in a file. There was some
disagreement as to whether the lock protocol should allow a lock to be lost or
denied to a client. There are locking APIs that assume locks are held indefinitely
and have no mechanism for notifying an application that a lock is lost. Solaris
has a SIGLOST signal, but it is not widely supported on other Unix
implementations. Mike Eisler pointed out though that existing NLM protocol
does cause one to lose locks.
DOS File Sharing:
DOS applications exercise a form of whole-file locking when a file is opened called
a "share" which specifies both and access mode (read, write, read-write) and a deny
mode (none, read, write, all). These semantics are currently implemented by the
NLM protocol but only in an advisory form. The strawman locking protocol cannot
be used to reproduce the precise share semantics either. Although there is consensus
that PC applications should be better supported by NFS version 4, there is some
debate as to what degree the share semantics should be supported, whether non-
DOS applications should be required to support share semantics, and whether the
share semantics should be supported as a type of lock, or as a new form of file or
There was a brief discussion on the approach to testing of v4 implementations.
Implementors should make their servers available on the Internet to facilitate
client and server testing. Clients and servers should also be tested through firewalls.
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.
Welcome, Agenda, WG Formation, Charter & Milestones
NFSV4 - Solutions for Enterprise Storage
go to list