draft-ietf-nfsv4-federated-fs-admin-00.txt   draft-ietf-nfsv4-federated-fs-admin-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: Standards Track NetApp
Expires: March 30, 2009 J. Lentini Expires: September 7, 2009 D. Ellard
NetApp BBN Technologies
R. Tewari R. Tewari
M. Naik M. Naik
IBM Almaden IBM Almaden
September 26, 2008 March 6, 2009
Administration Protocol for Federated Filesystems Administration Protocol for Federated Filesystems
draft-ietf-nfsv4-federated-fs-admin-00.txt draft-ietf-nfsv4-federated-fs-admin-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 September 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the administration protocol for a federated This document describes the administration protocol for a federated
file system that enables file access and namespace traversal across file system that enables file access and namespace traversal across
collections of independently administered fileservers. The protocol collections of independently administered fileservers. The protocol
specifies a set of interfaces by which fileservers and collections of specifies a set of interfaces by which fileservers and collections of
fileservers with different administrators can form a fileserver fileservers with different administrators can form a fileserver
federation that provides a namespace composed of the filesystems federation that provides a namespace composed of the filesystems
physically hosted on and exported by the constituent fileservers. physically hosted on and exported by the constituent fileservers.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3. Error Definitions . . . . . . . . . . . . . . . . . . . . . . 5
4. Administrator-Initiated Operations . . . . . . . . . . . . . . 7 4. Administrator-Initiated Operations . . . . . . . . . . . . . . 7
4.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Definition . . . . . . . . . . . . . . . . . . . . . 7
4.2. Required Operations . . . . . . . . . . . . . . . . . . . 8 4.2. Required Procedures . . . . . . . . . . . . . . . . . . . 8
4.2.1. CREATE_JUNCTION . . . . . . . . . . . . . . . . . . . 9 4.2.1. FEDFS_CREATE_JUNCTION . . . . . . . . . . . . . . . . 9
4.2.2. DELETE_JUNCTION . . . . . . . . . . . . . . . . . . . 10 4.2.2. FEDFS_DELETE_JUNCTION . . . . . . . . . . . . . . . . 10
4.2.3. LOOKUP_FSN . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. FEDFS_LOOKUP_FSN . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 14
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 22 9.2. Informational References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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].
2. Introduction 2. Introduction
A federated filesystem enables file access and namespace traversal in A federated filesystem enables file access and namespace traversal in
a uniform, secure and consistent manner across multiple independent a uniform, secure and consistent manner across multiple independent
fileservers within an enterprise (and possibly across multiple fileservers within an enterprise (and possibly across multiple
enterprises) with reasonably good performance. enterprises) with reasonably good performance.
The first requirement of a federated filesystem is the ability to Traditionally, building a namespace that spans multiple fileservers
traverse the data exported by different fileservers without requiring has been difficult for two reasons. First, the fileservers that
a static client configuration. The second requirement is that the export pieces of the namespace are often not in the same
location of the data should be dynamically discovered and the administrative domain. Second, there is no standard mechanism for
discovery process should be transparent to the clients. The third the fileservers to cooperatively present the namespace. Fileservers
requirement is that it should be possible for all clients, with may provide proprietary management tools and in some cases an
sufficient privilege, to view the same namespace regardless of the administrator may be able to use the proprietary tools to build a
fileserver they connect to. shared namespace out of the exported filesystems. Relying on vendor-
proprietary tools does not work in larger enterprises or when
collaborating across enterprises because it is likely that the system
will contain fileservers running different software, each with their
own protocols, with no common protocol to manage the namespace or
exchange namespace information.
Traditionally, fileserver collections are administered by a single The requirements for federated namespaces are described in
entity. Fileservers may provide proprietary management tools and in [FEDFS-REQTS].
some cases an administrator may be able to use the proprietary tools
to build a shared namespace out of the exported filesystems. Relying
on vendor-proprietary tools does not work in larger enterprises or
when collaborating across enterprises because it is likely that the
system will contain fileservers running different software, each with
their own interfaces, with no common protocol to manage the namespace
or exchange namespace information. There may also be independently-
administered singleton servers that export some or all of their
filesystem resources. A filesystem federation protocol enables the
interoperation across multi-vendor fileservers managed by the same
administrative entity, across singleton independent fileservers, and
across independent administrative entities that may manage a
collection of fileservers. The scope of the filesystem federation
protocol is limited to NFSv4 capable fileservers. The support for
NFSv3 fileservers is optional.
The basic requirements for a federated file system protocol are The filesystem federation protocol described in [FEDFS-NSDB] allows
described in IETF draft draft-ellard-nfsv4-federated-fs-reqts, and fileservers from different vendors and/or with different
the current proposed protocol is described in administrators to cooperatively build a namespace.
draft-tewari-nfsv4-federated-fs-protocol. Those drafts are
companions (and essential background material) to this document. This document describes the protocol used by administrators to
Please refer to those documents for the definitions of basic terms configure the fileservers and construct the namespace.
and concepts used in this document.
3. Error Definitions 3. Error Definitions
The results of successful operations will consist of a status of The results of successful operations will consist of a status of
FEDFS_OK. The results of unsuccessful operations will begin with a FEDFS_OK. The results of unsuccessful operations will begin with a
status, other than FEDFS_OK, that indicates the reason why the status, other than FEDFS_OK, that indicates the reason why the
operation failed. operation failed.
Many of the error status names and meanings (and the prose for their Many of the error status names and meanings (and the prose for their
descriptions) are taken from the specification for NFSv4 [RFC3530]. descriptions) are taken from the specification for NFSv4 [RFC3530].
skipping to change at page 7, line 12 skipping to change at page 7, line 12
FEDFS_ERR_SVRFAULT An unanticipated non-protocol error occurred on FEDFS_ERR_SVRFAULT An unanticipated non-protocol error occurred on
the server. the server.
4. Administrator-Initiated Operations 4. Administrator-Initiated Operations
The RPC protocol used by the administration operations is ONC RPC The RPC protocol used by the administration operations is ONC RPC
[RFC1831]. The data structures used for the parameters and return [RFC1831]. The data structures used for the parameters and return
values of these procedures are expressed in this document in XDR values of these procedures are expressed in this document in XDR
[RFC4506]. [RFC4506].
In contrast to earlier designs (which are not described in this
document), the current admin/server interface is very simple. A
server is relatively oblivious to the existence of junctions that
target the filesets it exports: the target server does not play an
essential role in the creation of junctions that reference them.
4.1. Basic Definition 4.1. Basic Definition
We begin by defining basic constants and structs, in XDR notation, We begin by defining basic constants and structures, in XDR notation,
that will be used to specify the types of the RPCs described in the that will be used to specify the types of the RPCs described in the
rest of this subsection. rest of this subsection.
<CODE BEGIN>
enum FedFsStatus { enum FedFsStatus {
FEDFS_OK = 0, FEDFS_OK = 0,
FEDFS_ERR_ACCESS = 1, FEDFS_ERR_ACCESS = 1,
FEDFS_ERR_BADCHAR = 2, FEDFS_ERR_BADCHAR = 2,
FEDFS_ERR_BADXDR = 3, FEDFS_ERR_BADXDR = 3,
FEDFS_ERR_EXIST = 4, FEDFS_ERR_EXIST = 4,
FEDFS_ERR_INVAL = 5, FEDFS_ERR_INVAL = 5,
FEDFS_ERR_IO = 6, FEDFS_ERR_IO = 6,
FEDFS_ERR_NOSPC = 7, FEDFS_ERR_NOSPC = 7,
FEDFS_ERR_NOTDIR = 8, FEDFS_ERR_NOTDIR = 8,
FEDFS_ERR_NOTEMPTY = 9, FEDFS_ERR_NOTEMPTY = 9,
FEDFS_ERR_NOTJUNCT = 10, FEDFS_ERR_NOTJUNCT = 10,
FEDFS_ERR_NOTLOCAL = 11, FEDFS_ERR_NOTLOCAL = 11,
FEDFS_ERR_PERM = 12, FEDFS_ERR_PERM = 12,
FEDFS_ERR_ROFS = 13, FEDFS_ERR_ROFS = 13,
FEDFS_ERR_SVRFAULT = 14 FEDFS_ERR_SVRFAULT = 14
}; };
typedef opaque FedFsFsnUuid<64>; typedef opaque FedFsFsnUuid<16>;
typedef opaque FedFsHostName<128>; typedef opaque FedFsNsdbName<>;
typedef opaque FedFsNsdbName<256>; typedef opaque FedFsPathName<>;
typedef opaque FedFsPathName<1024>;
struct FedFsFsn { struct FedFsFsn {
FedFsFsnUuid fsnUuid; FedFsFsnUuid fsnUuid;
FedFsNsdbName nsdbName; FedFsNsdbName nsdbName;
}; };
struct FedFsCreateJunctionArgs { struct FedFsCreateJunctionArgs {
FedFsPathName path; FedFsPathName path;
FedFsFsn fsn; FedFsFsn fsn;
FedFsUuid junctionKey;
}; };
union FedFsLookupFsnRes switch (FedFsStatus status) { union FedFsLookupFsnRes switch (FedFsStatus status) {
case FEDFS_OK: case FEDFS_OK:
FedFsFsn fsn; FedFsFsn fsn;
default: default:
void; void;
}; };
program FEDFS_PROG { program FEDFS_PROG {
version FEDFS_VERSION { version FEDFS_VERSION {
void NULL(void) = 0; void FEDFS_NULL(void) = 0;
FedFsStatus CREATE_JUNCTION(FedFsCreateJunctionArgs args) = 1; FedFsStatus FEDFS_CREATE_JUNCTION(
FedFsStatus DELETE_JUNCTION(FedFsPathName path) = 2; FedFsCreateJunctionArgs args) = 1;
FedFsLookupFsnRes LOOKUP_FSN(FedFsPathName path) = 3; FedFsStatus FEDFS_DELETE_JUNCTION(
FedFsPathName path) = 2;
FedFsLookupFsnRes FEDFS_LOOKUP_FSN(
FedFsPathName path) = 3;
} = 1; } = 1;
} = 100205; } = 100418;
4.2. Required Operations <CODE END>
There are three operations that servers MUST implement provide in The basic data types defined above MUST be formatted as follows:
order to serve as "internal" nodes in the federated namespace:
NULL The null RPC, which is included, by convention, in every ONC FedFsFsnUuid: A universally unique identifier (UUID) as described in
RPC protocol. [RFC4122] as a version 1 UUID. The UUID should be formatted in
network byte order.
CREATE_JUNCTION Create a new junction from some location on the FedFsNsdbName: A variable length UTF-8 string that represents an
server (defined as a pathname) to an FSN. NSDB's network location in either IPv4, IPv6, or DNS host name
notation.
DELETE_JUNCTION Delete an existing junction from some location on FedFsPathName: A variable UTF-8 string that represents a file system
the server (defined as a pathname). path.
LOOKUP_FSN Query the server to discover the current value of the 4.2. Required Procedures
junction (if any) at a given path in the server namespace.
The CREATE_JUNCTION, DELETE_JUNCTION, and LOOKUP_FSN operations are Fileservers that participate as "internal" nodes in the federated
described in more detail in the following sections. namespace MUST provide these procedures:
Servers that implement "leaf" nodes in the namespace (i.e., servers FEDFS_NULL The null RPC, which is included, by convention, in every
that host filesets that are the target of junctions, but that do not ONC RPC protocol.
contain any junctions) are not required to implement any of these
operations. FEDFS_CREATE_JUNCTION Create a new junction from some location on
the server (defined as a pathname) to an FSN.
FEDFS_DELETE_JUNCTION Delete an existing junction from some location
on the server (defined as a pathname).
FEDFS_LOOKUP_FSN Query the server to discover the current value of
the junction (if any) at a given path in the server namespace.
The FEDFS_CREATE_JUNCTION, FEDFS_DELETE_JUNCTION, and
FEDFS_LOOKUP_FSN operations are described in more detail in the
following sections.
Fileservers that participate as "leaf" nodes in the namespace (i.e.,
fileservers that host filesets that are the target of junctions, but
that do not contain any junctions) are not required to implement any
of these operations.
Note that operations that modify the state of a replicated fileset Note that operations that modify the state of a replicated fileset
MUST result in the update of all of the replicas in a consistent MUST result in the update of all of the replicas in a consistent
manner. Ideally all of the replicas SHOULD be updated before any manner. Ideally all of the replicas SHOULD be updated before any
operation returns. If one or more of the replicas are unavailable, operation returns. If one or more of the replicas are unavailable,
the operation MAY succeed, but the changes MUST be applied before the the operation MAY succeed, but the changes MUST be applied before the
unavailable replicas are brought back online. We assume that unavailable replicas are brought back online. We assume that
replicas are updated via some protocol that permits state changes to replicas are updated via some protocol that permits state changes to
be reflected consistently across the set of replicas in such a manner be reflected consistently across the set of replicas in such a manner
that the replicas will converge to a consistent state within a that the replicas will converge to a consistent state within a
bounded number of successful message exchanges between the servers bounded number of successful message exchanges between the servers
hosting the replicas. hosting the replicas.
4.2.1. CREATE_JUNCTION 4.2.1. FEDFS_CREATE_JUNCTION
This operation creates a junction from a server-relative path to a This operation creates a junction from a server-relative path to a
(potentially) remote fileset named by the given FSN. (potentially) remote fileset named by the given FSN.
We assume that the junction directory on the server is named by a The junction directory on the server is named by a pathname in the
pathname (or other arbitrary UTF-8 string that has a well-defined form of a UTF-8 string that has a well-defined interpretation by the
interpretation by the server). It is not required that this path be server). It is not required that this path be accessible in any
accessible in any other manner (e.g., to a client). This path does other manner (e.g., to a client). This path does not appear in the
not appear in the federated namespace, except by coincidence; there federated namespace, except by coincidence; there is no requirement
is no requirement that the global namespace parallel the server that the global namespace parallel the server namespace, nor is it
namespace, nor is it required that this path be relative to the required that this path be relative to the server pseudo-root. It
server pseudo-root. It does not need to be a path that is accessible does not need to be a path that is accessible via NFS (although the
via NFS (although the junction will be of limited utility if the junction will be of limited utility if the directory specified by the
directory specified by the path is not also accessible via NFS). path is not also accessible via NFS).
If the fileset is read-only, then this operation SHOULD indicate this If the fileset is read-only, then this operation SHOULD indicate this
with a status of FEDFS_ERR_ROFS. with a status of FEDFS_ERR_ROFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
The path is REQUIRED to exist and be completely local to the server. The path is REQUIRED to exist and be completely local to the server.
It MUST NOT contain a junction. If the last component of the path is It MUST NOT contain a junction. If the last component of the path is
a junction (i.e., this operation is attempting to create a junction a junction (i.e., this operation is attempting to create a junction
skipping to change at page 10, line 27 skipping to change at page 10, line 31
the final component. If the path cannot be traversed because of the final component. If the path cannot be traversed because of
insufficient permissions, or the final component is an unexecutable insufficient permissions, or the final component is an unexecutable
or unwritable directory, then the operation MAY fail with status or unwritable directory, then the operation MAY fail with status
FEDFS_ERR_ACCESS. FEDFS_ERR_ACCESS.
The association between the path and the FSN MUST be durable before The association between the path and the FSN MUST be durable before
the operation may return successfully. If the operation return codes the operation may return successfully. If the operation return codes
indicates success, then the caller may assume that the junction was indicates success, then the caller may assume that the junction was
successfully created and is immediately accessible. successfully created and is immediately accessible.
If successful, subsequent references via NFSv4 clients to the If successful, subsequent references via NFSv4 [RFC3530] or NFSv4.1
directory that has been replaced by junction will result in a [NFSv4.1] clients to the directory that has been replaced by the
referral to a current location of the target fileset (as described in junction will result in a referral to a current location of the
draft-tewari-nfsv4-federated-fs-protocol). target fileset [FEDFS-NSDB].
Note that the effective permissions of the directory that is Note that the effective permissions of the directory that is
converted, by this operation, into a junction are the permissions of converted, by this operation, into a junction are the permissions of
the root directory of the target fileset. The original permissions the root directory of the target fileset. The original permissions
of the directory (and any other attributes it might have) are of the directory (and any other attributes it might have) are
subsumed by the junction. subsumed by the junction.
Note that this operation does not create a junction from an arbitrary Note that this operation does not create a fileset at the location
location in the namespace to another location in the namespace. Such targeted by the junction. If the target fileset does not exist, the
an operation can be synthesized from other protocol operations, but junction will still be created. An NFS client will discover the
is not primitive. It cannot be used, for example, to create the missing fileset when it traverses the junction.
initial link to a fileset.
4.2.2. DELETE_JUNCTION 4.2.2. FEDFS_DELETE_JUNCTION
This operation removes a junction specified by a server-relative This operation removes a junction specified by a server-relative
path. path.
As with CREATE_JUNCTION, we assume that the junction on the server is As with FEDFS_CREATE_JUNCTION, the junction on the server is named by
named by a pathname (or other arbitrary UTF-8 string that has a well- a pathname in the form of a UTF-8 string that has a well-defined
defined interpretation by the server). It is not required that this interpretation by the server. It is not required that this path be
path be accessible in any other manner (e.g., to a client). This accessible in any other manner (e.g., to a client). This path does
path does not appear in the federated namespace, except by not appear in the federated namespace, except by coincidence; there
coincidence; there is no requirement that the global namespace is no requirement that the global namespace reflect the server
reflect the server namespace, nor is it required that this path be namespace, nor is it required that this path be relative to the
relative to the server pseudo-root. It does not need to be a path server pseudo-root. It does not need to be a path that is accessible
that is accessible via NFS. via NFS.
If the fileset is read-only, then this operation SHOULD indicate this If the fileset is read-only, then this operation SHOULD indicate this
with a status of FEDFS_ERR_ROFS. with a status of FEDFS_ERR_ROFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
It is NOT REQUIRED that the path used to delete a junction is the It is NOT REQUIRED that the path used to delete a junction is the
same path that was used to create the junction. If the namespace on same path that was used to create the junction. If the namespace on
the server has changed, then the junction may now appear at a the server has changed, then the junction may now appear at a
skipping to change at page 12, line 5 skipping to change at page 12, line 6
The removal of the association between the path and the FSN MUST be The removal of the association between the path and the FSN MUST be
durable before the operation may return successfully. If the durable before the operation may return successfully. If the
operation return codes indicates success, then the caller may assume operation return codes indicates success, then the caller may assume
that the junction was successfully destroyed. that the junction was successfully destroyed.
The effective permissions and other attributes of the directory that The effective permissions and other attributes of the directory that
is restored by this operation SHOULD be identical to their value is restored by this operation SHOULD be identical to their value
prior to the creation of the junction. prior to the creation of the junction.
4.2.3. LOOKUP_FSN 4.2.3. FEDFS_LOOKUP_FSN
This operation queries a server to determine whether a given path This operation queries a server to determine whether a given path
ends in a junction, and if so, the FSN to which the junction refers. ends in a junction, and if so, the FSN to which the junction refers.
Ordinary NFSv4 operations do not provide any general mechanism to Ordinary NFSv4 operations do not provide any general mechanism to
determine whether an object is a junction -- there is no encoding determine whether an object is a junction -- there is no encoding
specified by the NFSv4 protocol that can represent this information. specified by the NFSv4 protocol that can represent this information.
As with CREATE_JUNCTION, we assume that any junction on the server As with FEDFS_CREATE_JUNCTION, the pathname must be in the form of a
can be named by a pathname (or other arbitrary UTF-8 string that has UTF-8 string that has a well-defined interpretation by the server.
a well-defined interpretation by the server). It is not required It is not required that this path be accessible in any other manner
that this path be accessible in any other manner (e.g., to a client). (e.g., to a client). This path does not appear in the federated
This path does not appear in the federated namespace, except by namespace, except by coincidence; there is no requirement that the
coincidence; there is no requirement that the global namespace global namespace reflect the server namespace, nor is it required
reflect the server namespace, nor is it required that this path be that this path be relative to the server pseudo-root. It does not
relative to the server pseudo-root. It does not need to be a path need to be a path that is accessible via NFS.
that is accessible via NFS.
If the path contains an invalid UTF-8 character, then status If the path contains an invalid UTF-8 character, then status
FEDFS_ERR_BADCHAR must be returned. FEDFS_ERR_BADCHAR must be returned.
It is NOT REQUIRED that the path used to lookup a junction is the It is NOT REQUIRED that the path used to lookup a junction is the
same path that was used to create the junction. If the namespace on same path that was used to create the junction. If the namespace on
the server has changed, then a junction may now appear at a different the server has changed, then a junction may now appear at a different
path than where it was created. If there is more than one valid path path than where it was created. If there is more than one valid path
to the junction, any of them may be used. to the junction, any of them may be used.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
remain within the server-local namespace. remain within the server-local namespace.
The server MAY enforce the local permissions on the path, including The server MAY enforce the local permissions on the path, including
the final component. If the path cannot be traversed because of the final component. If the path cannot be traversed because of
insufficient permissions, or the parent directory of the junction insufficient permissions, or the parent directory of the junction
unexecutable or unwritable directory, then the operation MAY fail unexecutable or unwritable directory, then the operation MAY fail
with status FEDFS_ERR_ACCESS. with status FEDFS_ERR_ACCESS.
5. Security Considerations 5. Security Considerations
To be added. The ONC RPC protocol supports authentication, integrity and privacy
via the RPCSEC_GSS framework [RFC2203]. Fileservers which support
the FedFS administration protocol described above MUST support
RPCSEC_GSS.
6. IANA Requirements 6. IANA Requirements
The RPC protocol must be assigned a valid and reserved ONC RPC A range of ONC RPC program numbers were assigned for use by FedFS as
protocol number. described in section 7.3 "Program Number Assignment" of [RFC1831]:
IETF NFSv4 Working Group - FedFS 100418 - 100421
This assignment is recorded in Section 17 "Appendix C: Current number
assignments" of [RFC1831bis].
This document describes version 1 of the ONC RPC program 100418.
7. Conclusions 7. Conclusions
The federated filesystem protocol manages multiple independently The federated filesystem protocol manages multiple independently
administered fileservers to share namespace and referral information administered fileservers to share namespace and referral information
to enable clients to traverse seamlessly across them. to enable clients to traverse seamlessly across them.
8. Glossary 8. Glossary
Administrator: user with the necessary authority to initiate Administrator: user with the necessary authority to initiate
skipping to change at page 17, line 16 skipping to change at page 17, 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 19, line 5 skipping to change at page 19, 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.
9. Normative References 9. References
9.1. Normative 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.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995. Specification Version 2", RFC 1831, August 1995.
[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.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Beame, C., Eisler, M., and D. Noveck, "Network File System Specification", RFC 2203, September 1997.
(NFS) version 4 Protocol", RFC 3530, April 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.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
9.2. Informational References
[FEDFS-NSDB]
J. Lentini, et al., "NSDB Protocol for Federated
Filesystems (Work In Progress)",
draft-ietf-nfsv4-federated-fs-admin , 2009.
[FEDFS-REQTS]
J. Lentini, et al., "Requirements for Federated File
Systems (Work In Progress)",
draft-ietf-nfsv4-federated-fs-reqts , 2008.
[NFSv4.1] S. Shepler, et al., "NFS Version 4 Minor Version 1 (Work
In Progress)", draft-ietf-nfsv4-minorversion1 , 2008.
[RFC1831bis]
Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2 (Work In Progress)",
draft-ietf-nfsv4-rfc1831bis-13 , 2009.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
Appendix A. Acknowledgments
We would like to thank Paul Lemahieu of EMC, Robert Thurlow of Sun
Microsystems, and Mario Wurzl of EMC 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: dellard@bbn.com
Renu Tewari Renu Tewari
IBM Almaden IBM Almaden
650 Harry Rd 650 Harry Rd
San Jose, CA 95120 San Jose, CA 95120
US US
Email: tewarir@us.ibm.com Email: tewarir@us.ibm.com
Manoj Naik Manoj Naik
IBM Almaden IBM Almaden
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. 45 change blocks. 
149 lines changed or deleted 193 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/