draft-ietf-nfsv4-federated-fs-reqts-04.txt | draft-ietf-nfsv4-federated-fs-reqts-05.txt | |||
---|---|---|---|---|
NFSv4 Working Group J. Lentini | NFSv4 Working Group J. Lentini | |||
Internet-Draft C. Everhart | Internet-Draft C. Everhart | |||
Intended status: Informational NetApp | Intended status: Informational NetApp | |||
Expires: April 4, 2010 D. Ellard | Expires: April 19, 2010 D. Ellard | |||
BBN Technologies | BBN Technologies | |||
R. Tewari | R. Tewari | |||
M. Naik | M. Naik | |||
IBM Almaden | IBM Almaden | |||
October 1, 2009 | October 16, 2009 | |||
Requirements for Federated File Systems | Requirements for Federated File Systems | |||
draft-ietf-nfsv4-federated-fs-reqts-04 | draft-ietf-nfsv4-federated-fs-reqts-05 | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. This document may contain material | |||
from IETF Documents or IETF Contributions published or made publicly | from IETF Documents or IETF Contributions published or made publicly | |||
available before November 10, 2008. The person(s) controlling the | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | copyright in some of this material may not have granted the IETF | |||
Trust the right to allow modifications of such material outside the | Trust the right to allow modifications of such material outside the | |||
IETF Standards Process. Without obtaining an adequate license from | IETF Standards Process. Without obtaining an adequate license from | |||
skipping to change at page 1, line 47 | skipping to change at page 1, line 47 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 4, 2010. | This Internet-Draft will expire on April 19, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. | and restrictions with respect to this document. | |||
skipping to change at page 4, line 36 | skipping to change at page 4, line 36 | |||
3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 | 3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 | |||
4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 | 5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 | |||
5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 | 5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 | |||
5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26 | 6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
9.2. Informational References . . . . . . . . . . . . . . . . . 29 | 9.2. Informational References . . . . . . . . . . . . . . . . . 30 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
1. Overview | 1. Overview | |||
This document describes and lists the functional requirements of a | This document describes and lists the functional requirements of a | |||
federated file system and defines related terms. | federated file system and defines related terms. | |||
We do not describe the mechanisms that might be used to implement | We do not describe the mechanisms that might be used to implement | |||
this functionality except in cases where specific mechanisms, in our | this functionality except in cases where specific mechanisms, in our | |||
opinion, follow inevitably from the requirements. Our focus is on | opinion, follow inevitably from the requirements. Our focus is on | |||
the interfaces between the entities of the system, not on the | the interfaces between the entities of the system, not on the | |||
skipping to change at page 5, line 39 | skipping to change at page 5, line 39 | |||
called an "FSN" (fileset name), and each physical filesystem has a | called an "FSN" (fileset name), and each physical filesystem has a | |||
fileset location ("FSL"). A fileset is a directory tree containing | fileset location ("FSL"). A fileset is a directory tree containing | |||
files and directories, and it may also contain references to other | files and directories, and it may also contain references to other | |||
filesets. These references are called "junctions". To provide | filesets. These references are called "junctions". To provide | |||
location independence, a junction does not contain information about | location independence, a junction does not contain information about | |||
the location of the real resource(s), but instead contains an FSN | the location of the real resource(s), but instead contains an FSN | |||
that can be used to look up the location information. The service | that can be used to look up the location information. The service | |||
that can be used to map from FSN to FSL(s) is called a namespace | that can be used to map from FSN to FSL(s) is called a namespace | |||
database (NSDB) service. The NSDB provides a level of indirection | database (NSDB) service. The NSDB provides a level of indirection | |||
from the virtual paths in the uniform namespace to the actual | from the virtual paths in the uniform namespace to the actual | |||
locations of files. | locations of files. By design, the NSDB does not store the | |||
junctions. This allows junction administration and NSDB | ||||
administration to be separate roles. | ||||
The servers direct clients to the proper locations by existing | The servers direct clients to the proper locations by existing | |||
mechanisms (e.g. the referrals mechanism within [RFC3530] and | mechanisms (e.g. the referrals mechanism within [RFC3530] and | |||
[NFSv4.1]). Updates to the locations make it possible to support | [NFSv4.1]). Updates to the locations make it possible to support | |||
migration and replication of physical filesystems that comprise the | migration and replication of physical filesystems that comprise the | |||
namespace, in a way that is transparent to filesystem applications. | namespace, in a way that is transparent to filesystem applications. | |||
Figure 1 shows an example of a federation. This federation has two | Figure 1 shows an example of a federation. This federation has two | |||
members, named ALPHA and BETA. Federation members may contain an | members, named ALPHA and BETA. Federation members may contain an | |||
arbitrary number of file servers and NSDB nodes; in this illustration | arbitrary number of file servers and NSDB nodes; in this illustration | |||
skipping to change at page 14, line 19 | skipping to change at page 14, line 19 | |||
same. | same. | |||
Junction: A filesystem object used to link a directory name in the | Junction: A filesystem object used to link a directory name in the | |||
current fileset with an object within another fileset. The | current fileset with an object within another fileset. The | |||
server-side "link" from a leaf node in one fileset to the root of | server-side "link" from a leaf node in one fileset to the root of | |||
another fileset. | another fileset. | |||
Namespace: A filename/directory tree that a sufficiently-authorized | Namespace: A filename/directory tree that a sufficiently-authorized | |||
client can observe. | client can observe. | |||
NSDB (Namespace Database Service): A service that maps FSNs to FSLs. | NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. | |||
The NSDB may also be used to store other information, such as | The NSDB may also be used to store other information, such as | |||
annotations for these mappings and their components. | annotations for these mappings and their components. | |||
NSDB Node: The name or location of a server that implements part of | NSDB Node: The name or location of a server that implements part of | |||
the NSDB service and is responsible for keeping track of the FSLs | the NSDB service and is responsible for keeping track of the FSLs | |||
(and related info) that implement a given partition of the FSNs. | (and related info) that implement a given partition of the FSNs. | |||
Referral: A server response to a client access that directs the | Referral: A server response to a client access that directs the | |||
client to evaluate the current object as a reference to an object | client to evaluate the current object as a reference to an object | |||
at a different location (specified by an FSL) in another fileset, | at a different location (specified by an FSL) in another fileset, | |||
skipping to change at page 19, line 32 | skipping to change at page 19, line 32 | |||
to FSL(s) change under these transformations. | to FSL(s) change under these transformations. | |||
d. All files accessible from the global namespace MUST be part | d. All files accessible from the global namespace MUST be part | |||
of a fileset that has an assigned FSN. | of a fileset that has an assigned FSN. | |||
Not all filesets in the federation are required to have an FSN | Not all filesets in the federation are required to have an FSN | |||
or be reachable by an FSL. Only those filesets that are the | or be reachable by an FSL. Only those filesets that are the | |||
target of a junction (as described in R3) are required to have | target of a junction (as described in R3) are required to have | |||
an FSN. | an FSN. | |||
The FSN format MAY be variable size. If the format is variable | ||||
size, fileserver implementations MAY have a maximum supported | ||||
FSN size. By bounding the FSN size, some fileserver | ||||
implementations might be able to efficiently organize FSNs in | ||||
stable storage. For interoperability, the federation protocols | ||||
SHOULD define an FSN size that all fileservers support. | ||||
R2: USING THE FEDERATION INTERFACES, it MUST be possible to create | R2: USING THE FEDERATION INTERFACES, it MUST be possible to create | |||
an FSN for a fileset, and it must be possible to bind an FSL to | an FSN for a fileset, and it must be possible to bind an FSL to | |||
that FSN. These operations are NSDB operations and do not | that FSN. These operations are NSDB operations and do not | |||
require any action on the part of a file server. | require any action on the part of a file server. | |||
It is possible to create an FSN for a fileset that has not | It is possible to create an FSN for a fileset that has not | |||
actually been created. It is also possible to bind a | actually been created. It is also possible to bind a | |||
nonexistent FSL to an FSN. It is also possible to create a | nonexistent FSL to an FSN. It is also possible to create a | |||
fileset without assigning it an FSN. The binding between an | fileset without assigning it an FSN. The binding between an | |||
FSN and an FSL is defined entirely within the context of the | FSN and an FSL is defined entirely within the context of the | |||
skipping to change at page 28, line 5 | skipping to change at page 27, line 32 | |||
Well-established techniques for providing authenticated channels may | Well-established techniques for providing authenticated channels may | |||
be used to defeat these attacks, and the protocol MUST support at | be used to defeat these attacks, and the protocol MUST support at | |||
least one of them. | least one of them. | |||
For example, if LDAP is used to implement the query mechanism | For example, if LDAP is used to implement the query mechanism | |||
[RFC4510], then TLS may be used to provide both authentication and | [RFC4510], then TLS may be used to provide both authentication and | |||
integrity [RFC5246] [RFC4513]. If the query protocol is implemented | integrity [RFC5246] [RFC4513]. If the query protocol is implemented | |||
on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role | on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role | |||
[RFC2203] [RFC2743]. | [RFC2203] [RFC2743]. | |||
A federation could contain multiple Public Key Infrastructure (PKI) | ||||
trust anchors [RFC5280]. The federation protocols SHOULD define a | ||||
mechanism for managing a fileserver's NSDB trust anchors | ||||
[TA-MGMT-REQS]. A general purpose trust anchor management protocol | ||||
[TAMP] would be appropriate, though it might be desirable for the | ||||
federation protocols to facilitate trust anchor management by, for | ||||
example, using trust anchor interchange formats [TA-FORMAT]. | ||||
It is useful to note that the requirements described in this document | ||||
lead naturally to a system with distributed authorization, which has | ||||
scalability and manageability benefits. | ||||
FSNs are likely to be long lived resources. Therefore, the privilege | ||||
to create FSNs SHOULD be carefully controlled. To assist in | ||||
determining if an FSN is referenced by a junction somewhere in the | ||||
federation, the NSDB records SHOULD include non-authoritative | ||||
informational annotations recording the locations of any such | ||||
junctions. These annotations are non-authoritative because a | ||||
junction might be created, deleted, or modified by an individual that | ||||
does not have permission to modify the NSDB records. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 | [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 | |||
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work | Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work | |||
skipping to change at page 29, line 45 | skipping to change at page 29, line 45 | |||
(LDAP): Technical Specification Road Map", RFC 4510, | (LDAP): Technical Specification Road Map", RFC 4510, | |||
June 2006. | June 2006. | |||
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol | [RFC4513] Harrison, R., "Lightweight Directory Access Protocol | |||
(LDAP): Authentication Methods and Security Mechanisms", | (LDAP): Authentication Methods and Security Mechanisms", | |||
RFC 4513, June 2006. | RFC 4513, June 2006. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | ||||
Housley, R., and W. Polk, "Internet X.509 Public Key | ||||
Infrastructure Certificate and Certificate Revocation List | ||||
(CRL) Profile", RFC 5280, May 2008. | ||||
9.2. Informational References | 9.2. Informational References | |||
[RFC1094] Nowicki, B., "NFS: Network File System Protocol | [RFC1094] Nowicki, B., "NFS: Network File System Protocol | |||
specification", RFC 1094, March 1989. | specification", RFC 1094, March 1989. | |||
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS | [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS | |||
Version 3 Protocol Specification", RFC 1813, June 1995. | Version 3 Protocol Specification", RFC 1813, June 1995. | |||
[TA-FORMAT] | ||||
Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor | ||||
Format", draft-ietf-pkix-ta-format-03 (work in progress), | ||||
May 2009. | ||||
[TA-MGMT-REQS] | ||||
Reddy, R. and C. Wallace, "Trust Anchor Management | ||||
Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in | ||||
progress), September 2009. | ||||
[TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor | ||||
Management Protocol (TAMP)", draft-ietf-pkix-tamp-03 (work | ||||
in progress), October 2009. | ||||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
We would like to thank Robert Thurlow of Sun Microsystems for helping | We would like to thank Robert Thurlow of Sun Microsystems for helping | |||
to author this document. | to author this document. | |||
We would also like to thank Peter McCann and and Nicolas Williams for | ||||
their comments and suggestions. | ||||
Authors' Addresses | Authors' Addresses | |||
James Lentini | James Lentini | |||
NetApp | NetApp | |||
1601 Trapelo Rd, Suite 16 | 1601 Trapelo Rd, Suite 16 | |||
Waltham, MA 02451 | Waltham, MA 02451 | |||
US | US | |||
Phone: +1 781-768-5359 | Phone: +1 781-768-5359 | |||
Email: jlentini@netapp.com | Email: jlentini@netapp.com | |||
End of changes. 12 change blocks. | ||||
9 lines changed or deleted | 61 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |