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/