--- 1/draft-ietf-nfsv4-federated-fs-reqts-00.txt 2008-12-23 21:12:03.000000000 +0100 +++ 2/draft-ietf-nfsv4-federated-fs-reqts-01.txt 2008-12-23 21:12:03.000000000 +0100 @@ -1,227 +1,215 @@ -Network Working Group D. Ellard -Internet-Draft BBN Technologies -Intended status: Standards Track C. Everhart -Expires: March 30, 2009 J. Lentini - NetApp +NFSv4 Working Group J. Lentini +Internet-Draft C. Everhart +Intended status: Informational NetApp +Expires: June 26, 2009 D. Ellard + BBN Technologies R. Tewari M. Naik IBM Almaden - September 26, 2008 + December 23, 2008 Requirements for Federated File Systems - draft-ietf-nfsv4-federated-fs-reqts-00.txt + draft-ietf-nfsv4-federated-fs-reqts-01 Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (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 - This draft describes and lists the functional requirements of a - federated file system and defines related terms. Our intent is to - 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. + This document describes and lists the functional requirements of a + federated file system and defines related terms. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 - 2. Draft Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 - 5.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 8 - 5.1.1. Creating a Fileset and a FSN . . . . . . . . . . . . . 8 - 5.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 9 - 5.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 9 - 5.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 - 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 - 7.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 - 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 - 9. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 25 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 11.2. Informational References . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . . . 30 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Examples and Discussion . . . . . . . . . . . . . . . . . . . 7 + 4.1. Create a Fileset and its FSL(s) . . . . . . . . . . . . . 7 + 4.1.1. Creating a Fileset and an FSN . . . . . . . . . . . . 7 + 4.1.2. Adding a Replica of a Fileset . . . . . . . . . . . . 8 + 4.2. Junction Resolution . . . . . . . . . . . . . . . . . . . 8 + 4.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 10 + 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 15 + 6.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 15 + 6.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 + 7. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 10.2. Informational References . . . . . . . . . . . . . . . . . 27 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Note, that this is a requirements document, and in many instances where these words are used in this document they refer to qualities of a specification for a system that satisfies the document, or requirements of a system that matches that specification. These cases are distinguished when there is potential for ambiguity. -2. Draft Goals +2. Overview - This draft describes and lists the functional requirements of a - federated file system and defines related terms. Our intent is to - 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. + This document describes and lists the functional requirements of a + federated file system and defines related terms. We do not describe the mechanisms that might be used to implement this functionality except in cases where specific mechanisms, in our opinion, follow inevitably from the requirements. Our focus is on the interfaces between the entities of the system, not on the 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 provide a single namespace comprised of filesystem resources provided by different members of the collection, joined together with inter- - filesystem junctions. The namespace can either be assembled at the - fileservers, the clients, or by an external namespace service -- the - mechanisms used to assemble the namespace may vary depending on the - filesystem access protocol used by the client. - - 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. + filesystem references. The namespace can either be assembled at the + fileservers, the clients, or by an external namespace service, and is + often not easy or uniform to manage. The requirements in this draft + are meant to lead to a uniform server-based namespace that is capable + of spanning a whole enterprise and which is easy to manage. - We use the term "fileset" to represent the abstraction of a - filesystem. The fileset abstraction implies very little about how - the fileset is implemented, although in the simplest case a fileset - can be implemented by an exported filesystem. A fileset is a - directory tree that may contain files and references, called - "junction", to other filesets. Each fileset has a fileset globally - unique name (FSN) that is used as an identifier for the fileset. - Each implementation of a given fileset is specified by its fileset - location (FSL). + We define some terms to better describe the solution space. A + "fileset" is the abstract view of a filesystem in a uniform + namespace, and may be implemented behind that abstraction by one or + more physical filesystems at any given time. Each fileset has a name + called an "FSN" (fileset name), and each physical filesystem has a + fileset location ("FSL"). A fileset is a directory tree containing + files and directories, and it may also contain references to other + filesets. These references are called "junctions". To provide + 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 - indirection between the FSN the FSLs. If the NSDB service permits - updates to the set of mappings, then the FSLs may be changed (e.g., - moved or replicated) in a manner that is transparent to the referring - fileset and its server(s). + The servers direct clients to the proper locations by existing + mechanisms (e.g. the referrals mechanism within [RFC3530] and + [NFSv4.1 RFC TBD]). Updates to the locations make it possible to + support migration and replication of physical filesystems that + comprise the namespace, in a way that is transparent to filesystem + clients. - Current approaches are unsuitable to build common namespaces across - systems with multiple administrative domains and multiple NSDB nodes. - An approach which requires changing existing NSDB nodes to - collaborate or replacing them with a single NSDB node, while - possible, is not desirable. + Figure 1 shows an example of a federation. This federation has two + members, named ALPHA and BETA. Federation members may contain an + arbitrary number of file servers and NSDB nodes; in this illustration + ALPHA and BETA each have three servers and one NSDB node. - Figure Figure 1 shows an example of a federation. This federation - has two members, named ALPHA and BETA. Federation members may - contain an arbitrary number of file servers and NSDB nodes; in this - illustration ALPHA and BETA each have three servers and one NSDB - node. + +----------------------+ +----------------------+ + | Federation Member | | Federation Member | + | ALPHA | | BETA | + | | | | + | | | | + | +------------+ | | +------------+ | + | | NSDB | | | | NSDB | | + | | | | | | | | + | +------------+ | | +------------+ | + | | | | + | | | | + | | | | + | +----------+ | | +----------+ | + | | | | | | | | + | +-- | Servers | | | +-- | Servers | | + | | | | | | | | | | + | +-- | | | | | +-- | | | | + | | | +----------+ | | | | +----------+ | + | | | | | | | | | | + | | +----------+ | | | +----------+ | + | | | | | | | | + | +----------+ | | +----------+ | + +----------------------+ +----------------------+ 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. Figure 1 -4. Purpose +3. Purpose - Our objective is to specify a set of interfaces (and corresponding - protocols) by which such fileservers and collections of fileservers, - with different administrators, can form a federation of fileservers - and NSDB nodes that provides a namespace composed of the filesets - hosted on the different fileservers and fileserver collections. + Our objective is to specify a set of protocols by which fileservers + or collections of fileservers, with different administrators, can + form a federation of fileservers and NSDB nodes that provides a + namespace composed of the filesets hosted on the different + 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 federation. It should also be possible for different fileservers in the federation to project different namespaces and enable clients to traverse them. Such a federation may contain an arbitrary number of NSDB nodes, each belonging to a different administrative entity, and each providing the mappings that define a part of a namespace. Such a federation may also have an arbitrary number of administrative entities, each - responsible for administering a subset of the servers and NSDB nodes. - Acting in concert, the administrators should be able to build 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. + responsible for administering a subset of the fileservers and NSDB + nodes. Acting in concert, the administrators should be able to build + and administer this multi-fileserver, multi-collection namespace. It is not the intent of the federation to guarantee namespace consistency across all client views. Since different parts of the namespace may be administered by different entities, it is possible 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 another entity, has changed. -5. Examples and Discussion +4. Examples and Discussion In this section we provide examples and discussion of the basic operations facilitated by the federated file system protocol: creating a fileset, adding a replica of a fileset, resolving a 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 directory tree. The fileset abstraction is the fundamental unit of data management in the federation. This abstraction is implemented by an actual directory tree whose root location is specified by a fileset location (FSL). In this section, we describe the basic requirements for starting with 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 @@ -231,21 +219,21 @@ location(s) of the implementation of the fileset as FSL(s). There are many possible variations to this procedure, depending on 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 bound to the same FSN. 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. -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 related information 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 latter case is used if the fileset is being restored, perhaps as part of disaster recovery, and the server wishes to specify the FSN in order to permit existing junctions that reference that @@ -254,68 +242,64 @@ At this point, the FSN exists, but its location is unspecified. 3. Send the FSN, the local volume path, the export path, and the export options for the local implementation of the fileset to the NSDB node. Annotations about the FSN or the location may also be sent. The NSDB node records this info and creates the initial FSL for 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 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- - dependent operation (at least at this time). The only interface - required is the ability to register or remove the registration of - replicas for a fileset. + dependent operation (at least at this time). The only requirement is + that these fileset replicas be registered and unregistered with the + NSDB. -5.2. Junction Resolution +4.2. Junction Resolution A fileset may contain references to other filesets. These references are represented by junctions. If a client requests access to a fileset object that is a junction, the server resolves the junction to discover the FSL(s) that implements the referenced fileset. There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary - to perform resolution is represented by the server. In this example, - 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. + to perform resolution is represented by the server. - Step 5 is the only step that interacts directly with the federation - interfaces. The rest of the steps may use platform-specific + Step 4 is the only step that interacts directly with the federation + protocols. The rest of the steps may use platform-specific interfaces. 1. The server determines that the object being accessed is a junction. - 2. The server determines the junction key for the junction. - - 3. Using the junction key, the server does a local lookup to find - the FSN of the target fileset. + 2. Using the junction, 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. - 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 of FSLs. - 6. The server converts the FSL to the location type used by the - client (e.g., fs_location for NFSv4, as described in [RFC3530]). + 5. The server converts one of the FSLs to the location type used by + 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). These steps are illustrated in Figure 2. The client sends request 1 to server X, in federation member ALPHA, in an attempt to reference an object (which appears to the client as a directory). Server X recognizes that the referenced object is actually a junction that refers to a directory in a different fileset. Server X finds, from the FSN in the junction, that the NSDB responsible for knowing the 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 @@ -327,54 +311,74 @@ Given the current requirements and definitions, this resolution 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 the fallback when all else fails (or, for a simple implementation, it could be the only method). This is a degenerate implementation of the NSDB service as a simple composition of NSDB nodes; we expect that large federations will use more sophisticated methods to share 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 -5.3. Junction Creation +4.3. Junction Creation 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 remote export. There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary - to perform resolution is represented by the server. In this example, - 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. + to perform resolution is represented by the server. Step 1 is the only step that uses the federation interfaces. The rest of the steps may use platform-specific interfaces. 1. Contact the server named by the export and ask for the FSN for the fileset, given its path relative to that export. - 2. Create a new local junction key. - - 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 + 2. Insert the junction to the FSN, at the given path, into the local filesystem. -6. Glossary - - The phrase "USING THE FEDERATION INTERFACES" implies that the - subsequent requirement must be satisfied, in its entirety, via the - federation interfaces. +5. Glossary Administrator: user with the necessary authority to initiate administrative tasks on one or more servers. Admin entity: A server or agent that administers a collection of fileservers and persistently stores the namespace information. Client: Any client that accesses the fileserver data using a supported filesystem access protocol. @@ -417,24 +421,20 @@ for a fileset. Two FSLs that implement replicas of the same 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 same. Junction: A filesystem object used to link a directory name in the current fileset with an object within another fileset. The server-side "link" from a leaf node in one fileset to the root of 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 client can observe. NSDB (Namespace Database Service): A service that maps FSNs to FSLs. The NSDB may also be used to store other information, such as annotations for these mappings and their components. 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 (and related info) that implement a given partition of the FSNs. @@ -460,27 +460,31 @@ Server Collection: A set of fileservers administered as a unit. A server collection may be administered with vendor-specific software. The namespace provided by a server collection could be part of the federated namespace. Singleton Server: A server collection containing only one server; a 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 by all entities. We do not address the requirements of the system in the presence of faults. -7.1. Basic Assumptions +6.1. Basic Assumptions Several of the requirements are so fundamental that we treat them as basic assumptions; if any of these assumptions are violated, the rest of the requirements must be reviewed in their entirety. A1: The federation protocols do not require any changes to existing client-facing protocols, and MAY be extended to incorporate new client-facing protocols. A2: A client SHOULD NOT require any a priori knowledge of the @@ -542,52 +546,53 @@ different fileservers in the federation. As such, users may only be able to traverse the parts of the namespace that they have access to. The federation protocols do not impose any restrictions on how users are represented within the federation. For example, a single enterprise could employ a common identity for users across the federation. A grid environment could utilize user mapping or translations across different administrative domains. - A6: In a federated system, we assume that a FSN MUST express, or can - be used to discover, the following two pieces of information: + A6: In a federated system, we assume that an FSN MUST express, or + can be used to discover, the following two pieces of + information: 1. The location of the NSDB node that is responsible for knowing the filesystem location(s) (FSLs) of the named fileset. The NSDB node must be specified because there may be many NSDB nodes in a federation. We do not assume that any single entity knows the location of all of the NSDB nodes, and therefore exhaustive search is not an option. There are several ways in which a fileserver can locate the NSDB node responsible for a given fileset. One approach, given a DNS infrastructure, is to specify the location of the NSDB node by the FQDN of the server hosting the NSDB node. Another approach is to use a separate DNS-style 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 - identify the FSN of the target fileset. + The FSN identifier is the index used by the NSDB node to + 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 [RFC4122]. 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 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 server to contact the NSDB node specified by the FSN in order to 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 "near" the server. A7: All federation servers and NSDB nodes are assumed to execute the federation protocols correctly. The behavior of the federation is undefined in the case of Byzantine behavior by any federation @@ -604,59 +609,47 @@ NSDB node. (It is not necessary that the FQDN always resolve to the same address; the same service may appear at different addresses on different networks.) It is the responsibility of each federation member to ensure that the resources it wishes to expose have accessible network locations and that the necessary resolution mechanisms (i.e., DNS) are given the necessary data to perform the resolution correctly. -7.2. Requirements +6.2. Requirements 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 instance of the fileset it names within the federation at any time. - c. An FSN is a name of a fileset. (An FSL is not the name of - a fileset, but only a locator of an instance of a fileset - at some point in time. For example, the same FSL may - 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. + c. All FSNs MUST be invariant when their underlying + filesystems move or are replicated; only mappings from FSN + to FSL(s) change under these transformations. - e. If the fileset is replicated using the federation - interfaces, then all of the replicas have the same FSN. + d. All files accessible from the global namespace MUST be part + of a fileset that has an assigned FSN. - Not all filesets in the federation are required to have a FSN - or be reachable by a FSL. Only those filesets that are the + Not all filesets in the federation are required to have an FSN + or be reachable by an FSL. Only those filesets that are the target of a junction (as described in R3) are required to have an FSN. - NOTE: this requirement has been called into question. - 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 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 actually been created. It is also possible to bind a nonexistant FSL to an FSN. It is also possible to create a fileset without assigning it an FSN. The binding between an FSN and an FSL is defined entirely within the context of the NSDB; the servers do not "know" whether the filesets they host have been assigned FSNs (or, if so, what those FSNs are). The requirement that filesets can exist prior to being assigned @@ -668,23 +661,23 @@ permit the structure of the namespace to be defined prior to creation of the component filesets. In either case, it is the responsibility of the entity updating the NSDB with FSNs and FSN-to-FSL mappings to ensure that the namespace is constructed in a consistent manner. (The simplest way to accomplish this is to ensure that the FSN and FSN-to-FSL mappings are always recorded in the NSDB prior to the creation of any junctions that refer to that FSN.) 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 - 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 to recreate a lost fileset with a given FSN (for example, as part of disaster recovery). It is an error to assign an FSN that is already in use by an active fileset. Note that creating a replica of an existing filesystem is NOT accomplished by assigning the FSN of the filesystem you wish to replicate to a new filesystem. @@ -739,21 +732,21 @@ An FSN that has been invalidated MAY become valid again if the FSN is recreated (i.e., as part of a disaster recovery process). If an FSN is invalidated, clients who are already viewing the fileset named by the FSN MAY continue to view the old namespace. They might not discover that the FSN is no longer valid until they try to traverse a junction that refers to it. 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 resolving a junction. An FSL that has been invalidated MAY become valid again if the FSL is recreated (i.e., as part of a disaster recovery process). If an FSL is invalidated, clients who are already viewing the fileset implemented by the FSL MAY continue to use that FSL. @@ -762,34 +755,37 @@ implemented by the FSL. Note that invalidating an FSL does not imply that the underlying export or share (depending on the file access protocol in use) is changed in any way -- it only changes the mappings from FSNs to FSLs on the NSDB. R7: It MUST be possible for the federation of servers to provide multiple namespaces. - R8: USING THE FEDERATION INTERFACES, it MUST be possible to perform - queries about the state of objects relevant to the - implementation of the federation namespace. + R8: USING THE FEDERATION INTERFACES: - It MUST be possible to query the fileserver named in an FSL to - discover whether a junction exists at a given path within that - FSL. + a. It MUST be possible to query the fileserver named in an FSL + to discover whether a junction exists at a given path + 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 namespace) MUST be accessible to clients via at least one standard filesystem access protocol. - a. The namespace SHOULD be accessible to clients via the CIFS - protocol. + a. The namespace SHOULD be accessible to clients via versions + of the CIFS (SMB) protocol. b. The namespace SHOULD be accessible to clients via the NFSv4 protocol as described in [RFC3530]. c. The namespace SHOULD be accessible to clients via the NFSv3 protocol as described in [RFC1813]. d. The namespace SHOULD be accessible to clients via the NFSv2 protocol as described in [RFC1094]. @@ -857,26 +853,53 @@ Both FSNs and FSLs may be annotated. For example, an FSN property might be "This is Joe Smith's home directory", and an FSL property might be "This instance of the FSN is at the remote backup site." a. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for a junction. 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 - 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 specific fileserver. In the same manner that clients do not need to have a priori knowledge of the structure of the namespace or its mapping onto federation members, the projected namespace can exist without individual fileservers knowing the entire organizational structure, or, indeed, without knowing exactly where in the projected namespace the filesets they host exist. @@ -904,25 +927,21 @@ the namespace or related data stored in the system (including the creation, renaming, or deletion of junctions, and the creation, altering, or deletion of mappings between FSN and filesystem locations), can be performed in a manner that provides predictable semantics for the relationship between the observed values and the effect of the changes." "It MUST be possible to protect sequences of operations by transactions with NSDB-wide or server-wide ACID semantics." -9. IANA Requirements - - This document has no actions for IANA. - -10. Security Considerations +8. Security Considerations Assuming the Internet threat model, the federated resolution mechanism described in this document MUST be implemented in such a way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY and PEER ENTITY AUTHENTICATION, as described in [RFC3552]. CONFIDENTIALITY may be violated if an unauthorized party is able to eavesdrop on the communication between authorized servers and NSDB nodes and thereby learn the locations or other information about FSNs that they would not be authorized to discover via direct queries. @@ -931,27 +950,31 @@ and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server can masquerade as another server without proper authority, or if an arbitrary host can masquerade as a NSDB node. Well-established techniques for providing authenticated channels may be used to defeat these attacks, and the protocol MUST support at least one of them. For example, if LDAP is used to implement the query mechanism [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 [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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. @@ -960,116 +983,76 @@ (NFS) version 4 Protocol", RFC 3530, April 2003. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, 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 (LDAP): The Protocol", RFC 4511, June 2006. [RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", 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 specification", RFC 1094, March 1989. [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 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 - Daniel Ellard - BBN Technologies - 10 Moulton Street - Cambridge, MA 02138 + James Lentini + NetApp + 1601 Trapelo Rd, Suite 16 + Waltham, MA 02451 US - Phone: +1 617-873-8000 - Email: ellard@gmail.com + Phone: +1 781-768-5359 + Email: jlentini@netapp.com Craig Everhart NetApp 7301 Kit Creek Rd Research Triangle Park, NC 27709 US Phone: +1 919-476-5320 Email: everhart@netapp.com - James Lentini - NetApp - 1601 Trapelo Rd, Suite 16 - Waltham, MA 02451 + Daniel Ellard + BBN Technologies + 10 Moulton Street + Cambridge, MA 02138 US - Phone: +1 781-768-5359 - Email: jlentini@netapp.com + Phone: +1 617-873-8000 + Email: ellard@gmail.com Renu Tewari IBM Almaden 650 Harry Rd San Jose, CA 95120 US Email: tewarir@us.ibm.com Manoj Naik IBM Almaden 650 Harry Rd San Jose, CA 95120 US 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).