2.7.9 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07


Brian Pawlowski <beepy@netapp.com>
Spencer Shepler <spencer.shepler@sun.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: nfsv4@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4
Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html

Description of Working Group:

The objective of this working group is to advance the state of NFS
technology by producing specifications to extend the original NFS
Version 4 work (RFC 3010) to provide additional capabilities, as
described below.

o NFS version 4

  Advance the protocol along the standards track, coordinating the
  development of test suites to provide a high level of implementation
  quality. The ONC RPC standards that NFSv4 references must also be
  advanced. This includes work to make NFSv4 and the underlying ONC RPC
  protocol compatible with IPv6.  Specifically, we will advance RFC
  3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working
  group will help advance related security RFCs, specifically through
  the definition of a method to advance APIs.

o Replication and Migration

  The original working group defined a mechanism for NFS clients and
  servers to support replication and migration of data transparently
  to an application.  Left undefined in the initial work was the
  server back end migration and replication mechanism.  The working
  group will produce a draft submission of a replication/migration
  protocol that supports NFS Version 4 clients - needed to create and
  maintain replicated filesystems as well as migrating filesystems
  from one location to another -  and servers for consideration as
  Proposed Standard.

o Management

  The working group will produce a draft submission for consideration
  as Proposed Standard of a management MIBs to provide better
  management and administration capabilities for NFS and ONC RPC.

o Minor Versions

  NFS Version 4 contains within it the capability for minor versioning.
  Some discussions within the working group suggest addressing
  additional requirements over the original charter.  The WG will work
  to identify additional requirements for NFSv4 and determine if they
  are appropriate and worthwhile for a minor version.  This work may
  lead to proposals for additional work items.  If it does a specific
  proposal to add these work items to the charter will be forwarded to
  the IESG and IAB.

o RDMA/RDDP enabling

  The performance benefit of RDMA/RDDP transports in NFS-related
  applications, by reducing the overhead of data and metadata
  exchange, has been demonstrated sufficiently such that the
  working group will pursue in parallel enabling NFS and RPC over
  the transport defined by the RDDP working group. The WG will
  restrict its initial activities to defining the problem
  statement and specifying the requirements for possible
  extensions to RPC and NFS (in the context of a minor

Goals and Milestones:

Done  Issue strawman Internet-Draft for v4
Done  Submit Initial Internet-Draft of requirements document
Done  Submit Final Internet-Draft of requirements document
Done  AD reassesses WG charter
Done  Submit v4 Internet-Draft sufficient to begin prototype implementations
Done  Begin Interoperability testing of prototype implementations
Done  Submit NFS version 4 to IESG for consideration as a Proposed Standard.
Done  Conduct final Interoperability tests
Done  Conduct full Interoperability tests for all NFSv4 features
Done  Update API advancement draft
Done  Form core design team to work on NFS V4 migration/replication requirements and protocol
Done  Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard
Done  Strawman NFS V4 replication/migration protocol proposal submitted as an ID
Mar 03  ADs to submit API advancement internet draft as informational RFC (needed to advance GSSAPI to Draft Standard to allow advancement of NFS Version 4)
Mar 03  Continued interoperability testing of NFS Version 4
Apr 03  Internet draft on NFS V4 migration/replication requirements
Apr 03  AD review of NFS V4 migration/replication requirements draft
Apr 03  Creation of internet draft on ONC RPC MIB
Apr 03  Revision of internet draft on NFS MIB
Apr 03  Draft problem statement I-D for NFS/RPC/RDDP submitted
May 03  Document full Interoperability tests for all NFSv4 features
Jun 03  Depending on results of AD review of NFS Version 4 migration/replication requirements document, review scope of task
Jun 03  Submit related Proposed Standards required by NFS Version 4 for consideration as Draft Standards to IESG - RFCs 1831, 1833, 2203, 2078, 2744, RFC 1964, & 2847
Jun 03  Draft requirements document I-D for NFS/RPC/RDDP submitted
Jun 03  Submit ONC RPC and NFS MIBs to IESG for consideration as Proposed Standards
Jun 03  Submit an NFS V4 migration/replication protocol to IESG for consideration as a Proposed Standard
Jun 03  Submit report on results of NFS version 4 RFC interoperability testing
Jul 03  AD review of NFS/RPC/RDDP progress and charter
Jul 03  Interoperability tests of NFS V4 migration/replication
Aug 03  Submit revised NFS Version 4 Proposed Standard for consideration as Draft Standard to IESG


  • draft-ietf-nfsv4-rfc1832bis-05.txt
  • draft-ietf-nfsv4-rpc-iana-03.txt
  • draft-ietf-nfsv4-rfc1831bis-05.txt
  • draft-ietf-nfsv4-acl-mapping-03.txt
  • draft-ietf-nfsv4-channel-bindings-03.txt
  • draft-ietf-nfsv4-nfs-rdma-problem-statement-02.txt
  • draft-ietf-nfsv4-rpcrdma-01.txt
  • draft-ietf-nfsv4-nfsdirect-01.txt
  • draft-ietf-nfsv4-sess-01.txt

    Request For Comments:

    RFC2623 PS NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
    RFC2624 I NFS Version 4 Design Considerations
    RFC3010 PS NFS version 4
    RFC3530 PS Network File System (NFS) version 4 Protocol

    Current Meeting Report

    IETF 62 NFSv4 WG meeting
    Monday, March 7, 2005 7:50:02 PM

    Welcome, Agenda Bash etc. - beepy

    beepy blue sheeted, noted well, and agenda bashed.

    I-D Status - Shepler

    XDR moving through IETF last call. For consideration as Standard.

    RPC update from Thurlow is nearly ready?

    ACL mapping, Carl Burnett form IBM may get involved.

    RDMA - substantial revision Talpey will cover for RPC draft. Talpey to give update on sessions stuff. Shepler to wrap into a minor revision draft.

    Directory delegations - alternate proposal from Wickman at CITI. Saadia Khan has the other proposal. We will have a lively e-mail discussion. Saadia to post any feedback from Connectathon presentation to the alias.

    CCM and channel bindings. Drafts - have to move forward, how? Eisler says should progress with the RDMA stuff. Shepler asked if we need implementation experience. Eisler to retrigger draft. Nico is doing some prototyping.

    Noveck and Carl Burnett have written an interpretation draft around migration/replication on how to construct name spaces.

    How to move pNFS from individual to WG draft. beepy would like to see file flavor support shuffled in with Brent Welch's core draft as next step to move forward. Shepler says we need to give heads up to ADs.

    Connectathon - Shepler

    Normal NFS V4 testing went smoothly. ACL testing. Replication and Migration (get more comments from Shepler here)

    pNFS prototype from Sun and NetApp were played around with.

    RPC/RDMA draft - Talpey

    RPC level attack to enable RDMA support at minimum level for NFS. Mallakarjun comments are folded into the document. Including clarifications. We think document has no open issues at this time. Protocol itself is unchanged. Some new information on chunking rules.

    A lot of clarification on ... terminology. Draft is not completely bound to RDDP draft.

    Session Draft - Talpey

    Fourth major document updated in February. Reflects some implementation experience.

    Talpey talked about mgmt of sequence ID to prevent replays. Failed to document the CB_SEQUENCE operation, SEQUENCE operations has a sequence-id and a slot id - draft suggests that 1-bit can be used but that is not correct for unreliable/unorder transports; Talpey to follow up with additional detail.

    (Over UDP neither reliable nor ordered. Talpey hasn't thought about all permutations).

    Implementation experience - several. Sessions client on Linux and a server. Sessions client on Solaris. Sessions side had a protocol incompatibility. Linux sessions server was complete except for old version of draft and callback channel support is missing. But the implementations and issues arising from work was discussed amongst the developers at Connectathon.

    Mike Stolarchuk presented experience with using the callback channel in the client at Connectathon. Security of callback channel needs to be resolved

    Transport Switch is being used by Groupe Bull to do IPv6 work. Some IB and iWARP. Protocol on wire independent of wire type. (discussion with Mallakarjun)

    Changes will be pushed into Linux 2.6.12 (the transport switch fixes).

    Linux prototype on CITI UMich web site (see slides).

    pNFS Operations Summary - Brent Welch

    Brent gave a brief overview... Support parallel I/O to storage, adds concept of a layout to data to allow finding it (in a parallel world). Lots of proprietary solutions in this area (background). See slides.

    Motivated why add 'p' to NFS (parallel == performance).

    David Black says open issue on EOF update... Issue on overlapping layouts. More discussion needed here.

    Eisler asked about attributes being in sync - totally controlled by the metadata server (except perhaps EOF). GETATTR to data servers will yield unpredictable results...

    beepy is sitting here thinking of

    - the metadata server as a bottleneck
    - fundamental scalability issues in number of data servers?
    - availability issues of metadata server
    - etc.

    Garth Goodson had a NetApp pNFS server prototype, Sun had a pNFS client - they interoperated. Main thing that came up were error recovery cases...

    Brent covered OSD and T10 and stuff.

    David Black objected to the use of the word "signed" in context of capability communicated by metadata server for a given OSD device.

    Capabilities allow impersonation - capturing a
    capability is worse than capturing data...

    you want an encrypted channel between client and metadata server...but infrequent operation?

    Lots o' description of OSD capabilities...

    I attach here Spencer Shepler's pNFS talk notes mostly unedited, covering the same material:

    - Review of pNFS model

    - Proprietary solutions that provide parallel access

    - NFSv4 is THE standard protocol and extend it to provide feature set

    - performance requirements: e.g. 1Gbyte of data per 1 Teraflop of processing - Gary Grider

    - T10 metadata standards (for Panasas solution)

    - moving to specific operations

    - David Black mentions the EOF update issues

    - Went on to a question whether attributes on a data server (for a file) are interesting -- should they be interpreted? No, the meta-data server is the place to pick up the correct attributes

    - Brent mentioned the cthon testing of Netapp/Sun work

    - Sez that additional text is needed around the error recovery issues because of the additional parties involved in the filesystem interaction (client, mds, data-server)

    - Moved onto a discussion/review of the object model (capability based security scheme)

    - object-store knows about attributes like size and capacity

    - Eisler asked about the difference between object-store and NFSv4 data-servers

    - Brent admits that the major difference is the security protocol used to access the object-store

    - Object-store will have a limited set of attributes

    - Security capability of object-store

    - capability encodes (stuff) and is not specific to the principal - question about the need to keep the capability secret (not specific to the client)

    - capability can be revoked by the server by setting the version on the capability -- applies to all outstanding capabilities

    - capability has a time expiration (server determined)

    - signing == compute the HMAC

    - capsignature is used to sign the requests to the object-store

    - Question whether the gssapi infrastructure can be used to protect the LAYOUTGET for protection of the capability

    Wickman on Directory delegations

    Brian Wickman from the University of Michigan CITI group presented an overview and alternat proposal for directory delegations.

    - Directory Delegations for NFSv4

    - review of file delegation mechanism

    - applications shouldn't have to be tooled specifically to have
    an advantage with directory delegations

    - delegate portion of directory state to client
    filename to filehandle bindings
    file attributes
    anything else?

    - review of the options for directory delegation solution

    - review of Saadia's proposal

    - The Wickman proposal

    no new callbacks
    no notifications, existing data structures maintained
    read/write delegations are specified
    minimal information, coarse-grained
    implementation more straightforward

    NOTE: delegation does not provide for delegation of attributes of objects within the directory.

    Nico observed that if the directory is changing frequently then callbacks would be desired; Wickman does not protest (foreshadow of his study/data?)

    Write delegation is a little bizarre (...)

    Question about how directory write delegations would work in the current client model; Wickman suggests that the client can "fake" the attributes until a stat() is done and then the client can flush the creation/data.

    write delegation infer the need for STATEID (current stateid)

    How to evaluate the proposals

    beepy wondered if Saadia's proposal and Wickman's proposal can be reconciled with optional behaviour?

    Open discussion

    For pNFS deliveries, beepy thinks we'll be going after separate drafts to get parallelism in the workgroup and slice the problem up:
    pNFS with file layout
    separate drafts for object and blocks

    ----- End of forwarded message from beepy -----


    I-D Status
    NFS/RDMA and Sessions Updates
    pNFS extension for NFSv4
    Directory Delegations in NFSv4