draft-ietf-nfsv4-federated-fs-reqts-00.txt | draft-ietf-nfsv4-federated-fs-reqts-01.txt | |||
---|---|---|---|---|
Network Working Group D. Ellard | NFSv4 Working Group J. Lentini | |||
Internet-Draft BBN Technologies | Internet-Draft C. Everhart | |||
Intended status: Standards Track C. Everhart | Intended status: Informational NetApp | |||
Expires: March 30, 2009 J. Lentini | Expires: June 26, 2009 D. Ellard | |||
NetApp | BBN Technologies | |||
R. Tewari | R. Tewari | |||
M. Naik | M. Naik | |||
IBM Almaden | IBM Almaden | |||
September 26, 2008 | December 23, 2008 | |||
Requirements for Federated File Systems | Requirements for Federated File Systems | |||
draft-ietf-nfsv4-federated-fs-reqts-00.txt | draft-ietf-nfsv4-federated-fs-reqts-01 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. | |||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of 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. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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 March 30, 2009. | This Internet-Draft will expire on June 26, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (c) 2008 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://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. | ||||
Abstract | Abstract | |||
This draft 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. Our intent is to | federated file system and defines related terms. | |||
use this draft as a starting point and refine it, with input and | ||||
feedback from the file system community and other interested parties, | ||||
until we reach general agreement. We will then begin, again with the | ||||
help of any interested parties, to define standard, open federated | ||||
file system protocols that satisfy these requirements and are | ||||
suitable for implementation and deployment. | ||||
Table of Contents | Table of Contents | |||
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Draft Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7 | |||
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 | 4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7 | |||
5.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 | 4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7 | |||
5.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 8 | 4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8 | |||
5.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 | 4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8 | |||
5.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 | 4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 | 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 | |||
7. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 | 6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 | |||
7.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 | 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 | 7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | |||
9. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 25 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 | 10.2. Informational References . . . . . . . . . . . . . . . . . 27 | |||
11.2. Informational References . . . . . . . . . . . . . . . . . 27 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 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 | |||
requirements of a system that matches that specification. These | requirements of a system that matches that specification. These | |||
cases are distinguished when there is potential for ambiguity. | cases are distinguished when there is potential for ambiguity. | |||
2. Draft Goals | 2. Overview | |||
This draft 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. Our intent is to | federated file system and defines related terms. | |||
use this draft as a starting point and refine it, with input and | ||||
feedback from the file system community and other interested parties, | ||||
until we reach general agreement. We will then begin, again with the | ||||
help of any interested parties, to define standard, open federated | ||||
file system protocols that satisfy these requirements and are | ||||
suitable for implementation and deployment. | ||||
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 | |||
protocols or their implementations. | protocols or their implementations. | |||
For the first version of this document, we are focused on the | ||||
following questions: | ||||
o Are any "MUST" requirements missing? | ||||
o Are there any "MUST" requirements that should be "SHOULD" or | ||||
"MAY"? | ||||
o Are there any "SHOULD" requirements that should be "MAY"? | ||||
o Are there better ways to articulate the requirements? | ||||
3. Overview | ||||
Today, there are collections of fileservers that inter-operate to | Today, there are collections of fileservers that inter-operate to | |||
provide a single namespace comprised of filesystem resources provided | provide a single namespace comprised of filesystem resources provided | |||
by different members of the collection, joined together with inter- | by different members of the collection, joined together with inter- | |||
filesystem junctions. The namespace can either be assembled at the | filesystem references. The namespace can either be assembled at the | |||
fileservers, the clients, or by an external namespace service -- the | fileservers, the clients, or by an external namespace service, and is | |||
mechanisms used to assemble the namespace may vary depending on the | often not easy or uniform to manage. The requirements in this draft | |||
filesystem access protocol used by the client. | are meant to lead to a uniform server-based namespace that is capable | |||
of spanning a whole enterprise and which is easy to manage. | ||||
These fileserver collections are, in general, administered by a | ||||
single administrative entity. This administrator builds the | ||||
namespace out of the filesystem resources and junctions. There are | ||||
also singleton servers that export some or all of their filesystem | ||||
resources, but which do not contain junctions to other filesystems. | ||||
Current server collections that provide a shared namespace usually do | ||||
so by means of a service that maps filesystem names to filesystem | ||||
locations. We refer to this as a namespace database service (NSDB). | ||||
In some distributed file systems, this service is embodied as a | ||||
volume location database (VLDB), and may be implemented by LDAP, NIS, | ||||
or any number of other mechanisms. | ||||
We use the term "fileset" to represent the abstraction of a | We define some terms to better describe the solution space. A | |||
filesystem. The fileset abstraction implies very little about how | "fileset" is the abstract view of a filesystem in a uniform | |||
the fileset is implemented, although in the simplest case a fileset | namespace, and may be implemented behind that abstraction by one or | |||
can be implemented by an exported filesystem. A fileset is a | more physical filesystems at any given time. Each fileset has a name | |||
directory tree that may contain files and references, called | called an "FSN" (fileset name), and each physical filesystem has a | |||
"junction", to other filesets. Each fileset has a fileset globally | fileset location ("FSL"). A fileset is a directory tree containing | |||
unique name (FSN) that is used as an identifier for the fileset. | files and directories, and it may also contain references to other | |||
Each implementation of a given fileset is specified by its fileset | filesets. These references are called "junctions". To provide | |||
location (FSL). | location independence, a junction does not contain information about | |||
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 map from FSN to FSL(s) is called a namespace | ||||
database (NSDB) service. The NSDB provides a level of indirection | ||||
from the virtual paths in the uniform namespace to the actual | ||||
locations of files. | ||||
The primary purpose of the NSDB service is to provide a level of | The servers direct clients to the proper locations by existing | |||
indirection between the FSN the FSLs. If the NSDB service permits | mechanisms (e.g. the referrals mechanism within [RFC3530] and | |||
updates to the set of mappings, then the FSLs may be changed (e.g., | [NFSv4.1 RFC TBD]). Updates to the locations make it possible to | |||
moved or replicated) in a manner that is transparent to the referring | support migration and replication of physical filesystems that | |||
fileset and its server(s). | comprise the namespace, in a way that is transparent to filesystem | |||
clients. | ||||
Current approaches are unsuitable to build common namespaces across | Figure 1 shows an example of a federation. This federation has two | |||
systems with multiple administrative domains and multiple NSDB nodes. | members, named ALPHA and BETA. Federation members may contain an | |||
An approach which requires changing existing NSDB nodes to | arbitrary number of file servers and NSDB nodes; in this illustration | |||
collaborate or replacing them with a single NSDB node, while | ALPHA and BETA each have three servers and one NSDB node. | |||
possible, is not desirable. | ||||
Figure Figure 1 shows an example of a federation. This federation | +----------------------+ +----------------------+ | |||
has two members, named ALPHA and BETA. Federation members may | | Federation Member | | Federation Member | | |||
contain an arbitrary number of file servers and NSDB nodes; in this | | ALPHA | | BETA | | |||
illustration ALPHA and BETA each have three servers and one NSDB | | | | | | |||
node. | | | | | | |||
| +------------+ | | +------------+ | | ||||
| | NSDB | | | | NSDB | | | ||||
| | | | | | | | | ||||
| +------------+ | | +------------+ | | ||||
| | | | | ||||
| | | | | ||||
| | | | | ||||
| +----------+ | | +----------+ | | ||||
| | | | | | | | | ||||
| +-- | Servers | | | +-- | Servers | | | ||||
| | | | | | | | | | | ||||
| +-- | | | | | +-- | | | | | ||||
| | | +----------+ | | | | +----------+ | | ||||
| | | | | | | | | | | ||||
| | +----------+ | | | +----------+ | | ||||
| | | | | | | | | ||||
| +----------+ | | +----------+ | | ||||
+----------------------+ +----------------------+ | ||||
A federation with two members, ALPHA and BETA. ALPHA and BETA each | A federation with two members, ALPHA and BETA. ALPHA and BETA each | |||
have their own NSDB node and several file servers, but are | have their own NSDB node and several file servers, and they are | |||
administered separately. | administered separately. | |||
Figure 1 | Figure 1 | |||
4. Purpose | 3. Purpose | |||
Our objective is to specify a set of interfaces (and corresponding | Our objective is to specify a set of protocols by which fileservers | |||
protocols) by which such fileservers and collections of fileservers, | or collections of fileservers, with different administrators, can | |||
with different administrators, can form a federation of fileservers | form a federation of fileservers and NSDB nodes that provides a | |||
and NSDB nodes that provides a namespace composed of the filesets | namespace composed of the filesets hosted on the different | |||
hosted on the different fileservers and fileserver collections. | fileservers and fileserver collections. | |||
It should be possible, using a system that implements the interfaces, | It should be possible, using a system that implements the protocols, | |||
to share a common namespace across all the fileservers in the | to share a common namespace across all the fileservers in the | |||
federation. It should also be possible for different fileservers in | federation. It should also be possible for different fileservers in | |||
the federation to project different namespaces and enable clients to | the federation to project different namespaces and enable clients to | |||
traverse them. | traverse them. | |||
Such a federation may contain an arbitrary number of NSDB nodes, each | Such a federation may contain an arbitrary number of NSDB nodes, each | |||
belonging to a different administrative entity, and each providing | belonging to a different administrative entity, and each providing | |||
the mappings that define a part of a namespace. Such a federation | the mappings that define a part of a namespace. Such a federation | |||
may also have an arbitrary number of administrative entities, each | may also have an arbitrary number of administrative entities, each | |||
responsible for administering a subset of the servers and NSDB nodes. | responsible for administering a subset of the fileservers and NSDB | |||
Acting in concert, the administrators should be able to build and | nodes. Acting in concert, the administrators should be able to build | |||
administer this multi-fileserver, multi-collection namespace. | and administer this multi-fileserver, multi-collection namespace. | |||
Each singleton server can be presumed to provide its own NSDB node, | ||||
for example with a trivial mapping to local FSLs. | ||||
It is not the intent of the federation to guarantee namespace | It is not the intent of the federation to guarantee namespace | |||
consistency across all client views. Since different parts of the | consistency across all client views. Since different parts of the | |||
namespace may be administered by different entities, it is possible | namespace may be administered by different entities, it is possible | |||
that a client could be accessing a stale area of the namespace | that a client could be accessing a stale area of the namespace | |||
managed by one entity because a part of the namespace above it, | managed by one entity because a part of the namespace above it, | |||
managed by another entity, has changed. | managed by another entity, has changed. | |||
5. Examples and Discussion | 4. Examples and Discussion | |||
In this section we provide examples and discussion of the basic | In this section we provide examples and discussion of the basic | |||
operations facilitated by the federated file system protocol: | operations facilitated by the federated file system protocol: | |||
creating a fileset, adding a replica of a fileset, resolving a | creating a fileset, adding a replica of a fileset, resolving a | |||
junction, and creating a junction. | junction, and creating a junction. | |||
5.1. Create a Fileset and its FSL(s) | 4.1. Create a Fileset and its FSL(s) | |||
A fileset is the abstraction of a set of files and their containing | A fileset is the abstraction of a set of files and their containing | |||
directory tree. The fileset abstraction is the fundamental unit of | directory tree. The fileset abstraction is the fundamental unit of | |||
data management in the federation. This abstraction is implemented | data management in the federation. This abstraction is implemented | |||
by an actual directory tree whose root location is specified by a | by an actual directory tree whose root location is specified by a | |||
fileset location (FSL). | fileset location (FSL). | |||
In this section, we describe the basic requirements for starting with | In this section, we describe the basic requirements for starting with | |||
a directory tree and creating a fileset that can be used in the | a directory tree and creating a fileset that can be used in the | |||
federation protocols. Note that we do not assume that the process of | federation protocols. Note that we do not assume that the process of | |||
skipping to change at page 8, line 36 | skipping to change at page 7, line 36 | |||
location(s) of the implementation of the fileset as FSL(s). | location(s) of the implementation of the fileset as FSL(s). | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the FSN that binds the FSL is created, and whether other replicas | how the FSN that binds the FSL is created, and whether other replicas | |||
of the fileset exist, are known to the federation, and need to be | of the fileset exist, are known to the federation, and need to be | |||
bound to the same FSN. | bound to the same FSN. | |||
It is easiest to describe this in terms of how to create the initial | It is easiest to describe this in terms of how to create the initial | |||
implementation of the fileset, and then describe how to add replicas. | implementation of the fileset, and then describe how to add replicas. | |||
5.1.1. Creating a Fileset and a FSN | 4.1.1. Creating a Fileset and an FSN | |||
1. Choose the NSDB node that will keep track of the FSL(s) and | 1. Choose the NSDB node that will keep track of the FSL(s) and | |||
related information for the fileset. | related information for the fileset. | |||
2. Request that the NSDB node register a new FSN for the fileset. | 2. Request that the NSDB node register a new FSN for the fileset. | |||
The FSN may either be chosen by the NSDB node or by the server. | The FSN may either be chosen by the NSDB node or by the server. | |||
The latter case is used if the fileset is being restored, perhaps | The latter case is used if the fileset is being restored, perhaps | |||
as part of disaster recovery, and the server wishes to specify | as part of disaster recovery, and the server wishes to specify | |||
the FSN in order to permit existing junctions that reference that | the FSN in order to permit existing junctions that reference that | |||
skipping to change at page 9, line 10 | skipping to change at page 8, line 10 | |||
At this point, the FSN exists, but its location is unspecified. | At this point, the FSN exists, but its location is unspecified. | |||
3. Send the FSN, the local volume path, the export path, and the | 3. Send the FSN, the local volume path, the export path, and the | |||
export options for the local implementation of the fileset to the | export options for the local implementation of the fileset to the | |||
NSDB node. Annotations about the FSN or the location may also be | NSDB node. Annotations about the FSN or the location may also be | |||
sent. | sent. | |||
The NSDB node records this info and creates the initial FSL for | The NSDB node records this info and creates the initial FSL for | |||
the fileset. | the fileset. | |||
5.1.2. Adding a Replica of a Fileset | 4.1.2. Adding a Replica of a Fileset | |||
Adding a replica is straightforward: the NSDB node and the FSN are | Adding a replica is straightforward: the NSDB node and the FSN are | |||
already known. The only remaining step is to add another FSL. | already known. The only remaining step is to add another FSL. | |||
Note that the federation interfaces do not include methods for | Note that the federation protocols do not include methods for | |||
creating or managing replicas: this is assumed to be a platform- | creating or managing replicas: this is assumed to be a platform- | |||
dependent operation (at least at this time). The only interface | dependent operation (at least at this time). The only requirement is | |||
required is the ability to register or remove the registration of | that these fileset replicas be registered and unregistered with the | |||
replicas for a fileset. | NSDB. | |||
5.2. Junction Resolution | 4.2. Junction Resolution | |||
A fileset may contain references to other filesets. These references | A fileset may contain references to other filesets. These references | |||
are represented by junctions. If a client requests access to a | are represented by junctions. If a client requests access to a | |||
fileset object that is a junction, the server resolves the junction | fileset object that is a junction, the server resolves the junction | |||
to discover the FSL(s) that implements the referenced fileset. | to discover the FSL(s) that implements the referenced fileset. | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the junctions are represented and how the information necessary | how the junctions are represented and how the information necessary | |||
to perform resolution is represented by the server. In this example, | to perform resolution is represented by the server. | |||
we assume that the only thing directly expressed by the junction is | ||||
the junction key; its mapping to FSN can be kept local to the server | ||||
hosting the junction. | ||||
Step 5 is the only step that interacts directly with the federation | Step 4 is the only step that interacts directly with the federation | |||
interfaces. The rest of the steps may use platform-specific | protocols. The rest of the steps may use platform-specific | |||
interfaces. | interfaces. | |||
1. The server determines that the object being accessed is a | 1. The server determines that the object being accessed is a | |||
junction. | junction. | |||
2. The server determines the junction key for the junction. | 2. Using the junction, the server does a local lookup to find the | |||
FSN of the target fileset. | ||||
3. Using the junction key, the server does a local lookup to find | ||||
the FSN of the target fileset. | ||||
4. Using the FSN, the server finds the NSDB node responsible for the | 3. Using the FSN, the server finds the NSDB node responsible for the | |||
target object. | target object. | |||
5. The server contacts that NSDB node and asks for the set of FSLs | 4. The server contacts that NSDB node and asks for the set of FSLs | |||
that implement the target FSN. The NSDB node responds with a set | that implement the target FSN. The NSDB node responds with a set | |||
of FSLs. | of FSLs. | |||
6. The server converts the FSL to the location type used by the | 5. The server converts one of the FSLs to the location type used by | |||
client (e.g., fs_location for NFSv4, as described in [RFC3530]). | the client (e.g., fs_location for NFSv4, as described in | |||
[RFC3530]). | ||||
7. The server redirects (in whatever manner is appropriate for the | 6. The server redirects (in whatever manner is appropriate for the | |||
client) the client to the location(s). | client) the client to the location(s). | |||
These steps are illustrated in Figure 2. The client sends request 1 | These steps are illustrated in Figure 2. The client sends request 1 | |||
to server X, in federation member ALPHA, in an attempt to reference | to server X, in federation member ALPHA, in an attempt to reference | |||
an object (which appears to the client as a directory). Server X | an object (which appears to the client as a directory). Server X | |||
recognizes that the referenced object is actually a junction that | recognizes that the referenced object is actually a junction that | |||
refers to a directory in a different fileset. Server X finds, from | refers to a directory in a different fileset. Server X finds, from | |||
the FSN in the junction, that the NSDB responsible for knowing the | the FSN in the junction, that the NSDB responsible for knowing the | |||
location of the target of the junction is the NSDB of federation | location of the target of the junction is the NSDB of federation | |||
member BETA. Server X sends request 2 to the NSDB of BETA, asking | member BETA. Server X sends request 2 to the NSDB of BETA, asking | |||
skipping to change at page 11, line 5 | skipping to change at page 10, line 5 | |||
Given the current requirements and definitions, this resolution | Given the current requirements and definitions, this resolution | |||
method MUST work. However, there is no requirement that this is the | method MUST work. However, there is no requirement that this is the | |||
only resolution method that can be used. This method may be used as | only resolution method that can be used. This method may be used as | |||
the fallback when all else fails (or, for a simple implementation, it | the fallback when all else fails (or, for a simple implementation, it | |||
could be the only method). This is a degenerate implementation of | could be the only method). This is a degenerate implementation of | |||
the NSDB service as a simple composition of NSDB nodes; we expect | the NSDB service as a simple composition of NSDB nodes; we expect | |||
that large federations will use more sophisticated methods to share | that large federations will use more sophisticated methods to share | |||
the FSN and FSL information among multiple NSDB nodes. | the FSN and FSL information among multiple NSDB nodes. | |||
+---------------+ | ||||
| | | ||||
| Client | >--------------------------+ | ||||
| | | | ||||
+---------------+ | | ||||
v ^ | | ||||
+-----+---+-------------+ +-----------------+-----+ | ||||
| | | Federation| |Federation | | | ||||
| | | member | |member | | | ||||
| | | ALPHA | |BETA | | | ||||
| | | | | | | | ||||
| | | | | | | | ||||
| | | | | | | | ||||
| | | | | | | | ||||
| | | | | +---------+ | | | ||||
| | | +---------+------+-> | | | | | ||||
| | | | | | | NSDB Y | | | | ||||
| | | | +-----+------+-< | | | | | ||||
| | | | | | | +---------+ | | | ||||
| | | | | | | | | | ||||
| | | | | | | | | | ||||
| | | | | | | | | | ||||
| 1| 4| 2| 3| | | 5| | | ||||
| v ^ ^ v | | v | | ||||
| +---------------+ | | +---------------+ | | ||||
| | | | | | | | | ||||
| | Server X | | | | Server Y | | | ||||
| | | | | | | | | ||||
| +---------------+ | | +---------------+ | | ||||
| | | | | ||||
+-----------------------+ +-----------------------+ | ||||
Figure 2 | Figure 2 | |||
5.3. Junction Creation | 4.3. Junction Creation | |||
Given a local path, a remote export and a path relative to that | Given a local path, a remote export and a path relative to that | |||
export, create a junction from the local path to the path within the | export, create a junction from the local path to the path within the | |||
remote export. | remote export. | |||
There are many possible variations to this procedure, depending on | There are many possible variations to this procedure, depending on | |||
how the junctions are represented and how the information necessary | how the junctions are represented and how the information necessary | |||
to perform resolution is represented by the server. In this example, | to perform resolution is represented by the server. | |||
we assume that the only thing directly expressed by the junction is | ||||
the junction key; its mapping to FSN can be kept local to the server | ||||
hosting the junction. | ||||
Step 1 is the only step that uses the federation interfaces. The | Step 1 is the only step that uses the federation interfaces. The | |||
rest of the steps may use platform-specific interfaces. | rest of the steps may use platform-specific interfaces. | |||
1. Contact the server named by the export and ask for the FSN for | 1. Contact the server named by the export and ask for the FSN for | |||
the fileset, given its path relative to that export. | the fileset, given its path relative to that export. | |||
2. Create a new local junction key. | 2. Insert the junction to the FSN, at the given path, into the local | |||
3. Insert, in the local junction info table, a mapping from the | ||||
local junction key to the FSN. | ||||
4. Insert the junction, at the given path, into the local | ||||
filesystem. | filesystem. | |||
6. Glossary | 5. Glossary | |||
The phrase "USING THE FEDERATION INTERFACES" implies that the | ||||
subsequent requirement must be satisfied, in its entirety, via the | ||||
federation interfaces. | ||||
Administrator: user with the necessary authority to initiate | Administrator: user with the necessary authority to initiate | |||
administrative tasks on one or more servers. | administrative tasks on one or more servers. | |||
Admin entity: A server or agent that administers a collection of | Admin entity: A server or agent that administers a collection of | |||
fileservers and persistently stores the namespace information. | fileservers and persistently stores the namespace information. | |||
Client: Any client that accesses the fileserver data using a | Client: Any client that accesses the fileserver data using a | |||
supported filesystem access protocol. | supported filesystem access protocol. | |||
skipping to change at page 13, line 17 | skipping to change at page 13, line 16 | |||
for a fileset. Two FSLs that implement replicas of the same | for a fileset. Two FSLs that implement replicas of the same | |||
fileset MUST have the same FSN, and if a fileset is migrated from | fileset MUST have the same FSN, and if a fileset is migrated from | |||
one location to another, the FSN of that fileset MUST remain the | one location to another, the FSN of that fileset MUST remain the | |||
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. | |||
Junction key: The UUID of a fileset, used as a key to lookup an FSN | ||||
within an NSDB node or a local table of information about | ||||
junctions. | ||||
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. | |||
skipping to change at page 15, line 5 | skipping to change at page 15, line 5 | |||
Server Collection: A set of fileservers administered as a unit. A | Server Collection: A set of fileservers administered as a unit. A | |||
server collection may be administered with vendor-specific | server collection may be administered with vendor-specific | |||
software. | software. | |||
The namespace provided by a server collection could be part of the | The namespace provided by a server collection could be part of the | |||
federated namespace. | federated namespace. | |||
Singleton Server: A server collection containing only one server; a | Singleton Server: A server collection containing only one server; a | |||
stand-alone fileserver. | stand-alone fileserver. | |||
7. Proposed Requirements | 6. Proposed Requirements | |||
The phrase "USING THE FEDERATION INTERFACES" implies that the | ||||
subsequent requirement must be satisfied, in its entirety, via the | ||||
federation interfaces. | ||||
Note that the requirements are described in terms of correct behavior | Note that the requirements are described in terms of correct behavior | |||
by all entities. We do not address the requirements of the system in | by all entities. We do not address the requirements of the system in | |||
the presence of faults. | the presence of faults. | |||
7.1. Basic Assumptions | 6.1. Basic Assumptions | |||
Several of the requirements are so fundamental that we treat them as | Several of the requirements are so fundamental that we treat them as | |||
basic assumptions; if any of these assumptions are violated, the rest | basic assumptions; if any of these assumptions are violated, the rest | |||
of the requirements must be reviewed in their entirety. | of the requirements must be reviewed in their entirety. | |||
A1: The federation protocols do not require any changes to existing | A1: The federation protocols do not require any changes to existing | |||
client-facing protocols, and MAY be extended to incorporate new | client-facing protocols, and MAY be extended to incorporate new | |||
client-facing protocols. | client-facing protocols. | |||
A2: A client SHOULD NOT require any a priori knowledge of the | A2: A client SHOULD NOT require any a priori knowledge of the | |||
skipping to change at page 16, line 38 | skipping to change at page 16, line 42 | |||
different fileservers in the federation. As such, users may | different fileservers in the federation. As such, users may | |||
only be able to traverse the parts of the namespace that they | only be able to traverse the parts of the namespace that they | |||
have access to. | have access to. | |||
The federation protocols do not impose any restrictions on how | The federation protocols do not impose any restrictions on how | |||
users are represented within the federation. For example, a | users are represented within the federation. For example, a | |||
single enterprise could employ a common identity for users | single enterprise could employ a common identity for users | |||
across the federation. A grid environment could utilize user | across the federation. A grid environment could utilize user | |||
mapping or translations across different administrative domains. | mapping or translations across different administrative domains. | |||
A6: In a federated system, we assume that a FSN MUST express, or can | A6: In a federated system, we assume that an FSN MUST express, or | |||
be used to discover, the following two pieces of information: | can be used to discover, the following two pieces of | |||
information: | ||||
1. The location of the NSDB node that is responsible for | 1. The location of the NSDB node that is responsible for | |||
knowing the filesystem location(s) (FSLs) of the named | knowing the filesystem location(s) (FSLs) of the named | |||
fileset. | fileset. | |||
The NSDB node must be specified because there may be many | The NSDB node must be specified because there may be many | |||
NSDB nodes in a federation. We do not assume that any | NSDB nodes in a federation. We do not assume that any | |||
single entity knows the location of all of the NSDB nodes, | single entity knows the location of all of the NSDB nodes, | |||
and therefore exhaustive search is not an option. | and therefore exhaustive search is not an option. | |||
There are several ways in which a fileserver can locate the | There are several ways in which a fileserver can locate the | |||
NSDB node responsible for a given fileset. One approach, | NSDB node responsible for a given fileset. One approach, | |||
given a DNS infrastructure, is to specify the location of | given a DNS infrastructure, is to specify the location of | |||
the NSDB node by the FQDN of the server hosting the NSDB | the NSDB node by the FQDN of the server hosting the NSDB | |||
node. Another approach is to use a separate DNS-style | node. Another approach is to use a separate DNS-style | |||
hierarchy to resolve the location of the NSDB node. | hierarchy to resolve the location of the NSDB node. | |||
2. The junction key. | 2. The FSN identifier. | |||
The junction key is the index used by the NSDB node to | The FSN identifier is the index used by the NSDB node to | |||
identify the FSN of the target fileset. | identify the target fileset. | |||
There are several ways to represent junction keys. One | There are several ways to represent FSN identifiers. One | |||
approach could use 128-bit UUIDs as described described in | approach could use 128-bit UUIDs as described described in | |||
[RFC4122]. | [RFC4122]. | |||
As an example, an FSN could be represented by a URL of the form | As an example, an FSN could be represented by a URL of the form | |||
nsdb.example.com/UUID where nsdb.example.com is the FQDN of the | nsdb.example.com/UUID where nsdb.example.com is the FQDN of the | |||
server hosting the NSDB node and UUID is the string | server hosting the NSDB node and UUID is the string | |||
representation of the junction key. | representation of the identifier. | |||
Note that it is not assumed that it is always required for a | Note that it is not assumed that it is always required for a | |||
server to contact the NSDB node specified by the FSN in order to | server to contact the NSDB node specified by the FSN in order to | |||
find the FSLs. The relevant information stored in that NSDB | find the FSLs. The relevant information stored in that NSDB | |||
node may also be cached local to the server or on a proxy NSDB | node may also be cached local to the server or on a proxy NSDB | |||
node "near" the server. | node "near" the server. | |||
A7: All federation servers and NSDB nodes are assumed to execute the | A7: All federation servers and NSDB nodes are assumed to execute the | |||
federation protocols correctly. The behavior of the federation | federation protocols correctly. The behavior of the federation | |||
is undefined in the case of Byzantine behavior by any federation | is undefined in the case of Byzantine behavior by any federation | |||
skipping to change at page 18, line 5 | skipping to change at page 18, line 9 | |||
NSDB node. (It is not necessary that the FQDN always resolve to | NSDB node. (It is not necessary that the FQDN always resolve to | |||
the same address; the same service may appear at different | the same address; the same service may appear at different | |||
addresses on different networks.) | addresses on different networks.) | |||
It is the responsibility of each federation member to ensure | It is the responsibility of each federation member to ensure | |||
that the resources it wishes to expose have accessible network | that the resources it wishes to expose have accessible network | |||
locations and that the necessary resolution mechanisms (i.e., | locations and that the necessary resolution mechanisms (i.e., | |||
DNS) are given the necessary data to perform the resolution | DNS) are given the necessary data to perform the resolution | |||
correctly. | correctly. | |||
7.2. Requirements | 6.2. Requirements | |||
R1: Requirements of each FSN: | R1: Requirements of each FSN: | |||
a. Each FSN MUST be globally unique. | a. Each FSN MUST be unique within the scope of its NSDB (so | |||
that the FSN is globally unique). | ||||
b. The FSN MUST be sufficiently descriptive to locate an | b. The FSN MUST be sufficiently descriptive to locate an | |||
instance of the fileset it names within the federation at | instance of the fileset it names within the federation at | |||
any time. | any time. | |||
c. An FSN is a name of a fileset. (An FSL is not the name of | c. All FSNs MUST be invariant when their underlying | |||
a fileset, but only a locator of an instance of a fileset | filesystems move or are replicated; only mappings from FSN | |||
at some point in time. For example, the same FSL may | to FSL(s) change under these transformations. | |||
implement different filesets at different times.) | ||||
+ If a fileset instance is moved to a new location, it | ||||
will have a new FSL, but its FSN is unchanged. | ||||
+ An instance of a different fileset may be placed at a | ||||
FSL previously occupied by an instance of a different | ||||
fileset. | ||||
d. If a fileset instance is migrated to another location, the | ||||
FSN remains the same in the new location. | ||||
e. If the fileset is replicated using the federation | d. All files accessible from the global namespace MUST be part | |||
interfaces, then all of the replicas have the same FSN. | of a fileset that has an assigned FSN. | |||
Not all filesets in the federation are required to have a FSN | Not all filesets in the federation are required to have an FSN | |||
or be reachable by a 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. | |||
NOTE: this requirement has been called into question. | ||||
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 an NFS 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 | nonexistant 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 | |||
skipping to change at page 19, line 21 | skipping to change at page 19, line 13 | |||
permit the structure of the namespace to be defined prior to | permit the structure of the namespace to be defined prior to | |||
creation of the component filesets. In either case, it is the | creation of the component filesets. In either case, it is the | |||
responsibility of the entity updating the NSDB with FSNs and | responsibility of the entity updating the NSDB with FSNs and | |||
FSN-to-FSL mappings to ensure that the namespace is constructed | FSN-to-FSL mappings to ensure that the namespace is constructed | |||
in a consistent manner. (The simplest way to accomplish this | in a consistent manner. (The simplest way to accomplish this | |||
is to ensure that the FSN and FSN-to-FSL mappings are always | is to ensure that the FSN and FSN-to-FSL mappings are always | |||
recorded in the NSDB prior to the creation of any junctions | recorded in the NSDB prior to the creation of any junctions | |||
that refer to that FSN.) | that refer to that FSN.) | |||
a. An administrator MAY specify the entire FSN (including both | a. An administrator MAY specify the entire FSN (including both | |||
the NSDB node location and the junction key) of the newly- | the NSDB node location and the identifier) of the newly- | |||
created FSL, or the administrator MAY specify only the NSDB | created FSL, or the administrator MAY specify only the NSDB | |||
node and have the system choose the junction key. | node and have the system choose the identifier. | |||
The admin can choose to specify the FSN explicitly in order | The admin can choose to specify the FSN explicitly in order | |||
to recreate a lost fileset with a given FSN (for example, | to recreate a lost fileset with a given FSN (for example, | |||
as part of disaster recovery). It is an error to assign an | as part of disaster recovery). It is an error to assign an | |||
FSN that is already in use by an active fileset. | FSN that is already in use by an active fileset. | |||
Note that creating a replica of an existing filesystem is | Note that creating a replica of an existing filesystem is | |||
NOT accomplished by assigning the FSN of the filesystem you | NOT accomplished by assigning the FSN of the filesystem you | |||
wish to replicate to a new filesystem. | wish to replicate to a new filesystem. | |||
skipping to change at page 20, line 47 | skipping to change at page 20, line 39 | |||
An FSN that has been invalidated MAY become valid again if the | An FSN that has been invalidated MAY become valid again if the | |||
FSN is recreated (i.e., as part of a disaster recovery | FSN is recreated (i.e., as part of a disaster recovery | |||
process). | process). | |||
If an FSN is invalidated, clients who are already viewing the | If an FSN is invalidated, clients who are already viewing the | |||
fileset named by the FSN MAY continue to view the old | fileset named by the FSN MAY continue to view the old | |||
namespace. They might not discover that the FSN is no longer | namespace. They might not discover that the FSN is no longer | |||
valid until they try to traverse a junction that refers to it. | valid until they try to traverse a junction that refers to it. | |||
R6: USING THE FEDERATION INTERFACES, it MUST be possible to | R6: USING THE FEDERATION INTERFACES, it MUST be possible to | |||
invalidate a FSL. | invalidate an FSL. | |||
a. An invalid FSL MUST NOT be returned as the result of | a. An invalid FSL MUST NOT be returned as the result of | |||
resolving a junction. | resolving a junction. | |||
An FSL that has been invalidated MAY become valid again if the | An FSL that has been invalidated MAY become valid again if the | |||
FSL is recreated (i.e., as part of a disaster recovery | FSL is recreated (i.e., as part of a disaster recovery | |||
process). | process). | |||
If an FSL is invalidated, clients who are already viewing the | If an FSL is invalidated, clients who are already viewing the | |||
fileset implemented by the FSL MAY continue to use that FSL. | fileset implemented by the FSL MAY continue to use that FSL. | |||
skipping to change at page 21, line 21 | skipping to change at page 21, line 13 | |||
implemented by the FSL. | implemented by the FSL. | |||
Note that invalidating an FSL does not imply that the | Note that invalidating an FSL does not imply that the | |||
underlying export or share (depending on the file access | underlying export or share (depending on the file access | |||
protocol in use) is changed in any way -- it only changes the | protocol in use) is changed in any way -- it only changes the | |||
mappings from FSNs to FSLs on the NSDB. | mappings from FSNs to FSLs on the NSDB. | |||
R7: It MUST be possible for the federation of servers to provide | R7: It MUST be possible for the federation of servers to provide | |||
multiple namespaces. | multiple namespaces. | |||
R8: USING THE FEDERATION INTERFACES, it MUST be possible to perform | R8: USING THE FEDERATION INTERFACES: | |||
queries about the state of objects relevant to the | ||||
implementation of the federation namespace. | ||||
It MUST be possible to query the fileserver named in an FSL to | a. It MUST be possible to query the fileserver named in an FSL | |||
discover whether a junction exists at a given path within that | to discover whether a junction exists at a given path | |||
FSL. | within that FSL. | |||
b. It MAY be possible to query the fileserver named in an FSL | ||||
to discover the junctions, if any, in that FSL. If this | ||||
feature is implemented, the fileserver SHOULD report each | ||||
junction's path within the FSL and the targeted FSN. | ||||
R9: The projected namespace (and the objects named by the | R9: The projected namespace (and the objects named by the | |||
namespace) MUST be accessible to clients via at least one | namespace) MUST be accessible to clients via at least one | |||
standard filesystem access protocol. | standard filesystem access protocol. | |||
a. The namespace SHOULD be accessible to clients via the CIFS | a. The namespace SHOULD be accessible to clients via versions | |||
protocol. | of the CIFS (SMB) protocol. | |||
b. The namespace SHOULD be accessible to clients via the NFSv4 | b. The namespace SHOULD be accessible to clients via the NFSv4 | |||
protocol as described in [RFC3530]. | protocol as described in [RFC3530]. | |||
c. The namespace SHOULD be accessible to clients via the NFSv3 | c. The namespace SHOULD be accessible to clients via the NFSv3 | |||
protocol as described in [RFC1813]. | protocol as described in [RFC1813]. | |||
d. The namespace SHOULD be accessible to clients via the NFSv2 | d. The namespace SHOULD be accessible to clients via the NFSv2 | |||
protocol as described in [RFC1094]. | protocol as described in [RFC1094]. | |||
skipping to change at page 23, line 21 | skipping to change at page 23, line 18 | |||
Both FSNs and FSLs may be annotated. For example, an FSN | Both FSNs and FSLs may be annotated. For example, an FSN | |||
property might be "This is Joe Smith's home directory", and an | property might be "This is Joe Smith's home directory", and an | |||
FSL property might be "This instance of the FSN is at the | FSL property might be "This instance of the FSN is at the | |||
remote backup site." | remote backup site." | |||
a. USING THE FEDERATION INTERFACES, it MUST be possible to | a. USING THE FEDERATION INTERFACES, it MUST be possible to | |||
query the system to find the annotations for a junction. | query the system to find the annotations for a junction. | |||
b. USING THE FEDERATION INTERFACES, it MUST be possible to | b. USING THE FEDERATION INTERFACES, it MUST be possible to | |||
query the system to find the annotations for a FSN. | query the system to find the annotations for an FSN. | |||
c. USING THE FEDERATION INTERFACES, it MUST be possible to | c. USING THE FEDERATION INTERFACES, it MUST be possible to | |||
query the system to find the annotations for a FSL. | query the system to find the annotations for an FSL. | |||
8. Non-Requirements | R15: It MUST be possible for the federation to project a namespace | |||
with a common root. | ||||
a. It SHOULD be possible to define a root fileset that is | ||||
exported by one or more fileservers in the federation as | ||||
the top level of a namespace. [Corollary: There is one | ||||
root fileset per namespace and it is possible to support | ||||
multiple namespaces per federation.] | ||||
b. It SHOULD be possible for a fileserver to locate an NSDB | ||||
that stores the layout of a root fileset. | ||||
c. It SHOULD be possible to access, store and update | ||||
information related to a root fileset using the federation | ||||
protocols. | ||||
d. It SHOULD be possible to replicate root fileset information | ||||
across multiple repositories. | ||||
e. If a root fileset is defined it SHOULD be possible to | ||||
enable a file server to export that root fileset for client | ||||
access. | ||||
f. If a root fileset is defined it SHOULD be possible for | ||||
multiple file servers to project a common root with defined | ||||
consistency semantics. | ||||
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 | |||
projected namespace the filesets they host exist. | projected namespace the filesets they host exist. | |||
skipping to change at page 25, line 5 | skipping to change at page 25, line 5 | |||
the namespace or related data stored in the system (including | the namespace or related data stored in the system (including | |||
the creation, renaming, or deletion of junctions, and the | the creation, renaming, or deletion of junctions, and the | |||
creation, altering, or deletion of mappings between FSN and | creation, altering, or deletion of mappings between FSN and | |||
filesystem locations), can be performed in a manner that | filesystem locations), can be performed in a manner that | |||
provides predictable semantics for the relationship between | provides predictable semantics for the relationship between | |||
the observed values and the effect of the changes." | the observed values and the effect of the changes." | |||
"It MUST be possible to protect sequences of operations by | "It MUST be possible to protect sequences of operations by | |||
transactions with NSDB-wide or server-wide ACID semantics." | transactions with NSDB-wide or server-wide ACID semantics." | |||
9. IANA Requirements | 8. Security Considerations | |||
This document has no actions for IANA. | ||||
10. Security Considerations | ||||
Assuming the Internet threat model, the federated resolution | Assuming the Internet threat model, the federated resolution | |||
mechanism described in this document MUST be implemented in such a | mechanism described in this document MUST be implemented in such a | |||
way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER | way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER | |||
ENTITY AUTHENTICATION, as described in [RFC3552]. | ENTITY AUTHENTICATION, as described in [RFC3552]. | |||
CONFIDENTIALITY may be violated if an unauthorized party is able to | CONFIDENTIALITY may be violated if an unauthorized party is able to | |||
eavesdrop on the communication between authorized servers and NSDB | eavesdrop on the communication between authorized servers and NSDB | |||
nodes and thereby learn the locations or other information about FSNs | nodes and thereby learn the locations or other information about FSNs | |||
that they would not be authorized to discover via direct queries. | that they would not be authorized to discover via direct queries. | |||
skipping to change at page 26, line 28 | skipping to change at page 25, line 28 | |||
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 | [RFC4511], then TLS may be used to provide both authentication and | |||
integrity [RFC4346] [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]. | |||
11. References | 9. IANA Considerations | |||
11.1. Normative References | This document has no actions for IANA. | |||
10. References | ||||
10.1. Normative References | ||||
[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. | |||
skipping to change at page 27, line 30 | skipping to change at page 27, line 30 | |||
(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. | |||
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security | ||||
(TLS) Protocol Version 1.1", RFC 4346, April 2006. | ||||
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol | [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol | |||
(LDAP): The Protocol", RFC 4511, June 2006. | (LDAP): The Protocol", RFC 4511, 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. | |||
11.2. Informational References | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | ||||
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 | ||||
We would like to thank Robert Thurlow of Sun Microsystems for helping | ||||
to author this document. | ||||
Authors' Addresses | Authors' Addresses | |||
Daniel Ellard | James Lentini | |||
BBN Technologies | NetApp | |||
10 Moulton Street | 1601 Trapelo Rd, Suite 16 | |||
Cambridge, MA 02138 | Waltham, MA 02451 | |||
US | US | |||
Phone: +1 617-873-8000 | Phone: +1 781-768-5359 | |||
Email: ellard@gmail.com | Email: jlentini@netapp.com | |||
Craig Everhart | Craig Everhart | |||
NetApp | NetApp | |||
7301 Kit Creek Rd | 7301 Kit Creek Rd | |||
Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
US | US | |||
Phone: +1 919-476-5320 | Phone: +1 919-476-5320 | |||
Email: everhart@netapp.com | Email: everhart@netapp.com | |||
James Lentini | Daniel Ellard | |||
NetApp | BBN Technologies | |||
1601 Trapelo Rd, Suite 16 | 10 Moulton Street | |||
Waltham, MA 02451 | Cambridge, MA 02138 | |||
US | US | |||
Phone: +1 781-768-5359 | Phone: +1 617-873-8000 | |||
Email: jlentini@netapp.com | Email: ellard@gmail.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 | |||
650 Harry Rd | 650 Harry Rd | |||
San Jose, CA 95120 | San Jose, CA 95120 | |||
US | US | |||
Email: manoj@almaden.ibm.com | Email: manoj@almaden.ibm.com | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 76 change blocks. | ||||
234 lines changed or deleted | 262 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/ |