2.7.7 Network File System Version 4 (nfsv4)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

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: https://www1.ietf.org/mail-archive/working-groups/nfsv4/current/maillist.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 revision).

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-02.txt
  • - draft-ietf-nfsv4-ccm-02.txt
  • - draft-ietf-nfsv4-rfc1831bis-01.txt
  • - draft-ietf-nfsv4-acl-mapping-01.txt
  • - draft-ietf-nfsv4-channel-bindings-00.txt
  • - draft-ietf-nfsv4-nfs-rdma-problem-statement-00.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

    NFSv4 WG Meeting minutes 
    IETF59 Seoul 
    March 4, 2004, 1300-1500 
    The agenda was: 
    Network File System Version 4 (nfsv4) 
        Spencer Shepler <Spencer.Shepler@sun.com> 
        Brian Pawlowski <beepy@netapp.com> 
    AGENDA:  Thursday, March 4, 2004: 13:00pm - 15:00 (2 hours) 
        Welcome and Introduction            (Talpey)         1 min 
        Agenda bash 
            - Blue Sheets 
            - NOTE WELL 
        Connectathon results                (Shepler by proxy) 15 min 
        NFS V4 interoperability testing 
        Review and discussion of NFS/RDMA 
                                                    (Talpey)         30 min 
        NFS RDMA Problem Statement 
        NFS RDMA Requirements 
        Potential Minor Version Work - 20 mins 
             Review existing items 
             Informational items: 
                Parallel NFS (pNFS) position statement - (Talpey) 
        Open discussion                     (Talpey)          30 min 
        Wrapup                              (Talpey)          1 m 
    Brian was unable to attend at the last minute, so Tom Talpey sat in as 
    Chair Pro Tem. :-) 
    Agenda bashed 
    Blue sheeted 
    Noted well 
    - Connectathon Results (Shepler by proxy) 
      There were seven NFSv4 implementations at the recent 
    Connectathon, of which seven were servers and four were clients. The most 
      NFSv4 testing went smoothly, with no protocol or specification issues 
    found. All implementations were testing Kerberos, and some testing of 
    "advanced" features, such as ACLs and delegations was done. There was 
    interest in continuing the NFSv4 Bake-a-thons. 
      Numerous bugs were found and fixed, all basic Cthon tests were 
    completed by all. ACLs were rough (owing to the recent mapping changes) but 
    broad agreement on the needed fixes was had. 
    Replication/migration and fs_locations were missing in action, however. 
      NFS/RDMA prototyping efforts were also tested, based on NFSv3 
    implementations. Sun, CITI and NetApp tested a Linux client, Sun client and 
    server, and NetApp server. There were discussions related to including the 
    NFSv4 Session extensions in a minor revision. 
      Possible items for a v4 minor release: 
        + Channel Conjunction Mechanism (CCM, 
        + Sessions 
        + Directory delegation 
        + Clarifications/bugfixes 
        + More tbd... 
      Questions were asked: 
        Q: which Linux implementations were testing v4? 
        A: Primarily Linux 2.6. 
        Q: Was any security other than Kerberos being tested? 
        A: The focus was on the mandatory NFSv4 security - Kerberos. SPKM3 
    testing was also performed by the CITI Linux implementations. 
        Q: What are the goals of v4 fs_locations? 
        A: Covered in the RFC and drafts. 
        Q: Is there interest in employing IPSec? 
        A: Yes, absolutely, refer to the CCM draft. 
        Q: How does NFS detect that IPSec is in use? 
        A: Local interface issue. 
    - NFS/RDMA Document Review (Talpey): 
      The "NFS RDMA Problem Statement" document was presented. Updated in 
    draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt. The document 
    demonstrates that RDMA can reduce the overhead encountered by NFS 
    implementations, by eliminating data copies and offloading network 
    processing. Overhead in NFS stems from the message formats and the 
    presence of XDR. Page flipping, and protocol offload solutions are 
    quantifiably less effective than RDMA. Many references are provided. 
        Q: Is the RDMA Advantage primarily from copy avoidance or offload? 
        A: Clearly both, but the largest benefit comes from copy 
    avoidance. This is discussed in the referenced papers. 
        Q: What overhead is due to using TCP versus UDP? 
        A: TCP and UDP are now practically identical in performance and most use 
    TCP now. In fact, v4 requires a congestion-controlled transport - TCP. 
        Q: What overhead difference is seen between V3 and V4? 
        A: Performance between v3 and v4 is nearly identical as well, but v4 
    affords additional performance from delegations which may permit it to 
    outperform V3. 
        Q: Can't TOE perform certain copy avoidance? 
        A: Yes, but very limited, and not on receive. 
      The "NFS RDMA Requirements" document 
    (draft-callaghan-nfsrdmareq-00.txt) was next. This document lays out the 
    basic requirements made by NFS/RDMA on any RDMA transport, as input to the 
    RDDP group in particular. The requirements are compatible with the 
    current RDDP, with security integrity and privacy listed as 
    desirable. The relative functions of an RDMA layer versus NFS and RPC are 
    explored, and some guidelines for efficiency. 
    - RDDP WG questions for NFSv4 WG: 
      This discussion led directly to an item from the previous day's RDDP 
    Working group meeting. Does the NFS/RDMA effort wish RDDP to make 
    support of IPSec "mandatory to implement, optional to use"? The RDDP 
    working group seeks the NFS group's input on this, and also whether SSL or 
    other TLS support is desired, and whether there may be interactions 
    between RPCSEC_GSS and RDDP. 
      An opinion was stated in the room - RDDP IPSec, and its use by 
    NFS/RDMA, should be mandatory to implement and optional to use. The 
    reasons were as follows: 
        1) These are new protocols - they should come out of the gate as 
    secure. NFS should not leave IPSec-secured storage to "the block guys" 
    (iSCSI :), and should be just as secure in all modes. (IPSec is 
    mandatory for iSCSI). 
        2) Things move through IETF much better when they are mandatory, 
    especially security. Ensuring that vendors must provide it, and letting the 
    user decide to use it, is better for the industry. 
        3) Security support in hardware avoids data touches in software. So an 
    IPSec enabled NFS/RDMA can achieve higher performance. 
    - Questions were asked on issues which are open on the mailing list: 
      Q: Global namespace? Is there a draft? 
      A: No, but there has been significant discussion. At 
    Connectathon, there was agreement to implement an nfsv4.0 version, and thus 
    learn what else may need to be done in future nfsv4.x. 
      Q: Is the current fs_locations good enough? 
      A: Some think yes, some no. 
      Q: Is there an effort to define the "general form of a namespace"? 
      A: Not active. (?) 
      Q: What is the status of the replication/migration effort? 
      A: At Connectathon, Rob Thurlow indicated that an update to the draft was 
    in progress. 
    - Parallel NFS (Talpey) 
      An informational presentation on a possible future NFSv4 chartered 
    effort followed - "Parallel NFS". (See presentation 
    pNFS-intro-ietf59.pdf) This is an accompaniment to 
      Parallel NFS is a product of a workshop held at CITI last December. The 
    effort is to explore NFSv4 extensions to meet scalability needs, 
    including parallelizing NFS requests, and exporting block and object 
    "layouts" to enable direct client access to storage. 
      The presentation states that the problem is that NFS clients 
    experience limited bandwidth due to the NFS protocol linkage of files to 
    servers. The goal is to distribute file and objects across multiple 
    servers in order to eliminate this bottleneck. 
      The presentation goes on to argue that the subject is highly relevant to 
    the IETF because it expands NFS's role, standardizes what is today 
    proprietary, and links NFS to other IETF efforts such as iSCSI. 
      Q: Parallel NFS enables direct access to data, is there an implicit 
    object specification? 
      A: This is the subject of future discussion, but the goal would be to 
    provide a standard and extensible specification for numerous types. 
      Q: How would the extension include all of "striped" NFS, blocks and 
      A: The intent of group is to provide "layouts" which are 
      Q: How can we achieve interoperability with all these multiple 
      A: The format of the maps would be defined by this proposal, and the 
    client would participate in the decision to use them. 
      Q: Still an interop concern, because of the many possible formats. 
      A: Yes, an important issue for the discussion going forward. 
    Ends 1405 


    pNFS: What and Why