idnits 2.17.1 draft-ietf-nfsv4-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2054' on line 646 looks like a reference -- Missing reference section? 'RFC2055' on line 654 looks like a reference -- Missing reference section? 'RFC1831' on line 622 looks like a reference -- Missing reference section? 'XDSM' on line 728 looks like a reference -- Missing reference section? 'HPFS' on line 677 looks like a reference -- Missing reference section? 'Nagar' on line 699 looks like a reference -- Missing reference section? 'DCEACL' on line 672 looks like a reference -- Missing reference section? 'RFC2025' on line 640 looks like a reference -- Missing reference section? 'RFC1094' on line 610 looks like a reference -- Missing reference section? 'RFC1813' on line 616 looks like a reference -- Missing reference section? 'RFC1832' on line 628 looks like a reference -- Missing reference section? 'RFC1833' on line 634 looks like a reference -- Missing reference section? 'RFC2078' on line 660 looks like a reference -- Missing reference section? 'RFC2203' on line 666 looks like a reference -- Missing reference section? 'Hutson' on line 681 looks like a reference -- Missing reference section? 'Kistler' on line 686 looks like a reference -- Missing reference section? 'Mummert' on line 691 looks like a reference -- Missing reference section? 'Sandberg' on line 703 looks like a reference -- Missing reference section? 'Satyanarayanan1' on line 711 looks like a reference -- Missing reference section? 'Satyanarayanan2' on line 715 looks like a reference -- Missing reference section? 'PCNFS' on line 721 looks like a reference -- Missing reference section? 'XNFS' on line 733 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Spencer Shepler 3 Internet Draft November 1998 4 Document: draft-ietf-nfsv4-requirements-03.txt 6 NFS Version 4 Requirements 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 With the creation of the NFS version 4 working group, a set of 29 requirements for the next version of NFS must be codified to create a 30 reasonable context for the new protocol discussions and aide in the 31 upcoming decisions. This Internet Draft has the purpose of 32 presenting the requirements for NFS version 4 and will be used as the 33 leading document for NFSv4 working group. 35 NFSv4 NFSv4 Requirements November 1998 37 Table of Contents 39 1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3 40 2. Ease of implementation or complexity of protocol . . . . . . 3 41 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3 42 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3 43 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4 44 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 5 45 4.1. Throughput and Latency on the Network . . . . . . . . . . 5 46 4.2. Server Work Load or Scalability . . . . . . . . . . . . . 5 47 4.3. Client Caching . . . . . . . . . . . . . . . . . . . . . . 6 48 4.4. Disconnected Client Operation . . . . . . . . . . . . . . 6 49 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7 50 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 7 51 5.2. Additional or Extended Attributes . . . . . . . . . . . . 7 52 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . . 8 53 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . . 9 54 6.1. Remote Procedure Call Mechanism . . . . . . . . . . . . . 9 55 6.2. User identification . . . . . . . . . . . . . . . . . . . 9 56 6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 10 57 6.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 10 58 6.3.2. Data Integrity . . . . . . . . . . . . . . . . . . . . 11 59 6.3.3. Data Privacy . . . . . . . . . . . . . . . . . . . . . 11 60 6.3.4. Security Mechanisms . . . . . . . . . . . . . . . . . 11 61 6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 11 62 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 12 63 7.1. Congestion Control and Transport Selection . . . . . . . 12 64 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 12 65 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 13 66 8. File locking / recovery . . . . . . . . . . . . . . . . . 13 67 9. Internationalization . . . . . . . . . . . . . . . . . . . 14 68 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 15 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 19 70 12. Author's Address . . . . . . . . . . . . . . . . . . . . 19 72 NFSv4 NFSv4 Requirements November 1998 74 1. NFS Version 4 Requirements 76 As stated in the charter, the first deliverable for the NFS version 4 77 working group is this requirements document. This document is to 78 cover the "limitations and deficiencies of NFS version 3". Therefore 79 the intent of the following sections is to identify the various 80 feature points of NFS as a distributed file system and discuss its 81 current functionality and compare to other distributed file systems 82 and offer reasonable requirements for each of these areas. 84 2. Ease of implementation or complexity of protocol 86 One of the strengths of NFS has been the ability to implement a 87 client or server with relative ease. The eventual size of a basic 88 implementation is relatively small. The main reason for keeping NFS 89 as simple as possible is that a simple protocol design can be 90 described in a simple specification that promotes straightforward, 91 interoperable implementations. All protocols can run into problems 92 when deployed on real networks, but simple protocols yield problems 93 that are easier to diagnose and correct. 95 2.1. Extensibility / layering 97 With NFS' relative simplicity, the addition or layering of 98 functionality has been easy to accomplish. The addition of features 99 like the client automount or autofs, client side disk caching and 100 high availability servers are examples. This type of extensibility 101 is desirable in an environment where problem solutions do not require 102 protocol revision. This extensibility can also be helpful in the 103 future where unforeseen problems or opportunities can be solved by 104 layering functionality on an existing set of tools or protocol. 106 2.2. Managed Extensions or Minor Versioning 108 For those cases where the NFS protocol is deficient or where a minor 109 modification is the best solution for a problem, a minor version or a 110 managed extension could be helpful. There have been instances with 111 NFS version 2 and 3 where small straightforward functional additions 112 would have increased the overall value of the protocol immensely. 113 For instance, the PATHCONF procedure that was added to version 2 of 114 the MOUNT protocol would have been more appropriate for the NFS 115 protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP 116 procedure for NFS versions 2 and 3 would have been more cleanly 118 NFSv4 NFSv4 Requirements November 1998 120 implemented in a new LOOKUP procedure. 122 However, the perceived size and burden of using a change of RPC 123 version number for the introduction of new functionality led to no or 124 slow change. It is possible that a new NFS protocol could allow for 125 the rare instance where protocol extension within the RPC version 126 number is the most prudent course and an RPC revision would be 127 unnecessary or impractical. 129 The areas of an NFS protocol which are most obviously volatile are 130 new orthogonal procedures, new well-defined file or directory 131 attributes and potentially new file types. As an example, potential 132 file types of the future could be a type such as "attribute" that 133 represents a named file stream or a "dynamic" file type that 134 generates dynamic data in response to a "query" procedure from the 135 client. 137 It is possible and highly desirable that these types of additions can 138 be done without changing the overall design model of NFS without 139 significant effort or delay. This is particularly true in adding new 140 procedures. 142 A strong consideration should be given to a NFS protocol mechanism 143 for the introduction of this type of new functionality. This is 144 obviously in contrast to using the standard RPC version mechanism to 145 provide minor changes. The process of using RPC version numbers to 146 introduce new functionality brings with it a lot of history which may 147 not technically prevent its use. However, the historical issues 148 involved will need to be addressed as part of the NFS protocol work 149 to increase the chance of current and future success of the protocol. 151 As background, the RPC protocol described in [RFC1831] uses a version 152 number to describe the set of procedure calls, replies, and their 153 semantics. Any change in this set must be reflected in a new version 154 number for the program. An example of this was the 155 MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT 156 protocol. Except for the addition of this new procedure, the 157 protocol was unchanged. Many thought this protocol revision was 158 unnecessary, since the RPC protocol already allows certain procedures 159 not be implemented and defines a PROC_UNAVAIL error. 161 3. Reliable and Available 163 Current NFS protocol design has lead to quick recovery from server 164 and client failure. This approach to the design has lent itself well 165 to layered technologies like high availability and clustered servers. 167 NFSv4 NFSv4 Requirements November 1998 169 Providing a protocol design approach that lends itself to these types 170 of reliability and availability features is very desirable. 172 For the next version of NFS, consideration should be given to client 173 side availability schemes such as client switching between or fail- 174 over to available server replicas. NFS currently requires that file 175 handles be immutable; this requirement adds unnecessarily to the 176 complexity of building fail-over configurations. If possible, the 177 protocol should allow for or ease the building of such layered 178 solutions. 180 4. Scalable Performance 182 In designing and developing an NFS protocol from a performance 183 viewpoint there are several different points to consider. Each can 184 play a significant role in perceived and real performance from the 185 user's perspective. The three main areas of interest are: throughput 186 and latency on the network, server work load or scalability and 187 client side caching. 189 4.1. Throughput and Latency on the Network 191 NFS currently has characteristics that provide good throughput for 192 the reading and writing of file data. However, the number of RPCs 193 required to accomplish some tasks combined with high latency network 194 environments leads to sluggish response. The protocol should 195 continue to provide good raw read and write throughput while 196 addressing the issue of network latency. This issue is discussed 197 further in the section on Internet Accessibility. 199 4.2. Server Work Load or Scalability 201 Current NFS operations are relatively lightweight in that the 202 processing work for most of the operations is not CPU intensive. 203 This allows for potential support of a large number of clients. This 204 attribute can also be helpful in building efficient and scalable SMP 205 or cluster based servers. While this type of protocol design 206 (lightweight operations) is desirable, it needs to be balanced 207 against the previous issue of having the client generate a large 208 number of RPCs to accomplish a straight forward task. 210 NFSv4 NFSv4 Requirements November 1998 212 4.3. Client Caching 214 In an attempt to speed response time and to reduce network and server 215 load, NFS clients have always cached directory and file data. 216 However, this has usually been done as memory cache and in relatively 217 recent history, local disk caching has been added. 219 Having the client cache directory and file data is very desirable. 220 Other distributed file systems have shown that aggressive client side 221 caching can be very visible to the end user in the form of response 222 time gains. For AFS and DCE/DFS this is accomplished by the 223 utilization of server call backs to notify the client of potential 224 cache invalidation. CIFS uses opportunistic locks to provide a 225 similar call back mechanism. These clients can cache large amounts 226 of data avoiding traffic with the server. 228 Client caching is increasingly important for Internet environments 229 where throughput can be limited and response time can grow 230 significantly. Based on these factors, the NFS protocol should allow 231 for aggressive caching while balancing the needs for simplicity and 232 Internet accessibility (i.e. firewalls). 234 If possible, the caching ability should be layered on the protocol 235 instead of embedding specific client caching functions in the 236 protocol itself. This approach will allow for clients that are 237 unable to or choose not to cache data the ability to interact with a 238 server without encumbered protocol functions that assume client 239 caching. 241 4.4. Disconnected Client Operation 243 An extension of client caching is the idea or functionality of 244 disconnected operation at the client. With the ability to cache 245 directory and file data aggressively, a client could then provide 246 service to the end user while disconnected from the server or 247 network. 249 While very desirable, disconnected operation has the opportunity to 250 inflict itself upon the NFS protocol in an undesirable way as 251 compared to traditional client caching. Given the complexities of 252 disconnected client operation and subsequent resolution of client 253 data modification through various playback or data selection 254 mechanisms, disconnected operation should not be a requirement for 255 the NFS effort. Even so, the NFS protocol should consider the 256 potential layering of disconnected operation solutions on top of the 258 NFSv4 NFSv4 Requirements November 1998 260 NFS protocol (as with other server and client solutions). The 261 experiences with Coda, disconnected AFS and others should be helpful 262 in this area. (see references) 264 5. Interoperability 266 The NFS protocols are available for many different operating 267 environments. Even though this shows the protocol's ability to 268 provide distributed file system service for more than a single 269 operating system, the design of NFS is certainly Unix centric. The 270 next NFS protocol needs to be more inclusively of platform or file 271 system features beyond those of traditional Unix. 273 5.1. Platform Specific Behavior 275 Because of its Unix centric design, some of the protocol requirements 276 have been difficult to implement in some environments. For example, 277 persistent file handles (unique identifiers of file system objects), 278 Unix uid/gid mappings, directory modification time, accurate file 279 sizes, file/directory locking semantics (SHAREs, PC-style locking). 281 5.2. Additional or Extended Attributes 283 NFS Versions 2 and 3 do not provide for file or directory attributes 284 beyond those that are found in the traditional Unix environment; for 285 example the user identifier/owner of the file, a permission or access 286 bitmap, time stamps for modification of the file or directory and 287 file size to name a few. While the current set of attributes has 288 usually been sufficient, the file system's ability to manage 289 additional information associated with a file or directory can be 290 useful. 292 There are many possibilities for additional attributes in the next 293 version of NFS. Some of these include: object creation timestamp, 294 user identifier of file's creator, timestamp of last backup or 295 archival bit, version number, file content type (MIME type), 296 existence of data management involvement (i.e. DMAPI [XDSM]). 298 This list is representative of the possibilities and are meant to 299 show the need for an additional attribute set. Enumerating the 300 'correct' set of attributes is difficult and is one of the reasons 301 for looking towards minor versioning as a way to provide needed 302 extensibility. Another way to provide some extensibility is in 303 providing support for a generalized named attribute mechanism. This 305 NFSv4 NFSv4 Requirements November 1998 307 mechanism would allow a client to name, store and retrieve arbitrary 308 data and have it associated as an attribute of a file or directory. 310 One difficulty in providing this feature is determining if the 311 protocol should specify the names for the attributes, their type or 312 structure. How will the protocol determine or allow for attributes 313 that can be read but not written is another issue. Yet another could 314 be the side effects that these attributes have on the core set of 315 file properties such as setting a size attribute to 0 and having 316 associated file data deleted. 318 As these brief examples show, this type of extended attribute 319 mechanism brings with it a large set of issues that will need to be 320 addressed in the protocol specification while keeping the overall 321 goal of simplicity in mind. 323 However, there are operating environments that provide named or 324 extended attribute mechanisms. Digital Unix provides for the storage 325 of extended attributes with some generalized format. HPFS[HPFS] and 326 NTFS [Nagar] also provide for named data associated with traditional 327 files. SGI's local file system, XFS, also provides for this type of 328 name/value extended attributes. However, there does not seem to be a 329 clear direction that can be taken from these or other environments. 331 5.3. Access Control Lists 333 Access Control Lists (ACL) can be viewed as one specific type of 334 extended attribute. This attribute is a designation of user access 335 to a file or directory. Many vendors have created ancillary 336 protocols to NFS to extend the server's ACL mechanism across the 337 network. Generally this has been done for homogeneous operating 338 environments. Even though the server still interprets the ACL and has 339 final control over access to a file system object, the client is able 340 to manipulate the ACL via these additional protocols. Other 341 distributed file systems have also provided ACL support. DFS, AFS 342 and CIFS to name a few. 344 The basic factor driving the requirement for ACL support in all of 345 these file systems has been the user's desire to grant and restrict 346 access to file system data on a per user basis. Based on the desire 347 of the user and current distributed file system support, it seems to 348 be a requirement that NFS provide this capability as well. 350 Because many local and distributed file system ACL implementations 351 have been done without a common architecture, the major issue is one 352 of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and 353 Windows NT ACLs have a similar structure in an array of Access 355 NFSv4 NFSv4 Requirements November 1998 357 Control Entries consisting of a type field, identity, and permission 358 bits, the similarity ends there. Each model defines its own variants 359 of entry types, identifies users and groups differently, provides 360 different kinds of permission bits, and describe different procedures 361 for ACL creation, defaults, and evaluation. 363 In the least it will be problematic to create a workable ACL 364 mechanism that will encompass a reasonable set of functionality for 365 all operating environments. Even with the complicated nature of ACL 366 support it is still worthwhile to work towards a solution that can at 367 least provide basic functionality for the user. 369 6. RPC Mechanism and Security 371 NFS relies on the underlying security mechanisms provided by the 372 ONCRPC protocol. Until the introduction of the ONCRPC RPCSEC_GSS 373 security flavor, NFS security was generally limited to none 374 (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not 375 successful in providing readily available security for NFS because of 376 a lack of implementation and deployment. Also the Diffie-Hellman 192 377 bit public keys modulos used for the AUTH_DH security flavor quickly 378 became too small for reasonable security. 380 6.1. Remote Procedure Call Mechanism 382 The ONCRPC protocol provides the basic NFS foundation for the 383 following reasons: 385 o Open protocol definition managed by IETF 387 o Transport independent (i.e. UDP and TCP supported) 389 o Simple data representation and procedure encoding models 391 o Various security mechanisms available through use of RPCSEC_GSS 393 6.2. User identification 395 NFS has been limited to the use of the Unix centric user 396 identification mechanism of numeric user id based on the available 397 file system attributes and the use of the ONCRPC. However, for NFS 398 to move beyond the limits of large work groups, user identification 400 NFSv4 NFSv4 Requirements November 1998 402 should be string based and the definition of the user identifier 403 should allow for integration into an external naming service or 404 services. 406 Internet scaling should also be considered for this as well. The 407 identification mechanism should take into account multiple naming 408 domains and other extremes that can be presented by use outside of 409 the work group. 411 If NFS is to move among various naming and security services, it may 412 be necessary to stay with a string based identification. This would 413 allow for servers and clients to translate between the external 414 string representation to a local or internal numeric (or other 415 identifier) which matches internal implementation needs. 417 DFS uses a string based naming scheme but translates the name to a 418 UUID (16 byte identifier) that is used for internal protocol 419 representations. The DCE/DFS string name is a combination of cell 420 (administrative domain) and user name. As mentioned, NFS clients and 421 servers map a Unix user name to a 32 bit user identifier that is then 422 used for ONCRPC and NFS protocol fields requiring the user 423 identifier. 425 6.3. Security 427 As a result of a lack of implementation and deployment and relatively 428 weak protection, authentication has been a major issue for ONCRPC and 429 hence NFS. With the introduction of the RPCSEC_GSS security flavor, 430 ONCRPC can provide for reasonable authentication along with integrity 431 and privacy, if desired. The RPCSEC_GSS framework will allow the use 432 of both public and private key mechanisms. Therefore, NFS as a user 433 of ONCRPC should state its specific requirements for each of these 434 areas. 436 In comparison, AFS and DFS provide strong authentication mechanisms. 437 CIFS does provide authentication at initial server contact and a 438 message signing option for subsequent interaction. 440 6.3.1. Authentication 442 Strong authentication is a requirement for NFS and the logical 443 solution for this is in the use of ONCRPC and RPCSEC_GSS. This 444 solution will allow for both private and public key mechanisms to be 445 employed if required. This flexibility will allow for security 447 NFSv4 NFSv4 Requirements November 1998 449 usability in varying environments. 451 6.3.2. Data Integrity 453 Since file and directory data is the essence of distributed file 454 service, the NFS protocol should provide to the users of the file 455 service a reasonable level of data integrity. The RPCSEC_GSS 456 mechanisms chosen to protect NFS data should use a cryptographically 457 strong checksum. 459 6.3.3. Data Privacy 461 Data privacy, while desirable, is not as important in all 462 environments as authentication and integrity. For example, in a LAN 463 environment the performance overhead of data privacy may not be 464 required to meet an organization's data protection policies. It may 465 also be the case that the performance of the distributed file system 466 solution is more important than the data privacy of that solution. 467 Therefore, data privacy should be an available option within NFS but 468 not a requirement. 470 6.3.4. Security Mechanisms 472 With the use of the RPCSEC_GSS framework, both public and private 473 mechanisms can and should be provided by NFS. The choice from both 474 public and private key mechanisms will allow for the appropriate 475 choice being made by the user based on factors within their 476 environment. 478 Potential choices for the private key mechanism would be Kerberos V5 479 and for the public key choice, SPKM [RFC2025] is available. 481 6.3.5. Security Negotiation 483 With both private and public key mechanisms available to the end 484 user, the NFS server and client will need a method to negotiate 485 appropriate usage based on availability and policy. This negotiation 486 should account for authentication, integrity, and privacy so that 487 administrators and users can employ the appropriate security policies 488 for their environments. 490 NFSv4 NFSv4 Requirements November 1998 492 7. Internet Accessibility 494 Being a product of an IETF working group, the NFS protocol should not 495 only be built upon IETF technologies where possible but should also 496 work well within the broader Internet environment. 498 7.1. Congestion Control and Transport Selection 500 As with any network protocol, congestion control is a major issue and 501 the transport mechanisms that are chosen for NFS should take this 502 into account. Traditionally implementations of NFS have been 503 deployed using both UDP and TCP. With the use of UDP, most 504 implementations provide a rudimentary attempt of congestion control 505 with simple back-off algorithms and round trip timers. While this 506 may be sufficient in today's NFS deployments, as an Internet protocol 507 NFS will need to ensure sufficient congestion control or management. 509 With congestion control in mind, NFS must use TCP as a transport (via 510 ONCRPC). The UDP transport provides its own advantages in certain 511 circumstances. In today's NFS implementations, UDP has been shown to 512 produce greater throughput as compared to similarly configured 513 systems that use TCP. If UDP is to be supplied as an NFS transport 514 mechanism, then the issues of congestion control must be dealt with. 516 7.2. Firewalls and Proxy Servers 518 NFS's protocol design should allow its use via Internet firewalls. 519 The protocol should also allow for the use of file system proxy/cache 520 servers. Proxy servers can be very useful for scalability and other 521 reasons. The NFS protocol needs to address the need of proxy servers 522 in a way that will deal with the issues of security, access control, 523 and content control. It is possible that these issues can be 524 addressed by documenting the related issues of proxy server usage. 525 However, it is likely that the NFS protocol will need to support 526 proxy servers directly through the NFS protocol. 528 The protocol could allow a request to be sent to a proxy that 529 contains the name of the target NFS server to which the request might 530 be forwarded, or from which a response might be cached. In any case, 531 the NFS proxy server should be considered during protocol 532 development. 534 NFSv4 NFSv4 Requirements November 1998 536 7.3. Multiple RPCs and Latency 538 As an application at the NFS client performs simple file system 539 operations, multiple NFS operations or RPCs may be executed to 540 accomplish the work for the application. While the NFS version 3 541 protocol addressed some of this by returning file and directory 542 attributes for most procedures hence reducing follow up GETATTR 543 requests, there is still room for improvement. Reducing the number 544 of RPCs can lead to a reduction of processing overhead on the server 545 (transport and security processing) along with reducing the time 546 spent at the client waiting for the server's individual responses. 547 This issue is more prominent in environments with larger degrees of 548 latency. 550 The CIFS file access protocol supports 'batched requests' that allow 551 multiple requests to be batched and therefore reducing the number of 552 round trip messages between client and server. 554 This same approach can be used by NFS to allow the grouping of 555 multiple procedure calls together in a traditional RPC request. Not 556 only would this allow for the reduction in protocol imposed latency 557 but would reduce transport and security processing overhead and could 558 allow a client to complete more complex tasks by combining 559 procedures. 561 8. File locking / recovery 563 NFS has provided Unix file locking and DOS SHARE capability with the 564 use of an ancillary protocol (Network Lock Manager / NLM). The DOS 565 SHARE mechanism is the DOS equivalent of file locking in that it 566 provides the basis for the sharing or exclusive access to file and 567 directory data without risk of data corruption. The NLM protocol 568 provides for file locking and recovery of those locks in the event of 569 client or server failure. NLM requires that the server make call 570 backs to the client for certain scenarios and therefore is not 571 necessarily well suited for Internet firewall traversal. 573 Desirable features of file locking support are: 575 o Integration with the NFS protocol. 577 o Interoperability between operating environments. The protocol 578 should make a reasonable effort to support the locking semantics 579 of both PC and Unix clients and servers. 581 o Scalable solutions - thousands of clients. The server should 583 NFSv4 NFSv4 Requirements November 1998 585 not be required to maintain client lock state across reboots. 587 o Internet capable (firewall traversal, latency sensitive). The 588 server should not be required to initiate TCP connections to 589 clients. 591 o Timely recovery in the event of client/server or network 592 failure. Server recovery should be rapid. The protocol should 593 allow clients to detect the loss of a lock. 595 CIFS supports file locking and DOS SHARE support. 597 9. Internationalization 599 The current NFS protocols are limited in their support of anything 600 more than 7-bit ASCII strings. It is imperative that NFS support a 601 range of character sets. This can be provided by requiring support 602 for Unicode with a UTF-8 wire encoding. Therefore, all strings 603 defined as part of the NFS protocol will need to be defined as UTF-8 604 and the appropriate XDR encoding used. 606 NFSv4 NFSv4 Requirements November 1998 608 10. Bibliography 610 [RFC1094] 611 Sun Microsystems, Inc., "NFS: Network File System Protocol 612 Specification", RFC1094, March 1989. 614 ftp://ftp.isi.edu/in-notes/rfc1094.txt 616 [RFC1813] 617 Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol 618 Specification", RFC1813, Sun Microsystems, Inc., June 1995. 620 ftp://ftp.isi.edu/in-notes/rfc1813.txt 622 [RFC1831] 623 Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification 624 Version 2", RFC1831, Sun Microsystems, Inc., August 1995. 626 ftp://ftp.isi.edu/in-notes/rfc1831.txt 628 [RFC1832] 629 Srinivasan, R., "XDR: External Data Representation Standard", 630 RFC1832, Sun Microsystems, Inc., August 1995. 632 ftp://ftp.isi.edu/in-notes/rfc1832.txt 634 [RFC1833] 635 Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, 636 Sun Microsystems, Inc., August 1995. 638 ftp://ftp.isi.edu/in-notes/rfc1833.txt 640 [RFC2025] 641 Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, 642 Bell-Northern Research, October 1996. 644 ftp://ftp.isi.edu/in-notes/rfc2025.txt 646 [RFC2054] 647 Callaghan, B., "WebNFS Client Specification", RFC2054, Sun 648 Microsystems, Inc., October 1996 650 NFSv4 NFSv4 Requirements November 1998 652 ftp://ftp.isi.edu/in-notes/rfc2054.txt 654 [RFC2055] 655 Callaghan, B., "WebNFS Server Specification", RFC2055, Sun 656 Microsystems, Inc., October 1996 658 ftp://ftp.isi.edu/in-notes/rfc2055.txt 660 [RFC2078] 661 Linn, J., "Generic Security Service Application Program Interface, 662 Version 2", RFC2078, OpenVision Technologies, January 1997. 664 ftp://ftp.isi.edu/in-notes/rfc2078.txt 666 [RFC2203] 667 Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification" 668 RFC2203, Sun Microsystems, Inc., August 1995. 670 ftp://ftp.isi.edu/in-notes/rfc2203.txt 672 [DCEACL] 673 The Open Group, Open Group Technical Standard, "DCE 1.1: 674 Authentication and Security Services," Document Number C311, August 675 1997. Provides a discussion of DEC ACL structure and semantics. 677 [HPFS] 678 Les Bell and Associates Pty Ltd, "The HPFS FAQ," 679 http://www.lesbell.com.au/hpfsfaq.html 681 [Hutson] 682 Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June 683 1993. Proc. USENIX Symp. on Mobile and Location-Independent 684 Computing, Cambridge, August 1993. 686 [Kistler] 687 Kistler, James J., Satyanarayanan, M., "Disconnected Operations in 688 the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. 689 1, pp. 3-25, Feb. 1992. 691 [Mummert] 693 NFSv4 NFSv4 Requirements November 1998 695 Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak 696 Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on 697 Operating Systems Principles Dec. 1995. 699 [Nagar] 700 Nagar, R., "Windows NT File System Internals," ISBN 1565922492, 701 O`Reilly & Associates, Inc. 703 [Sandberg] 704 Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design 705 and Implementation of the Sun Network Filesystem," USENIX Conference 706 Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The 707 basic paper describing the SunOS implementation of the NFS version 2 708 protocol, and discusses the goals, protocol specification and trade- 709 offs. 711 [Satyanarayanan1] 712 Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," 713 Proc. of the ACM Principles of Distributed Computing, 1995. 715 [Satyanarayanan2] 716 Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R., 717 Kumar, P. , Lu, Q., "Experience with disconnected operation in 718 mobile computing environment," Proc. of the USENIX Symp. on Mobile 719 and Location-Independent Computing, Jun. 1993. 721 [PCNFS] 722 The Open Group, Open Group Developers' Specification "Protocols for 723 X/Open PC Interworking: (PC)NFS," ISBN 1-872630-00-6, August 1990. 724 This is an indispensable reference for NFS version 2 protocol and 725 accompanying protocols, including the Lock Manager and the 726 Portmapper. 728 [XDSM] 729 The Open Group, Open Group Technical Standard, "Systems Management: 730 Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January 731 1997. 733 [XNFS] 734 The Open Group, Open Group Technical Standard, "Protocols for 735 Interworking: XNFS, Version 3W," ISBN 1-85912-184-5, February 1998. 737 NFSv4 NFSv4 Requirements November 1998 739 This is an indispensable reference for NFS version 2 protocol and 740 accompanying protocols, including the Lock Manager and the 741 Portmapper. 743 NFSv4 NFSv4 Requirements November 1998 745 11. Acknowledgments 747 o Brent Callaghan for content contributions. 749 12. Author's Address 751 Address comments related to this memorandum to: 753 spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com 755 Spencer Shepler 756 Sun Microsystems, Inc. 757 7808 Moonflower Drive 758 Austin, Texas 78750 760 Phone: (512) 349-9376 761 E-mail: spencer.shepler@eng.sun.com