The NFS Version 4 Protocol

5,574 views

Published on

The Network File System (NFS) Version 4 is a distributed file system similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network.
NFS, was developed by Sun Microsystems to provide distributed transparent file access in a heterogeneous network. It achieves this by being relatively simple in design and not relying too heavily on any particular file system model.
This presentation is based on the paper of “The NFS Version 4 Protocol” written by Brian Pawlowski, Spencer Shepler, Carl Beame, Brent Callaghan, Michael Eisler, David Noveck, David Robinson and Robert Thurlow.

Published in: Education, Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,574
On SlideShare
0
From Embeds
0
Number of Embeds
154
Actions
Shares
0
Downloads
192
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

The NFS Version 4 Protocol

  1. 1. The NFS Version 4 Protocol By :- Kelum Senanayake[Based on the paper of “The NFS Version 4 Protocol”, Brian Pawlowski,Spencer Shepler, Carl Beame, Brent Callaghan, Michael Eisler,David Noveck, David Robinson, Robert Thurlow]
  2. 2. What is NFS 4 The Network File System (more commonly known as NFS) is a distributed file system that may be accessed via a network connection. NFS Version 4 is similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network. NFS, was developed by Sun Microsystems together with Internet Engineering Task Force (IETF). IETF develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies.
  3. 3. The IETF process and NFS1998 Sun/IETF Agreement BOF, working group forms Strawman Proposal from Sun Meetings, writing, e-mail1999 Prototyping by 5 organizations Working Group Draft Additional prototyping Six working group drafts Working Group Last Call2000 IETF Last Call IESG Review Assign RFC number2001 Proposed Standard RFC 30102002 Proposed Standard RFC 3530 Two independent implementations 6+ months Draft Standard Internet Standard apotheosis
  4. 4. Requirements for NFS Version 4 Improved access and good performance on the Internet Strong security, with security negotiation built into the protocol Enhanced cross-platform interoperability Extensibility of the protocol Improvements in locking and performance for narrow data sharing applications
  5. 5. Overview The NFS Version 4 protocol is stateful. NFS is built on top of the ONC Remote Procedure Protocol. Also uses XDR. ◦ The External Data Representation (XDR) enables heterogeneous operation by defining a canonical data encoding over the wire.
  6. 6. Basic NFS Architecture XDR Protocol RPC Protocol
  7. 7. Structural Changes Elimination of ancillary protocols. ◦ Mount protocol, Network Lock Manager protocol. ◦ NFS 4 is a single protocol that uses a well-defined port with the use of initialized filehandles and fully integrated Locking in to the protocol. The introduction of a COMPOUND RPC procedure ◦ Allows the client to group traditional file operations into a single request to send to the server. ◦ Reduce network round trip latency for related operations, which can be costly over a WAN NFS 3 was designed to be easy to implement given an NFS 2 implementation. NFS 4 did not have that requirement.
  8. 8. Structural Changes… contd Introduction of the stateful operations OPEN and CLOSE The regular file CREATE procedure is replaced by the OPEN operation (with a create bit set) in NFS 4. ◦ The CREATE operation in NFS 4 is used only to create special file objects such as symbolic links, directories, and special device nodes. ◦ CREATE and REMOVE in NFS Version 4 subsumes the MKDIR and RMDIR directory functionality of prior versions of NFS. A LOOKUP is very simple. ◦ Only sets the current filehandle to point at the file object resolved. ◦ Attributes can be obtained with a subsequent GETATTR operation in the same COMPOUND procedure.
  9. 9. Structural Changes… contd Does not assign special semantics to the directory entries “.” and “..” ◦ Client should explicitly use the LOOKUPP operation. The NFS 3 directory scanning operation READDIRPLUS procedure was dropped. ◦ Now supported by the READDIR operation.
  10. 10. NFS Protocol Stack NFSv4 (RFC3530) KerberosV5 (RFC1510) SPKM-3 LIPKEY (RFC2847) RPC (RFC1831) RPCSEC_GSS (RFC2203) XDR (RFC1832) TCP*
  11. 11. File system model A file system is an implementation of a single file name space containing files, and provides the basis for administration and space allocation. file system identifier, or fsid, which is a 128-bit per-server unique identifier. A file is a single named object consisting of data and attributes, residing in a file system. A regular file is a simple byte stream – not a directory, symbolic link or special (device) file. A filehandle uniquely identifies a file on a server.
  12. 12. Exporting file systems The export operation makes available only those file systems, or portions of file systems, desired to be shared with clients. In all versions of NFS, a server contains one or more file systems that are exported to clients. In NFS 4, a server presents a single seamless view of all the exported file systems to a client. The client can notice file system transitions on the server by observing that the fsid changes. The name space describes the set of available files arranged in a hierarchy.
  13. 13. Pseudo-file systems Server Local FS Pseudo FS / / A C A B C D F D E F I G H I
  14. 14. The COMPOUND procedure RPC call defines a single request-response transaction between the client and server. But client may actually be required to transmit a series of related requests. The COMPOUND procedure groups multiple related operations into a single RPC packet. The RPC response to a COMPOUND procedure contains the replies to all the operations. Evaluation of the operations stops on first error. It may be unwise to attempt grouping unrelated operations into a single COMPOUND procedure.
  15. 15. Properties of the COMPOUND procedure The set of operations in a COMPOUND procedure is not atomic. Error handling is simple on the server. Most operations do not explicitly have a filehandle as an argument or result. ◦ The server maintains a single filehandle, the current filehandle, as the argument.
  16. 16. Communication Compound procedures NFS v3 NFS v4
  17. 17. Important data structures Filehandles Client ID State ID
  18. 18. Filehandles A filehandle, is a per server unique identifier for a file system object. Filehandles that are equal refer to the same file system object. ◦ But no assumptions can be made by the client if the filehandles differ. The current filehandle is used by subsequent operations in a single COMPOUND procedure. ◦ GETFH operation to fetch the current filehandle.
  19. 19. Client ID A client first contacts the server using the SETCLIENTID operation with a verifier. A verifier is a unique, non-repeating 64-bit object. ◦ Generated by the client. The server will return a 64-bit clientid. ◦ The clientid is unique. ◦ Will not conflict with those previously granted. ◦ Even across server reboots. The clientid is used in client recovery of locking state following a server reboot. After a client reboot, the client will need to get a new clientid
  20. 20. State ID A stateid is a unique 64-bit object that defines the locking state of a specific file. Client requests a lock with clientID and a unique-per- client lock owner identification. Server returns a unique 64-bit object, the stateid. Client uses this in subsequent operations as a shorthand notation to the lock owner information.
  21. 21. Locking NFS 4 locking is similar to the Network Lock Manager (NLM) protocol. NLM is used with NFS Versions 2 and 3. Locking is tightly coupled to the NFS 4 protocol. ◦ Better support different operating system semantics and error recovery.
  22. 22. Drawbacks of NLM A major failing was the detection and recovery of error conditions. The design assumed that the underlying transport was reliable and preserved order. But an unreliable network easily resulted in orphan locks on the server. If a client crashed and never recovered, ◦ Locks could be permanently abandoned ◦ Prevents any other client from ever acquiring the lock.
  23. 23. Leases The key change in NFS 4 locking is the introduction of leases for lock management. A lease is a time-bounded grant of control of the state of a file, through a lock, from the server to the client. A lock granted by the server will remain valid for a fixed interval. ◦ Time interval can be renewal by the client. Client is responsible for contacting the server to refresh the lease to maintain the lock. ◦ Client failure vs Server failure. A client exists in two states: either all the locks held from a given server are correct or all are lost. ◦ Eliminates another drawback of a lease-based protocol
  24. 24. Mandatory locking & Share reservations Mandatory locking - the ability to block I/O operations by other applications on a file that contains a lock. Share reservation - grants a client access to open a file and the ability to deny other clients open access to the same file.
  25. 25. Sequence IDs The most problematic part of network locking is dealing with lock requests that arrive out of order or are replayed. NFS 4 adds to every lock and unlock operation a monotonically increasing sequence number. Server maintains for each lock owner the last sequence number and the response sent. ◦ Earlier sequence number. ◦ Last sequence number. ◦ Sequence number beyond the next sequence number.
  26. 26. Security Model NFS relies on the underlying security model of RPC for its security services. In the area of security, NFS Version 4 improves over NFS Versions 2 and 3 by ◦ Mandating the use of strong RPC security flavors that depend on cryptography. ◦ Negotiating the security used via a system that is both secure and in-band. ◦ Using character strings instead of integers to represent user and group identifiers. ◦ Supporting access control that is compatible with UNIX and Windows. ◦ Removing the Mount protocol.
  27. 27. GSS-API framework Generic Security Services API ◦ Several security flavors NFS is based on RPC and a security flavor based GSS- API called RPCSEC_GSS. RPCSEC_GSS differs from other traditional flavors in two ways ◦ RPCSEC_GSS does more than authentication such as performing integrity checksums and encryption of the entire body of the RPC request and response. ◦ RPCSEC_GSS simply encapsulates the GSS-API messaging tokens – Adding new security mechanisms (as long as they conform to GSS-API) does not require significant re-writing.
  28. 28. Mandated strong security All versions of NFS are capable of using RPCSEC_GSS. NFS 4 implementations must implement security based on Kerberos Version 5 and LIPKEY
  29. 29. Kerberos versus LIPKEY Kerberos has been used on other distributed file systems. ◦ Andrew File System ◦ Open Software Foundations Distributed File System ◦ Microsofts CIFS Kerberos is an excellent choice for enterprises and work groups operating within an Intranet. ◦ Provides centralized control. ◦ Single sign on to the network. Kerberos does not work well on the Internet.
  30. 30. Kerberos versus LIPKEY… contd NFS Version 4 is also designed to work outside of intranets on the global Internet. LIPKEY - Low Infrastructure Public Key LIPKEY uses a symmetric key cipher and server-side public key certificates. The LIPKEY system provides an SSL-like model and equivalent security for use on the Internet. The LIPKEY user experience is similar to that of HTTP over the Secure Sockets Layer (SSL).
  31. 31. Why not SSL? NFS Version 4 does not use SSL. SSL does not work over connectionless protocols like UDP. RPC has its own security architecture ◦ It is unclear how to cleanly merge SSL and RPC security.
  32. 32. NFS v4 Secure RPC
  33. 33. Migration and replication NFS Version 4 has added features to support file system migration and replication. A file system can migrate to a new server. ◦ Clients are notified of the change by means of a special error code. A client is informed of the new location by means of the fs_locations file attribute.
  34. 34. Modifications for use on the Internet Requiring TCP as a transport. Defining COMPOUND operation to reduce roundtrip latency Defining a global user identifier name space Mandating strong security based on a public key scheme Enabling operation through firewalls
  35. 35. Firewall friendly Port 111PORTMAP } Dynamic MOUNT Port 2049 Port 2049 NFSv2/v3 Dynamic NFSv4LOCK/NLM TCP Dynamic STATUS Dynamic ACL*
  36. 36. Future Works Enhanced “Sessions” based NFS (correctness) CCM - session-based security for IPsec Migration/replication completion ◦ Core protocol defines client/server failover behaviour ◦ Definition of the server-server file system movement ◦ Transparent reconfiguration from client viewpoint Proxy NFS file services (NFS caches) Uniform global name space ◦ Features exist in the core protocol to support this Support for multi-realm security
  37. 37. Reference [1] B. Pawlowski, S. Shepler, C. Beame, B. Callaghan, M. Eisler, D. Noveck, D. Robinson, and R. Thurlow. “The NFS Version 4 Protocol”. In Proceedings of the 2nd International System Administration and Networking Conference (SANE2000), page94, Maastricht, The Netherlands, May 2000.

×