draft-ietf-nfsv4-federated-fs-reqts-01.txt   draft-ietf-nfsv4-federated-fs-reqts-02.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: June 26, 2009 D. Ellard Expires: October 22, 2009 D. Ellard
BBN Technologies BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
December 23, 2008 April 20, 2009
Requirements for Federated File Systems Requirements for Federated File Systems
draft-ietf-nfsv4-federated-fs-reqts-01 draft-ietf-nfsv4-federated-fs-reqts-02
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. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 26, 2009. This Internet-Draft will expire on October 22, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
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.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 25 skipping to change at page 2, line 25
4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7 4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7
4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7 4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7
4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7 4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7
4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8 4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8
4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8 4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8
4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10 4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10
5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15
6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15
6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
10.2. Informational References . . . . . . . . . . . . . . . . . 27 10.2. Informational References . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Note, that this is a requirements document, and in many instances Note, that this is a requirements document, and in many instances
where these words are used in this document they refer to qualities where these words are used in this document they refer to qualities
of a specification for a system that satisfies the document, or of a specification for a system that satisfies the document, or
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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.
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 RFC TBD]). Updates to the locations make it possible to [NFSv4.1]). Updates to the locations make it possible to support
support migration and replication of physical filesystems that migration and replication of physical filesystems that comprise the
comprise the namespace, in a way that is transparent to filesystem namespace, in a way that is transparent to filesystem clients.
clients.
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
ALPHA and BETA each have three servers and one NSDB node. ALPHA and BETA each have three servers and one NSDB node.
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| Federation Member | | Federation Member | | Federation Member | | Federation Member |
| ALPHA | | BETA | | ALPHA | | BETA |
| | | | | | | |
skipping to change at page 18, line 39 skipping to change at page 18, line 39
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.
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
nonexistant 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
NSDB; the servers do not "know" whether the filesets they host NSDB; the servers do not "know" whether the filesets they host
have been assigned FSNs (or, if so, what those FSNs are). have been assigned FSNs (or, if so, what those FSNs are).
The requirement that filesets can exist prior to being assigned The requirement that filesets can exist prior to being assigned
an FSN, and the requirement that FSNs can exist independent of an FSN, and the requirement that FSNs can exist independent of
filesets are intended to simplify the construction of the filesets are intended to simplify the construction of the
namespace in a convenient manner. For example, they permit an namespace in a convenient manner. For example, they permit an
admin to assign FSNs to existing filesets and thereby admin to assign FSNs to existing filesets and thereby
skipping to change at page 24, line 5 skipping to change at page 24, line 5
across multiple repositories. across multiple repositories.
e. If a root fileset is defined it SHOULD be possible to e. If a root fileset is defined it SHOULD be possible to
enable a file server to export that root fileset for client enable a file server to export that root fileset for client
access. access.
f. If a root fileset is defined it SHOULD be possible for f. If a root fileset is defined it SHOULD be possible for
multiple file servers to project a common root with defined multiple file servers to project a common root with defined
consistency semantics. consistency semantics.
g. If a root fileset is defined it SHOULD be stored using a
compact representation that is compatible with
heterogeneous fileserver implementations. The root
fileset's internal format SHOULD contain enough information
to generate any attributes, including referrals, required
by the standard filesystem access protocols in R9.
7. Non-Requirements 7. Non-Requirements
N1: It is not necessary for the namespace to be known by any N1: It is not necessary for the namespace to be known by any
specific fileserver. specific fileserver.
In the same manner that clients do not need to have a priori In the same manner that clients do not need to have a priori
knowledge of the structure of the namespace or its mapping onto knowledge of the structure of the namespace or its mapping onto
federation members, the projected namespace can exist without federation members, the projected namespace can exist without
individual fileservers knowing the entire organizational individual fileservers knowing the entire organizational
structure, or, indeed, without knowing exactly where in the structure, or, indeed, without knowing exactly where in the
skipping to change at page 25, line 27 skipping to change at page 26, line 27
undetectably alter the contents of the communication between servers undetectably alter the contents of the communication between servers
and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server
can masquerade as another server without proper authority, or if an can masquerade as another server without proper authority, or if an
arbitrary host can masquerade as a NSDB node. arbitrary host can masquerade as a NSDB node.
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
[RFC4511], 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].
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work
in progress), December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
skipping to change at page 27, line 30 skipping to change at page 28, line 34
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): Technical Specification Road Map", RFC 4510,
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.
10.2. Informational References 10.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.
Appendix A. Acknowledgements 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.
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
skipping to change at page 29, line 32 skipping to change at page 30, line 32
Phone: +1 919-476-5320 Phone: +1 919-476-5320
Email: everhart@netapp.com Email: everhart@netapp.com
Daniel Ellard Daniel Ellard
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
US US
Phone: +1 617-873-8000 Phone: +1 617-873-8000
Email: ellard@gmail.com Email: dellard@bbn.com
Renu Tewari Renu Tewari
IBM Almaden IBM Almaden
650 Harry Rd 650 Harry Rd
San Jose, CA 95120 San Jose, CA 95120
US US
Email: tewarir@us.ibm.com Email: tewarir@us.ibm.com
Manoj Naik Manoj Naik
IBM Almaden IBM Almaden
 End of changes. 15 change blocks. 
28 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/